Terminal-2 icon

Refund a payment

Learn how to issue a point of sale refund.

Not refunding point-of-sale payments often?

To return funds to a shopper after a payment is Approved, you need to refund the payment.

We offer two refund types:

  • Referenced refund: a ReversalRequest. Referenced refunds are connected to the original payment using the unique identifier of that payment. This unique identifier includes the tender reference and/or the PSP reference

  • Unreferenced refund: a PaymentRequest with PaymentType Refund. Unreferenced refunds let you return any amount to any card presented to the terminal. For example, you can issue a refund to someone who did not make the original payment, such as a gift recipient.

You can implement one or both refund types.

When you initiate a refund, the amount is deducted from your in-process funds.

Referenced and unreferenced refunds

The following table compares some aspects of the two refund types.

Feature Referenced refund Unreferenced refund
Reconciliation Simple: match the refund against a payment using the PSP reference Manual process
Return fraud risk Low: a payment cannot be refunded multiple times, or for more than 100% of the original amount Risk of refunding the same payment multiple times, and of human error (for example, wrong amount )
Refund to QR code wallet Supported Not supported
Omnichannel refunds Supported, using the PSP reference Not supported
Processing Asynchronous Asynchronous or synchronous, depending on card scheme and country/region

Referenced refunds are always processed asynchronously. The Terminal API response only confirms we received the request. After the refund is processed, we inform you of the result through refund webhooks. It can take up to 40 business days for the funds to be returned to the shopper's account, depending on the payment method.

Unreferenced refunds can be processed synchronously. This is automatic and depends on the card scheme and the country/region where the card is used. If processed synchronously, you get the acquirerResponseCode field in the response which indicates whether the refund is approved.

Allowed refund method

In general, you can use any refund method you like—referenced or unreferenced. There are some limitations though, depending on the payment method and the transaction routing.

Payment method

  • Refunding BankAxept payments requires an additional contract with the BankAxept scheme and is only possible in stores where the shopper has made a purchase.

  • The following card schemes only support unreferenced refunds:

    • Dankort
    • Interac

Transaction routing

Your payment terminals support both credit and debit cards. Depending on the transaction routing, a debit card is processed either through a debit network like Maestro, Interac, and Pulse, or through a credit network like MasterCard and Visa.

  • All credit networks are dual-messaging, meaning that you can issue a referenced refund against an existing transaction.
  • Some debit networks are single-messaging, meaning that a referenced refund is not possible and you must use an unreferenced refund instead.

To determine the allowed refund method, keep track of the paymentMethodVariant in the payment response. This field returns the network through which the transaction was routed. Keep in mind that the routing is independent of the funding source of the card. To determine whether the card itself is a credit, debit, or prepaid card, check the fundingSource. By keeping track of the fundingSource along with the paymentMethodVariant you can determine both the type of card and the routing, and use the correct refund method.

Refund authorization

Refund authorization means that before processing a refund, Adyen checks with the issuer if the shopper's card or account is valid. This happens automatically; you do not have to ask for this in your refund request.

Adyen supports this for:

  • American Express
  • Discover
  • Mastercard
  • Visa

As soon as the issuer authorizes the refund, the refund is visible on the shopper's account. This improves customer satisfaction and reduces the number of questions from shoppers about their refund. Also, there are less refund-related chargebacks because issuers usually return the funds to the shopper sooner.

Issuers can decline a refund authorization for reasons like:

  • Lost or expired card
  • Invalid card number
  • Closed account
  • Suspected fraud

When a refund authorization is declined, we still try to process the refund.

Pilot to prepare for 2025 changes

Adyen is currently running a pilot where declined refund authorizations are handled differently:

  • We do not proceed with the refund. In your Customer Area, the transaction status remains Settled.
  • We inform you of the reason for the declined refund authorization in the REFUND, CANCEL_OR_REFUND, and REFUND_WITH_DATA webhooks. The reason parameter in the webhook will a have a value of Authorisation for refund failed with response code followed by the raw response we received.

This improved transparency about the status of a refund enables you to take action sooner, so you can return the funds to the shopper in some other way.

The behavior described above will become the default in 2025. If you want to prepare for that and participate in this pilot, reach out to your Adyen contact or to our Support Team. Note that some card networks charge a refund authorization fee.

Next steps