Skip to main content
Tonder’s refund functionality enables merchants to return funds to customers for card transactions. You’ll use this when you need to process customer returns, cancellations, or any situation requiring payment reversal. Refunds are processed through the same unified /process/ endpoint using operation_type: "refund".
Refunds are only available for card payments. SPEI, OXXO Pay, and Mercado Pago transactions cannot be refunded.

Prerequisites

Important limitations
  • Refunds work exclusively with credit and debit card transactions.
  • Each transaction can only be refunded and in full.
  • Refunds must be processed within 29 days after payment confirmation.

Processing a Refund

The refund process involves preparing your request data, sending it to the API, and handling the response appropriately.

Step 1: Make the Refund Request

Gather the required information and send your refund request to the Process Transaction endpoint. You’ll need four essential fields: The amount field determines whether you’re processing a partial or full refund. You can refund any amount up to the original transaction value. Make your request to the Process Transaction endpoint with your refund data. Here’s how to do it using cURL:

Step 2: Handle the Response

Upon successful request, the API will return an immediate acknowledgment. Here you find a description of the fields in the response:
In this example, the refund has been processed successfully. Always check the status field in your response and implement appropriate logic based on the status value received. After receiving the response, save the transaction ID from the id field to monitor progress.
Validation of id and status fieldsFor proper refund validation, you must check the id and status fields:
  • id is the unique transaction identifier - store this for future reference.
  • status indicates the current refund state - use this to determine next steps.
The table below details the fields that are returned in the response:

Step 3: Handle Errors

Handle common refund errors by checking the response status and error messages. Here’s a Python example that demonstrates proper error handling:
This example demonstrates comprehensive error handling for refund operations. The code follows these key principles:
  1. Prevents hanging requests with a 30-second timeout.
  2. Checks for successful 201 responses.
  3. Catches network and request errors.
  4. Returns consistent success/error objects.
  5. Provides clear status messages for debugging.
These complete implementations show how to integrate refund processing into your application with both partial and full refund capabilities. The implementations follow these steps:
  1. Set up base URL and authentication.
  2. Structure the refund data payload.
  3. Make the POST request with proper headers.
  4. Process success and error responses.
  5. Implement partial vs full refund logic.

Troubleshooting

Check the following common errors and how to resolve them:
This error occurs when attempting to refund a transaction that has already been refunded (partial or full).
To solve this issue, remember that each transaction can only be refunded once. Keep a local record of refunded transactions to avoid duplicate attempts and always check the transaction status before initiating a refund.
This error occurs when the refund amount exceeds the original transaction amount.
To solve this issue, ensure the refund amount is less than or equal to the original payment amount. Always validate refund amounts against original transaction amounts before sending requests and implement proper validation logic in your application.
This error occurs when the original transaction cannot be found or is not eligible for refunds.
This can happen due to an invalid transaction ID, attempting to refund non-card payments (SPEI, OXXO Pay, or Mercado Pago), transactions older than 120 days, or incomplete transactions. To solve this, verify the transaction ID is correct and ensure the transaction is a completed card payment within the refund window.
This error occurs when experiencing request timeouts, connection refused, or other network-related exceptions.To solve this issue, implement retry logic with exponential backoff for network-related failures and always use appropriate timeout values (recommended: 30 seconds) in your HTTP requests. This ensures your application can handle temporary network issues gracefully.

Next Steps

Now that you can process refunds, consider these next steps to enhance your payment system:
  • Set up webhooks to receive real-time notifications when refund statuses change, ensuring your system stays synchronized with payment updates.
  • Implement proper logging and audit trails for refund operations to maintain compliance and help with customer service inquiries.
  • Consider integrating refund functionality into your customer-facing interfaces to allow self-service refund requests.