Blog / ON5 Card Network

ON5.com vs ON5.org: Why We Issue on Visa and Mastercard While Building a Rival Network

Three years of paperwork, a network still in testing, and a deliberate choice to issue on Visa and Mastercard first. The strategy behind two ON5 domains.

24 August 2026 14 min read

The question comes up in nearly every conversation, and it is a fair one: if you are building a card network to compete with Visa and Mastercard, why is your product issuing cards on Visa and Mastercard?

It sounds like a contradiction. It is the opposite — it is the only sequence we found that has any chance of working, and this article explains why, what each domain is for, and what we are deliberately not claiming.

Since 2023: the paperwork, and still going

Building a card network is not primarily an engineering problem. We have been working on the regulatory and scheme groundwork for the ON5 Card Network since 2023, and that work is still ongoing. Not three years of writing code — three years of applications, legal structuring, correspondence, review cycles and the specific kind of waiting that anyone who has been through a payments licensing process will recognise.

That is not a complaint. The barriers exist for reasons: a card network moves other people's money, and the requirements are the accumulated response to everything that has gone wrong in payments over half a century. But it is the fact that shapes everything else, so it is worth stating plainly rather than glossing over with a launch date.

The engineering can be finished long before the paperwork is. A company that ties its entire existence to the completion date of a regulatory process has made a bet it does not control.

The three-sided cold start

Suppose the paperwork completed tomorrow and the ON5 Card Network went live. What would we have?

A network that is new to everybody at once:

Each of those three depends on the other two. Merchants join for cardholders; cardholders want cards that merchants accept; issuers issue where there is acceptance. This is the cold start problem, and in card networks it is unusually severe because the incumbents crossed it decades ago at enormous cost and now define the baseline everyone is compared against.

A launch announcement does not solve it. Neither does better technology. The only thing that solves it is arriving with a base that already exists.

The part that was not starting from scratch

One piece of this predates the card network by three years, and it is the reason the technical side is further along than the regulatory side.

Kaanch Network is a sister company to ON5. Work on it began in 2020, and the chain went live on 23 December 2024. Its technology is intended to be the settlement layer underneath the ON5 Card Network — the mechanism that makes a merchant confident of being paid without an acquirer standing behind the transaction.

That is not a slide in a deck. Kaanch is a live chain, and ON5 already runs on it: activation payments are made in KNCH on the Kaanch Network, and it is one of the four chains ON5 scans for USDT and USDC deposits alongside Ethereum, BNB Smart Chain and Base. Every ON5 issuer touching activation has already used it, whether or not they thought about it that way.

• Kaanch Network — in development since 2020, live since 23 December 2024. Carries ON5 activation payments and stablecoin deposits today.
• ON5 Card Network — since 2023. In development and testing. Intended to settle on Kaanch technology.

So of the four hard problems a decentralized card network faces — acceptance, disputes, settlement certainty and regulation — the settlement layer is the one where running infrastructure is doing the work rather than a specification. The other three are still open, and we are not going to pretend otherwise.

So we built the distribution first

That is what ON5.com is. Not a stopgap, not a placeholder while we wait — a real business that also happens to be the only viable route to launching a network.

ON5.com lets any business become a card issuer without assembling a licence, a sponsor and a processor of its own. Fund an account with USDT or USDC, choose a product, and issue branded Visa or Mastercard virtual cards through a dashboard or a single API. The minimum load is $5, so a programme can be tested with real money before it is trusted with real volume.

Every issuer that launches on it is a company with real cardholders, real transaction volume and a working integration. That is precisely the base a new network needs and cannot otherwise obtain.

One API, any network

The second half of the plan is what makes the base broad rather than deep in one place.

Card networks are not interchangeable across geographies. A brand issuing to customers in India, Japan or China frequently wants the network those customers actually use — and today that means a separate integration, a separate agreement and a separate programme for each one. The engineering cost is real; the commercial cost of negotiating each relationship is much larger.

The goal for ON5.com is that the network becomes a parameter, not a project. One integration, one API, and the choice of network is a field in a request.

For an issuer, the value of that is concrete. Today, offering cards in three regions means three integrations and three commercial relationships. The intent is that it becomes one integration and a different cardProductId.

# The same call. The network is a parameter.
curl -X POST https://api-auth.on5.com/api/v1/cards \
  -H "Authorization: Bearer $ON5_API_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "initialAmount": "50.00",
    "cardholderName": "Sam Rivera",
    "cardholderEmail": "[email protected]",
    "cardProductId": "9a71…"
  }'

Nothing about that request changes when a new network is added. GET /card-products returns one more product; you pass its id. Your ledger, your reconciliation and your support tooling are untouched.

And then the network becomes an add-on

Here is where the two halves meet, and it is the whole argument.

A brand that already issues through ON5.com has an integration, a funded account, cardholders and an operational process. When the ON5 Card Network is ready, offering it to that brand is not a migration or a pitch to adopt an unproven network as their only rail. It is one more card product in a list they already read.

• For the issuer, adopting it is a low-risk experiment: issue a batch on the ON5 network while every existing card continues on Visa or Mastercard. If it disappoints, nothing was staked on it.
• For the network, that is real issuers with real cardholders on day one, rather than a launch announcement into silence.
• For merchants, acceptance becomes worth building because the cardholders demonstrably exist — the direction of the chicken-and-egg problem is reversed.

That is the sequence: distribution first, network second. Most attempts at new networks do it the other way around — build the network, announce it, then try to attract issuers and merchants simultaneously to something that does not yet do anything useful for either. That is where they stall, and it is the failure mode we designed around.

ON5.com vs ON5.org: the full comparison

The two domains are not two versions of one thing. They are different products at different stages, and conflating them helps nobody.

What each one is trying to solve

ON5.com solves an access problem

Card issuing is gated by licensing and sponsorship. Without a licence you need a sponsor, and a sponsor asks for due diligence, a compliance function, capital and audit rights — a process measured in quarters, with a headcount attached. ON5.com removes that for anyone who wants to issue cards on the networks that already exist.

What it does not remove is the networks themselves. You are still issuing on Visa or Mastercard, under their rules, with their reach and their economics. That is a good trade for almost everyone, and it is a real limitation worth being clear about.

ON5.org solves a permission problem

The deeper constraint is not that issuing is hard to access — it is that someone decides. A licensing authority decides who may issue. An acquirer decides who may accept. Both decisions are gated for real reasons, and both mean the answer depends on your category and your jurisdiction as much as on your conduct.

The ON5 Card Network is being built so that both become participation rather than permission: anyone can issue, anyone can accept, and the rules are enforced in code rather than in a private rulebook that can be revised without your agreement.

That is a much harder problem, which is why it has taken three years of paperwork and is still in testing — and why it needs the base that ON5.com is building.

What this means if you are building today

The practical answer is short: build on ON5.com, and nothing you write is wasted.

• Your Visa and Mastercard cards keep working exactly as they do.
• Regional networks, if and when the applications complete, appear as additional card products — same API call, different product id.
• The ON5 Card Network, when it is ready, appears the same way.
• Your ledger, reconciliation, support tooling and fee handling do not change for any of it.

The integration you write now is the integration you keep. That is the design intent behind putting the network choice in a product id rather than in the shape of the API.

What we are not claiming

A strategy article is exactly where companies overstate things, so here is the explicit list.

• We are not claiming the ON5 Card Network works. It is in development and testing. Merchant acceptance, dispute resolution without a central arbiter, and settlement certainty under adversarial conditions are all unsolved, and we have written about them at length.
• We are not claiming partnerships with JCB, UnionPay or RuPay. We have applied. Applications are not approvals, and none of these networks is available to issue on today.
• We are not giving dates. Not for the network, not for the regional applications. A date that slips is worse than no date, and we do not control the timelines of regulators or schemes.
• We are not claiming to replace Visa and Mastercard. We issue on them, they work extremely well, and their acceptance is the reason a card is useful at all. The ON5 network is being built to sit alongside them.
• We are not claiming decentralization exempts anyone from regulation. It does not. Anti-money-laundering rules, sanctions regimes and consumer protection apply to payments because of what payments are.

The short version

We spent three years on the paperwork for our own card network and we are still in it. Rather than wait, we built the thing a new network actually needs: a platform that makes any business a card issuer on the networks that already have global acceptance, through one API, with more networks applied for.

That platform is a real business serving real issuers today. It is also, not coincidentally, the distribution the ON5 Card Network will need on the day it is ready — because a network that launches to an existing base of issuers, cardholders and volume is solving a completely different problem from one that launches to an empty room.

Two domains, one plan. Issue cards today, and follow the network.

Frequently asked questions

Related reading

• The ON5 Card Network: A Decentralized Card Network in Testing
• What Is ON5 Protocol? The Card Issuing Network Explained
• How Card Networks Work: Visa, Mastercard, Amex, RuPay and JCB