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.

Types of Refunds

Type	Description
Full Refund	A Full Refund returns the entire payment amount to the customer for a settled sale.
Partial Refund	A Partial Refund returns a partial amount of a settled sale. If you make multiple partial refunds, the sum of the refund amounts cannot be more than the captured amount.

How it Works

To create a refund, you submit a new transaction with a negative amount.

Make a POST request to the checkout/v3/payment/{id} endpoint using the parameters below. Specify the refund amount as a negative numberin the request body.

Parameter	Required	Description
`amount`	✓	The amount to refund, specified as a negative value in USD. Example, `"amount"= "-15.00"`
`merchantId`	✓	The Merchant's unique identifier.
`tenderType`	✓	Set to `Card` for card transactions.
`paymentToken`	Recommended	The secure token from the original settled payment. Including this makes the refund a Referenced Refund.
`originalId`	Recommended	The `id` of the original payment. Recommended for direct association.
`cardAccount`		Valid Payment Card details or a vaulted Card token. Only required for Standalone Refunds where a `paymentToken` or `originalId` is not provided.

ℹ️
Refunds with surcharge: If the original transaction included a card surcharge, PCE automatically calculates the applicable surcharge amount for the refund. Initiate only the base refund amount as a negative value. You do not need to pass additional surcharge parameters or calculate the surcharge amount yourself.

Once the payment request is submitted, our system performs a series of system-level validations before sending the transaction to the card network. These validations check for:
1. Missing or invalid required fields
2. Incorrect parameter formats or values
3. Merchant configuration or permission issues. If any validation fails, the request is rejected immediately, and an error response is returned. You must correct the issue and resubmit the request. For a complete list of validation errors and how to resolve them, refer to the System Error Codes guide.
If all system-level validations pass, 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 the status and responseCode fields in the response.
1. status: The primary outcome of the transaction, either Approved or Declined.
2. 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 theid. 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 GET request to the /checkout/v3/paymentrelated?id={id} endpoint. You must provide the id of the original sale transaction as a query parameter.

Best Practices

Practice	Recommendation
Prefer Referenced Refunds	Always link refunds to the original transaction using the `paymentToken` or `originalId`. This prevents refunding more than the original amount and automates reconciliation.
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: Refund: the refund status is updated
Test your integration	Use our provided Test Card Data to safely test all payment scenarios, including declines and errors, in our sandbox environment.