Card issuing API
2328 is a virtual card issuing API for teams that want to put a payment card in front of their users without becoming a licensed issuer. You register cardholders, issue cards under a sponsored BIN, fund them from your USDT wallet and control the entire lifecycle — freeze, unload, close — through one REST interface.
Building a card program the traditional way means a scheme licence, a BIN, a processor, a sponsoring bank and eighteen months of certification work before the first authorisation goes through. That work is already done here. What remains on your side is the part that is actually your product: who gets a card, what they can spend, and what the experience looks like.
The API is JSON only, all fields are camelCase, and every request except the public health check is authorised with a Bearer key. Money is always an integer in minor units with an explicit currency and scale — the wallet is USDT at scale 6, cards are USD at scale 2 — so there is never an ambiguous float in a ledger.
Cardholders
Register cardholders with the identity data the program requires, then issue one or many cards under each of them. Onboarding, limits and lifecycle are driven entirely from your side.
Instant virtual card issuing
Cards are created by a single API call and are usable immediately — no plastic, no shipping, no activation step. Issue one per user, per subscription, per campaign or per supplier.
Funding from a USDT wallet
Cards are funded from your stablecoin balance. USDT comes in at scale 6, the card balance is USD at scale 2, and the API is explicit about both so the ledgers never drift.
Full lifecycle control
Freeze, unfreeze, unload and close cards programmatically. A compromised card is dead in one request; an ended subscription costs nothing to shut down.
Balances and transactions
Read live card balances and transaction history across the whole program, including authorisations, settlements, declines and fees.
Orders and webhooks
Money operations are asynchronous: you submit an operation, receive an order, and treat the webhook as the source of truth rather than assuming success on a 200.
BIN sponsorship, without the two-year detour
Every card is anchored to a BIN — the number that tells the card networks which licensed institution stands behind it. Getting your own means becoming a principal member of Visa or Mastercard: regulatory licence, scheme collateral, capital requirements and years of certification.
Cards issued through 2328 run on an existing sponsored BIN. The sponsoring institution holds the scheme membership and settles with the network; you keep the product, the branding, the cardholder relationship and the economics. In practice that turns a licensing project into an integration project.
Onboarding is still real diligence — you will be asked who your cardholders are, where the money comes from and what your KYC and monitoring look like. The clearer those answers, the faster the program starts.
How an integration goes
- 1.Agree the program: cardholder profile, funding flow, geographies and limits.
- 2.Get API keys and check connectivity against the public GET /ping endpoint.
- 3.Register your first cardholder and issue a card in the live environment.
- 4.Fund the card from your USDT wallet and confirm the resulting order via webhook.
- 5.Wire balances, transactions and lifecycle operations into your product.
- 6.Go live and scale — issuance is a single call, so volume is not an engineering problem.
Frequently asked questions
Do I need my own licence or BIN to issue cards?
No. Cards are issued under an existing sponsored BIN, so you do not need to become a principal member of Visa or Mastercard. You describe your cardholders and funding flow during onboarding; the licensing and scheme settlement sit with the sponsoring institution.
What authentication does the card issuing API use?
Bearer authentication. Every request except the public health check carries Authorization: Bearer ck_{keyId}_{secret}. The key identifies your account, so no merchant or account IDs are passed in the payload. Keep the key on your backend only.
How are cards funded?
From your USDT wallet inside 2328. Funding converts stablecoin into a USD card balance. The wallet is USDT at scale 6 and cards are USD at scale 2 — amounts are always integers in minor units with an explicit currency and scale.
Are card operations synchronous?
Money operations are asynchronous. A funding or unload request returns an order that you track to completion, and a webhook confirms the final state. Read operations such as balances and transactions are synchronous.
Is there a sandbox environment?
There is a single live environment — no separate sandbox keys. A public GET /ping endpoint is available without authentication for liveness checks.
What can the cards be used for?
Typical programs cover online subscriptions, advertising spend, employee and contractor spending, marketplace payouts and general crypto-funded consumer spending. Permitted use cases are agreed during program onboarding.