IMBA Wallet B2B API: cards, eSIM and gift cards for your product
IMBA Wallet gives companies programmatic access to issue and top up Visa/Mastercard 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.
Autonomous software agents that register a key and spend prepaid USDT are a different API: see IMBA Agent API and agent tiers (tier 0 catalog-only; no Partner JWT, /api/partner, or ledger 2403).
B2B API at a glance
| Who it is for | Sites, bots, marketplaces, and fintech products that need digital-product issuance through their own interface |
|---|---|
| IMBA retail channels | The site imbawallet.com, the web app, Telegram, MAX, RuStore, and Google Play. Virtual cards are not limited to the Telegram bot |
| B2B | A separate REST API for companies that sell products to their own customers |
| Cards | Visa / Mastercard, USD; issuers — Singapore and Hong Kong. EUR cards are in preparation |
| API products | Cards with issue and partner-side top-up; eSIM and gift cards if those catalogs are enabled (gift cards: about 20,000 catalog positions, around 2,000 unique items) |
| Settlement | Company USDT balance; funded by TRC-20 deposit. Card issuance is paid; tariffs are set in the contract |
| KYC | Simplified: cardholder data without liveness or passport biometrics. .ru emails and +7 phones are not accepted |
| Your customers | Do not sign in to IMBA Wallet; orders come from your server |
| Status delivery | HMAC-signed webhook plus status polling via API |
| Referral program | Available in IMBA Wallet retail; B2B terms are set in the contract |
| API docs | Partner B2B: api-docs.imbawallet.com. Prepaid Agent API is a separate product: /agent — not a Partner guide. |
What the API gives a business
You embed IMBA digital products into your sales flow and keep the customer in your interface — including for top-ups.
Card product, wallets, and the App Store
The current line is virtual Visa and Mastercard cards in USD. Issuers are Singapore and Hong Kong. EUR cards are in preparation.
Google Pay is supported on two card products. Simultaneous Google Pay and Apple Pay support is available on one product, which has a higher issue price. New cards are in preparation: a lower issue price and support for both wallets.
App Store billing is not supported on current cards. For purchases in the Apple ecosystem, use gift cards.
KYC and cardholder data
Virtual card issuance uses simplified verification: the customer fills cardholder data on your side. Liveness biometrics, selfies, and passport biometrics are not required.
Emails in the .ru zone and +7 phone numbers are not accepted: the issuer blocks such cards immediately. The phone number has no operational role for issuance and is not used for OTP on payments — the partner shows the 3-D Secure code in its own cabinet.
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: the site, Telegram, MAX, RuStore, Google Play. 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.
For a card, the customer fills cardholder data on your side. The card is issued with that data. Do not send .ru emails or +7 phones.
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.
How integration works
The partner creates a key, sends IMBA the public key, and receives an HMAC secret to verify webhook signatures. USDT is then credited to the settlement balance; from that balance the company buys cards, top-ups, eSIM, and gift cards within the enabled catalogs.
Without sufficient available USDT the order is not created. Card top-ups, eSIM, and gift cards are fulfilled on your side: the customer stays with you, and IMBA executes the operation in the background.
Balance, deposit, and issuance cost
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.
Card issuance is paid. Tariffs, top-up fees, and whether eSIM/gift catalogs are enabled are set in the contract.
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; signatures are verified with the HMAC secret issued during key exchange.
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, tariffs, and webhook.
Exchange keys — send the public key, receive HMAC for webhooks, fund USDT on TRC-20, and run a trial order.
Go live after checking statuses, idempotency, and how you deliver data to customers.
Related guides
Mintlify: B2B KYB, /partner paths. Agent API docs
Separate Mintlify product. Prepaid catalog, not B2B. White Label and B2B
Brand, reseller model, no $15–20k onboarding fee. Virtual card
How the retail Visa/MasterCard product works. Travel eSIM
Mobile data abroad and Russia plans. Gift cards
Digital brand codes paid with USDT.
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.
Are virtual cards available only in the Telegram bot?
No. Retail customers use the site imbawallet.com, the web app, Telegram, MAX, RuStore, and Google Play. Companies use the B2B API. English-language group: @imbawallet_eng.
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.
Is full KYC or liveness required to issue a card?
No. Virtual cards use simplified verification: cardholder data without liveness biometrics and without passport biometrics. .ru emails and +7 phone numbers are rejected — the issuer blocks such cards. The phone number is not used for payment OTP.
Which cards: currency, issuer, Google Pay and Apple Pay?
The current line is Visa and Mastercard in USD, issued in Singapore and Hong Kong. EUR cards are in preparation. Two products support Google Pay; one product supports both Google Pay and Apple Pay and has a higher issue price. New cards will be cheaper and support both wallets. App Store billing is not supported on current cards; use gift cards for the Apple ecosystem.
Do we pay to issue cards?
Yes. Card issuance is paid. Tariffs, top-up fees, and catalog scope are set in the contract.
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?
Visa/Mastercard virtual cards with issue and partner-side top-up. Travel eSIM follows the same model. Digital gift cards: about 20,000 catalog positions (including denomination repeats) and around 2,000 unique items. eSIM and gift-card catalogs are enabled at onboarding.
Is there a referral program?
Yes. IMBA Wallet’s retail service has a referral program. B2B partnership terms are set separately in the contract.
How do I know when a card or order is ready?
The primary channel is a webhook to your URL. Notification signatures are verified with the HMAC secret issued during key exchange. 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.