A refund returns funds to the cardholder as a new transaction in the opposite direction. Use it for product returns and as the fallback when a same-day reversal is refused — the decision table lives in Reversing a transaction.
The request
A refund is a standard payment with PaymentType: "Refund":
"PaymentRequest": {
"PaymentData": {"PaymentType": "Refund"},
"PaymentTransaction": {"AmountsReq": {"Currency": "EUR", "RequestedAmount": "11.99"}},
"SaleData": {"OperatorID": "Cashier_01", "SaleTransactionID": {"TimeStamp": "...", "TransactionID": "2001"}}
}It follows the full payment lifecycle — 202, polling, cardholder presents their card, 200 with a PaymentResponse. Because it is a new transaction it gets its own POITransactionID; store it like any payment's.
Rules that matter
- Amount: a refund can be partial — refund only what is returned. It does not have to match any original transaction, because the protocol does not link it to one.
- Business controls are yours: since the protocol does not enforce a link to an original sale, preventing over-refunding (refunding more than was paid, or twice) is POS-side logic. Certification expects your POS to have a coherent policy here.
- Card presence: the cardholder presents the card being credited — a refund is a card transaction like any other.
Reversing a refund
A refund, being a normal transaction, can itself be reversed same-day: send a Reversal referencing the refund's POITransactionID. This is the correction path for "cashier refunded the wrong amount".
Related
- Reversing a transaction — reversal-vs-refund decision and the credit fallback that lands here.
- Taking a payment — the lifecycle a refund shares.