Every eSIM business eventually takes a payment for a profile the provider does not deliver. The failure itself is rarely the problem. What matters is what happens next: what the traveller is told, what tries again and for how long, and who decides whether the money goes back.
Failure is a normal state
Provisioning an eSIM means asking another company's system for a profile and waiting for the answer, and sometimes that request fails: the provider is down, a plan was withdrawn, an account limit was reached, or the call timed out. Treat it as a normal state with a designed response, because the traveller has already paid.
Treating this as an exception is the mistake. It is a normal state that needs a designed response, because the traveller has already paid and is standing somewhere with no data.
Designing for it means answering three questions before the first failure arrives. What does the traveller see? What retries on its own, and for how long? And who decides when to stop trying? The rest of this article takes them in order.
What the traveller should see
The traveller should see the truth in plain words: the payment went through, the eSIM is taking longer than usual, and it will arrive by email. They should never see a success screen for something that did not happen, a spinner that never resolves, or your provider's name in an error message.
What the traveller must never see is the provider's name in an error message. They bought from you. The supplier behind the plan is your commercial arrangement, and putting it on screen at the worst moment transfers your problem to someone who cannot act on it.
Tell them before they have to ask. An email saying the eSIM is running late, sent as soon as the first attempt fails, turns an anxious traveller into a patient one. And once it is clear the eSIM will not arrive soon, say that too. "We could not issue your eSIM, the fault is ours and we already know about it" is a sentence a traveller can act on. A page that keeps promising an update is not.
A failed order that is visible and being retried is an inconvenience. A failed order that looks successful is a refund and a review.
Retry, then escalate
Retry automatically first, because most provisioning failures are temporary and clear on a later attempt. Keep the retries bounded, and once they run out, put the order in front of a person: on the order screen, with the provider's own error message and a way to try again, not in a log file nobody reads.
Most failures are transient and clear on a second attempt a few seconds later. Retrying automatically, with a gap that grows each time, resolves the majority without anyone noticing. What matters is that the retries are bounded: after a handful of attempts the order stops being a technical problem and becomes a human one.
Put together, a failed order should move through four stages:
- Automatic retries. Spaced further apart each time, and limited in number.
- The traveller is told. An email that says the eSIM is late, before they have to ask.
- A person sees it. On the order screen, with the provider's own reason and a way to try again.
- A person decides. Try again, take it up with the provider, or refund.
One safeguard matters more than any other here: trying again must never issue a second eSIM for an item that already has one, and must never charge the traveller twice. A retry that can buy a duplicate profile turns a delivery problem into a money problem.
Refunds are a decision, not a rule
Do not refund automatically when provisioning fails. A traveller about to board usually wants the eSIM, not their money back, and an automatic refund removes the chance to fix the order a few minutes later. Keep the order open until it is either delivered or a person decides to close it.
It is tempting to refund automatically after a failure. Resist it. An automatic refund closes the order at exactly the moment it could still be saved, when the provider is back a few minutes later and the traveller is still waiting for their eSIM.
The order should stay open until either it provisions or a person decides to close it. The decision is yours because the customer relationship is yours: you know whether this traveller is at a desk in front of you or somewhere in a different time zone.
When a refund is the right answer, make it promptly and tell the traveller in the same message. A refund that arrives silently three days later looks like a second failure.
Reading the failure log
One failure is noise; a pattern is information. Failures that cluster on one provider call for a supplier conversation, failures on one destination suggest a withdrawn plan and an out-of-date catalogue, and failures bunched in time point to an outage. Each pattern needs a different decision, so keep the reason with every failure.
| Pattern | Likely cause | What to do |
|---|---|---|
| A single failure | A temporary error | Let the retries run and check the order later |
| Many failures, one provider | A problem on the supplier's side, or with your account there | Raise it with the provider, quoting their own error messages |
| Many failures, one destination | The plan was withdrawn or changed | Update your catalogue and stop selling the plan |
| Many failures in a short window | An outage | Wait, keep travellers informed and try again when it clears |
Reporting that lists reason, provider and amount together turns those three cases into three different decisions. Without it, every failure looks the same and gets the same shrug.
How it works with eSIMLab
- Retried on its own A paid order without its eSIM is tried again each time Stripe redelivers the payment event, and each time the traveller opens their order link.
- The traveller is told They are emailed that their eSIM is running late. Their order page says so under your brand, never the provider's.
- You see the reason The order screen shows the provider's own error, word for word, with a button to try issuing it again.
- You decide on refunds Nothing is refunded automatically. The money is in your own Stripe account, and a refund is made there.
Stripe keeps redelivering a payment event it was not told succeeded for up to three days, so an order caught by a short provider outage can still be issued without anyone pressing a button. Trying again from the order screen can never issue a second eSIM for an item that already has one, and never charges the traveller. The Issued eSIMs screen can be filtered to failed profiles, which is the quickest way to see whether failures are clustering.
Frequently asked questions
What happens if an eSIM fails to provision after payment?
The payment has been taken but no profile exists yet. The order should stay open and be retried automatically, and the traveller should be told the eSIM is running late. If the retries do not succeed, a person decides whether to try again, raise it with the provider or refund.
Should failed eSIM orders be refunded automatically?
No. Many travellers would rather have the eSIM a little late than their money back, and an automatic refund closes the order before it can be fixed. Refund when a person has decided the order cannot be delivered in time, and tell the traveller when you do.
Does eSIMLab retry failed orders?
Yes. A paid order whose eSIM was not issued is retried each time Stripe redelivers the payment event and each time the traveller opens their order link, and the order screen has a button to try again. A retry never issues a second eSIM for the same item and never charges the traveller again.
Will my customer see which provider failed?
No. The traveller bought from your brand, and the storefront only tells them that their eSIM is late or could not be issued. The provider's own error message appears on the order screen in your dashboard, where you can act on it.
