How to Decouple Apple Pay From Your PSP

Apple Pay is one of the highest converting payment methods a merchant can offer. It can also be one of the most tightly welded payment methods to a single processor.

Many processors keep the wallet credentials behind their own vault, priced on their terms, and portable on their timeline.

This is a playbook to get those credentials into your possession.

What does it mean to decouple Apple Pay from your PSP? 

Decoupling means separating the storage of your Apple Pay wallet credentials (the Device or Merchant Primary Account Numbers, known as DPANs and MPANs) from the processor handling your checkout. Instead of those credentials living inside one PSP's vault, they live in a neutral, agnostic vault you control. Any processor that can accept decrypted wallet credentials can be plugged in behind it.

The practical effect: adding, dropping, or negotiating with a processor becomes a routing change instead of a re-integration.

This approach typically shrinks your PCI scope. Your systems handle only encrypted Apple payloads and opaque token references; decrypted credentials appear exclusively on the vault-to-processor proxy hop inside Basis Theory's PCI DSS Level 1 environment.

Return to Top

Why should you decouple Apple Pay from a processor? 

Let me boil it down to four reasons you can share with your manager to advocate for engineering time.

1. Data portability. Device and merchant tokens (DPANs/MPANs) vaulted with Basis Theory can be routed to any processor that accepts decrypted Apple Pay credentials.
2. Negotiating leverage. When your wallet can move, processing fees become a conversation. Locked credentials are the biggest switching cost a PSP holds over you.
3. Multi-processor routing. Route transactions by cost, approval rate, geography, or redundancy.
4. Lifecycle ownership. Apple’s token lifecycle events (card updates, suspensions, device changes) flow to your vault, not to a processor. This means that MPANs metadata (real card last 4 digits and expiration date) is within your grasp, and you can show to your returning customers in a checkout or payment method management page.

Return to Top

Four Degrees of Freedom: Decoupling Apple Pay from Your PSP 

1. Coupled: Apple Pay through the PSP’s SDK.

This is the starting point for most merchants. Checkout embeds the PSP's SDK. When a shopper authorizes payment, Apple's encrypted payload travels straight to the PSP, which decrypts it, stores the DPAN or MPAN in its own vault, and hands your backend an opaque token.

Every future charge, customer-initiated or merchant-initiated, routes through that one processor, because it's the only party holding the credential.

2. Hybrid: Direct Apple Pay for Net-New, PSP SDK for existing book.

You add a second, parallel path without touching the first. Checkout gains Apple's own JS SDK (or PassKit on iOS) alongside the PSP's SDK, and traffic ramps between them behind a feature flag, starting small and dialing up as confidence grows.

On the new path, the encrypted Apple payload goes to a vaulting endpoint that decrypts and stores the DPAN or MPAN and returns a token reference.

Your backend makes the first charge through an ephemeral proxy call that injects the decrypted credential and one-time cryptogram into the request to your existing PSP, so reconciliation and settlement stay unchanged. From this point forward, every net-new credential is vaulted agnostically, while the legacy book keeps charging exactly as it always has.

3. Migration: Export the existing book out of the PSP.

Once net-new traffic is fully on the agnostic path, what's left is the historical book: credentials still sitting at the PSP, powering in-flight subscriptions. Rather than waiting for them to expire naturally, many PSPs support exporting wallet credentials to another PCI DSS Level 1 party. This applies to DPANs today; MPAN portability varies by PSP and network and is still evolving. The sensitive transfer happens directly between the PSP and the destination vault, so your systems only orchestrate, they never touch the credential itself.

4. Decoupled: One vault, any processor.

The PSP SDK is retired from checkout. Every Apple Pay credential, net-new and migrated, lives in one vault, with Apple's lifecycle events flowing to it directly. Customer-initiated transactions consume the cryptogram through a proxy call to whichever processor you choose; merchant-initiated transactions replay the vaulted credential with the stored network transaction ID. Adding a processor becomes a new proxy destination, not a new integration. The processor you were once locked into is now one row in a routing table.

Return to Top

FAQs About Decoupling Apple Pay 

Does decoupling change your PCI compliance scope?

No, it typically shrinks it. Your systems only ever handle encrypted Apple payloads and opaque token references. Decrypted credentials appear exclusively on the vault-to-processor proxy hop, inside a PCI DSS Level 1 environment.

What happens to in-flight subscriptions during the hybrid phase?

Nothing. The legacy book keeps charging through the PSP exactly as before. Hybrid only changes where net-new credentials land. Existing merchant-initiated transactions stay untouched until the migration step moves them, and even then the billing schedule continues; only the credential source changes.

Can you migrate MPANs too, or only DPANs?

The proven path today is DPANs. MPAN portability depends on your PSP's export support and network policies, which are still maturing. If your recurring flows rely on merchant tokens, plan for MPANs to accumulate on the direct path while DPANs cover the migrated book.

What does Apple Pay lifecycle management look like after decoupling?

For merchant tokens, point Apple's token notification URL at your vault's tenant endpoint. Apple then sends card updates, suspensions, and device events straight there, keeping tokens current without any action on your side.

Will your processor accept decrypted Apple Pay credentials?

Most major processors do, but many require the capability to be enabled on your account first. Confirm this before go-live. It's the most common surprise in these migrations.

Return to Top

Where to Start 

If Apple Pay is running through a single PSP today, you don’t have to choose between disruption and staying locked in. The hybrid step is for proving out a direct integration with minimal traffic, and no impact on the book you have running.

Start with the Apple Pay implementation guide, it walks through the hybrid step in detail.

Return to Top