OXXO for Merchants

OXXO for Merchants: How Cash-to-Online Payments Work in Mexico

A customer buys a digital product online. The money changes hands at a neighborhood convenience store. The merchant never shares a physical counter with the customer.

OXXO Pay connects those two environments.

For merchants entering Mexico, that is the useful way to think about the method. OXXO Pay is not simply another checkout logo and accepting it does not necessarily mean building a direct integration with the OXXO retail chain. It is a physical payment route into ecommerce: the online checkout creates a payment instruction, the customer completes the payment at an OXXO store, and a payment provider turns that retail event into a merchant payment state.

That distinction is central to the editorial brief: OXXO should be evaluated as access to a physical collection network, with the retailer, provider, voucher, confirmation, fulfillment and settlement layers kept separate.

The question for an international merchant is therefore not simply “Can we accept OXXO?”

It is:

Which customers does OXXO Pay enable us to serve, and does that additional access justify the delayed customer action, voucher management, fulfillment rules, reconciliation and refund operations the method introduces?

How OXXO Pay actually works

The basic transaction crosses from an online environment into a physical one:

•The customer selects OXXO Pay at checkout.

•The ecommerce flow generates a payment reference or barcode.

•The customer takes that reference to an OXXO store.

•The cashier scans or enters the reference and accepts payment.

•The payment event is communicated back through the payment infrastructure.

•The merchant receives the relevant payment status and updates the order.

OXXO's current customer documentation says the shopper can present either a barcode or a numeric reference. Its merchant FAQ describes the reference as 14–16 digits.

This is an online-to-offline payment flow.

The important asynchronous interval is not necessarily between the store payment and merchant notification. It is between creating the online order and the customer actually going to an OXXO store and paying.

That distinction improves on a common description of OXXO as simply a “slow cash payment.”

The customer may wait minutes, hours or longer before paying. Until that physical payment happens, the merchant has an unpaid order rather than completed revenue.

OXXO Pay is not the same as every payment made at OXXO

This distinction is particularly important.

OXXO's current merchant FAQ separates OXXO Pay from other ecommerce receipts that customers may also be able to settle at OXXO stores.

For a receipt carrying the OXXO Pay designation, OXXO says the ecommerce merchant receives notification when the customer pays and describes the application of the payment as real time. Its customer page says the online payment should be reflected in less than ten minutes. By contrast, OXXO says some other online-payment receipts accepted at its stores but not using OXXO Pay can take 24–48 hours to be reflected.

That means a merchant should not write one universal rule such as:

“Payments made at OXXO take one or two days to confirm.”

Nor should it assume every OXXO-collected reference has OXXO Pay's current confirmation behavior.

The exact payment product matters.

The retailer and the payment provider are different layers

A merchant hearing “accept OXXO” may reasonably assume it needs to establish and maintain a direct technical relationship with the retail chain.

That is not the only model.

OXXO's current merchant page says merchants obtain OXXO Pay through technology/payment partners and publishes a group of authorized aggregators through which ecommerce businesses can connect to the service.

The architecture is therefore better represented as:

Customer creates order

→ merchant/payment provider creates OXXO Pay instruction

→ customer visits OXXO

→ OXXO accepts payment

→ payment event reaches provider

→ provider communicates merchant status

→ merchant confirms order

→ reconciliation and settlement follow

Different participants own different parts of that transaction.

OXXO provides the physical retail collection environment and records the customer's payment.

The payment provider can expose the payment method to the merchant, generate or deliver the relevant payment instruction, communicate payment status and provide merchant operational capabilities.

The merchant controls checkout presentation, order state, customer messaging, fulfillment and its own reconciliation logic.

That division of responsibility matters when something fails. A missing payment status, an expired reference and a delayed settlement are not automatically the same problem or owned by the same participant.

The physical network is the product advantage

OXXO currently describes OXXO Pay as available through more than 23,000 OXXO stores in Mexico. FEMSA separately reported that OXXO Mexico handled roughly 13 million consumer transactions per day during 2025. Those figures describe the retail network, not OXXO Pay ecommerce volume.

For an ecommerce merchant, the important implication is geographic and behavioral.

A customer does not need the merchant to operate a cash desk. The retailer's existing physical network becomes the place where a digital order can be funded.

That can matter for customers who:

•do not have a suitable card for the online purchase;

•prefer to use cash;

•prefer paying through a familiar physical location;

•do not want to enter card credentials online;

•or want to separate the ecommerce decision from the actual payment event.

Those segments should not be collapsed into the label “unbanked.” Cash payment can be access-driven, but it can also reflect budgeting, trust, habit or convenience. The brief specifically requires the article to distinguish access from preference rather than stereotype Mexican customers.

Although cash is the strategic use case, OXXO Pay is not literally cash-only

The previous version described OXXO Pay entirely as a cash transaction. That is too narrow for the current product.

OXXO's current merchant FAQ says an OXXO Pay reference can be paid in-store with cash or eligible Visa and Mastercard bank cards; it excludes American Express and grocery-benefit vouchers. OXXO nevertheless positions the product strongly around enabling customers who want a physical payment route into ecommerce.

For this Cash & Voucher Payments cluster, the merchant case still centers on cash-funded access.

But the technically precise statement is:

OXXO Pay is an in-store payment method for ecommerce purchases whose physical collection flow can accept cash and certain card payments.

That is different from saying the product itself is universally cash-only.

A generated reference is not a paid order

This is where merchants used to synchronous card authorization can make the most expensive mistake.

At voucher creation:

the customer has received a way to pay.

They have not necessarily paid.

The order state should therefore distinguish at least:

Payment instruction created

→ awaiting customer payment

→ payment confirmed

→ order fulfilled

Depending on the provider, additional states may include expired, cancelled, late payment, refunded or failed.

The merchant should not fulfill when the reference is generated.

It should fulfill when the integration receives the provider event that is contractually and technically defined as authoritative payment confirmation.

That still does not make the entire transaction synchronous.

The customer can generate the instruction during checkout and walk into an OXXO much later.

The retail receipt is evidence for the customer, not the merchant's payment API

When the customer pays, OXXO issues a store receipt. OXXO tells customers to keep that receipt as their proof of payment.

For the merchant, however, a photograph of that receipt should not replace the payment status delivered through the merchant's provider.

A clean operating rule is:

Customer receipt = customer evidence

Provider confirmation = merchant order-state input

That distinction avoids fulfillment based on screenshots, mistyped references or support conversations.

If a customer says they paid but the authoritative provider event has not arrived, the payment should enter an exception workflow rather than automatically being marked paid.

Expiry is an order-policy problem, not just a voucher setting

The older draft was right to avoid publishing a universal OXXO expiry period.

The production article should therefore not invent a fixed “three days,” “seven days,” or similar rule.

Merchants need to verify the actual provider configuration and separately define four deadlines:

Voucher validity: how long the reference can be paid.

Order validity: how long the merchant keeps the commercial order open.

Inventory reservation: how long stock is held for an unpaid customer.

Price validity: how long the quoted price remains economically acceptable.

Those periods do not have to be identical.

For digital goods with effectively unlimited inventory, holding an order may be inexpensive.

For event tickets, scarce inventory, travel or flash-sale products, leaving capacity reserved while a customer has not yet paid can have a direct economic cost.

Late payments need an explicit policy

Expiry creates a second question:

What if the merchant cancels the order, but the customer still manages to pay?

The answer depends on the provider and the actual reference behavior, so it should be verified rather than assumed.

But the merchant operating policy should exist before launch.

Possible outcomes include:

•restore the original order if inventory and price still permit;

•create a replacement order;

•route the case to manual support;

•or refund the customer.

The system should preserve the original order and payment identifiers so a late payment does not become an unidentified cash receipt.

Reconciliation must connect the physical and digital transaction

The operational chain should be traceable end to end:

Order

→ OXXO payment instruction

→ barcode/reference

→ store payment

→ provider transaction

→ authoritative merchant status

→ settlement record

→ refund, if any

Useful identifiers may include:

•merchant order ID;

•merchant payment ID;

•OXXO reference;

•provider transaction ID;

•confirmation timestamp;

•amount;

•and settlement identifier.

The merchant should test what happens when:

•a payment notification is delivered twice;

•the customer creates two OXXO references for one shopping cart;

•the payment arrives after the order has been cancelled;

•the expected payment state is missing;

•a refund follows the original payment;

•or a settlement batch groups multiple OXXO transactions.

“Money was collected” is not the same as “the payment was automatically reconciled.”

Current OXXO Pay limits matter to checkout design

OXXO's current merchant FAQ states a maximum OXXO Pay transaction amount of MXN 10,000 and lists an in-store commission of MXN 17 per transaction. These are current OXXO-published figures and should be rechecked immediately before publication because method limits and fees can change.

That distinction illustrates why merchant documentation should identify the source of each limit.

A retail-network maximum, provider minimum, merchant configuration and supported checkout currency are different constraints.

If the merchant sells globally in several currencies, it should determine how its provider converts or presents the transaction before assuming a customer can take an arbitrary USD or EUR order directly to OXXO.

OXXO is not an automatic recurring-payment method

The customer must actively complete the OXXO payment journey.

That makes the method a poor substitute for a stored card, direct debit or other merchant-initiated recurring instrument when automatic renewal is essential.

Subscription businesses can still decide that OXXO is valuable for:

•a first payment;

•prepaid access;

•manual renewal;

•account top-ups;

•occasional purchases;

•or recovery flows where the customer actively pays again.

But they should not model one successful OXXO payment as a reusable mandate.

Refunds should no longer be described as universally manual bank transfers

This is another area where the earlier draft should change.

It is true that an in-store cash payment does not inherently give the merchant the same original digital instrument as an online card authorization.

But that does not mean every OXXO refund must be manually returned by bank transfer.

Refund capability belongs to the provider configuration.

•refunds supported;

•partial refunds supported;

•and a 180-day refund timeframe.

The public page does not describe the exact customer-facing return-of-funds mechanism, so the article should not invent it.

Before launch, the merchant should verify:

•how a full refund is initiated;

•how a partial refund is initiated;

•whether customer information is required;

•where the refunded funds go;

•the refund status model;

•the expected completion time;

•how failed refunds are handled;

•and how refunds appear in reconciliation.

That is more precise than assuming “cash in means bank transfer out.”

No card chargeback does not mean no operational risk

Merchants should not turn that characteristic into:

no disputes, no fraud and no merchant loss.

A cash/voucher-style flow can still produce:

•fake payment receipts;

•social-engineering attempts;

•duplicate payment references;

•fraudulent refund requests;

•incorrect refund beneficiaries;

•payment-status exceptions;

•and customer-service disputes over fulfillment.

For higher-risk goods, fulfillment should still follow authoritative provider confirmation rather than customer-supplied evidence.

OXXO Merchant Readiness Map

Before adding OXXO Pay, evaluate eleven questions.

Dimension

Merchant question

•Mexican customer segment

Which customers are we trying to reach?

•Cash-access need

Are customers genuinely unable or unwilling to complete existing digital methods?

•Provider availability

Which PSP/provider exposes the current OXXO Pay product?

•Merchant eligibility

Can our entity, vertical and business model activate it?

•Voucher UX

Is the reference easy to save, display and retrieve later?

•Payment-point coverage

Does OXXO's physical footprint align with our target customers?

•Confirmation model

Which provider event authoritatively means “paid”?

•Fulfillment policy

What is reserved before payment, and when is value released?

•Refunds

Can full and partial refunds be operated cleanly?

•Reconciliation

Can order, reference, payment and settlement be matched automatically?

•Commercial contribution

Does OXXO generate incremental completed orders worth the operational cost?

The decision should not be based on voucher generation volume.

The brief explicitly requires the merchant to measure paid rate, expiry, time-to-pay, confirmation latency, completed orders, support burden and refund success.

Which merchant models fit OXXO Pay?

Gaming and digital goods

OXXO can create a cash-funded route to digital value.

The operational advantage is that inventory is usually not scarce.

The risk is fulfillment discipline: virtual currency, game credit or other immediately transferable value should not be released merely because the customer generated a payment reference.

Ecommerce retail

The method can expand access, but unpaid orders interact with stock.

Merchants need a clear policy for:

•inventory reservation;

•expiration;

•shipping release;

•late payments;

•and refunds.

Education

OXXO can suit planned payments where the customer prefers a familiar physical payment point.

Strong order/reference reconciliation becomes important when the transaction value is larger or payments need to be linked to a particular student, invoice or enrollment.

Travel and ticketing

Fit is more conditional.

A payment method that allows the customer to pay later can conflict with:

•volatile prices;

•expiring fares;

•scarce inventory;

•event capacity;

•or rapid ticket issuance.

Use OXXO only when the reservation policy can tolerate the gap between online order creation and physical payment.

Subscriptions

It can still be useful for prepaid or manually renewed services.

Measure what happens after checkout

OXXO breaks an assumption built into many ecommerce dashboards:

payment conversion can happen after the browser session ends.

A useful funnel is:

Eligible customer

→ OXXO visible

→ OXXO selected

→ payment instruction generated

→ customer reaches OXXO

→ payment made

→ provider confirmation received

→ order completed

The most important metrics are therefore post-checkout.

Voucher payment rate

Paid valid references

÷ valid references issued

Expiry rate

References expiring unpaid

÷ valid references issued

Time to pay

Measure the distribution from:

reference issued

→ customer payment

Useful cohorts can include same hour, same day, next day and unpaid at expiry.

Confirmation latency

Time from the verified retail-payment event

→ authoritative merchant confirmation

Do not mix this with customer time-to-pay.

Completed-order rate

Orders reaching paid and fulfillable status

÷ valid OXXO payment instructions issued

Incremental completed orders

The harder commercial question is:

Would these customers have successfully paid another way if OXXO had not been available?

A paid OXXO order is not necessarily incremental revenue. It may represent new access—or a customer switching away from a card or another method that would also have succeeded.

How to test OXXO before a broad rollout

Start with Mexican customers for whom there is a credible access hypothesis.

Test the entire lifecycle, not just reference creation:

•generate the payment instruction;

•save it on mobile;

•retrieve it from email or account history;

•pay in an OXXO store;

•observe provider confirmation;

•verify duplicate-notification handling;

•allow a reference to expire;

•simulate cancelled orders;

•test late-payment procedures where technically possible;

•process a full refund;

•process a partial refund where supported;

•and reconcile the resulting payment and settlement records.

The hypothesis should be reconsidered if OXXO receives substantial selection but few customers actually pay the reference, or if inventory reservation, support contacts, late payments and refund work outweigh the additional completed orders.

It is the possibility of handling a Mexico-specific physical payment method inside the same broader payment integration used for other markets and methods.

•current OXXO Pay versus legacy OXXO product naming;

•exact customer reference format;

•voucher validity;

•whether the public OXXO Pay MXN 17 customer commission applies identically;

•authoritative merchant notification/event;

•refund destination and mechanics;

•late-payment handling;

•settlement timing and currency;

•merchant eligibility by vertical;

•and whether any implementation details in the public OXXO documentation need updating.

Final recommendation

OXXO Pay should not be added simply because OXXO is a familiar Mexican brand.

It deserves priority when the physical collection network solves a real payment-access problem among the merchant's target customers.

The commercial value comes from turning money that a customer wants to hand over in a physical environment into a structured ecommerce payment:

online order

→ unique payment instruction

→ in-store payment

→ authoritative provider confirmation

→ reconciled merchant order

The trade-off is that the customer's part of the payment does not finish at checkout.

That affects fulfillment, inventory, expiry, customer communication, reconciliation and refunds.

For merchants whose customers genuinely need that physical route, those costs can be justified.

For merchants whose customers already complete digital payments successfully, or whose inventory cannot tolerate an unpaid reservation window, OXXO Pay may deserve less prominence.

The decision should ultimately be made with one question:

Does OXXO Pay generate enough incremental completed orders from Mexican customers who otherwise struggle to pay to justify the operational complexity between reference creation, physical payment and fulfillment?

Editorial and publication package

Evidence anchor

A large physical retail network can become part of ecommerce payment infrastructure when it gives customers a standardized way to turn an online payment instruction into a physical payment.

Editorial position

Prioritize OXXO Pay when the retail network serves a material Mexican customer segment that cannot or does not want to complete the merchant's existing digital payment methods.

Do not add it merely because the OXXO brand is widespread.

Common assumption challenged

“Accepting OXXO means integrating directly with OXXO.”

Current OXXO merchant materials instead describe provider/technology-partner access to the payment service.

Merchant decision

Does provider-enabled access to OXXO's physical payment network create enough incremental completed orders to justify delayed customer payment, expiry policies, post-checkout measurement and refund/reconciliation complexity?

Selected format

Physical-network payment journey.

Structural rationale

The article follows the money and information across the merchant, provider, OXXO store and customer rather than treating OXXO as a generic payment-method feature list. That follows the brief's requirement to distinguish retailer from provider, voucher generation from cash receipt, retail receipt from merchant confirmation, and cash collection from settlement.

SEO metadata

H1: OXXO for Merchants: How Cash-to-Online Payments Work in Mexico

Meta description: Learn how OXXO Pay turns an online order into an in-store payment in Mexico, including references, confirmation, expiry, fulfillment, refunds and merchant integration.

URL slug: /solve/customers-cant-pay-their-way/cash-and-voucher-payments/oxxo-for-merchants/

Secondary keywords: OXXO payments ecommerce; accept OXXO payments; OXXO cash payments merchants; OXXO payment voucher; Mexico cash payment ecommerce; OXXO merchant integration; OXXO payment method; pay cash at OXXO online purchase

Excerpt: OXXO Pay lets an ecommerce order cross into Mexico's physical retail network. For merchants, the challenge is not generating the payment reference—it is operating the delayed customer payment, authoritative confirmation, expiry, reconciliation and refund lifecycle reliably.

Suggested structured data: Article. Use FAQPage only if a final FAQ is retained.

Suggested FAQ

Does a merchant integrate directly with OXXO to accept OXXO Pay?

Not necessarily. OXXO currently describes merchant access through authorized payment/technology partners.

Is OXXO Pay cash-only?

No. Although cash access is a central use case, OXXO currently says customers can also pay eligible OXXO Pay transactions with Visa or Mastercard cards in-store.

How quickly is an OXXO Pay payment confirmed?

Can OXXO support recurring subscriptions?

Internal links

•Mexico payment methods → Mexico Payment Guide

•why cash-funded payment access persists → Cash-Based Payments in Emerging Markets

•how payment vouchers work → Voucher Payments Explained

•cash-payment refund operations → Refunds for Cash Payment Methods

•voucher confirmation and payment states → How Voucher Payment Confirmation Works

Avoid re-explaining generic voucher mechanics or generic cash-market behavior in depth; the brief assigns this article ownership of the OXXO merchant payment flow specifically.

Supporting visual

OXXO physical-network payment flow

Online

Customer places order

↓

Merchant/provider generates reference or barcode

Physical

Customer visits OXXO

↓

Cash or eligible card presented

↓

OXXO records payment and issues receipt

Online

Payment event reaches provider

↓

Merchant receives authoritative confirmation

↓

Order becomes fulfillable

↓

Settlement and reconciliation

Visual callout

Creating the reference does not mean the customer has paid.

Secondary callout

Customer receipt and merchant confirmation are different evidence states.

Alt text

“Diagram showing an OXXO ecommerce payment moving from online checkout to an OXXO store and back through a payment provider to merchant confirmation and reconciliation.”

Proposed human contribution

Reviewers:

•Mexico payments specialist;

•cash-method operations specialist;

•ecommerce product reviewer;

•reconciliation/finance reviewer where settlement detail is included.

Fact-check list before publication

OXXO/product

Confirm:

•exact current branding: OXXO Pay versus generic OXXO collection;

•current store count;

•accepted in-store funding methods;

•current reference/barcode format;

•current OXXO Pay maximum amount;

•current customer commission;

•current confirmation promise;

•hours/availability.

As of this review, OXXO publishes more than 23,000 Mexican locations, a MXN 10,000 OXXO Pay maximum and a MXN 17 transaction commission, while describing OXXO Pay payment application as real time.

Confirm internally:

•that the public Oxxo product corresponds to the current OXXO Pay service described by OXXO;

•supported merchant entities/verticals;

•exact reference format;

•expiry;

•max amount;

•min amount;

•processing and settlement currencies;

•authoritative notification;

•late-payment handling;

•refund mechanics and beneficiary route;

•settlement/payout timing;

•reporting/reconciliation identifiers.

Expiry and late payments

Confirm:

•validity duration;

•whether merchant can configure it;

•what happens after expiry;

•whether a late store payment is technically possible;

•how it is reported;

•whether a cancelled order can be restored;

•when a refund becomes necessary.

Settlement

Verify:

•settlement currency;

•payout schedule;

•aggregation;

•fees;

•settlement identifier;

•relationship between payment confirmation and payout.

Do not call confirmation “settlement.”

Refunds

Verify the actual return-of-funds mechanism before publication.

Amber-flag claims

“OXXO is cash-only.”

Outdated/incomplete for OXXO Pay; OXXO currently accepts cash and specified bank cards for the product.

“OXXO payments take 24–48 hours.”

Too broad. OXXO distinguishes OXXO Pay's real-time behavior from other receipts paid at OXXO.

“OXXO Pay is synchronous.”

Misleading. Confirmation after store payment can be rapid, but the customer still pays after leaving the ecommerce checkout.

“Voucher expiry is X days.”

Verify provider/configuration.

“OXXO has no disputes because there are no chargebacks.”

Do not equate card-chargeback status with absence of fraud, refunds or customer disputes.

“Refunds must be made by bank transfer.”

“OXXO supports automatic recurring billing.”

Cluster sameness-audit fields

Field

OXXO article

Title

OXXO for Merchants: How Cash-to-Online Payments Work in Mexico

Opening

A digital transaction whose money changes hands in a neighborhood store

Customer-access problem

Customer wants or needs a physical route to fund ecommerce

Primary market

Mexico

Payment method

OXXO Pay

Offline location

OXXO retail store

Primary format

Physical-network payment journey

Evidence anchor

Physical retail footprint becomes ecommerce collection infrastructure

Editorial position

Prioritize when physical payment materially expands customer access

Merchant decision

Do incremental paid orders justify asynchronous-operation complexity?

Original asset

OXXO Merchant Readiness Map

Primary metric

Paid-reference/completed-order rate, with incrementality analysis

Conclusion

OXXO matters when the physical route unlocks customers rather than merely adding a checkout logo

CTA

Evaluate OXXO against Mexican customer access and the complete operating lifecycle

Closing element

Readiness map plus lifecycle measurement

Information notice: This article provides general information and does not constitute legal, regulatory, financial, tax or compliance advice. Merchants should verify applicable requirements with qualified advisers, relevant payment providers, collection networks, banks and authorities.

v1

OXXO for Merchants

OXXO is a convenience store chain with a nationwide footprint in Mexico, and OXXO Pay lets a customer complete an online purchase by paying cash at any of those stores. For merchants used to card payments, the appeal is straightforward — it reaches Mexican consumers who prefer cash or don't have full access to card-based banking. The mechanics, though, work nothing like a card transaction, and treating it as a drop-in payment method rather than a distinct transaction model is where most integration problems start.

How the transaction actually works

The flow has a real-world step in the middle that no card payment has:

•At checkout, the customer selects OXXO as the payment method

•A voucher is generated — typically a barcode plus a reference code and an amount due

•The customer takes that voucher, printed or on their phone, to any OXXO store and pays in cash

•OXXO confirms the payment back to the merchant's payment provider, usually via webhook

This makes OXXO an asynchronous payment method. The order doesn't move from pending to confirmed in the same session — it stays open until the customer actually walks into a store, which can be anywhere from minutes to days later.

Why the voucher window and settlement timing vary by provider

The exact number of days a voucher stays valid before it expires is not a fixed OXXO-wide constant — it depends on the processor and how the merchant has it configured. Some setups fix the window at a few days by default; others let the merchant specify the number of calendar days before expiration directly in the payment request. Confirmation-to-merchant timing works the same way: once the customer pays in-store, the merchant's system is typically notified within about a day, though this can take longer depending on when in the day the store processes the transaction and how the specific provider handles reconciliation.

Because these details vary by processor and configuration rather than being fixed by OXXO itself, they need to be confirmed against whichever specific integration a merchant is using rather than assumed from general product documentation. (See How Voucher Payment Confirmation Works.)

What this means for order handling

An asynchronous, cash-based method changes what "checkout complete" means operationally:

•Orders should stay in a pending state, not confirmed, until the webhook or status update actually arrives

•Customers need a way to retrieve the voucher again if they don't pay immediately — email and SMS reminders before expiration reduce the number of vouchers that lapse unpaid

•Expired vouchers need a defined process, whether that's automatically canceling the order or prompting the customer to generate a new one

•Fulfillment should wait for confirmed payment, the same discipline used for any delayed or asynchronous payment method, rather than the instant-fulfillment assumptions built for card checkout

Currency and transaction limits

OXXO transactions are processed in Mexican pesos — most integrations require the checkout to be in MXN specifically, meaning a merchant offering OXXO alongside other currencies typically needs a separate checkout flow or session for Mexican customers rather than a single multi-currency page. Transaction minimums and maximums exist as well, though the specific thresholds are set by the processor and configuration rather than being a single universal OXXO limit — a merchant should confirm the actual limits with whichever provider is handling the integration rather than assume a fixed figure.

What OXXO doesn't support directly

Because it's a manual, in-person cash transaction, OXXO isn't built for recurring billing the way a stored card is — a subscription business can't charge a saved OXXO voucher on a renewal date the way it would a card on file. Merchants with subscription models that want to offer OXXO typically use it for the initial or occasional payment while relying on a different method, or a dunning/reminder flow, to handle renewals. (See Subscription Billing in Multiple Currencies and Failed Payment Recovery for how this is usually handled around cash-based methods.)

Refunds work differently too

There's no card or bank account on file to refund back to automatically — a cash payment has no originating payment instrument to reverse a transaction against. Refunds for OXXO payments typically require a separate process, often a bank transfer or an alternative payout method collected from the customer directly, rather than the automatic reversal a merchant would expect from a card refund. (See Refunds for Cash Payment Methods.)

Why it matters beyond a single payment method

OXXO is one of the more prominent examples of why "just accept cards" isn't a complete strategy in markets with large unbanked or cash-preferring populations. Mexico has a substantial share of consumers who transact in cash by preference or necessity, and a checkout that only offers cards is invisible to that portion of the market regardless of how well-designed the rest of the funnel is. (See Cash-Based Payments in Emerging Markets and Why Cash Vouchers Still Matter.) Boleto Bancário serves a similar function in Brazil, for merchants expanding across Latin America more broadly. (See Boleto Bancário for Merchants.)

Title

OXXO for Merchants

Url

/solve/customers-cant-pay-their-way/cash-and-voucher-payments/oxxo-for-merchants/

Pillar

Customers Can't Pay Their Way

Cluster

D — Cash and voucher payments

OXXO isn't a card alternative — it's a different transaction model entirely. Here's how the voucher flow actually works, and what it means for order handling.

Status

draft — integration specifics checked against processor documentation (July 2026); exact expiration windows, limits, and settlement timing vary by processor and configuration and should be reconfirmed before publishing