Refunds across local payment methods: what each one supports

A returns policy is usually written once, for cards. Then the checkout adds Pix, OXXO, SPEI, a local wallet and a buy now, pay later option, and the same policy quietly stops being true. Some of those methods refund in minutes, some only in full, some only within a fixed window, and some cannot refund at all because the customer paid in cash at a shop counter.

This article is a method-by-method reference for refunds: which methods support them, whether partial refunds work, how long you have, how long the customer waits, and how to reconcile the result. The general rule that refunds go back to the original payment method, and why money going out is harder than money coming in, is covered in why payouts are harder than payments. Here we go one level deeper, method by method.

Which local methods support refunds?

Support is a property of the method and of the provider that processes it. The same method can be refundable through one provider and not through another, and documentation sometimes disagrees even within one provider. The table below summarises what provider documentation said when we checked it in October 2026.

Method type	Example	Refund through the method?	Partial refunds	Window at one provider
Cards	Visa, Mastercard, mada	Yes, or a reversal if very recent	Yes	Set by the provider and scheme
Instant payment	Pix	Yes, to the paying bank account	Yes	90 days (Stripe)
Cash voucher	OXXO, Boleto	No; separate transfer or payout	Depends on the fallback	Not applicable
Bank transfer	SPEI, bank transfers	Yes, usually needs bank details	Often	Varies
Direct debit	SEPA Direct Debit	Yes	Yes	180 days (Stripe)
Wallet or super app	Kaspi, Mercado Pago	Yes	Yes	365 days Kaspi (Antom), 180 days Mercado Pago
BNPL	Klarna, Tabby	Yes; instalments are adjusted	Yes	180 days (Stripe for Klarna; Tabby)

Two cautions apply to every row. First, the window shown is one provider’s rule, not the method’s. Second, “yes” means the provider accepts the request; it does not mean the customer has the money. Stripe’s Pix documentation makes the point directly: a successful refund request or an early status update is not, by itself, proof that the customer’s account has been credited.

How do card refunds differ from reversals?

A card payment can be undone in three ways, and they look different to the customer. Adyen’s documentation separates them clearly: a cancel is for a payment that has not been captured, a refund is only possible after capture, and a reversal is for when you do not know which state the payment is in. If it has not been captured, the reversal cancels it; if it has, the reversal refunds it.

Timing matters too. Stripe says refunds issued shortly after the original charge can appear as a reversal instead of a refund, so the original charge drops off the customer’s statement and no separate credit is issued. That is the cleanest outcome for the customer, and Stripe notes that reversals usually incur lower network fees than refunds. Our glossary entry on authorization reversal explains the terms.

Card refunds are also authorized now, like payments. Visa told acquirers that from 18 April 2020 all merchants globally must send purchase return authorization messages, with airlines and mass transit merchants optional. The same Visa notice allows a refund to a different Visa account in two cases: the original account is no longer available or valid, for example a replaced or discarded card, or the issuer declined the refund authorization. It also recommends that merchants using Visa Account Updater include accounts to be refunded in their update file.

Refunds can still fail after they have been accepted. Adyen sends a REFUND_FAILED webhook when the card scheme rejects a refund that first looked successful, and says this can happen days later.

What happens with Pix refunds?

Pix is the easy case, which is why it is a useful benchmark. Stripe’s documentation says a Pix refund can be requested within 90 days of the original payment, supports full and partial amounts, returns the money to the bank account used for the payment, and usually reaches the customer within a few minutes, without a guaranteed maximum. Pix refunds cannot be cancelled once sent.

Mercado Pago’s documentation follows the same logic for its own checkout: card refunds go to the card statement, while methods such as Pix return the amount to the payer’s account. The practical consequence is that a Pix refund rarely needs customer data. The weak point is the 90-day window at that provider: a return processed late, for example on a long warranty, has to become a bank payout instead.

Why do cash vouchers need bank details?

Because nobody holds an account on the other side. A customer who paid an OXXO voucher at a shop counter, or a Boleto at a bank branch or authorized agency, gave the merchant cash and no account to send it back to.

Provider documentation is blunt about this:

• OXXO. Stripe says OXXO payments cannot be refunded and that merchants who want to allow refunds must create a separate process to credit customers. dLocal’s Mexico page says offline OXXO refunds are available through payout links, enabled by its team.
• Boleto. Stripe’s Boleto page marks refunds as unsupported, while its general refund guide lists Boleto among the methods where it emails the customer for bank account details before it can refund. Read both kinds of statement as the same thing: the refund is a bank transfer, not a voucher reversal.
• Collecting the details. Ebanx’s refund guide lists the fields it accepts, including bank name, branch, account number, account type, and the holder’s name and tax document, and says this option is available in its cross-border model in Brazil, Chile, Colombia and Mexico. When a refund is pending, Ebanx emails the customer to ask for bank information.

The design lesson is to decide the fallback before launch. For Mexico, a SPEI transfer to the customer’s own account is the usual answer; for Brazil, a Pix transfer. Either way it is a payout, with name checks, not a refund call.

How do bank transfer and direct debit refunds work?

Bank transfers. dLocal lists refunds as supported for SPEI in Mexico, and its refunds documentation says cash and bank transfer refunds require a payout to the customer and always return a pending status on the first response. If the beneficiary details are missing or invalid, dLocal emails the customer for name, bank, account number, account type and branch. Stripe’s bank transfer documentation describes the same pattern: to refund to the customer’s bank account it needs the account details, sometimes received with the incoming transfer, otherwise collected by email.

SEPA Direct Debit. Stripe says SEPA Direct Debit payments can be refunded for up to 180 days, in full or in part, that refunds typically take 3 to 4 business days to process, and that funds arrive within 5 business days. It also warns about double credits: the customer can dispute a debit through their bank on a no questions asked basis for eight weeks, and a proactive refund does not stop that dispute. Tell the customer you are refunding, and refund after the original payment has settled.

What about wallets and BNPL?

Wallets and super apps usually refund cleanly because the customer has an account. Antom’s documentation lists Kaspi with partial refunds and a 365-day refund period. Mercado Pago allows refunds within 180 days of approval, accepts partial amounts, and requires enough available balance in the merchant’s account, otherwise the refund is not completed. Smaller wallets vary more; check each provider’s rules for cancellation versus refund and for partial amounts.

BNPL refunds change a loan, not just a payment. Stripe’s Klarna documentation says charges can be refunded up to 180 days after payment, that Klarna cancels remaining instalments on a refunded charge, that refunds usually take 5 to 7 business days, and that a payment escalated to a dispute cannot be refunded. Tabby’s documentation sets a 180-day limit from payment creation and explains that a partial refund reduces the remaining instalments first, returning part of the down payment only when the refund exceeds them.

How long does the customer wait?

Expectations follow the fastest method the customer has used, so publish the realistic time per method rather than one number.

Rail	Typical time to the customer	Source
Pix	Usually within a few minutes	Stripe
SEPA Direct Debit	Within 5 business days	Stripe
Klarna	Usually 5 to 7 business days	Stripe
Cards	About 5 to 10 business days after issue	Stripe
Some local methods	Up to 40 business days	Adyen

For cards, Stripe says an acquirer reference number can take up to 7 business days to arrive and is not available for a reversal. Give it to the customer when you have it: it is the reference their bank can trace.

Worked example: one returns policy, five methods

Example figures, for illustration only.

A store selling into Mexico and Brazil processes 1,000 refunds a month: 400 on cards, 250 on Pix, 150 on SPEI, 120 on OXXO and 80 on Boleto.

Method	Refunds	Path	Needs customer bank details
Cards	400	Refund or reversal	No
Pix	250	Refund to paying account	No
SPEI	150	Transfer back	Sometimes
OXXO	120	SPEI payout	Yes
Boleto	80	Pix or bank payout	Yes

Up to 350 refunds, 35% of the total, depend on the customer answering an email with correct account details. If one in ten of those details bounce on the first try, 35 refunds a month come back, each a support contact. Collecting a verified payout account when the customer chooses a cash voucher, rather than when the refund starts, removes most of that work.

How do you reconcile refunds across methods?

Each provider reports refunds in its own states. Stripe uses requires_action, pending, succeeded, failed and canceled. Adyen sends REFUND, then REFUND_FAILED if the scheme rejects it, and REFUNDED_REVERSED when a bank transfer refund returns. Ebanx moves from requested to pending to confirmed, and dLocal from pending to success or rejected.

1. Map every provider’s states to one model: requested, waiting for customer, in progress, completed, failed, returned.
2. Close the refund only on a final status received by webhook, never on the API response.
3. Treat a returned refund as a new task, not a retry: contact the customer, fix the details, then send a payout.
4. Use an idempotency key on every refund request, so a timeout does not refund twice.
5. Watch the balance per provider. Stripe holds card refunds as pending when the balance is short but fails refunds on other methods; Mercado Pago does not complete the refund at all.

What are the common mistakes?

• Promising partial refunds on a method that only supports full ones.
• Letting a late return run past the provider’s window, then discovering the original rail is closed.
• Asking a cash-voucher customer for bank details only when the refund is due.
• Refunding a direct debit or card payment that the customer is already disputing, and paying twice.
• Marking a refund complete when the provider accepted it, not when it reached the customer.

Where does Omno fit?

Refunds through Omno are not available yet; they are on the roadmap. What Omno does today is the payment side: one API in front of many providers, routing rules you set, and cascading, so if a provider is unavailable or rejects the request, the payment moves to the next provider in the rule until one accepts. The transaction trail shows every attempt, provider response and webhook, which tells your support and finance teams which provider took each payment before they refund it, and the final status of every payment arrives by webhook. The payment orchestration page shows how providers are configured.