Article
Payment Gateways in Mexico: 3DS, Installments, Chargebacks
How to choose and build ecommerce payments in Mexico: gateway, 3-D Secure, interest-free installments (MSI), chargebacks and the Adobe Commerce integration.

On this page
- Who's who in an online card payment
- Which payment methods an ecommerce in Mexico needs, and what each one implies
- Interest-free installments: how they work and what they really cost
- 3-D Secure: when to request authentication without losing the sale
- Why cards get declined, and what actually raises the approval rate
- Chargebacks and fraud: how disputes work in Mexico
- How payments integrate with Adobe Commerce
- Reconciliation and invoicing: where payment ends and finance begins
- Common mistakes when implementing payments
- How we do it at WolfSellers
- Frequently asked questions about payment gateways in Mexico
- Which payment gateway is best for an ecommerce in Mexico?
- Should I use an aggregator or a direct merchant account with a bank?
- Who pays for interest-free installments, the customer or the merchant?
- Is 3-D Secure mandatory in Mexico?
- How long does a chargeback take in Mexico?
- Can I store my customers' cards for future purchases?
- Does Adobe Commerce include a payment gateway for Mexico?
- Related services
In Mexican ecommerce, payment is the step where you lose the sale you had already won. The customer picked the product, entered an address and reached the final button. If the card gets declined at that moment, if the interest-free installments they expected don't show up, or if their bank's authentication challenge fails, the purchase collapses at the most expensive point of the funnel. And it rarely shows up in reports: analytics records an abandoned cart, not an issuer decline.
Volume makes the topic matter more every year. According to the 2026 Online Sales Study by AMVO (Mexico's online sales association), ecommerce in Mexico reached 941 billion pesos, with 77.2 million digital buyers, growing 25 times faster than GDP. At that scale, one point of payment approval stops being a technical detail and becomes a line on the income statement.
That is why we treat payments as architecture, not as a plugin installed at the end of a project. The gateway you choose determines which methods you can offer, how much PCI DSS compliance work lands on you, how deposits reconcile with your ERP and how well you can fight a chargeback. At WolfSellers we implement Adobe Commerce (formerly Magento) for brands selling in Mexico, and payment integration is one of the pieces with the biggest impact on conversion and on finance operations. If you are a US or Canadian brand selling into Mexico, this is also where most of the local surprises live.
This guide covers how the payment stack fits together, what each method Mexican shoppers expect implies technically, how interest-free installments and 3-D Secure really work, what moves the approval rate, how chargebacks are handled and how it all integrates with Adobe Commerce. For the broader market picture —platforms, logistics, marketplaces— see our guide to ecommerce in Mexico.
One caveat up front: we are not going to name a winning gateway, because there isn't one. The right choice depends on your payment method mix, your volume, your average order value and what you negotiate with each provider. What does exist is an orderly way to decide.
Who's who in an online card payment
When a customer pays by card on your site, at least five parties are involved in those two or three seconds. Knowing them prevents the most common confusion in selection meetings: comparing "gateways" that actually do different things.
| Party | What it does | Who chooses it |
|---|---|---|
| Issuer | The customer's bank. Approves or declines the charge and decides whether to request extra authentication | The customer |
| Card network | Visa, Mastercard or American Express. Routes the transaction and sets dispute rules | Nobody in particular: it comes with the card |
| Acquirer | The bank that receives funds on the merchant's behalf and answers for it to the network | The merchant, by contract |
| Gateway or processor | Connects your checkout to the acquirer, tokenizes the card and exposes the API your store uses | The merchant |
| Aggregator (payfac) | Gives you access to acquiring under its own merchant account: fast onboarding in exchange for less control | The merchant, as an alternative to a direct merchant account |
| Orchestrator | Optional layer that routes each payment across several gateways and retries when it makes sense | The merchant, usually at high volume |
The distinction that moves the most money is aggregator versus direct merchant account. With an aggregator you onboard in days, with standard fees and no bank negotiation; it is the natural way to start. With a direct account at an acquirer you negotiate rates, control how your name appears on the customer's statement and get a direct line when something breaks. As volume grows, the question stops being "which gateway" and becomes "which acquirer, on what terms and with what backup".
Which payment methods an ecommerce in Mexico needs, and what each one implies
Mexican shoppers don't pay by card alone, and each method has different consequences for integration and operations. The table summarizes what changes for your team:
| Method | What it implies for the integration | Operational watch-out |
|---|---|---|
| Credit and debit cards | Online authorization, 3-D Secure and tokenization for repeat purchases | Approval rate and chargebacks |
| Interest-free installments (MSI, meses sin intereses) | Checkout must identify the card's issuing bank to offer only the terms that apply | Financing cost absorbed by the merchant |
| Cash at convenience stores (references such as OXXO Pay) | The order is created as "pending payment" with an expiring reference; confirmation arrives later via webhook | How long you hold inventory and when you cancel expired orders |
| SPEI bank transfer | A reference or CLABE account number per order; asynchronous confirmation | Reconciliation, especially when the customer transfers a different amount |
| Wallets (Mercado Pago, PayPal, Apple Pay, Google Pay) | Provider flow via redirect or SDK, with its own tokens | Refunds and disputes under each wallet's rules |
| Buy now, pay later (BNPL) | Redirect to the lender, which approves the credit on its own | Higher fees and reconciliation with a third party |
The asynchronous methods —cash and transfers— cause the most implementation problems, because they break the assumption that an order is born paid. Decide three things before switching them on:
- How long you hold inventory while the customer goes to pay. If you don't hold it, you sell units you don't have; if you hold it too long, you block stock another customer would have paid for.
- What happens when the reference expires. In Adobe Commerce, the reference's validity must line up with the Pending Payment Order Lifetime setting; if they don't match, you get canceled orders that were later paid.
- What you tell the customer between purchase and payment: the reference, the deadline and a reminder before it expires.
Interest-free installments: how they work and what they really cost
Interest-free installments (meses sin intereses, MSI) are the signature payment promotion of Mexican commerce. For the customer, they mean paying monthly at no extra cost. For the merchant, they mean absorbing the financing cost: in the most common setup, the acquirer settles the full sale amount minus a fee that grows with the term, and the issuing bank bills the customer in monthly installments.
That fee is why MSI should not be switched on across the whole catalog by reflex. These are the decisions we make with each client:
- Which terms to offer (3, 6, 9, 12, 18 months) and the minimum order amount for each.
- Which products to exclude, usually low-margin ones where the fee eats the profit.
- Which banks participate. Not every issuer has agreements for every term, and checkout must read the card's first digits (the BIN) to show only the options that actually apply. Offering 18 months and declining it at the end is worse than not offering it.
- When to run them. Seasons like Hot Sale and El Buen Fin usually bring special campaigns with the banks, with their own rules and dates that are best loaded as scheduled promotions, not by hand the night before.
Two details that surface late if you don't plan for them:
- Showing MSI before checkout. The monthly price on the product page and in the cart is part of the purchase decision in high-ticket categories such as electronics, furniture or appliances. If customers only discover installments at the last step, they have already left.
- Partial refunds on MSI are more complex than on a one-time charge, because the bank has to adjust the remaining installments. Agree with your acquirer on how they are processed before launch, not when the first return arrives.

3-D Secure: when to request authentication without losing the sale
3-D Secure is the protocol merchants and issuing banks use to exchange information and confirm that the person paying is the cardholder. The current version, EMV 3-D Secure, is maintained by EMVCo —the card networks' technical body— and has two paths:
- Frictionless flow: the issuer assesses risk in real time using data the merchant sends (device, history, amount) and approves authentication without bothering the customer.
- Challenge flow: the issuer asks the customer for extra proof, such as an SMS code or a confirmation in their banking app.
The first generation of 3-D Secure was a password pop-up many customers couldn't remember, which is where its bad reputation for conversion comes from. Version 2 sends the issuer far more data, so a larger share of transactions authenticates without a challenge. But challenges still happen, and in Mexico the experience varies widely between banks: some confirm in their app, others by SMS, and when the message doesn't arrive the sale is lost.
The other half of the equation is liability. Broadly, and depending on each network's rules, when a transaction is authenticated with 3-D Secure the liability for certain fraud chargebacks shifts to the issuer; when you don't authenticate, you keep it. Check what your acquirer contract says exactly, because that is where it is decided who pays when a customer disputes a charge.
That is why neither "3-D Secure on everything" nor "3-D Secure on nothing" is a good policy. What we recommend is risk-based authentication:
- Request 3-D Secure on first purchases, above a certain amount or in fraud-prone categories (electronics, gift cards, easily resold items).
- Let repeat customers with a tokenized card and a good history through without a challenge, where the acquirer allows it.
- Use your fraud signal: if the model flags medium risk, authenticate instead of declining.
- Measure the challenge funnel by issuing bank: how many transactions get challenged, how many complete it and how many abandon. Without that data, 3-D Secure debates get settled by opinion.
Why cards get declined, and what actually raises the approval rate
Not all declines are equal. The issuer's response code separates two families:
- Soft declines: insufficient funds, issuer fraud suspicion, temporary errors or card limits. Some can be retried or resolved by requesting authentication.
- Hard declines: card reported stolen, canceled or nonexistent. Retrying doesn't help, and the networks also have rules against excessive retries.
What moves the approval rate, in the order we usually tackle it:
- Send complete data with the authorization. Name, email, address, IP and device data help the issuer decide. A minimal integration that only sends the card number and amount gets declined more.
- Process locally. Mexican cards tend to approve better with a Mexican acquirer than in a cross-border transaction processed abroad. On top of that, interest-free installments with Mexican banks require local acquiring —a key point for foreign brands entering Mexico.
- Network tokenization for stored cards. With Visa and Mastercard network tokens, the token keeps working when the bank replaces a card, so repeat purchases and subscriptions fail less often on expired cards.
- Smart retries, for soft declines only, with clear rules on how many times and how often.
- Routing across acquirers. If you have two, send each payment through the one that approves that issuer best. That is the main use case for an orchestrator, and it makes sense when volume justifies the complexity.
- A recognizable descriptor. If the charge appears on the statement under a name the customer doesn't recognize, calls to the bank, preventive card blocks and "I don't recognize this charge" chargebacks all go up.
And what to measure to know whether it's working: approval rate by issuer, method, device and amount, separating declines that come from the bank from those generated by your own fraud rules. It is common to discover that a significant share of "declines" isn't coming from the bank at all, but from the store's own fraud rule.
Chargebacks and fraud: how disputes work in Mexico
A chargeback happens when the cardholder disputes a charge, their bank reverses it and the acquirer bills it back to the merchant. In Mexico, the consumer side is well defined. According to Condusef, Mexico's financial consumer protection agency, when a customer reports an unrecognized charge the bank must credit the amount within 48 hours while it investigates, and the investigation can take up to 45 days; if the bank doesn't respond within that period, the claim is deemed valid.
For the merchant, that means the money leaves fast and your defense depends on the evidence you have ready. Chargebacks fall into three groups:
| Type | What happened | How to prevent or fight it |
|---|---|---|
| True fraud | Someone used a stolen card | Fraud screening, 3-D Secure and review of risky orders |
| Friendly fraud | The customer did buy, but disputes the charge | Clear descriptor, email confirmations, proof of delivery |
| Commercial dispute | The order didn't arrive, arrived incomplete or damaged | Tracking, proof of delivery, a clear returns policy and fast support |
The evidence that wins disputes is the evidence captured automatically: the 3-D Secure authentication result, the purchase IP and device, delivery confirmation with signature, photo or geolocation, the customer's history and communications. If that information lives in five different systems, nobody will pull it together in time. And time matters: the acquirer gives you a short window to respond to each dispute, and if you don't respond you lose by default.
On fraud screening, a balance worth keeping in mind: an overly strict filter also costs money. Every legitimate order you decline is a lost sale and a customer who probably won't come back. The combination that tends to work best is simple rules for the obvious cases —attempt velocity, serious mismatches, unusual amounts—, a scoring model for the rest and manual review only for the gray zone.
Finally, the networks run monitoring programs for merchants with high chargeback rates, with fines and, in extreme cases, the risk of losing the merchant account. Give the topic an owner before your acquirer reminds you.

How payments integrate with Adobe Commerce
Adobe Commerce offers several ways to connect a gateway, and the one you choose determines two things at once: the customer experience and how much PCI DSS compliance work lands on you. Adobe's own payments guidance frames it this way:
| Integration type | What your server sees | Typical PCI scope | Experience |
|---|---|---|---|
| Hosted payment page (redirect) | Nothing from the card | The smallest | The customer leaves your site to pay |
| Hosted fields or iframe | Nothing: the provider captures and tokenizes | SAQ A or SAQ A-EP, depending on the implementation | The customer pays without leaving your site |
| Direct API | The full card number | SAQ D, the most demanding | Full control, maximum compliance burden |
The final classification is determined by a Qualified Security Assessor (QSA), not by the provider or the integrator. We cover it in detail, including what PCI DSS 4.0 changed for payment pages, in our article on PCI DSS 4.0 for ecommerce.
Other architecture decisions we make on every project:
- Adobe Payment Services or a local gateway. Payment Services is Adobe's payment solution for Adobe Commerce, and its compatibility documentation lists Mexico among the countries with full support. Still, check which local methods it covers for your case: Adobe's own guidance recommends third-party gateways when local method coverage falls short for a market. In Mexico that tends to happen with cash payments at stores, SPEI or bank-specific MSI promotions.
- Stored cards as tokens, never in your database. Adobe Commerce can store payment methods for repeat purchases, always through the gateway's token. The card number must never touch your tables.
- Idempotent, signed webhooks. Asynchronous payments are confirmed by provider notification. If your endpoint doesn't validate the signature and can't tolerate receiving the same notification twice, you end up with paid orders stuck in "pending" or, worse, duplicates.
- Authorize and capture at the right moment. Authorizing at order creation and charging at fulfillment protects the customer when stock is missing, but authorizations expire. If your fulfillment is slow, decide whether you capture immediately or re-authorize.
- More than one gateway only when justified. A second gateway for backup or issuer-based routing improves availability and approval, at the cost of more complex reconciliation and refunds, which must go back through the original gateway. On Adobe Commerce as a Cloud Service, Adobe's reference architecture uses API Mesh as the routing layer across gateways.
- Payment scripts and checkout security. Every provider script running on the payment page falls under the inventory PCI DSS 4.0 requires. It pays to know which ones they are before going live.
Reconciliation and invoicing: where payment ends and finance begins
The work doesn't end when the customer sees "order confirmed". On the finance side, three processes start that the integration has to support:
- Reconciliation. The acquirer deposits in batches, net of fees, installment fees and chargebacks. Matching order, transaction and deposit requires every order to store the transaction ID and the provider's reports to load into the ERP without manual re-keying.
- Invoicing. In Mexico, how the payment is recorded shapes the CFDI e-invoice. We explain it in the CFDI 4.0 section of our guide to integrating Adobe Commerce with an ERP.
- Refunds. A card is refunded through the same channel; a cash or transfer payment is not, and requires asking the customer for bank details. That flow must exist before the first return.

Common mistakes when implementing payments
- Choosing a gateway on fees alone. One more point of approval is usually worth more than a few cents off the rate.
- Turning on 3-D Secure for everything, or for nothing. Both positions cost money: one in conversion, the other in fraud.
- Not holding inventory for cash payments, or holding it forever.
- Webhooks without idempotency or signature validation.
- Not measuring approval by issuing bank, which is where the real problems show up.
- Storing card data in the store database, even "temporarily".
- A generic descriptor the customer doesn't recognize on their statement.
- Nobody owning chargebacks. Without an owner, disputes are lost by default.
How we do it at WolfSellers
When a client asks us to integrate payments into Adobe Commerce, we start with the numbers, not the gateway: average order value, method mix, volume by bank, current approval rate and chargeback cost. With that we define the selection criteria and compare them against the options on the market, with no commission from any provider involved.
Then we integrate with the architecture that minimizes PCI scope, instrument the payment funnel —approval by issuer, 3-D Secure challenges, declines from your own fraud rules— and connect reconciliation to the ERP. If you're already live and suspect the problem is in payments, a funnel diagnosis usually finds it within a few weeks. You can tell us about your case or review our Adobe Commerce implementation service.
Frequently asked questions about payment gateways in Mexico
Which payment gateway is best for an ecommerce in Mexico?
There is no single answer, because it depends on your method mix and your volume. These are the criteria we use to decide: whether it processes locally through a Mexican acquirer, which methods it covers (cards, bank-specific interest-free installments, cash at stores, SPEI, wallets), what type of integration it offers and how that affects your PCI scope, how it handles 3-D Secure, what tools it provides for disputes and fraud, what reports it delivers for reconciliation and how good its support is when something breaks on a Friday night during El Buen Fin.
Should I use an aggregator or a direct merchant account with a bank?
An aggregator is the fastest way to start: you onboard in days and don't negotiate with a bank. A direct account with an acquirer takes more paperwork, but lets you negotiate rates, control how your name appears on the customer's statement and get a direct line when something fails. Many companies start with an aggregator and move to a direct account when their volume justifies it.
Who pays for interest-free installments, the customer or the merchant?
In the most common setup, the merchant does. The customer pays in interest-free monthly installments, and the acquirer settles the full sale amount to the merchant minus a fee that grows with the term. That is why it makes sense to set minimum amounts, exclude low-margin products and offer long terms only where the sale justifies it.
Is 3-D Secure mandatory in Mexico?
More than a universal obligation, 3-D Secure determines who bears the cost when a customer disputes a charge. Broadly, authenticated transactions shift that liability to the issuing bank, while unauthenticated ones leave it with the merchant. The exact terms depend on each network's rules and on your acquirer contract, so confirm them with your acquirer. In practice, the best policy is to authenticate based on each transaction's risk.
How long does a chargeback take in Mexico?
On the customer's side, according to Condusef, the bank must credit the disputed amount within 48 hours while it investigates, and the investigation can last up to 45 days. On the merchant's side, the acquirer notifies you of the dispute and gives you a short window to submit evidence. If you don't respond in time, you lose even if you're right.
Can I store my customers' cards for future purchases?
Yes, but through the token the gateway generates, never by storing the card number in your own database. Adobe Commerce supports stored payment methods for repeat purchases under that model. If you also use network tokens, stored cards keep working when the bank replaces them.
Does Adobe Commerce include a payment gateway for Mexico?
Adobe offers Payment Services, its payment solution for Adobe Commerce, and its compatibility documentation lists Mexico among the countries with full support. Still, check whether it covers the local methods your customers expect; when it doesn't, Adobe itself recommends complementing it with third-party gateways. Any local gateway can also be integrated through an existing module or a custom integration.
Related services
If this topic is relevant to your business, these services from WolfSellers can help you implement it:


