No momento, esta página não está disponível em português
Checkout icon

Refund

Refund a payment back to the shopper.

Refund in Customer Area

You can also refund payments in your Customer Area. For more information, refer to Manage payments.

To return funds to your shopper, you can refund the shopper's payment after it has been captured. For example: if a shopper returns an item they purchased, you refund their payment.

When you make a refund request, Adyen attempts to authorize the refund and transfers the funds to the shopper's account. It can take up to 40 business days before the funds are returned to the shopper's account, depending on the payment method.

Requirements

Requirement Description
Integration type An online payments integration.
Webhooks Subscribe to Standard webhooks and listen for webhook messages with the following eventCode values:
Customer Area roles To edit capture settings, make sure that you have the following roles:
  • Merchant admin
  • View Payments
  • Merchant manage payments
Webhooks Subscribe to Standard webhooks.
Limitations You can only refund a payment after it has been captured. If a payment has not been captured, you can cancel it. If you do not know if a payment has been captured, you can instead reverse the payment.

Types of refunds

Type Description
Full refund You refund the full amount of the payment.
Partial refund Supported for some payment methods. You refund a partial amount of the payment. If you make multiple partial refunds, the sum of the refund amounts cannot be more than the captured amount.
Check which payment methods support partial refunds and multiple partial refunds.
Unreferenced refund When you make a refund without a reference (for example, the PSP reference or your order reference) for the payment.

Make a refund

To return funds to the shopper:

  1. From the information of the payment you want to refund, get the PSP reference.

  2. Make a /payments/{paymentPspReference}/refunds request, including the following:

    In your request, include:

    Parameter Required Description
    paymentPspReference
    Path parameter
    -white_check_mark- The PSP reference of the payment. You can find this in the following:
    • The webhook message with eventCode: AUTHORISATION for the payment.
    • In your Customer Area, in the list of payments (Transactions > Payments).
    • If you made a /payments request for the payment, the /payments response.
    merchantAccount -white_check_mark- The name of your merchant account that is used to process the payment.
    amount -white_check_mark- The amount that you want to refund.
    • The value must be the same or, in case of a partial refund, less than the captured amount.
    • The currency must match the currency used in the authorization.
      reference Your reference for the refund, for example to tag a partial refund for future reconciliation. The reference parameter is required for GrabPay refunds.
      merchantRefundReason The reason for the refund request. Possible values:
      • FRAUD
      • CUSTOMER REQUEST
      • RETURN
      • DUPLICATE
      • OTHER
    • When you receive the /payments/{paymentPspReference}/refunds response, note:

      • paymentPspReference: the PSP reference of the authorization you want to refund.
      • pspReference: Adyen's unique reference associated with this refund request.
    • Wait for the REFUND webhook to learn the outcome of the refund request.

    Make an unreferenced refund

    To refund the shopper without the reference for the payment:

    1. From the information of the payment you want to refund, get the PSP reference.
    2. Make a /refunds request, including the following:

      Parameter Required Description
      paymentMethod -white_check_mark- The object with payment method information used to process the original payment.
      merchantAccount -white_check_mark- The name of your merchant account that was used to process the original payment.
      amount -white_check_mark- The amount that you want to refund.
      • For a full refund: The value must be the same as the value of the original payment. The currency value must be the same as the one used in the original payment.
      • For a a partial refund: The value must be less than the value of the original payment. The currency must match the currency used in the authorization.
        shopperReference Your unique reference for the shopper. This should be the same as the one you included in the request to make the original payment.
        reference Your reference for the refund, for example to tag a partial refund for future reconciliation.
        shopperStatement Text that appears on the shopper's bank statement.
        shopperIP The shopper's IP address.
        shopperEmail The shopper's email address.
        billingAddress The shopper's billing address.

      Test failed refunds

      In our test environment, you can check how your integration handles failed refunds:

      1. Make a test card payment, specifying:

        • holderName: refund failed
        {
         "amount": {
           "currency": "EUR",
           "value": 500
         },
         "reference": "Refund failed test",
         "paymentMethod": {
           "type": "scheme",
           "encryptedCardNumber": "test_4111111111111111",
           "encryptedExpiryMonth": "test_03",
           "encryptedExpiryYear": "test_2030",
           "encryptedSecurityCode": "test_737",
           "holderName": "refund failed"
         },
         "returnUrl": "https://your-company.example.com/...",
         "merchantAccount": "YOUR_MERCHANT_ACCOUNT"
        }
      2. Refund this payment, either in your Customer Area, or by making an API request.
        It can take several hours to process your refund request.

      3. Check that you receive a webhook with eventCode: REFUND_FAILED for your test payment.

      Webhooks for refunds

      The refund process is asynchronous. To keep you informed, we send webhook event messages.

      REFUND webhook

      Before we send a refund request to be processed, we perform various validations. If these validations succeed, usually the refund itself also succeeds. You receive the outcome of the validations asynchronously, in a webhook that includes:

      • eventCode: REFUND.
      • pspReference: the pspReference from the response for your refund request.
      • success: indicates the outcome of the refund validations. Possible values:

        • true: Adyen's validations were successful and we sent the refund request to the card scheme. This usually means that the refund will be processed successfully. However, in rare cases the refund can be rejected by the card scheme, or reversed. For information about these exceptions, see REFUND_FAILED webhook, and REFUNDED_REVERSED webhook.

        • false: the refund validations failed. The webhook includes a reason field with a short description of the problem. Review the reason, fix the issue if possible, and resubmit the refund request.

      For more information about the included fields, see the REFUND webhook reference.

      Reasons for failed refund validation

      When our validations of a refund fail, you receive a webhook for the refund with success: false and the reason of the failure. The next table shows the most common reasons.

      Where the table mentions the balance on the payment, this refers to the amount that remains from the original payment. For example, if a transaction has a total of EUR 10 and no refund or chargeback is processed, then the balance on the payment is EUR 10. After a refund or chargeback of EUR 3 is processed, the remaining balance on the payment is EUR 7.

      reason Description
      Requested refund amount too high No chargeback or refund has been processed, and the requested refund amount is more than the balance on the payment.
      Already partially refunded, new requested refund amount too high Partial refund(s) has(/have) been processed, and the requested refund amount is more than the balance on the payment.
      Already partially disputed, new requested refund amount too high Partial chargeback(s) has(/have) been processed, and the requested refund amount is more than the balance on the payment.
      Already fully refunded, no balance available for new requested refund Full refund has been processed, and the remaining balance on the payment is 0.
      Partially refunded and partially disputed, no balance available for new requested refund Partial refund(s) and chargeback(s) have been processed, and the requested refund amount is more than the balance on the payment.
      Partial refund(s) and chargeback(s) have been processed, and the balance on the payment is a negative amount.
      Already fully disputed, no balance available for new requested refund Full chargeback has been processed, and the balance on the payment is 0.
      A full chargeback and partial refund(s) have been processed, and the balance on the payment is a negative amount.
      Insufficient in-process funds on account There is not enough balance on your merchant account to process the refund.
      Transaction hasn't been captured, refund not possible The refund was requested before the transaction was captured. You need to cancel the transaction instead or wait until the transaction is settled.
      The maximum period for this operation has expired The refund was requested past the expiration date permitted by the payment method to process the request.
      Amount too low to be accepted by Card Network The refund amount was too low. The amount must be greater than 0.01 in any currency.
      Modification in different currency than authorisation The refund was requested in a currency different from the currency in which the authorization was made.

      REFUNDED_REVERSED webhook

      For some payment methods, for example bank transfers, iDEAL, or Bancontact, the status of the payment can change from **Refunded** to **RefundedReversed**. This means that the funds have been returned to Adyen, and are back in your account. This can happen, for example, if the shopper's bank account is no longer valid. Before you retry the refund, contact the shopper about the status of their bank account.

      When a refund is reversed, we inform you of this with a webhook containing:

      • eventCode: REFUNDED_REVERSED
      • success: true

      For more information about the included fields, see the REFUNDED_REVERSED webhook reference.

      An overview of reversed refunds is available in your Payment accounting report.

      REFUND_FAILED webhook

      Although rare, a refund can fail after you received a REFUND webhook with success: true. A successful REFUND webhook means that our validations were successful and we sent the refund request to the card scheme. However, the card scheme can still reject the refund. This can happen even a few days after you submitted the refund request.

      Most of the time Adyen can fix the issue, so that the shopper will eventually receive the funds. Sometimes, however, you need to take action yourself. To learn why a refund can fail and what, if anything, you need to do in each case, refer to Failed refunds.

      When a refund fails after you received success: true in the REFUND webhook, we inform you of this with another webhook containing:

      • eventCode: REFUND_FAILED
      • pspReference: the pspReference of the refund request.

      For more information about the included fields, see the REFUND_FAILED webhook reference.

      An overview of failed refunds is available in your Payment accounting report.

      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 2026 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 2026. 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.

      See also