Mexican WordPress hosting where the invoice comes after the sale.
A Mexican customer buys first and asks for a tax invoice afterwards, sometimes days later. The order has to remain invoiceable long after it was paid and shipped.
Two transactions, not one.
The sale and the invoice are separate events here, separated by an unpredictable amount of time.
Orders that stay invoiceable
A customer requesting an invoice a week later needs the order intact with everything required to issue one. Orders remain in an invoiceable state rather than being closed at fulfilment.
Tax details collected without blocking the sale
Requiring a tax identifier at checkout loses buyers who do not need an invoice. Those details are captured when the invoice is requested instead.
Stamping handled as an outbound call that can fail
Issuing an invoice means a request to an authorised provider which can be rejected. Those calls are retried and logged rather than fired once and assumed.
Records kept for the retention period
Issued invoices have to be reproducible for years, which is an archive and backup requirement rather than a plugin feature.
Origin placement decided
Mexico sits between two large markets and much of the audience may be north of the border, so placement is a deliberate choice.
The order is not finished when it ships.
A store that closes an order at fulfilment cannot issue an invoice for it a week later, which is when a meaningful share of customers ask.
- Orders remain invoiceable after fulfilment
- Tax identifiers optional at checkout
- Stamping calls retried and logged
- Issued invoices retained and reproducible
The measure is invoices issued.
Nobody complains that a Mexican store is slow. They complain that they cannot get an invoice for something they bought last week.
What we change for Mexican stores
The invoice being a separate, later event from the sale drives everything here.
| Setting | What we do | Why |
|---|---|---|
| Order lifecycle | Kept invoiceable well after fulfilment | Customers request a tax invoice days after buying, and a store that closes the order at dispatch has thrown away the ability to issue one. |
| Checkout fields | Tax identifiers optional rather than required | Demanding tax details from every buyer loses the ones who do not need an invoice, which is most of them on a consumer store. |
| Stamping calls | Retried with failures recorded | Issuing an invoice requires an authorised provider to stamp it, and that request can be rejected - fire-and-forget leaves the seller believing it succeeded. |
| Invoice archive | Retained and reproducible for the statutory period | The obligation runs for years and requires producing the document on request, which is a backup question rather than a store feature. |
| Origin placement | Decided explicitly given a cross-border audience | A large share of a Mexican store's traffic can be north of the border, so an inherited origin serves an assumption nobody checked. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Why can't I invoice an order from last week?
Should I require tax details at checkout?
What if the stamping provider rejects an invoice?
How long must invoices be kept?
Issue the invoice whenever they ask.
Move the store across. Migration is free, invoice records retained.