Unreferenced refund

To return funds to a shopper after a payment is Approved, you need to refund the payment. Unreferenced refunds let you return any amount to any card presented to the payment terminal. But you need to manually reconcile those refunds.

If you are using unreferenced refunds, we highly recommend that you ensure your POS app can reconcile a refund against the original purchase. This reduces the risk of return fraud (a payment being refunded multiple times), and human error (store staff enter the wrong refund amount).

Also consider checking beforehand if the card that the shopper presents to the terminal is the same card that was used for the original payment. To do so, you need to implement card acquisition and save the card alias of all transactions. See card acquisition before refunding.

Enable unreferenced refunds

Before you make unreferenced refunds, contact our Support Team team and ask them to:

• Enable unreferenced refunds for your merchant account.

  Due to anti-money laundering and payment industry regulations, it is not always possible to enable unreferenced refunds.

• (Optional) Set a refund delay, so you have time to cancel an unreferenced refund when necessary.

Make an unreferenced refund

1. Make a POST request to a Terminal API endpoint, specifying:

   • MessageHeader: the standard SaleToPOIRequest.MessageHeader object. Specify:

     Parameter	Required	Description
     ProtocolVersion		3.0
     MessageClass		Service
     MessageCategory		Payment
     MessageType		Request
     ServiceID		Your unique ID for this request, consisting of 1-10 alphanumeric characters. Must be unique within the last 48 hours for the terminal (POIID) being used.
     SaleID		Your unique ID for the POS system component to send this request from.
     POIID		The unique ID of the terminal to send this request to. Format: [device model]-[serial number].

   • PaymentRequest: the request body. Specify:

     Parameter	Description
     SaleData.SaleTransactionID	An object with: TransactionID: your unique reference to identify the refund. Your Customer Area and Adyen reports show this ID as the merchant reference for the transaction. If the original payment was an offline payment, you can make reconciliation easier by including the tender reference of the offline payment. TimeStamp: Date and time of the refund in UTC format.
     PaymentTransaction.AmountsReq	An object with: Currency: The transaction currency. RequestedAmount: The amount being refunded to the card.
     PaymentData.PaymentType	Refund

   The following example shows how to refund EUR 10.99 to a card.

2. Let the shopper complete the transaction on the terminal. The terminal prompts the shopper to present their card, and then shows Approved.

3. When you receive the PaymentResponse, note the following:

   • Response.Result: Success. This means we received your request. Usually, the refund is processed asynchronously.

     Whether the refund is processed synchronously or asynchronously depends on the card scheme and the country where the card is used. If processed synchronously, you get the acquirerResponseCode in the AdditionalResponse.

   • POIData.POITransactionID.TransactionID: the transaction identifier for this refund request, in the format tenderReference.pspReference.
   • PaymentReceipt: the generated receipt data. This includes transaction_type_refund.
   • SaleData.SaleTransactionID.TransactionID: the reference you provided in the request.
   • Response.AdditionalResponse with:
     • transactionType: REFUND
     • posAuthAmountValue: the refund amount (in minor units) that we try to get authorized.
     • pspReference: the PSP reference for this refund request.
     • acquirerResponseCode: if this field is included, the request was processed synchronously. The value Approved means the refund is approved.

4. Wait for the REFUND_WITH_DATA webhook to learn the outcome. If successful, the refund is issued to the shopper's account.

See also