Nigerian WordPress hosting where a failed card is not a lost sale.
Card declines and gateway timeouts are routine here rather than exceptional. A checkout with one payment path treats a normal event as the end of the transaction.
Failure is the normal path.
Designing a checkout around the successful case means designing it for the minority of attempts.
More than one way to pay, tried in order
When a gateway times out the customer should be offered another route rather than an error. Failover is part of the checkout rather than a manual fallback.
Retries that cannot charge twice
Retrying an attempt whose outcome is unknown is how a customer gets debited twice. Requests carry an idempotency key so a repeat is recognised rather than re-executed.
Declines recorded as data
A decline reason tells you whether to retry, offer another method or stop. Discarded, every failure looks identical and nothing improves.
Pending states that resolve
An attempt whose result never arrived is neither paid nor failed, and left alone it becomes an order nobody reconciles.
Built for variable mobile networks
Traffic is overwhelmingly mobile with wide quality variation, so fewer round trips beats fewer kilobytes.
One path is not enough.
A checkout offering a single gateway converts whatever share of attempts that gateway happens to accept today, and treats the rest as customers who changed their minds.
- Failover between payment providers at checkout
- Retries carrying an idempotency key
- Decline reasons recorded and used
- Unresolved attempts reconciled
The measure is completed payments.
Page speed barely moves the number here. How many attempts eventually succeed does, and that is a matter of routing and retries.
What we change for Nigerian stores
Payment failure being common rather than exceptional changes the whole shape of a checkout.
| Setting | What we do | Why |
|---|---|---|
| Gateway routing | Failover to an alternate provider on timeout or decline | With declines routine rather than rare, a single payment path converts only the share that one provider happens to accept today. |
| Retry safety | Idempotency keys carried on every attempt | Retrying a request whose outcome is unknown is exactly how a customer is debited twice, and that is worse than the original failure. |
| Decline handling | Reasons recorded and acted on | A decline reason distinguishes retry from offer-another-method from stop, and discarding it makes every failure look the same. |
| Pending resolution | Unresolved attempts reconciled rather than left | An attempt with no returned result is neither paid nor failed, and untouched it becomes an order that never balances. |
| Round trips | Reduced ahead of payload size | Traffic is overwhelmingly mobile with wide network variation, where an extra sequential request costs more than the bytes it carries. |
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 is my Nigerian conversion rate low?
Is retrying a payment safe?
Should I record decline reasons?
What about attempts that never return a result?
Convert the second attempt.
Move the store across. Migration is free, payment routing reviewed.