What Payment Processing Actually Looks Like in Mexico

Payment processing in Mexico doesn’t work the same way most US-based engineering teams expect. If your mental model starts with Stripe, you’re already carrying assumptions that will break in production — not just in the payment flow, but in fraud prevention, settlement, banking reconciliation, and tax compliance.

We learned this building PayTable — a QR ordering and payments platform deployed across restaurants in Mexico. What started as “add a payment gateway” turned into a ground-up rethink of how transactions, fraud prevention, tax, invoicing, and settlement actually work outside the US.

The processors aren’t Stripe

PayTable processes payments through T1 Pagos. The integration looks superficially similar to any payment API — you send a request, you get a response — but the operational details diverge fast.

Card clearing in Mexico runs through PROSA and eGlobal — two firms that together handle the majority of card transaction routing, as well as VISA, MC, and AMEX. BBVA and Banamex hold roughly 60% market share in both issuing and acquiring. T1 Pagos connects into all of this infrastructure as a processor, not an acquirer, routing transactions through these rails. The plumbing is different from US ACH and the Stripe abstraction layer that hides it.

Chargebacks and disputes follow global Visa/Mastercard/AMEX rules (120-day dispute window), but Mexico’s CNBV (National Banking and Securities Commission) layers additional requirements on banks and processors. The documentation requirements, the evidence standards, and the merchant’s obligations have their own shape. If your dispute-handling logic assumes a US-only process, you’ll miss things.

Tax is inclusive, not additive

This is the single detail that cascades the furthest. In Mexico, IVA (Impuesto al Valor Agregado) is 16%, and it’s included in the displayed price. The number on the menu is the number the customer pays.

In the US, tax is additive — you see $10.00 on the menu, and the receipt says $10.87 after state and local tax. Two completely different data models.

What this changes in practice:

• Receipt rendering: The receipt has to decompose the inclusive price into base + IVA for the tax line. You’re calculating backwards from the total, not forward from a subtotal.
• Refund logic: A partial refund on an inclusive-tax item requires recalculating the tax component of the refunded portion. Get this wrong and your tax reporting is off.
• Accounting integration: Your books need to track IVA collected separately. The tax authority (SAT) expects this breakdown on every transaction.
• Menu pricing: When a restaurant owner sets a price, they’re setting the final price. Your admin interface can’t show “price before tax” — that concept doesn’t apply.

One tax rule. Four downstream systems. Each one is a place where a US-centric assumption will silently produce wrong output.

CFDI electronic invoicing is mandatory

Every transaction in Mexico that requires a tax receipt must generate a CFDI (Comprobante Fiscal Digital por Internet) — a digitally signed XML document submitted to the SAT through an authorized certification provider (PAC).

This isn’t optional. It’s not a “nice to have for enterprise clients.” It’s the law. A restaurant that can’t issue a CFDI when a customer requests one is operating non-compliantly.

What this means for the engineering:

• Every completed order must be able to generate a CFDI on demand
• The XML must conform to SAT’s schema, including the correct tax breakdown, payment method codes, and fiscal regime of the issuer
• The document gets signed by a PAC and stamped with a UUID (folio fiscal) that makes it legally valid
• You need to store the signed XML and make it retrievable — customers and tax authorities can request it months later

We integrated CFDI generation into PayTable’s order completion flow. When a customer requests an invoice, the system generates the XML, submits it to the PAC, and returns the stamped document. The entire process has to complete in seconds — a customer at a restaurant counter isn’t going to wait.

What we didn’t appreciate initially is that CFDI also functions as fraud infrastructure. Every invoice is cryptographically signed with a digital certificate issued by the SAT, validated by the PAC against both the issuing and receiving entity, and time-stamped immutably. This creates a second audit trail parallel to the payment system. A voided transaction that doesn’t have a corresponding CFDI cancellation is an anomaly. A charge with no matching invoice is visible. The SAT’s five-year retention requirement means the evidence persists. It’s not real-time fraud prevention — it’s forensic infrastructure the regulatory environment hands you for free.

Anti-fraud when your US playbook doesn’t apply

This is where the gap between US and Mexican payment infrastructure hits hardest.

AVS doesn’t work here

In the US, Address Verification System (AVS) is a primary fraud signal for card-not-present transactions. You send the billing address, the issuing bank returns a match or mismatch. It’s table-stakes fraud tooling.

AVS does not function for Mexican-issued cards. Mexican banks don’t participate in the AVS network. Visa and Mastercard mandate AVS support only for the US, Canada, UK, and a subset of European issuers. If you’re processing Mexican-issued cards in Mexico — which is the vast majority of PayTable’s transaction volume — AVS returns are either unavailable or meaningless.

Any fraud ruleset ported from a US-market platform that uses AVS match/mismatch as a scoring input needs to be disabled or re-weighted for Mexico. This isn’t a configuration change. It’s a gap in the fraud model that has to be filled with something else.

Device fingerprinting as the primary signal

We integrated FingerprintJS Pro into PayTable’s frontend. Every customer session captures a visitorId before the checkout flow begins — on the home screen, not at payment time. If the initial capture fails, a fallback runs on the checkout view as a safety net.

That visitorId flows through the entire payment chain. On the frontend, it identifies the session and the customer. On the backend, it’s passed to T1 Pagos as DeviceFingerprint on the charge request and as IdExterno on the customer record. It’s the thread that ties a browser session to a payment to a processor’s fraud evaluation.

This matters operationally because it’s also how PayTable prevents cross-session payment leakage. In a split-payment scenario — multiple people paying on the same tab — the system checks whether the current visitorId matches the one that authorized the original payment. If it doesn’t match, the stored card details aren’t restored. Without this check, a guest joining a split could theoretically access the tab originator’s payment method. Device fingerprinting isn’t just fraud scoring — it’s session-level authorization.

Zip code for card ownership validation

When a customer pays by card, PayTable requires a billing zip code (código postal). It’s validated on the client, sent to the .NET backend, and forwarded to T1 Pagos as the cp field on the billing address.

This isn’t AVS — there’s no issuer-side match response coming back from Mexican banks. But it serves two purposes: it adds friction that deters opportunistic fraud (fraude amigo) with stolen card numbers, and it provides a data point for chargeback dispute evidence. When you can show the processor that the billing zip matches the cardholder’s registered address, it strengthens your case in a dispute even without a formal AVS match.

Wallet payments (Apple Pay, Google Pay) skip the zip code requirement entirely. The card is device-bound and tokenized — the cryptographic proof of ownership from the CAVV and ECI is stronger than any address check we could ask for.

Wallet payments carry their own authentication

Apple Pay and Google Pay transactions follow a different path through PayTable’s stack. The wallet SDK provides a payment token that routes through Cybersource for decryption, which extracts the CAVV (Cardholder Authentication Verification Value) and ECI (Electronic Commerce Indicator) — 3D Secure artifacts that prove the cardholder authenticated through the wallet’s biometric or device passcode flow.

These are forwarded to T1 Pagos on the charge request. The result is a structurally more fraud-resistant transaction: no raw card number is transmitted, no CVV is needed (the cryptogram replaces it), and the liability shifts to the issuing bank on authenticated transactions.

The problem is penetration. Apple Pay adoption in Mexico sits around 5% — a fraction of the US market. The dominant digital wallets are MercadoPago and platform-specific solutions, not the Apple/Google ecosystem. The bulk of PayTable’s transactions are standard card CNP, where the fraud toolbox is thinner and every signal — fingerprint, zip code, velocity — has to carry more weight.

The approval rate tension

Here’s the number that frames everything: only 62% of online card transactions in Mexico are approved, according to CONDUSEF. The false decline rate across Latin America hovers around 50%. Nearly two-thirds of failed payments are difficult for businesses to recover — the customer doesn’t retry. This is where T1 shines as a partner. Their approval rate hovers around 90%+, providing us an advantage and edge over the competition for restaurant owners.

At the same time, 94% of Mexican consumers rate fraud prevention as more important than checkout ease. They want security, but the infrastructure rejects them at alarming rates. Without T1, our application would fall among the much lower average approvals, creating friction for our customers.

Ultimately, this means fraud scoring in Mexico has to optimize for precision over recall. Every false decline has an elevated cost in a market where consumers are already nervous about paying online. Aggressive fraud rules that would be acceptable in the US — where baseline approval rates are above 90% — will crater your conversion in Mexico, and without the right partners this is difficult to mitigate.

We’ve had to calibrate around this: enough friction to catch real fraud (fingerprinting, zip code, device signals), not so much that we’re declining the 94% of customers who are legitimate but anxious.

Settlement, reconciliation, and disbursement

In the US, Stripe settles in 2 business days by default. You wire up a bank account, money appears, and the abstraction holds.

In Mexico, settlement runs through PROSA and eGlobal at T+1 to T+2 business days depending on the acquiring bank. That’s comparable to the US on paper, but less predictable in practice — especially with smaller acquirers. Your reconciliation logic needs to account for the variance, or your accounting reports will drift from reality within the first week.

The payment state machine

PayTable tracks every payment through a full lifecycle: Pending → Authorized → Captured → Reconciled → Disbursed. Each state transition is a real event in the banking system, not an internal status we invented.

Authorized means T1 Pagos confirmed the card is valid and funds are available. Captured means the charge has been submitted for settlement. Reconciled means T1 Pagos has confirmed the funds settled with the acquiring bank. Disbursed means the funds have been deposited into the restaurant’s bank account via SPEI — Mexico’s real-time interbank payment system.

T1 Pagos fires webhooks at each settlement gate. Each webhook carries an event ID, and we deduplicate on that ID before processing — concurrent duplicate events hit a unique constraint and get silently dropped. State transitions can only advance forward. A payment that’s been captured can move to reconciled, but it can never regress to authorized. If your system doesn’t enforce this directionality, you’ll eventually process a stale webhook that rolls back a settled payment.

SPEI: real-time rails, not real-time settlement

SPEI (Sistema de Pagos Electrónicos Interbancarios) is Banxico’s real-time interbank system. It processed 5.34 billion operations in 2024 — a 39% increase over 2023 — and settles effectively instantly. It’s fundamentally different from US ACH, which runs batch cycles with next-day or same-day settlement depending on the window.

But instant interbank clearing doesn’t mean instant merchant settlement. The card network authorization cycle, the acquirer’s reconciliation process, and T1 Pagos’s own clearing schedule all run before SPEI moves money. SPEI is the last mile — fast, but only as fast as everything upstream allows.

For restaurant operators, this means cash flow visibility requires modeling the full pipeline: capture to reconciliation to disbursement. A shift closeout report that only shows captured payments is showing intent, not cash. We built the distinction into PayTable’s reporting so that restaurant owners see the difference between “this money was charged” and “this money is in your bank.”

Hardware is not optional

A QR ordering app that doesn’t print a ticket at the right kitchen station isn’t saving anyone time. In a restaurant environment, the hardware layer is part of the product.

PayTable integrates with:

• Thermal printers (Star TSP143IV via CloudPRNT) for kitchen tickets and customer receipts
• Kitchen display systems for order management (Elo devices)
• Dynamic screen stations for table identification
• Tablets (Elo devices) for waiter-facing order management

Each device has its own protocol, its own failure modes, and its own reliability characteristics. The printer might be offline. The dynamic screen station might lose connection. The kitchen display might be running a different firmware version than you tested against.

Real-time matters here. We use SignalR for sub-second order delivery to kitchen displays and printers. An order submitted via QR code hits the kitchen printer within 2 seconds. If that number were 10 seconds, waitstaff would walk to the kitchen and check manually — and your app becomes decoration.

The stack

PayTable runs on .NET 9 with Azure infrastructure. The customer-facing app is a Vue 3 PWA — it needs to work on any tourist’s phone without an app store install. The admin interface runs on Blazor WebAssembly. The API layer handles payment processing, fraud signal collection, CFDI generation, real-time order dispatch, and multi-language menu serving.

Menus auto-translate into 35+ languages because a restaurant in Cancún or Mexico City serves tourists from everywhere. That’s not internationalization as a feature — it’s internationalization as a revenue requirement. A French tourist who can’t read the menu orders less, or leaves.

The lesson

Building for an international market isn’t a localization layer on top of a US product. It’s a different product — from the fraud model to the settlement pipeline to the receipt printer.

The tax structure reshapes your data model. The invoicing requirements add a regulatory layer with its own engineering surface. The fraud tools you rely on in the US don’t function. The settlement timeline introduces states your payment system has to model explicitly. The hardware has to work in real time or the software is irrelevant.

None of these are configuration changes. They’re architectural decisions that compound from the moment you accept a payment to the moment the restaurant owner sees money in their bank account.

If you’re not willing to rebuild at that level, you’re shipping a demo, not a product.