Custom software development in Mexico
In Mexico an invoice is not issued: it is stamped. That one-word difference reorganises the checkout, the database and what happens when a customer pays in two instalments.
Let us be clear about Mexico
We do not yet have a client in Mexico. The above is what the market requires and how we approach it from our base in Spain and Argentina, where we already operate. We would rather say so up front than have it surface in the first meeting.
Building retail software for Mexico means no receipt is valid until a SAT-authorised provider stamps it and returns a fiscal folio. The system does not generate invoices: it generates requests a third party validates, and it must know what to do when that third party errors, delays, or the receipt has to be cancelled with the recipient's approval.
How you get paid
The payment method decides the checkout.
Currency: Mexican peso (MXN). A checkout copied from another country fails here before it fails anywhere else.
SPEI
Real-time interbank transfer operated by the Bank of Mexico. It is the rail money moves on between accounts and what companies expect for large transactions.
Cash payment in store
A significant share of online commerce is paid in cash at a convenience chain using a printed reference. The order is created unpaid, expires, and the system must hold stock meanwhile and release it if nobody pays. It is a flow that does not exist in Europe and has to be designed separately.
Interest-free instalments
The equivalent of Argentine instalments, with the twist that the financing cost is usually borne by the merchant. It affects margin and therefore the displayed price.
Tax obligations
What the tax authority demands from the software.
It is not a module bolted on at the end. It shapes the data model, and redoing it later costs far more than getting it right from the start.
| Framework | What it means for the system |
|---|---|
| SAT · CFDI 4.0 | The digital fiscal receipt is an XML with a mandatory structure that a PAC — authorised certification provider — validates and seals, returning a UUID. Without that seal there is no invoice, only a file. |
| Payment complement (REP) | When a sale is collected in instalments or after the receipt is issued, an electronic payment receipt must also be issued for each payment. A system that invoices on order confirmation and never issues the complement leaves the customer unable to deduct. |
| SAT catalogues | Every invoice line carries a product-or-service key and a unit key taken from official catalogues. It is not a free-text field: the catalogue is updated and the software must be able to follow. |
| Cancellation | Cancelling an already-stamped receipt requires a reason and, in many cases, the recipient's approval. It is not deleting a table row, and the data model has to reflect that. |
Experience
The mistake that shows up at filing time
Stamping is a call to a third party, and like any third-party call it can fail, stall or answer twice. A system that treats the sale as done the moment the request leaves, without storing the receipt's real status, ends up with collected sales lacking a valid invoice, and duplicate invoices when the retry lands late. The fix is the same as with card payments: an idempotency key, an explicit receipt status and later reconciliation against the PAC. Someone who has never done it does not know it is needed.
Regulatory framework
Who regulates the product.
COFEPRIS
Federal commission for protection against sanitary risks. It authorises medicines, food and medical devices, and its sanitary registration is the figure anchoring a product record in a vademecum or a health marketplace.
SENASICA
National service for agri-food health, safety and quality. It regulates veterinary products and withdrawal times, the Mexican equivalent of what SENASA does in Argentina and the AEMPS in Spain.
Data protection
Federal law on protection of personal data held by private parties. It requires an accessible privacy notice before collecting data and express consent for sensitive data, with its own rules for third-party transfers that do not match the GDPR's.
Other markets
The figures behind all of the above are on the pricing page, and the terms used here are in the glossary.
FAQ
Custom software in Mexico
Do you have clients in Mexico?
Not yet. We work from Spain and Argentina, and we say so openly. What we do have is the architecture solved for a market where invoicing is validated by a third party, which is what makes the Mexican case hard.
Can you integrate stamping with a PAC?
Yes. It is an integration with an external service that validates and seals, with the same reliability problems as any payment gateway: idempotency, explicit status and reconciliation. That is familiar ground for us.
How do you handle cash payment at a convenience store?
As a pending order with stock reservation and an expiry. It is a different flow from immediate payment and is designed separately, not patched on top of the card checkout.
Is development done in Mexican Spanish?
Content is written in neutral Spanish unless the project requires otherwise. Mixing Rioplatense voseo with peninsular tuteo on the same screen is a mistake we have corrected in our own projects.
A project in Mexico?
Tell us what you need and we will say what it involves in this market and what we do not know yet.