Brazilian WordPress hosting for payments that finish elsewhere.
A Brazilian checkout often ends outside your site - in a banking app, or on a slip paid days later. The order has to survive that gap.
The order outlives the session.
Brazilian payment methods break the assumption that a checkout completes while the customer is still on the page.
Boleto orders that are still there on Thursday
A slip generated on Monday might be paid three days later. The pending order, its stock reservation and its confirmation all have to survive that window without anyone touching the site.
Pix confirmations that arrive as webhooks
Payment confirmation comes from the provider rather than from the customer's browser. That callback must be reachable, unthrottled and never served from cache.
LGPD answered with specifics
Brazil's regime asks who controls the data, who processes it and where it goes. Those are answered with a location and a list rather than a summary.
An origin chosen for South American reach
Brazil is far from most infrastructure. Origin placement is a decision we make with you rather than a default nobody discussed.
Instalment logic that stays correct
Prices displayed as instalments are calculated per product and per method, and those calculations must not be cached across customers.
A checkout that finishes days later.
Almost every ecommerce assumption breaks here. The order exists before the money does, and the confirmation arrives from a third party long after the customer left.
- Pending orders survive multi-day payment windows
- Provider webhooks reachable and never cached
- Instalment display calculated per customer
- Data handling documented for LGPD
The webhook matters more than the page.
A fast storefront that misses a payment confirmation has failed at the only thing that counted. Callback reliability is the measurement here.
What we change for Brazilian sites
Local payment behaviour drives most of this, and it is genuinely different from card-first markets.
| Setting | What we do | Why |
|---|---|---|
| Pending order lifetime | Sized for multi-day boleto windows | A payment slip can be settled three days after it was generated, so an order expiry written for card checkouts cancels sales that were about to be paid. |
| Provider callbacks | Reachable, unthrottled and never cached | Confirmation arrives from the payment provider rather than the customer's browser, so a blocked or cached callback loses a payment that already succeeded. |
| Instalment display | Calculated per customer rather than cached | Instalment pricing varies by product and method, and a cached calculation quotes one customer terms that belong to another. |
| Origin placement | Decided explicitly for South American reach | Brazil sits far from most infrastructure, so accepting a default origin means accepting a distance nobody measured. |
| LGPD documentation | Controller, processor and location recorded | Brazil's regime asks who holds what and where it goes, and those answers have to exist before somebody asks rather than afterwards. |
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 do my boleto orders get cancelled?
Are payment webhooks reliable here?
Where should a Brazilian site be hosted?
Can you help with LGPD?
Keep the order until the money lands.
Move the store across. Migration is free, payment flows checked.