Refunds in Przelewy24 and cancelling in Apilo

A payment refund in Przelewy24 takes one API call from your own system, with nobody logging into the operator's panel. The call is not the hard part. The hard part is what has to happen before it: you have to check that the parcel has not left and cancel the order in the shop. The refund is the only step you cannot undo, so it starts only after those two. Below is the order from our implementation, the four moments of cancellation, and a simulator that lays out that path for your case.

I am writing this while building exactly that path for a B2C shop we are implementing right now. The customer cancels in their own account before the parcel leaves, and the shop checks the shipment in Apilo, cancels the order, requests a refund in Przelewy24 and marks the cancellation in Apilo. The shop has not launched yet, so I am quoting no numbers from that project. I am quoting the decisions, because those travel.

Four moments of cancellation and what you can still do in each

The customer calls and says: "I made a mistake, please cancel it". The first question is not about money, it is about where the parcel is right now. That decides whether you are facing a three-minute process or a three-day one.

The line that cuts this table in half does not run through a system, it runs across the loading bay. While the parcel has not left, everything is reversible except one thing: money already sent. After dispatch the goods become irreversible too, because they come back only as fast as the courier wants. That is why those two worlds are separate in the code: cancellation works only before shipping, and once a parcel is dispatched the shop refuses and points the customer to a product return.

Now the scale. I assume 600 orders a month, as in the other calculations on this blog, and 2 percent cancellations before shipping, which is 12 cases a month. For handling one case by hand I assume 10 minutes: the shop admin, Apilo, the payment panel and the e-mail. Swap both assumptions for your own, because the cancellation rate depends on what you sell and on how fast you ship.

cancellations at 600 orders

12 / mo

by hand, three panels per case

10 min

a month to win back

~1.4 h

I come back to that arithmetic at the end of the post. The minutes are not what matters here; the order in which the steps follow each other is.

The order you must not reverse

In our version a cancellation is one click by the customer in their account and four steps in a fixed order: checking in Apilo whether the parcel has left, cancelling in the shop, requesting the refund in Przelewy24 and marking the cancellation in Apilo. Handled by hand, the reverse order is tempting: a person starts with what matters most to the customer, which is the refund, because they want to say "already done" into the phone.

Checking the parcel goes first and can stop everything. The shop asks Apilo about the shipment at the moment of cancellation instead of trusting what it stored at the last sync. If the order already has a tracking number, the cancellation is refused and the customer is told they can request a return after delivery. If Apilo does not answer, the cancellation is refused too, with a request to try again in a moment. Guessing at this point costs the value of the basket.

Cancelling in the shop goes second. It changes the order status, puts the goods back on sale and sends the customer an e-mail saying the money will go back the same way they paid.

The refund goes third, because it is irreversible and must not start without the two previous steps. You cannot call back a refund once it is requested. If a minute later it turns out the parcel did leave after all, you have neither the goods nor the money, and what is left is a phone call asking the customer to pay again.

The Apilo status goes last: a cancellation and a note for the warehouse not to ship. In the automation only a fraction of a second separates it from the refund, so the order of the third and fourth steps starts to matter only when one of them fails.

This is the most important decision on the path: a failure in the third or fourth step does not undo the cancellation. The customer already has the e-mail and the goods are back on sale, so undoing it would cause more confusion than the failure itself. Instead, support gets an e-mail listing what could not be finished. The refund is then requested with a button in the shop admin or directly in Przelewy24. The Apilo status has to be changed by hand straight away, because the refund may already have gone out while the warehouse still sees an order to pack.

A payment refund in Przelewy24 from the inside

The instruction itself is simple: you say which payment the refund is for, pass the amount and your own request id, and the operator replies that it has accepted the request. The interesting part is four things that are easy to forget on the first attempt.

A partial refund is a separate decision, even though it is the same call. The customer drops one of three items because they picked the wrong size, and the rest is meant to ship. A smaller amount is all it takes, but from that moment you have a partially refunded order that carries on living. If your data model only knows "refunded" and "not refunded", this is where it falls apart, not on the amount. In the shop we are building, the customer can cancel only the whole order on their own, and dropping a single item goes through support.

Check until when the operator accepts a refund for a given payment. The deadline depends on the operator and your contract, so I am not going to put a number of days here. Check it once and write it into your instructions, because after it what is left is an ordinary transfer from the company account, with an account number taken from the customer. That is a completely different process: it needs a human, a sign-off and a record of who approved it.

An accepted request is not yet money in the customer's account. Straight away the operator confirms only that it has accepted the request. It carries out the refund on its own side, and the result shows up in the Przelewy24 panel. The customer calls exactly in that window: on your side the refund is requested, on theirs there is nothing. That is why the e-mail says what to expect, not just "refund completed".

A refund request can fail. The operator may reject it or not answer. For us such a failure does not undo the cancellation; it sends support an e-mail with the order number and what to do by hand. That e-mail catches failures at the request, and what happens to the refund afterwards shows up in the Przelewy24 panel. Without a notification like that, a failed refund is one operation among hundreds of successful ones, and you will hear about it from the customer two weeks later. It is the same mechanism I described with prices from several sources: data nobody has marked as authoritative always ends up lying in somebody's favour.

Lay out your own path and take the procedure away

Below is the same process in a form you can write out for your own shop. You set the order state, the payment method, the document and the tracking number, and the simulator lays out the order of the steps in three systems, marks the irreversible one and lists what stays with a human. At the bottom it builds text ready to paste into your instructions.

Cancelling a paid order / Paid, not picked yet / BLIK / Sales document: None / Tracking number: Not issued

01. [Apilo] Apilo: check whether the order already has a tracking number, right now rather than at the last sync. If Apilo does not answer, do not guess; try again in a moment.
02. [Shop] Shop: cancel the order. The goods go back on sale and the customer gets an e-mail saying the money will go back the same way they paid, within a few working days.
03. [Human] There is no document, so there is nothing to correct. Just check that the automation does not issue one along the way.
04. [Przelewy24] Przelewy24: request the refund. Straight away the operator confirms only that it accepted the request, not that the customer already has the money. If the request fails, do not undo the cancellation; request the refund by hand.
    Note: BLIK: the money goes back to the account at the bank whose app confirmed the payment, so you need no bank details from the customer.
05. [Apilo] Apilo: set the cancelled status and add a note telling the warehouse not to ship. If Apilo does not accept the change, make it by hand straight away, because the refund has already gone and the warehouse still sees an order to pack.
06. [Shop] Shop: leave in the order history who cancelled and when, plus the refund id from Przelewy24. A month later that is the only place you will find it.

Stays with a human:
- A refund that could not be requested and a cancellation Apilo did not accept. The automation writes to support, and a human takes it from there.
- A request to refund to an account other than the one the payment came from. We deliberately leave this alone, because this is where fraud starts.

As you change the order state, two things show up. The irreversible step never comes before the parcel check: before shipping it follows the cancellation in the shop, and after shipping it waits until the goods are back in the warehouse. And for a dispatched or delivered order there are more steps, half of them belonging to a human, because there is no sensible way for automation to judge the condition in which goods came back.

The sales document and the e-mail to the customer

The money has gone back, but the books still show a sale that never happened. With an invoice the road is known: a credit note for the amount that actually returns, issued on the side of the trading system, not in the payment panel. With a cash receipt the rules are different and have changed more often than we managed to write down, so settle them once with your accountant and check the current legal position.

We treat the e-mail to the customer as part of the process, not as a courtesy. In our version it goes out together with the cancellation in the shop and says four things: which order was cancelled and for what amount, that the goods will not ship, that the money will go back the same way the customer paid, and that the refund can take a few working days depending on the bank. Without that last piece you get a phone call on the third day, which is exactly the window where the refund is requested on your side and the customer's side shows nothing yet.

What stays with a human, and deliberately so

On this path, where not to write code matters more than the code. Five things stay with a human, and I do not treat any of them as a backlog item for the next stage.

1. 01A cancellation when the parcel already has a tracking number. The automation asks Apilo and refuses once there is a tracking number. Whether the box can still be stopped is something only a person in the warehouse can judge, and automation must not guess.
2. 02A request to refund to a different account than the one the payment came from. Technically trivial, in practice the simplest way to walk money out of a shop. The automation refunds only the same way the money came in, and the exception stays a human decision permanently.
3. 03A refund that could not be requested, and a cancellation Apilo did not accept. The automation knows it failed and writes to support with a list of steps. From there a human takes over.
4. 04Judging the condition of returned goods. Whether they came back complete and fit for resale. A photo from the warehouse does not replace the decision, and the decision has financial consequences.
5. 05A refund past the operator's window. An ordinary transfer from the company account, with an account number from the customer and a sign-off from whoever approved it. This is an outgoing payment, not the reversal of an incoming one.

A list of exceptions like that is a healthy sign in a project, not a failure. We automate what happens the same way every time, not what merely looks similar. There is more on where that line falls and how to draw it at your own company on the page about process automation.

What it really removes and when it is worth building

At 12 cancellations a month and 10 minutes per case, handling this by hand takes about 2 hours a month. After automation the customer clicks on their own, and support steps in when it gets an e-mail about a step to do by hand or when the customer asks something. I cautiously assume 3 minutes per case for that. So there is about 1.4 hours a month to win back, or just under 17 hours a year.

You cannot build a business case for an implementation on that number and I am not going to try. The business case sits on the risk side: one mistake in the order means goods that went out to a customer who already has their money back, which is a loss equal to the basket value, not to a few minutes. The second thing is the calm of the support team: a procedure where nobody has to remember the order does not wear people down on a Friday afternoon.

That is why a path like this is worth building as part of something larger rather than on its own. For us it is part of the shop, not a separate project. The mechanism is the same as with sales documents for a seller on five Amazon EU marketplaces, where 100 percent of invoices are created with no manual work and the implementation took 3 weeks: automatic VAT invoices. And the same one that tied four systems together at a B2B appliance wholesaler: a B2B platform with Subiekt nexo. The common denominator: one place where the order of the steps is written down, and one place where you can see what happened.

If you want to translate this to your own shop, write out your current path with the simulator above and compare it with what support actually does. The difference between those two lists is your scope. If it comes out as more than a few fixes, the next step is an audit for PLN 699 net: a document with the architecture, the scope, the risks, a fixed price and a deadline, deducted in full from the implementation price. What automation like this costs in total is written up in a separate post on costs.