Refund
Return funds securely with sale-referenced or adhoc refunds
A refund is used to return funds to a customer for a transaction that has already settled. You can issue a refund for the full captured amount or for a partial amount. You can issue multiple partial refunds, but their combined total cannot exceed the original captured amount.
Refund vs. Void: A refund is used for transactions that have settled (i.e., funds have been transferred to your account). If a transaction has been authorized but not yet settled, you should perform a Void instead to cancel it.
When you initiate a refund, funds are transferred from your merchant account back to the customer’s original payment method. Before processing, an authorization check is performed with the card issuer to ensure the customer's account is still valid.
Key information on Refunds
| Feature | Description |
|---|---|
| Timing | Can only be performed on settled transactions. If the payment hasn't settled, you must void it. |
| Reference | We strongly recommend linking a refund to the original transaction (Referenced Refund) to prevent errors and simplify reconciliation. Unlinked refunds (Standalone Refunds) are also possible. |
| Processing Time | May take 3–10 business days to appear on a customer’s statement, depending on the issuing bank. |
Create a Refund
To create a refund, you submit a new transaction with a negative amount.
- Make a
POSTrequest to thecheckout/v3/payment/{id}endpoint using the parameters below. Specify the refund amount as a **negative number **in the request body.
Parameter | Required | Description |
|---|---|---|
| ✓ | The amount to refund, specified as a negative value in USD.
Example, |
| ✓ | The Merchant's unique identifier. |
| ✓ | Set to |
| Recommended | The secure token from the original settled payment. Including this makes the refund a Referenced Refund. |
| Recommended | The |
| Valid Payment Card details or a vaulted Card token. Only required for Standalone Refunds where a |
- After the request, use the GET
/checkout/v3/payment/{id}endpoint to check the refund payment's details and status. - Our system will processes the refund and returns a response indicating the outcome. You can learn the outcome of the request via
GET /checkout/v3/payment/{id}or wait for the Refund webhook. You can determine the result by checking thestatusandresponseCodefields in the response.status: The primary outcome of the transaction, either Approved or Declined.responseCode: A detailed code explaining the reason for the status. See our comprehensive Response code guide for full list.
- For every approved refund, it is critical to store the
id. This is unique Refund ID. Use this for retrieving or voiding the transaction before it settles.
Viewing Refund History for a Payment
To reconcile your records or view all refunds associated with a specific sale, you can retrieve a list of all linked transactions.
- Make a
GETrequest to the/checkout/v3/paymentrelated?id={original-id}endpoint. You must provide theidof the original sale transaction as a query parameter.
Best Practices
Practice | Recommendation |
|---|---|
Prefer Referenced Refunds | Always link refunds to the original transaction using the |
Communicate with Customers | Inform customers that refunds can take 3-10 business days to process. This manages expectations and reduces chargebacks and support inquiries. |
Use Webhooks | Stay informed about the refund status asynchronously by subscribing to these webhooks:
|
Test your integration | Use our provided Test Card Data to safely test all payment scenarios, including declines and errors, in our sandbox environment. |
Updated 19 days ago