Your provider and payment accounts

What Connections holds

Connections lists the two outside accounts your store runs on: the eSIM provider that issues the eSIMs, and the payment account that takes the money. Both are yours. A standing band on the screen repeats the deal — "Esimbit stores them encrypted and uses them only to fulfil your own orders. Customers pay into your payment account; we never hold funds or inventory."

The header counts what you have — "1 eSIM provider(s) · 1 payment account(s) — all yours" — and carries two buttons, "Add payment account" and "Add eSIM provider". Either one opens a form on the page itself, headed "New connection".

• The form asks for Provider, Label and Environment, then one masked field for each credential that provider needs.
• A credential the provider can work without is tagged "optional" beside its name.
• There is one button: "Connect and verify". It stores the keys and tests them against the provider in a single press — there is no save now, test later.

A connection that saves but fails the test is kept, not thrown away. The panel says what happened: "The connection is saved but marked invalid — no orders will be routed through it until it verifies." It will sit in your list looking like a connection while nothing routes through it, so read the toast rather than the row.

Reading a connection

Each row leads with the label you gave it, then a line of facts about the account behind it. eSIM providers and payment accounts show different facts, because different things go wrong with each.

A badge on the right of the row says where the connection stands: active, pending, invalid or disabled. Only an active one is used — an invalid provider fills no orders, and an invalid gateway leaves your setup incomplete.

Testing a connection

"Test" asks the provider, right now, whether the stored keys still work. Reach for it when an order has not been filled, when someone else has been in your provider account, or before you send traffic at your store.

If the answer is yes, a toast confirms the connection reconnected and the verified time on the row moves to now. If the answer is no, you get "The provider rejected those credentials" and the row goes invalid — from that moment nothing routes through it.

Nothing on the row updates itself. If your keys are revoked in the provider’s dashboard, the row keeps its old verified time and its old badge until something asks again — a customer’s order, or you pressing Test. A green row is not a health check.

Bringing in new packages

"Sync catalog" re-reads everything your provider offers you, with the cost you pay, and feeds it into Catalog & pricing. Press it after your provider adds destinations or moves its wholesale prices. Payment rows have no such button — there is nothing to sync from a gateway.

The panel queues the job and tells you so: "Catalog sync queued" / "Packages and costs appear in Catalog & pricing when the sync finishes." Packages arriving for the first time are priced by your store markup, unless you give them a price of their own.

That toast is the last thing this screen will say about it. If the job cannot even be queued you are told "Sync could not be queued" — but whether it then finished, how many packages it found, and whether it failed are not reported here. There is no progress bar and no completion notice. Give it a minute and look at Catalog & pricing.

Replacing keys

There is no edit. "Replace keys" opens the same form with the provider locked and every credential field blank, and saving it removes the old connection and creates a new one. The form says so: "Keys are stored encrypted and never shown again — only the last four characters. Replacing a key removes the old connection and creates a new one."

So gather everything before you start. If your provider needs a key and a secret, you cannot replace just the secret — both fields come back empty and both have to be filled in again.

The old connection is deleted before the new one is created. If the new credentials are rejected — a typo, or a key already revoked at the provider’s end — you are left with no connection at all, and the working keys you had are gone. Have every credential in front of you before you press "Connect and verify".

Moving from sandbox keys to live ones is this same operation: Replace keys, choose the live environment, paste the live credentials. What you end up with is a new connection — and for a payment account, a new connection means a new webhook URL while your gateway is still pointing at the old one.

The webhook signing secret

Your gateway takes the money. Something then has to tell Esimbit that it happened, or no eSIM is bought from your provider and nothing is delivered. That something is a webhook from your gateway, and the signing secret is what proves the message really came from your gateway — every notification’s signature is checked before an eSIM is delivered.

On the credential form the field is labelled "webhook secret" and tagged "optional"; the setup step calls it the webhook_secret credential. It is optional only in the sense that the connection will save without it. The form warns you as you fill it in: "Leave the webhook secret empty only if you are still testing: without it we cannot verify that a customer paid, so no eSIM is delivered."

A payment row with no secret stored carries an amber line of its own: "No webhook signing secret stored — orders cannot be confirmed automatically until you add one."

Nothing stops you selling in this state. Your store publishes, checkout works, the customer is charged, and the money lands in your gateway — and no eSIM is ever delivered. That amber line on the payment row is the only lasting sign of it anywhere in the panel. Fix it before customers reach your store, not after.

Registering the webhook, in the right order

The webhook needs an address to send to. The panel builds it and shows it under "Webhook URL" on the Payment account step of setup, once a payment connection exists, with a Copy button beside it. That address carries the id of the connection it belongs to — which is why the order you do things in matters.

1. Save the payment connection with your gateway key. The Payment account step then shows you the webhook URL.
2. Copy that URL and create a webhook in your gateway dashboard pointing at it.
3. Your gateway hands you a signing secret. Back in the panel, press "Add webhook secret" and enter the gateway key and the secret together — this is a replace, so both fields are empty.
4. Saving moves you on to the next setup step. Go back to "Payment account" in the step list, read the webhook URL again — it has changed — and update the webhook in your gateway to match.

The last step is the one that gets skipped, and skipping it costs you every sale until someone notices: the connection that URL named no longer exists, so your gateway is announcing payments to nothing. After any "Replace keys" on a payment account, check that the webhook in your gateway still matches the URL the panel is showing now.

Which provider fills an order

With more than one eSIM provider connected, something has to choose between them for each order. The eSIM providers card states the rule in force in one line at the top of the card. It is a statement, not a switch — there is nothing on this screen that changes it.

Least-cost routing moves your costs and your listed prices together. A package following the store markup is priced from the cheapest source that could actually fulfil it, so when a cheaper source appears the package gets cheaper for your customer at the same margin. A package you priced by hand does not move — the saving lands in your profit instead.

• Your plan and its limits →

With a single eSIM provider connected, the line makes no difference to anything — there is nothing to choose between.

When your plan will not take another connection

Your plan sets how many eSIM providers and how many payment accounts you can hold. You meet the limit when you try to add the next one: the form refuses with "Connection not saved" and "Your plan does not allow another connection of this type." There is no upgrade prompt on this screen. The counts live on the Subscription screen.

A limit blocks the next addition and removes nothing. No connection is ever disconnected for you, and nothing already connected stops working because you reached a limit.

Disconnecting a provider

Disconnecting has its own red-bordered card at the bottom of the screen, listing every connection as a pill. Click one and the card asks you to confirm it by name, then offers "Disconnect" and "Cancel". There is nothing to type; one click does it.

The card spells out the consequence before you start: "Disconnecting stops new orders through that provider immediately. Already-issued eSIMs keep working, and their usage stops updating once the connection is gone."

• New orders stop routing through it the moment you confirm. There is no wind-down.
• Customers who already hold an eSIM from that provider keep their data. Nothing is revoked.
• Their remaining-data figures freeze at whatever was last read, and "Read usage now" on the eSIMs screen has nobody left to ask.

Disconnecting your only payment account, or your only eSIM provider, genuinely un-finishes your setup: the panel works it out from your live account rather than remembering that you once finished, so the setup card returns to your Overview. Reconnecting later gives you a new connection — and, for a payment account, a new webhook URL to register.

Who can open this screen

Connections is closed to Support entirely. A Support member sees a lock panel and no data at all — not even the masked hint, because the last four characters of a key still say something about your provider account.

The panel gives the reason rather than hiding the screen: "Provider and payment credentials are visible to Admins and the account owner only — even the masked hint says something about your provider account."

Everything in this chapter — testing, syncing, replacing keys, disconnecting — is an Admin or owner job. Someone you hired to answer customers cannot re-test a connection for you, so a stalled delivery has to come back to you.