Blog / ON5 Card Network

The ON5 Card Network: A Decentralized Card Network in Testing

ON5 is building a decentralized card network where anyone can issue a card and anyone can accept one. What it aims to do, why it is hard, and where it stands.

22 August 2026 11 min read

There are perhaps half a dozen card networks that matter globally — Visa, Mastercard, American Express, and the regional networks such as RuPay, JCB and Discover. Between them they decide two things for the entire world: who may issue a card, and who may accept one.

Both decisions are gated. Issuing requires a licence, or sponsorship from someone who holds one. Acceptance requires an acquirer willing to take you on, and continued compliance with scheme rules that can be changed without your agreement. Neither gate is arbitrary — they exist because payments carry real risk — but both are centralised, and centralised gates are where exclusion happens.

The ON5 Card Network, in development at ON5.org, is an attempt to remove both gates.

What the two ON5 products are

This is worth separating clearly, because they are different things at different stages.

The two gates, and why they exist

The issuing gate

To put card numbers into circulation you need a Bank Identification Number, which networks grant only to licensed institutions. Everyone else works through sponsorship: a licensed institution stakes its licence on your behaviour, and in return asks for due diligence, a compliance programme, capital and ongoing audit rights.

The reason is sound. A card issuer holds other people's money and can create payment instruments. Unqualified issuers create real losses for real people. But the effect is that whether you can issue depends on whether an institution will vouch for you — which correlates with where you are, who you know and how much capital you have, rather than only with whether you would run a good programme.

The acceptance gate

The merchant side is less discussed and at least as restrictive. To accept cards you need an acquirer. Acquirers decline entire categories of business, price by perceived risk, hold reserves against your takings, and can terminate an account with notice measured in days. Whole legitimate industries are effectively unbanked for card acceptance.

Again the reason is real — the acquirer carries chargeback risk. And again the effect is a permission system, where the answer depends on your category and your jurisdiction more than on your conduct.

What a decentralized network changes

The design goal is that both gates become participation rather than permission.

• Issuing without a licensing authority. Rather than an institution vouching for an issuer, the network's rules and its settlement mechanics determine what an issuer can do. An issuer that cannot fund its obligations cannot create them.
• Acceptance without an acquirer. Rather than a company deciding whether a merchant may take payments, joining the network is the act of becoming able to accept.
• Rules that are visible and not unilaterally changed. Scheme rules today are long, private and revised by the scheme. A network whose rules are enforced in code is at least inspectable by the people subject to them.

Note the shape of this: it is not "the same system with a blockchain underneath". It is a different answer to the question of who decides, which is why the incumbents cannot simply adopt it.

Why this is genuinely hard

It would be dishonest to describe the ambition without the difficulty. Four problems are real and none of them are solved by wanting to solve them.

1. Acceptance is a chicken-and-egg problem

A card is worth having only where merchants take it; merchants take a card only where cardholders have it. Visa and Mastercard spent decades and enormous capital crossing that gap, and it is the single hardest thing about launching any network. This is precisely why ON5.com issues on established rails today: a card that works everywhere now is worth more than a card that will work everywhere eventually.

2. Fraud and chargebacks need an answer

Card networks are not only routing. They are dispute resolution systems — a mechanism for deciding, when a cardholder says a charge was wrong, who bears the loss. A decentralized network needs an answer to that question that does not require a central arbiter, and "the transaction is final" is not an acceptable answer to a consumer whose card was misused.

3. Settlement has to be certain

A merchant who accepts a payment must be confident of being paid. That is what an acquirer guarantees today. A network without that intermediary needs settlement assurance built into the mechanism itself, and it has to hold under adversarial conditions rather than only in the ordinary case.

This is the one of the four where we are not starting from a blank page. Kaanch Network, a sister company, has been building blockchain infrastructure since 2020 and took its chain live on 23 December 2024. Its technology is intended to be the settlement layer underneath the ON5 Card Network, and it already carries ON5 traffic: activation payments are made in KNCH on Kaanch, and it is one of the four chains ON5 scans for stablecoin deposits.

That does not make settlement solved — an existing chain is a foundation, not a finished settlement guarantee for card authorisations. But it is a materially different starting position from designing one.

4. Regulation does not stop applying

Decentralization is an architectural property, not a legal exemption. Anti-money-laundering obligations, sanctions regimes and consumer protection rules apply to payments because of what payments are, regardless of the system's topology. A network that ignores this is not a network, it is a liability.

Why build the issuing platform first

The sequencing is deliberate and worth understanding, because it is the opposite of how most such projects are attempted.

The usual approach is to build the network, announce it, and try to attract issuers and merchants simultaneously to something that does not yet do anything useful. Most fail at exactly that point.

ON5 has been in the regulatory groundwork for the network since 2023, and built the issuing platform in parallel rather than waiting. That produces three things a network needs and cannot easily obtain otherwise: real issuers with live programmes, real cardholders spending real money, and an operational understanding of what card issuing actually demands — the reconciliation, the disputes, the support load, the failure modes. A network designed by people who have run an issuing programme is a different artefact from one designed from first principles.

It also means the network launches into demand rather than into silence. The issuers on ON5.com are already issuing; adding a network they can issue on is a product decision for them, not a leap of faith.

What it will mean if you are building on ON5.com today

Very little disruption, by design. The ON5 Card Network is intended to appear as an additional card product, not a different integration.

• Your existing Visa and Mastercard cards continue exactly as they are.
• A new product appears in GET /card-products, as any new product would.
• Issuing on it uses the same POST /cards call with a different cardProductId.
• Your ledger, your reconciliation and your support tooling are unchanged.

That is the practical argument for the sequencing: the integration you write now is the integration you keep.

Following the work

The network is at ON5.org, and it is in testing. The honest summary is that ON5.com is a product you can use today and ON5.org is a project you can watch. Conflating the two would help nobody — least of all anyone trying to decide what to build on this quarter.

Frequently asked questions

Related reading

• What Is ON5 Protocol? The Card Issuing Network Explained
• ON5 vs Other Card Issuing Models: A Comparison
• How Card Networks Work: Visa, Mastercard, Amex, RuPay and JCB