On 26 October 2026, Interswitch announced that a tokenisation initiative had gone live with five Nigerian banks: GTBank, Wema Bank, ProvidusUnity Bank, Zenith Bank and FirstBank. The group says it wants to extend tokenised transactions — described in its release as “tap-to-pay” — across Google Pay, Apple Pay and bank mobile applications.

The announcement is an important step for mobile payment issuing and processing in Nigeria. It does not, however, mean that every customer of the five banks can already make contactless payments with every card, on every phone and at every merchant.

That distinction is fundamental: tokenisation protects a payment credential, while tap-to-pay describes an acceptance experience. Several links must work together between the two.

Tokenisation is not limited to contactless payments

In a traditional card transaction, the primary account number, or PAN, identifies the payment account. Tokenisation replaces that number with an alternative value. According to EMVCo, an EMV payment token can be constrained to a specific device, merchant or use case. A stolen token is therefore less reusable than an exposed card number without equivalent restrictions.

This protection can support several channels: in-store mobile payments, e-commerce, in-app purchases and QR-code payments. NFC contactless acceptance is only one of these use cases.

Interswitch says it is providing the issuer connectivity, tokenisation and processing capabilities required for the initiative. Its release associates the infrastructure with three expected benefits: higher authorisation rates, lower fraud risk and stronger customer confidence. It does not yet publish evidence showing that these outcomes have been achieved in production.

Five links required for a mobile payment to work

1. An eligible card must be provisioned

A bank’s participation does not automatically make all of its cards eligible. The issuer must define which products, networks, ranges, account statuses and risk rules are permitted. The provisioning process must also verify that the person adding the card to a wallet is the legitimate cardholder.

This stage has its own performance indicators: the proportion of requests approved, declined or referred for additional verification, activation time and the number of tokens suspended or deleted.

2. The wallet must actually be available

The official Google Wallet page for Nigeria, checked on 29 October 2026, lists eligible cards from FirstBank, GTBank, UBA and Zenith. It therefore confirms part of the scope described by Interswitch, but does not yet list Wema Bank or ProvidusUnity Bank.

Apple Pay is different. Apple’s official list of supported countries and regions, updated in October 2026, does not include Nigeria. In Africa, it lists Egypt, Mauritius, Morocco and South Africa. Interswitch mentions Apple Pay, but its release does not specify a launch date, eligible cards or availability conditions in Nigeria. PayX therefore does not treat the service as confirmed for the Nigerian market at this stage.

Banks may also provide a separate tokenised experience through their own applications. Availability must be verified bank by bank and device by device.

3. The phone must meet technical requirements

To make a contactless payment with a smartphone, the device generally needs NFC, a compatible operating-system version, a device lock and the security features required by the wallet. Banking infrastructure can therefore be ready while part of the installed handset base remains excluded.

This constraint matters in markets where entry-level devices and non-NFC phones still represent a significant share of usage. Adoption cannot be inferred from the number of bank customers alone.

4. The merchant must accept contactless payments

A mobile token has value in store only if the merchant terminal accepts contactless transactions, the function is enabled and the acquirer-processor chain can route the payment correctly. Deployed-terminal counts are not enough: the market needs to know how many terminals are active, compatible and actually used.

Acceptance quality also depends on operational settings: terminal configuration, limits, connectivity, duplicate handling, reversals, refunds and reconciliation.

5. The token lifecycle must be controlled

A token must be created, activated, suspended, resumed or deleted. When a card expires, is replaced or is reported lost, participants must decide whether the token is updated automatically or revoked. Fraud and customer-service teams must also link the tokenised identifier to the relevant account without unnecessarily exposing the PAN.

EMVCo notably defines the Payment Account Reference, which can help link tokenised and non-tokenised transactions for fraud controls, compliance or certain associated services. Effectiveness still depends on the implementation quality of networks, issuers, acquirers and processors.

What the announcement confirms — and what it does not yet confirm

The release confirms the five partner banks and the existence of issuer-connectivity, tokenisation and processing capabilities provided by Interswitch. It also says that the initiative is live.

It does not provide a complete eligible-card matrix, operating-system coverage, active-token count, compatible-terminal estate, transaction volume, authorisation rate, fraud reduction or a wallet-by-wallet timetable. Nor can the release attribute any performance improvement to tokenisation before comparison against an appropriate baseline.

This caution does not diminish the project. It separates a real technical capability from commercial adoption that still needs to be documented.

The indicators that should be published

To assess scale, the banks and orchestrator could track at least eight indicators:

  • the number of eligible cards by bank and network;
  • provisioning success and reasons for failure;
  • active tokens, kept separate from provisioned-card counts;
  • active merchant terminals that genuinely accept contactless payments;
  • tokenised transaction volume and value by channel;
  • authorisation rates compared with similar non-tokenised transactions;
  • fraud, dispute and refund rates;
  • end-to-end availability, latency and incident levels.

An authorisation-rate improvement should not be claimed without controlling for differences in customers, ticket size, merchants or channels. Similarly, lower PAN fraud does not guarantee lower overall fraud if attackers shift to fraudulent provisioning, account takeover or social engineering.

A lesson for other African markets

The Nigerian initiative shows how a local processor can orchestrate banks, wallets, networks and merchant acceptance. For francophone Africa, the lesson is not to reproduce one particular wallet brand, but to prepare the full chain.

Issuers need a clear eligible-card matrix and provisioning rules. Acquirers need to measure genuine terminal compatibility. Fraud teams need to monitor token creation and lifecycle events. Operations must prepare refunds, disputes and reconciliation. Finally, commercial communication must distinguish available infrastructure from a service that is accessible to everyone.

Interswitch’s partnership with five banks creates a credible foundation for tokenised payments in Nigeria. The next proof point will not be another partnership announcement. It will be data showing that customers can provision their cards, merchants can accept the transactions, and security improves without degrading the experience or shifting fraud elsewhere.

Sources

Cover: official visual published by Interswitch with its 26 October 2026 announcement.