Blog / ON5 Protocol

What Is ON5 Protocol? The Card Issuing Network Explained

ON5 Protocol is a card issuing network for launching branded Visa and Mastercard virtual cards funded with stablecoins. What it is, what it is not, and how it works.

10 August 2026 9 min read

If you have ever tried to launch a card programme, you already know the shape of the problem. Issuing a card is not one product. It is a stack: a licensed issuer, a BIN sponsor, a processor, a KYC provider, a ledger, a 3-D Secure flow, a settlement account, and a compliance function that sits across all of it. Assembling that stack is the reason card programmes are measured in quarters rather than weeks.

ON5 Protocol collapses that stack into an account and an API. You top up a balance with stablecoins, choose a card product, and issue a card. The card runs on Visa or Mastercard rails, so it works anywhere those networks are accepted. The programme underneath it — the issuer relationship, the processor integration, the settlement — is ON5's problem, not yours.

What ON5 actually is

ON5 is a card issuing network. Three things define it:

• It issues on established rails today. Cards are Visa or Mastercard, so they work anywhere those networks are accepted. A card is only useful where merchants already take it, and that is why issuing begins on the networks that already have that reach.
• It is funded with stablecoins. Your balance is topped up with USDT or USDC on Ethereum, BNB Smart Chain, Base or Kaanch Network. There is no wire, no correspondent bank, and no multi-day settlement window before you can issue.
• It is white-label by default. The cardholder sees your brand: your name on the card, your logo in the email, your support address at the bottom of it. ON5 appears as the network underneath, in the way Visa appears on a bank's card.

What ON5 is not

Being precise about this saves everyone time.

• It is not a consumer app. ON5 has no retail customers. Its customers are businesses that issue cards to their own users.
• It is not a bank. ON5 does not take deposits, pay interest, or hold customer funds as a bank does. A balance on ON5 is a prepaid float against which cards are issued and loaded.
• It is not a crypto exchange. Stablecoins fund a balance denominated in USD. There is no trading, no order book, and no exposure to a volatile asset between deposit and spend.
• It is not, today, a card network of its own. Cards issued through ON5.com run on Visa and Mastercard. A decentralised ON5 Card Network is in development and testing separately — see below — but it is not yet something you can issue on.

How a card gets issued

The whole flow, end to end:

1. Activate. A one-time account activation of $5,000 worth of KNCH, paid on the Kaanch Network. The dashboard quotes the exact KNCH amount at the current price and holds it for an hour; the price used is frozen on the record.
2. Deposit. Send USDT or USDC to your account's deposit address. The network scans for the transfer, waits for confirmations, and credits your balance in USD.
3. Choose a product. Each card product determines the network the card runs on — Visa or Mastercard — and the fee charged to issue on it.
4. Issue. Provide the cardholder's name and email, the amount to load, and a design. The card is created and the load and fee are debited from your balance.
5. The cardholder is told. They receive a welcome email carrying your brand, showing their card in the design you chose, with the number masked to the last four digits.

Where the money sits

Every movement is recorded in a double-entry ledger. A card issue does not simply subtract a number from a balance — it debits your available balance, credits a pending account, and then commits when the network confirms the card exists. If the card fails, the reservation is released and the funds return to available. The ledger is the source of truth, and it balances to zero by construction.

This matters more than it sounds. The common failure in prepaid programmes is a balance that drifts from reality because a failed operation left money in neither place. A double-entry ledger with reserved and committed states makes that arithmetically impossible rather than merely unlikely.

Fees, stated plainly

ON5 charges per operation, as a fixed component plus a percentage. A card issued at $5.00 + 1% on a $100 load costs $6.00. The two parts are shown separately in the dashboard and in the API, because a single blended number is only true for the amount it was computed from.

The fee that applies is captured at the moment of the transaction and stored with it. Changing a rate never rewrites what was already charged, so a historical statement stays correct forever.

The API

Everything the dashboard does, the API does — same balance, same fees, same limits. Keys are scoped, so a key that only reads cannot create them:

Operations that move money — creating a card, topping one up — require an Idempotency-Key. Retry with the same key and you get the original result rather than a second charge. That is not a nicety; it is the difference between a network timeout being a non-event and being a duplicate card.

Keys can also be restricted to specific IP addresses or CIDR ranges. A key used from anywhere else is rejected exactly like an invalid one — the response never reveals that the key itself was valid, so it cannot be used to probe which keys exist.

Multi-chain funding

Deposits are accepted in USDT and USDC across four chains. Each has its own confirmation requirement, chosen to match the reorganisation risk of that chain:

One EVM address serves all of them. You are emailed when a deposit is detected and again when it is credited, so a funding operation is observable rather than something you poll for.

The ON5 Card Network: what is being built

Everything above describes ON5.com as it works today: a platform that turns any business into a card issuer on Visa and Mastercard. Alongside it, ON5 is building something more ambitious — a decentralised card network of its own, at ON5.org.

The intent is a network that sits alongside Visa, Mastercard, American Express, RuPay, JCB and Discover rather than depending on them. Two things would be different about it:

• Anyone can issue. Card issuance would not require a licence granted by a central authority, but participation in an open network.
• Anyone can accept. Becoming a merchant would not require approval from an acquirer or a scheme; it would be a matter of joining the network.

That is the part of the payments stack that has never been open. Issuing has been intermediated by licences and sponsorship; acceptance has been intermediated by acquirers and scheme rules. A decentralised network attacks both at once, which is why it is hard and why it is worth attempting.

The practical consequence for anyone building on ON5.com now: you are integrating against an API and a card model that will not change when the network arrives. A new card product appears, on a new network, through the same GET /card-products call you already use.

Who it is for

ON5 fits a specific shape of company: one that has users, wants to give them cards, and does not want to become a payments company to do it.

• Fintechs and neobanks launching a card product without a two-quarter integration.
• Crypto platforms giving users a way to spend a stablecoin balance at ordinary merchants.
• Marketplaces and gig platforms paying out to a card instead of a bank transfer.
• Businesses issuing spend cards to staff, contractors or campaigns, with a per-card limit set by what is loaded onto it.

The honest trade-off

Using ON5 means accepting a dependency. You do not own the issuer relationship, you do not control the BIN, and you inherit the network's rules on what can be issued and to whom. For a company whose card programme is the business, owning that stack eventually becomes worth the cost. For everyone else — which is most companies — owning it is a distraction with a long lead time and a compliance function attached.

The question is not which model is better in the abstract. It is whether cards are your product or a feature of your product. ON5 is built for the second case.

Frequently asked questions

Related reading

• Card Issuing Made Easy: Launch a Virtual Card Programme with ON5
• ON5 vs Other Card Issuing Models: A Comparison
• Virtual Card Issuing: A Complete Guide