Sample Refund Flows

This article shows how to handle refund flows when implementing a Refund Transaction endpoint. For general information about this endpoint, see Processing Refunds.

The Payment Provider Platform supports these refunds flows:

• Wix-initiated refunds
• Payment Service Provider (PSP)-initiated refunds

Refunds can be full or partial but cannot exceed the original payment amount.

The following sections include examples of each refund flow. These examples are based on the Refund Transaction request body and the Submit Event request body. The values in these examples are fake. Examples are applicable for both live and sandbox modes.

Wix-initiated refunds

Here are some examples of Wix-initiated refunds flows:

Successful full refund

1. Wix calls Refund Transaction to initiate a full refund for 10 USD. The request body looks like this:
   Copy

2. The PSP responds with an HTTP status code of 200 and this JSON object:
   Copy

3. The PSP sends this webhook to Submit Event. Note that the amount field is a string:
   Copy

4. Wix marks the payment as refunded and responds with an HTTP status code of 200 and an empty JSON object.

Successful partial refund

Requests for partial refunds are handled the same way as requests for full refunds. If Wix initiates a partial refund, the PSP can initiate another partial refund for the same payment.

1. Wix calls Refund Transaction to initiate a partial refund for 5 USD. The request body looks like this:
   Copy

2. The PSP responds with a HTTP status code of 200 and this JSON object:
   Copy

3. The PSP sends this webhook to Submit Event. Note that the amount field is a string:
   Copy

4. Wix marks the payment as partially refunded and responds with an HTTP status code of 200 and an empty JSON object.
   At a later point, the merchant can request another partial refund.

Failed refund

When a refund attempt fails, the PSP must respond with the appropriate reason code. For a list of reason codes, see Reason Codes. The following example is relevant for both full and partial refunds.

1. Wix calls Refund Transaction to initiate a full refund for 10 USD. The request body looks like this:
   Copy

2. The PSP responds with an HTTP status code of 200 and a JSON object that includes "reasonCode": 3025. This reason code indicates that the refund failed because of insufficient funds. The errorCode and errorMessage fields include PSP-specific data.
   Copy

3. The PSP sends this webhook to Submit Event. Note that the amount field is a string:
   Copy

4. Wix does not update the payment status and responds with an HTTP status code of 200 and an empty JSON object.

PSP-initiated refunds

PSP-initiated refunds don't involve the Refund Transaction endpoint. Instead, the PSP sends a webhook to Submit Event to notify Wix about the refund. The following examples show how to handle PSP-initiated refunds.

Successful full refund

1. A merchant successfully refunds a 10 USD payment through the PSP's platform.
2. The PSP sends the following webhook to Submit Event:
   Copy

3. Wix marks the payment as refunded and responds with an HTTP status code of 200 and an empty JSON object.

Successful partial refund

Requests for partial refunds are handled the same way as requests for full refunds. When a PSP initiates a partial refund, Wix can initiate another partial refund for the same payment.

1. A merchant successfully refunds 6 USD out of a 10 USD payment through the PSP's platform.
2. The PSP sends the following webhook to Submit Event:
   Copy

3. Wix marks the payment as partially refunded and responds with an HTTP status code of 200 and an empty JSON object.