The Mexican payment landscape, and where the cost hides
Inside Mexico, moving pesos is not the hard part. Bank transfers between Mexican accounts are fast and familiar, and card acceptance is widespread in the larger consumer segments. For a business whose customers and suppliers are all domestic, there is often no reason to reach past the existing rails.
The cost concentrates at the border. Mexico's economy is unusually cross-border by nature — a great deal of commerce, contracting, and family money moves between Mexico and the United States, and much of the wider world prices in US dollars. The moment a payment has to cross that line, it picks up correspondent banks, currency conversion the customer or the merchant pays for, and settlement delays measured in days rather than minutes. International card acceptance adds its own drag: cross-border declines, conversion the cardholder notices, and chargebacks that can reverse a sale weeks after it shipped.
Because so much of this commerce is dollar-denominated already, Mexican merchants commonly think in two currencies at once — they may price a local sale in pesos but quote a cross-border sale, or hold a reserve, in US dollars. That is exactly the gap a dollar-stablecoin rail fits: a way to be paid in something dollar-stable, by a customer anywhere, without each payment threading the correspondent-banking system.
Which assets fit a peso-and-dollar business
For a business that already half-thinks in dollars, the asset that fits best is the one that holds a stable value while the payment confirms. Dollar-pegged stablecoins — USDT and USDC — are the common case: the customer pays a stable dollar amount and the merchant receives a stable dollar amount, with no exposure to a swinging market in the minutes a payment takes. halfin anchors each invoice to your fiat figure — whether you price in MXN or USD — and locks the quote when the invoice activates, so the order owes a fixed crypto amount even if the asset's price drifts while the customer is paying.
Where the customer holds those stablecoins decides the network. USDT settles on Tron, Ethereum, or Solana; USDC on Ethereum, Base, or Solana. In practice a lot of cross-border dollar flow gravitates to the lower-cost networks, but a Mexican merchant does not have to choose for the customer — you enable the networks your customers actually use and let each pay on the rail they already hold funds on. Bitcoin stays available for customers who prefer to pay in BTC, with the same fiat-anchored invoice and the same reorg-aware crediting before a payment counts as settled.
On your side, a mixed inflow does not have to stay scattered across assets and chains. Balance conversion consolidates what arrives — BTC, SOL, a spread of stablecoins on different networks — into the asset you want to hold as your reserve, automatically on a policy you set or manually when you decide to rebalance. A business that wants to sit mostly in a dollar stablecoin can do that without managing each balance by hand. Balance conversion moves between assets you hold; it is not a way to cash out to pesos in a bank account.
- Price in MXN or USD; the invoice locks a fixed crypto amount at activation, so the customer is not exposed to price movement mid-payment.
- USDT on Tron, Ethereum, or Solana; USDC on Ethereum, Base, or Solana — enable what your customers hold.
- Bitcoin for customers who pay in BTC, same fiat-anchored invoice and confirmation rules.
- Balance conversion consolidates a mixed inflow into the reserve asset you choose — asset-to-asset, not a peso off-ramp.
Verticals that reach for this in Mexico
The businesses that pull toward a crypto rail in Mexico are the ones whose money is already crossing the border. None of these are exotic — they are ordinary operations hitting the cross-border, conversion, or payout friction described above, on both the collect side and the pay side.
Cross-border online stores are the broadest case: a Mexican seller wants buyers in the US and beyond without losing them to declined international cards or conversion they resent, and the same store often needs to settle with suppliers abroad. Software, digital-goods, and services firms bill clients internationally and want final settlement for something delivered instantly that cannot be shipped back if a card later reverses. And businesses that run on distributed teams or networks of contractors — much of that work spanning Mexico, the US, and elsewhere — need a way to pay many people across borders that does not route each payment through a slow, fee-heavy bank corridor.
- Cross-border online stores and marketplaces selling into the US and beyond, where international card declines and conversion cost real conversions.
- Software, SaaS, and digital-goods sellers billing clients abroad, where machine-to-machine settlement moves value without a human-facing checkout in the loop.
- Services and agencies invoicing international clients in dollars while keeping local peso costs.
- Businesses paying distributed teams, contractors, and affiliates across borders, where mass payouts replace many slow individual bank transfers.
- Wholesale and B2B operators settling with suppliers outside Mexico, where traditional cross-border transfer is slow and expensive.
How halfin fits the existing setup
halfin sits alongside what a Mexican business already runs; it does not replace the peso accounting or the domestic bank flows that work. You create an invoice anchored to your MXN or USD price, redirect the customer to the hosted checkout page — which handles the wallet, the network choice, the QR code, and live status — and wait for one HMAC-signed webhook before you treat the order as paid. The on-chain detail stays on halfin's side; your order system keeps its existing shape.
For automated commerce — a billing platform, a subscription service, a system that pays another system — machine-to-machine settlement moves value programmatically without a checkout page in the loop. Static deposit addresses give you a persistent receive address when you would rather hand out one address than mint an invoice each time. On the outbound side, single payouts cover a one-off send with operator review, and mass payouts batch many destinations into one idempotent run — submitting the same batch twice does not pay twice — which is what paying a cross-border roster of contractors or sellers on a schedule actually needs.
Treat the customer's redirect back to your success page as cosmetic and the signed webhook as authoritative: a customer can pay and close the tab before the redirect fires, but the webhook still arrives. Always verify the signature before acting on it. If you ever need to return funds, refunds run as a first-class flow against the original invoice rather than an ad-hoc manual send.
- Create an invoice anchored to your MXN or USD price; the rate locks at activation and expiry is enforced.
- Hosted checkout handles wallet, network, QR, and live status — no on-chain code on your side.
- A signed webhook is the source of truth for marking an order paid; verify the HMAC first.
- Mass payouts settle many cross-border destinations in one idempotent batch; refunds run against the original invoice.
curl -X POST https://api.thehalfin.com/api/v1/invoices \
-H "X-API-Key: $HALFIN_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"amount_fiat": "1500.00",
"fiat_currency": "MXN",
"idempotency_key": "order-MX-40192"
}'
# The fiat amount anchors the order — price in MXN or USD. The
# customer settles in the crypto asset they pick on the hosted
# checkout page returned in the response. Redirect the customer
# there, then verify the signed invoice webhook before releasing
# the order. See the full request and response schema at
# docs.thehalfin.com.Compliance and availability — a rail, not a licence
A Mexican business taking crypto still owns its own obligations. halfin is payment infrastructure: it collects payments, executes payouts, keeps payment records, and exposes status through dashboard data and signed webhooks. It does not take over the merchant's customer onboarding, its bookkeeping, its tax handling, or any approval the goods or services themselves require under local rules. Nothing on this page is legal, tax, or financial advice, and halfin makes no claim to be registered or licensed in Mexico or anywhere else.
Onboarding to halfin involves KYB — verifying the business behind the merchant account — and the platform operates with AML awareness as a process. The travel rule, which concerns information that travels with certain transfers, is a concept to understand as you design flows, not a certificate halfin issues. The practical pattern for a Mexican merchant is to keep your own customer checks, your own counterparty and wallet screening, and your own record of which order each invoice and payout belongs to; halfin gives you the payment primitives and the audit trail, and you keep the decisions about who you serve and what you sell.
Availability is subject to jurisdiction and sanctions screening, and some places are out of scope regardless of demand — see the restricted-countries note for where halfin cannot operate. If your business is based in Mexico and trades across the border and beyond, the relevant question is which networks and assets your customers and counterparties actually use, and how you want incoming balances to settle.
- KYB onboarding verifies the business behind the merchant account.
- AML awareness is a process, not a status halfin grants — and halfin is not 'licensed' in any country.
- Keep your own customer checks, screening, and per-order records as the source of truth.
- Availability is subject to jurisdiction and sanctions screening; see the restricted-countries note.