Chilean WordPress hosting where the security step does not lose the sale.
Chile is card-first, which means nearly every checkout includes an authentication challenge on the bank's page. The customer leaves your site and has to arrive back.
The bank interrupts the sale.
Strong authentication is good for fraud and hard on conversion, and the handling decides which of those you get.
A session that exists on return
The customer is sent to their bank and returned by callback. A session rotated or cached away in between produces an authenticated payment and an abandoned cart.
Callbacks never served from cache
The return URL carries a single-use result, so a cached or throttled response turns a completed authentication into a failed order.
Timeouts sized for a human step
The challenge may involve waiting for a code on another device, which takes far longer than any network timeout allows for.
Drop-off measured at the right point
Abandonment during authentication looks identical to abandonment at checkout unless the two are distinguished, and only one of them is fixable by you.
Origin placement decided
Chile is distant from most infrastructure and long north to south, so origin choice is deliberate rather than inherited.
Lost between two pages.
The bank says the payment authenticated and the store has no order. Almost always the session did not survive the round trip, and it is recorded as a customer who changed their mind.
- Session preserved across the authentication round trip
- Callback URLs excluded from caching and throttling
- Timeouts sized for a human with a second device
- Authentication drop-off measured separately
Authenticated and ordered.
The number worth watching is the share of authentication attempts that end with an order, not the speed of the page in front of them.
What we change for Chilean stores
A mandatory detour to the bank sits in the middle of every checkout, and everything here protects the return journey.
| Setting | What we do | Why |
|---|---|---|
| Session continuity | Preserved across the authentication redirect | The customer is returned by callback after authenticating, and a session rotated or dropped in between leaves the payment approved and the order missing. |
| Callback handling | Excluded from caching and rate limiting | The return URL carries a single-use result, so a cached or throttled response converts a successful authentication into a failed order. |
| Timeout window | Sized for a person retrieving a code on another device | The challenge frequently involves a second device, which takes far longer than a timeout written for a network response allows. |
| Drop-off attribution | Authentication abandonment measured separately from checkout | The two look identical in aggregate, and only one of them is something you can act on. |
| Origin placement | Decided explicitly for a distant, elongated market | Chile is far from most infrastructure and long north to south, so an inherited origin is an unmeasured cost. |
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 authenticated payments not produce orders?
Can the 3-D Secure callback be cached?
Why do challenges time out?
How do I tell authentication drop-off from checkout drop-off?
Bring the customer back.
Move the store across. Migration is free, authentication flow tested.