Understanding ApplePay in PIN Debit

Posted on by

Payment Geek detail on the EMVCO Dependencies of Debit and How Cap One Solved It

This is a technical addendum to today’s post on the reported JPMorgan/BofA/Wells/PNC exploration of buying Fiserv’s Star network. That post laid out five business and political reasons the deal is unlikely to happen. This one goes underneath the business case to the technical architecture that makes the wallet portion (ie ApplePay, GPay, SamsungPay) of the problem particularly ugly for any bank that thinks owning a PIN debit network gets them out from under Durbin.

The short version: an issuer that buys Star cannot simply route its ApplePay volume through Star. The tokenization and provisioning plumbing that makes Apple Pay work belongs to Visa and Mastercard, sits inside a standards body (EMVCo) that issuers are not members of, and is architecturally structured around the card brand on the card (not the issuer that issued it). A bank that owns Star still can’t put a Star token in Apple Pay; it is a new AID in the phone.

1. Issuers Are Not Members of EMVCo

Every modern tokenized payment (Apple Pay, Google Pay, Click to Pay, card-on-file network tokens) sits on top of the EMV Payment Tokenization Specification, first published in March 2014 and expanded to e-commerce and card-on-file in September 2017. That specification is owned and governed by EMVCo.

EMVCo has six members: Visa, Mastercard, American Express, Discover, JCB, and UnionPay. That’s it. As the Federal Reserve Bank of Boston laid out in its 2019 tokenization primer, “EMVCo is a consortium that manages the security specifications for chip-based payment cards (EMV), including payments tokenization and the 3DS authentication protocol. It is jointly owned by American Express, Discover, Visa, Mastercard, JCB, and Union Pay” (Pandy & Crowe, Federal Reserve Bank of Boston, June 2019).

Notice who is missing. Issuers and PIN debit networks: Star, NYCE, PULSE, Accel, Interlink, Maestro. The consortium that writes the rules for tokenization is a card-network club, and PIN debit rails are guests, not owners. The same is true of Apple Pay itself: Apple is not a member of EMVCo. Apple is a Token Requestor registered with the card-network Token Service Providers. It plays inside the rules; it does not write them.

This matters because tokenization is not a feature bolted onto payments — it is the substrate. Once you accept that the substrate is owned by six card networks, the rest of the architecture follows.

2. The Apple Pay Agreement Is Really a Network Agreement

The commercial arrangement most people describe as “an issuer’s Apple Pay deal” is not, in a strict sense, a bilateral issuer-Apple agreement. It is a tri-lateral arrangement in which the card network sits in the middle. The card network is the party that enrolls issuers into VTS or MDES and allows the Issuer to select which wallet its cards can be provisioned into. The network is the entity that actually monetizes Apple Pay for Apple.

UBS’s Timothy Chiodo laid out the economics precisely in his November 2025 update: “Apple Pay has no additional costs to merchants, does not require a contract, etc. Rather, Apple Pay functions as a pass-through mechanism that provides card credentials in a secure manner to the merchant and its underlying payments processor. Apple charges 15bps for credit card transactions and a fixed fee of $0.005 per debit transaction, which are paid by card-issuing bank partners” (UBS Securities, November 2025).

Read that again. Apple’s fee is paid by the issuer, not the merchant, and it flows through the network rails. The network is the plumbing that makes the fee collectible, the token routable, and the transaction settleable. Without a Visa or Mastercard on the front of the card, there is no VTS or MDES tokenization; without VTS or MDES tokenization, there is no Apple Pay for that card. Which brings us to how provisioning actually works.

Side Note. Kudos to Apple for “forcing” banks to add debit cards at parity to credit cards. As I wrote in 2014, US Issuers had no desire to add debit cards to mobile as they sought to enable a “premium experience” for credit. Apple’s Issuer agreeement required banks to add their debit portfolios at parity. It is this Apple mandate that allowed debit cards to existin in Today’s ApplePay.

3. Networks Provision Cards/Tokens. Issuers Own the PAN

The provisioning flow for a Visa-branded debit card being added to Apple Pay looks approximately like this:

  1. Cardholder adds their card to Apple Wallet on iPhone.
  2. Apple, acting as a registered Token Requestor with an 11-digit Token Requestor ID (positions 1–3 identify the TSP; positions 4–11 identify Apple as the specific requester within that TSP’s namespace), submits a provisioning request to the card network’s Token Service Provider — Visa Token Service (VTS) in this example.
  3. VTS requests Identification & Verification (ID&V) from the issuing bank — the bank verifies its customer through mobile banking OTP, in-app confirmation, 3-D Secure ACS, call center, or whatever channel it has configured.
  4. Issuer approves the provisioning request. This is the only step where the issuer has actual control in this chain.
  5. VTS generates the DPAN (Device Primary Account Number — the network token), maps it 1:1 to the FPAN (Funding PAN — the real card number owned by the issuer), and pushes the DPAN plus a per-transaction cryptogram capability down to Apple.
  6. Apple stores the DPAN and cryptogram in the phone’s Secure Element (SE) a tamper-resistant certified chip running the Java Card Platform. The DPAN never leaves the SE unencrypted; the FPAN never leaves the network’s token vault.

Look at where the pieces sit. The issuer owns the BIN and the FPAN. That has not changed since Diners Club invented the card. But the token/cryptogram is issued by Visa, held in Visa’s token vault (VTS), and passed to Apple’s Secure Element under Visa’s Token Requestor domain rules. The issuer is the primary actor in provisioning but the process of provisioning, the token itself, and the vault that stores it are all owned by the network (note that TCH does act as vault for some issuers. see related blog).

Two footnotes on the provisioning chain:

  • Third-party TSPs exist but they do not escape network control. First Data (FDC) launched the first third-party TSP with Apple Pay in 2014, connecting “on behalf of” its issuer clients into VTS. FDC eventually built its own TSP with Mastercard and Apple in December 2017. The Clearing House launched its own TSP in 2018. But — critically — the Federal Reserve Bank of Boston noted in 2019 that “in the U.S., tokens from third party TSPs must still flow through the card networks. TSPs must have access to the PANs in order to provide the networks with a ‘mirror’ token vault so that the networks can ensure the operation of their payment networks” (Pandy & Crowe, Federal Reserve Bank of Boston, June 2019). A third-party TSP is still, in effect, a card-network affiliate. It does not create an independent tokenization path for a PIN debit network.
  • In markets with proprietary debit networks, this whole model breaks. Canada’s Interac has a proprietary debit token that operates outside the card network TSP framework. The Federal Reserve’s Boston paper is explicit: “Because its Interac debit network provides a proprietary token, the card network tokenization model does not work for all issuers in foreign markets.” This is the closest thing to what a Star-owning bank would want in the U.S. — and Interac operates this way because Canada has one dominant debit network with its own EMVCo-registered TSP status. Star, NYCE, and PULSE do not.

4. Tap and PIN: What Actually Happens at the Terminal

When a debit card is provisioned into Apple Pay, it is not assigned a single payment application on the Secure Element — it is assigned two AIDs (Application Identifiers) that the terminal can select from during a contactless tap:

  • Global AID (e.g., Visa Debit `A0000000032010` or Mastercard Debit `A0000000041010`). This AID routes the transaction exclusively through the primary brand’s network rails. It is used for tap-to-pay contactless in most contexts, and for cross-border acceptance where the merchant terminal only supports the global brand.
  • Common U.S. Debit AID (`A0000000980840`, the “US Common Debit AID”). This is a standardized, open identifier developed specifically for the United States to comply with Durbin’s dual-network routing requirement. When a terminal selects the Common Debit AID, it pulls a list of all debit networks the card supports, including both the global brand’s PINless debit product (Visa Interlink or Maestro) and any regional PIN debit networks the issuer has enabled on the card (Star, NYCE, PULSE, Accel).

Two important pieces of nuance here. First, the cardholder cannot change which AID the terminal selects. Apple Pay presents both AIDs to the terminal; it is the terminal that decides which AID to prefer for a given transaction.

Second, the merchant controls the terminal but not Apple Pay itself. A merchant cannot change how Apple Pay works on the phone. But the merchant has complete control over their own POS terminal’s payment application kernel and routing tables. That is where the Common Debit AID becomes meaningful. A merchant’s terminal, if properly configured, detects that a debit card is being presented via Apple Pay and can automatically select the Common U.S. Debit AID instead of the Global AID by pulling the transaction off Visa rails and onto whichever PIN debit network sits on the routing list.

This is real, and it works. It is the technical foundation of the Durbin dual-network routing right, extended into the contactless / tokenized world. But it is also more fragile than it sounds, for one specific reason we’ll get to in the next section.

5. Does Visa Still Provide Tokenization for Non-Visa Networks?

Yes. And this is the piece most people who read the Star acquisition story do not fully appreciate. When a Visa debit card is added to Apple Pay, VTS issues a Device PAN (DPAN) that masks the real FPAN. The DPAN is unambiguously a Visa token — it is generated inside Visa’s token vault, it uses Visa’s Token Requestor namespace, it is subject to Visa’s domain restriction controls, and it is provisioned into the Secure Element under the Visa Global AID.

Now suppose the merchant’s terminal selects the Common U.S. Debit AID and elects to route the transaction over Star (or NYCE, or PULSE). What happens?

Visa is legally required to facilitate the routing. Durbin’s dual-network requirement, combined with the operational reality that Visa has effectively made itself the tokenization backbone for the U.S. debit ecosystem, means Visa cannot simply refuse to release the tokenized transaction to a competing PIN debit network. The mechanism looks like this:

  1. Merchant terminal captures the Apple Pay tap. The DPAN is in the transaction.
  2. Merchant’s POS kernel selects the Common Debit AID and routes to Star (per the terminal’s routing table).
  3. Star receives a Visa-branded token it cannot detokenize itself. Star has no Visa token vault. It has no cryptographic key material for VTS-issued DPANs.
  4. Star passes the tokenized transaction through a shared, interoperable gateway back to Visa — this gateway exists specifically because Durbin requires the routing to work.
  5. Visa performs detokenization — mapping the DPAN back to the FPAN using its token vault.
  6. Visa passes the clearing data back to Star, which then routes to the issuing bank for authorization on Star rails.
  7. Star pays interchange to the issuer at PIN debit economics. Visa charges a technical processing fee for the token look-up — because Visa did the detokenization work. The actual transaction (interchange) fee goes to Star, per the routing.

Merchants, understandably, do not love this arrangement. When Visa detokenizes, it also strips essentially all the ancillary card data (the wallet metadata, provisioning path, device-info fields, network token PAR linkages that would let a merchant tie the Apple Pay transaction back to the same cardholder’s prior card-on-file transaction). Merchants would like that data but I agree with Visa here: the ancillary data was created through Visa’s proprietary provisioning process (VTS’s ID&V, VTS’s token domain rules, VTS’s mirror vault infrastructure with Apple). Visa built the plumbing; Visa is entitled to charge for what runs through it. But the practical effect for the merchant is that routing an Apple Pay transaction over an alternative debit network is technically permissible and operationally clunky.

Why This Is Bad News for a Bank That Buys Star

Bring all of this back to the FISV Star acquisition scenario. Suppose one of the top-4 banks (ex JPM) buys Star tomorrow. Here is what JPMorgan does not get:

JPMorgan does not become an EMVCo member. Membership is not for sale, and it is not conferred on network buyers. JPMorgan cannot vote on the tokenization specification.

JPMorgan does not gain an AID inside Apple Pay’s Secure Element. Chase debit cards are Visa-branded; every Chase debit card in every Apple Wallet on every iPhone in America has a DPAN issued by VTS, provisioned under the Visa AID. Owning Star does not retroactively swap those tokens for Star tokens. Buying the network does not buy the provisioning path.

JPMorgan cannot force Apple Pay tap and PIN transactions over Star. The Secure Element hands the terminal a Visa DPAN under the Visa Global AID. If the merchant’s terminal happens to be configured to select the Common Debit AID and route to Star, fine then Star will get a switch fee, JPMorgan-as-Star will get a modest amount of new interchange (at PIN debit rates), and Visa will still get a technical detokenization fee. But this depends entirely on the merchant’s terminal configuration. In practice, most contactless tap-to-pay POS deployments in the U.S. default to selecting the Global AID, because that produces the cleanest customer experience with the fewest failed transactions.

JPMorgan cannot strip Visa off its debit cards without breaking Apple Pay entirely. Recall from yesterday’s post: if a bank tries to remove Visa Interlink and go Star-only, the card falls out of Apple Pay because the Secure Element has no path to a Star-issued network token. Star does not run VTS. Star does not run MDES. Star has no Token Service Provider relationship with Apple, no Token Requestor ID inside Apple’s provisioning stack, no domain restriction controls, no mirror vault. The card simply cannot be provisioned. This is why the ApplePay: Debit Issues point I made back in 2014, and the Debit, Routing, Tokens and Liability Shift analysis from 2022, still stand: PIN debit networks are second-class citizens in the tokenized world, and no amount of merger activity fixes that.

The economics are actually inverted for the Star-owning issuer. Every time a JPMorgan-issued debit card is used in Apple Pay tap-to-pay, JPMorgan pays Apple its $0.005-per-debit-transaction fee (UBS, Nov 2025). If the transaction routes over Visa rails (which is the default) Visa collects switch fees. If Visa detokenizes and hands off to Star, Visa still collects the technical processing fee for the token look-up. Star (owned by JPMorgan) only gets the switch fee if the merchant’s terminal actively selected the Common Debit AID and routed to Star — which requires the merchant to have configured their POS for that behavior. JPMorgan-as-issuer pays Apple, Visa gets a technical fee, and JPMorgan-as-Star-network gets a switch fee only when the merchant chooses. Owning Star gives JPMorgan an option, not a right, to earn Star switch fees on its own cards’ Apple Pay transactions.

What About Card-Not-Present?

CNP is worse, not better. UBS’s June 2026 alternative-debit-routing report (Timothy Chiodo, with FreshBooks and RPY Innovations as panelists) walks through the eligibility screen for pulling an e-commerce Apple Pay transaction over Star or NYCE. The transaction is only eligible if: the PSP supports the alternative route; PSP token / vault setup is supported for that use case; the terminal or checkout can pass the required data fields; and the alternative network supports the required capability (dual-message, PINless debit, tokenization). If any of those fails, the transaction stays on Visa rails.

The One Thing Cap One Actually Had

I made this point in yesterday’s post but it bears repeating here in more technical terms. Capital One’s Discover acquisition works because Discover has its own EMVCo-registered TSP infrastructure, its own network token issuance capability (which Discover has been quietly building out for years), its own tap-to-pay contactless implementation, and its own Apple Pay provisioning path. When Cap One re-issues its Chase-competitor debit portfolio on Discover BINs, those cards can be added to Apple Wallet, they get a Discover-issued DPAN, and the transaction routes over Discover rails (including tap-to-pay in Apple Pay). Cap One preserves the customer experience because Discover already ran the plumbing.

Star did not build this plumbing. Star is a single-message PIN debit network. It has no token vault integrated with Apple, no Common Debit AID provisioning path, no Secure Element domain rights, no NFC contactless kernel implementation, and most fundamentally it is not an EMVCo member. Building all of that from scratch, on top of a debit-only PIN network, is a multi-year, multi-hundred-million-dollar project. And even after the project ships, the bank owning Star would still need Apple’s willingness to add a new tokenization path to iPhone Secure Elements which requires Apple’s own product prioritization, not just a check written to Apple.

The Uncomfortable Conclusion

Tokenization and provisioning are network innovations that encompass many EMVCo standards. Issuers are not members of EMVCo.

That single sentence encapsulates why the Star acquisition rumor is so much less compelling than it looks in a spreadsheet. The Durbin exemption logic gets you the theoretical repricing opportunity. But once you trace what actually happens when a debit card is tapped on a POS terminal, you realize the transaction is running on infrastructure that Star does not own, cannot easily replicate, and cannot force to route around.

For 15 years, the card networks have used tokenization as a moat. They wrote the spec, they own the vault, they issued the tokens to Apple, they set the domain rules, and they extract technical processing fees on every transaction that touches their infrastructure, even when they are legally required to hand off routing to a competing network. Owning Star does not scale that moat. It only lets you compete on the far side of it.

Which is another way of saying: the top-4 banks looking at Star are not just buying a PIN debit network. They would be buying an asset that Visa’s plumbing will still price on every transaction. That is a different deal than the WSJ headline suggests.

Sources & Further Reading

Prior posts on this blog:

Industry research (subscription or academic — no link):

  • Susan M. Pandy, Ph.D. and Marianne Crowe, Industry Perspectives on the Evolution of EMV Payment Tokenization, Federal Reserve Bank of Boston, June 2019 (originally September 2018, revised May 2019)
  • Deloitte Cross Industry Payments Practice, Network Tokenization for Merchants, Deloitte, January 2023
  • Yue Zhu, Asmaa Aljohani, Gyan Singh Namdhari, Identity-Enabled Transactions Based on the EMVCo Payment Tokenization Specification, Johns Hopkins University (Capstone Project), December 2016
  • Timothy E. Chiodo, CFA et al., Apple Pay Desktop Update, UBS Securities LLC, November 13, 2025
  • Timothy E. Chiodo, CFA et al., US Alternative Debit Routing Discussion (UBS Payments Innovation Event Series), UBS Global Research, June 16, 2026

Please Login to Comment.