IMBA Wallet B2B API: cards, eSIM and gift cards for your product
IMBA Wallet gives companies programmatic access to issue and top up virtual cards and — when enabled in the agreement — to buy travel eSIM plans and digital gift cards. You sell on your own site or service, collect payment yourself, and send fulfillment to IMBA over the API. The buyer stays with you — they do not need to open the IMBA Wallet app.
B2B API at a glance
| Who it is for | Sites, bots, marketplaces, and fintech products that need digital-product issuance through their own interface |
|---|---|
| Products | Virtual cards under an agreed card product; eSIM and gift cards only if those catalogs are enabled in the contract |
| Settlement | Company USDT balance; funded by TRC-20 deposit |
| Your customers | Do not sign in to IMBA Wallet; orders come from your server |
| Status delivery | Webhook plus status polling via API |
| Access | After contract: auth credentials, scopes, and notification URL |
What the API gives a business
You embed IMBA digital products into your sales flow without rebuilding card and eSIM rails from scratch.
How is B2B API different from a regular app account?
A retail IMBA Wallet user buys a card or eSIM for themselves. The B2B rail is for a company that resells those products to its customers.
| Who pays IMBA | Retail: the end user. B2B: the company from its USDT balance |
|---|---|
| Where the person buys | Retail: in the IMBA app. B2B: on the company’s site or service |
| How operations run | Retail: app UI. B2B: server-side API calls with the company token |
| Pricing | B2B tariffs are set individually at onboarding, separate from the retail catalog |
Typical sale flow
The customer pays you. Card acquiring, crypto, or another method stays on your side. IMBA does not verify that the end customer paid you.
Your backend calls the API. You send the product, amount, cardholder data for cards, and your external order id.
Funds are reserved on the company balance. If USDT is insufficient, the refusal is immediate and the order does not start.
Fulfillment finishes asynchronously. Success or failure arrives by webhook; on failure the reserve returns to available balance.
You deliver the result to the customer. Card access, eSIM profile, or gift-card code is shown in your own cabinet under the contract rules.
Balance, deposit, and USDT withdrawal
The company has one USDT settlement balance. Funding is a USDT transfer on the TRC-20 network to a sticky deposit address. That balance pays for card issue and top-up, eSIM and gift-card purchases, and USDT withdrawal when the agreement allows it.
Balance responses show available and reserved amounts. While an operation is in progress, part of the funds is held; on cancel or failure the hold is released. End buyers do not get a personal IMBA wallet account in this rail.
Available operations
Scopes and product catalogs are enabled at onboarding. The base surface usually includes cards; eSIM and gift cards are connected separately and may be off by default until enabled in the contract:
The API also exposes balance, the deposit address, and USDT withdrawal requests (with the matching access right). Idempotency uses your external order id: repeating the same request with the same body does not create a second charge.
Security and notifications
Access uses cryptographic server auth (short-lived access token and limited scopes). The company id comes from the token, not from the request body. Async events go to a registered webhook URL with signature verification.
Sensitive card credentials and activation codes are not sent in webhooks: they are fetched with a separate protected status or details request under the contract rules. Internal ledger identifiers are not exposed.
Who it fits
Card marketplace — you sell virtual cards, collect payment yourself, and issue via API after payment.
Travel product — add eSIM to a trip checkout (if the catalog is enabled) and show activation data inside your app.
Gift-card bot or storefront — brand catalog on your side, purchase fulfillment and code delivery through IMBA when the catalog is enabled.
Fintech / agency channel — you need programmatic digital-product issuance without every end customer completing retail IMBA onboarding.
How to get access
Contact IMBA Wallet support at support@imbawallet.com or via the Telegram bot / @imbawallet_eng group and mention that you need the B2B API.
Agree on the contract and products — legal entity, card products, whether to enable eSIM/gift, limits, and webhook.
Receive access credentials, fund USDT on TRC-20, and run a trial order on the agreed products.
Go live after checking statuses, idempotency, and how you deliver data to customers.
Related guides
FAQ
What is the IMBA Wallet B2B API?
It is a programmatic interface for companies that sell virtual cards, travel eSIM, and gift cards to their customers through their own site, bot, or marketplace. Orders are fulfilled by IMBA while the buyer stays in the company’s interface.
Do end customers need an IMBA Wallet account?
No. End buyers do not sign in to the IMBA Wallet app and do not receive retail client access. All calls are made by the company’s server with a B2B token.
How are API issues paid for?
From the company’s USDT balance. The balance is funded by a USDT TRC-20 deposit to a sticky address. If available funds are insufficient, the order is not created.
Which products are available via API?
Virtual cards with issue and top-up under an agreed card product. Travel eSIM and digital gift cards — only if those catalogs are enabled at onboarding; they may be off by default.
How do I know when a card or order is ready?
The primary channel is a webhook to your URL. You can also poll status via API. Full card credentials and activation codes are not sent in webhooks — they are fetched with a separate protected request under the contract rules.