# Refunds
source: https://developer.mastercard.com/ob-accept-payments/documentation/payments/refunds/index.md

The functionality available in Refunds depends on the Market / Payment Rails and additional Services that you signed with us. For example, we will only execute the refund when you have signed up for a Mastercard Settlement Account. In all other cases, we will return the PSU source account used in the original payment so that you can initiate the refund outside of this solution. Please [contact us](https://openbankingeu.mastercard.com/contact-us) to learn how you can benefit from a Mastercard Settlement Account and the payment rails it currently supports.

Given the dual-use nature of this API, detailed step-by-step guides are provided below to demonstrate how the Refund API can be implemented for each supported scenario:

* [Step-by-step guide to fetch the PSU's account details which can be used to issue a refund outside of the Mastercard Open Finance Pay solution.](https://developer.mastercard.com/ob-accept-payments/tutorial/obtain-psu-source-account/index.md)
* [Step-by-step guide to issue a refund to a PSU using a Mastercard Settlement Account.](https://developer.mastercard.com/ob-accept-payments/tutorial/make-a-refund/index.md)

Note: We depend on the ASPSPs to provide us with the details of the Source Account the PSU selected during the payment flow. This does not happen reliably in all markets. Where possible, we provide alternative ways for capturing the PSU account through an AIS (Account Information Service) flow. Please find more details on this in the steps below.

### Pre-conditions {#pre-conditions}

Ensure the following pre-conditions are met before proceeding:

* You have been set up with access to the Refunds endpoint as part of the Integrator Onboarding.
* You have the `paymentId` for the original payment made to one of your (Merchants) destination accounts.
* The original payment is in at least **PAYMENT_EXECUTED_CREDITED** status when you are using a Mastercard Settlement Account, or at least in **INITIATED** status when you do not.
* The refundSupport flag was set to TRUE as part of the respective Merchant's onboarding details.
* A decision has been made to refund the original payment either in full or partially, with a clear reason for the refund. The list of supported refund reasons are explained below.
* The refund **amount** for each specific refund request and the cumulative amount of all refunds made for a specific payment cannot exceed a threshold (percentage of the original payment) based on your agreed terms and conditions.
* The **currency** of the refund matches the currency of the original payment. For example, for a payment made with UKFasterPayments, the currency needs to be "GBP".

Consider using one of the following reasons for refunds:

|      **Reason**       |                                  **Description**                                  |
|-----------------------|-----------------------------------------------------------------------------------|
| DISPUTES              | The refund is made as a result of a Dispute.                                      |
| DUPLICATE_ORDER       | The Merchant charged the Consumer twice by accident.                              |
| GOODS_NOT_RECEIVED    | The Consumer did not receive the goods.                                           |
| GOODS_RETURNED        | The goods were returned by the Consumer.                                          |
| LATE_CONFIRMATION     | Confirmation of the payment was late, and the merchant did not fulfill the order. |
| MERCHANT_OUT_OF_STOCK | The Merchant has charged the Consumer but it is out of stock.                     |
| ORDER_CANCELLED       | The Consumer cancelled the order.                                                 |

### STEP 1 - Authenticate with the API {#step-1---authenticate-with-the-api}

To use the API, you need to be authenticated with the service. You will need to make sure that you are using the **ob_accept_payments** scope in the request body when Authenticating. Refer to [Authentication](https://developer.mastercard.com/ob-accept-payments/documentation/developer-support/api-basics/authentication/index.md) for detailed instructions regarding how you can authenticate with the service.

### STEP 2 - Call the Create payment refund endpoint {#step-2---call-the-create-payment-refund-endpoint}

Call the following endpoint and provide all required parameters (please see the pre-conditions section above for more details).

Please use the `paymentId` of the original payment as `{payment_id}` path parameter.

API Reference: `POST /payments/{payment_id}/refunds`

As part of the logic for this endpoint, we will:

* Validate the request. (see pre-conditions above)
* Verify if the Payment Rail, including the PSU Source Account, is available for the original payment.
* If you signed up for a Mastercard Settlement Account, we will execute the refund and capture the payment status from the bank.
* Otherwise, we will enable you to retrieve the Payment Rail and PSU Source Account information. (see the steps below)
* If the Payment Rail and PSU Source Account are not available, we will update the Refund status accordingly.

For some markets/payment rails, we will enable you to engage the PSU in an AIS flow to capture their account. (see the steps below)

In response, you will obtain a `refundId`, which you will need to use at the next step to view the refund's status.

### STEP 3 - Call the Get refund endpoint {#step-3---call-the-get-refund-endpoint}

Call the following endpoint. Use the `refundId` obtained from the previous step as `{refund_id}` path parameter.

API Reference: `GET /refunds/{refund_id}`

This will return the details of the created refund request, including the refund status.

|        **Status**         |                **Scope**                |                                                                                       **Description**                                                                                       |
|---------------------------|-----------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| PREPARING                 | All requests.                           | The refund request details have been captured and it is ready to be processed.                                                                                                              |
| PAYMENT_RAILS_AVAILABLE   | All requests                            | The refund cannot be executed, but the source account is available. The source account details are provided as a set of payment rails so that the client can execute the refund themselves. |
| PAYMENT_RAILS_UNAVAILABLE | All requests                            | The refund cannot be executed and the source account cannot be obtained. Consider starting a flow for collecting the source account of the payment.                                         |
| COLLECTING_SOURCE_ACCOUNT | All requests                            | The source account used to make a payment was unavailable and a source account collection was started. The status will change once the source account collection succeeds or times out.     |
| PENDING                   | Only for Mastercard Settlement Accounts | The refund is being processed by our settlement account provider.                                                                                                                           |
| PAYMENT_EXECUTED_DEBITED  | Only for Mastercard Settlement Accounts | The payment has been settled and debited from the settlement account.                                                                                                                       |
| FAILED                    | Only for Mastercard Settlement Accounts | The refund failed.                                                                                                                                                                          |

### STEP 4 - Call the Get refund payment rails endpoint {#step-4---call-the-get-refund-payment-rails-endpoint}

This endpoint returns the Payment Rail and the PSU Source Account details we have identified for the original payment.

This can only be called if the Get refund endpoint (see step 3 above) returned the refund status as PAYMENT_RAILS_AVAILABLE.

Use the `refundId` obtained from step 2 as `{refund_id}` path parameter.

API Reference: `GET /refunds/{refund_id}/payment-rails`

Note: **Polymorphic models** The response models are polymorphic, with a different response for each payment rail. For example, the UkFasterPayments rail will return the **sort code** , **accountNumber** and **accountName** , while GermanSepaCreditTransfer will return the **IBAN**

### STEP 5 - Call the Collect refund source account endpoint {#step-5---call-the-collect-refund-source-account-endpoint}

This endpoint enables you to engage the PSU in an AIS flow to capture their account. Note: This flow is currently not supported for payments made with the UKFasterPayments rail.

You can only call this if the refund has the status PAYMENT_RAILS_UNAVAILABLE. This happens when we cannot identify the PSU original payment's PSU Source Account.

Call the following endpoint with all required parameters. Use the `refundId` obtained from step 2 as `{refund_id}` path parameter.

API Reference: `POST /refunds/{refund_id}/payment-rails`

This will return a **flowUrl** where you need to send the PSU to start the flow. Ensure that the flow is started before the expiryDate specified in the request.

This flow will require the PSU to go through an SCA with the ASPSP, select their account and authorize the account information request so that we can obtain the account details.

Once the flow is completed, we will redirect the PSU back to you on the **redirectUrl** specified in the request.

After that, you can go back and re-iterate from step 3.