Apple Pay certification paths

Apple recognizes several app architectures for card-issuer integrations. Each path is a different combination of:

• Where the cardholder authenticates (your app, our companion app, the web).
• Where Card Lifecycle ManagementCard Lifecycle Management The set of in-app card operations Apple and Mastercard expect an issuer app to surface so cardholders can self-serve without leaving the app. Typical operations: view card number / CVV / PIN, lock and unlock, freeze and unfreeze, replace, report lost or stolen, view balance, and view transactions. Issuer apps that omit any of these are flagged at lab certification. operations happen.
• Where in-app provisioningIn-app provisioning The flow that adds a card to a digital wallet (Apple Pay, Google Pay) from inside an issuer's mobile app, using the issuer's own authentication. In Weavr's stack, in-app provisioning is implemented via our Push Provisioning SDK on iOS or React Native. to Apple Wallet happens.

This page compares the supported paths and helps you pick the one that suits your product.

Comparison at a glance

Path	Primary auth & CLM	In-app provisioningIn-app provisioning The flow that adds a card to a digital wallet (Apple Pay, Google Pay) from inside an issuer's mobile app, using the issuer's own authentication. In Weavr's stack, in-app provisioning is implemented via our Push Provisioning SDK on iOS or React Native.	Best for
Primary mobile app (recommended)	Your app	Your app	EmbeddersEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. that own a mobile app and can integrate the SDK into it.
Primary + companion mobile app	Your app	Our companion app	EmbeddersEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. that prefer to keep development on their primary app light.
Web-initiated provisioning (documentation in progress)	Web portal	Companion app	EmbeddersEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. whose users primarily authenticate on the web.

Recommended path

As of Q1 2026, Primary mobile app is the path we recommend and the only one with a fully supported solution. Choose it unless you have a specific reason to keep the SDK and Wallet ExtensionsWallet Extension An iOS app extension that integrates an issuer app with Apple Wallet. The UI Wallet Extension provisions a card from the issuer app into Wallet (the in-app provisioning flow). The Non-UI Wallet Extension exposes the issuer's card-management actions (such as 'View card details') from inside Wallet itself. Apple requires both for a primary issuer-app integration. out of your primary app.

Choosing a path

A few questions usually narrow the choice quickly:

1. Do your users already use a mobile app you operate?

   • Yes — go with the Primary mobile app path, or use the primary + companion variant if you prefer to keep the Apple Pay-specific work out of your primary app.
   • No — you likely need a web-initiated path, since Apple does not allow in-app provisioningIn-app provisioning The flow that adds a card to a digital wallet (Apple Pay, Google Pay) from inside an issuer's mobile app, using the issuer's own authentication. In Weavr's stack, in-app provisioning is implemented via our Push Provisioning SDK on iOS or React Native. to be initiated solely from a web context without a paired native experience.

2. Are you prepared to integrate our Push ProvisioningPush Provisioning A method that allows cardholders to add their card to a digital wallet (such as Apple Pay or Google Pay) directly from your app. The card details are securely tokenized and sent to the wallet provider, streamlining the process and enhancing the user experience compared to manual provisioning. This feature is currently in beta. SDK and Wallet ExtensionsWallet Extension An iOS app extension that integrates an issuer app with Apple Wallet. The UI Wallet Extension provisions a card from the issuer app into Wallet (the in-app provisioning flow). The Non-UI Wallet Extension exposes the issuer's card-management actions (such as 'View card details') from inside Wallet itself. Apple requires both for a primary issuer-app integration. directly into your primary app?

   • Yes — the Primary mobile app path keeps everything in one binary and gives the best end-user experience.
   • No — the primary + companion path lets you keep that work isolated in our companion app, with a deep link from your primary app.

3. Where do users perform card lifecycle managementCard Lifecycle Management The set of in-app card operations Apple and Mastercard expect an issuer app to surface so cardholders can self-serve without leaving the app. Typical operations: view card number / CVV / PIN, lock and unlock, freeze and unfreeze, replace, report lost or stolen, view balance, and view transactions. Issuer apps that omit any of these are flagged at lab certification. (lock, unlock, replace, view PIN)?

   • Apple expects CLM to be in the same app the user authenticates with, which in most cases is your primary app.

If you are unsure, our support team helps you map your existing product to the right path. Contact [email protected].

What every path has in common

Whatever path you choose, expect Apple to require:

• Strong cardholder authenticationStrong cardholder authentication Apple Pay's requirement that a cardholder authenticate with at least two factors — typically a knowledge factor (password) plus an inherence factor (biometrics on a trusted device) — before adding a card to Apple Wallet or accessing sensitive card details. The principle aligns with PSD2 SCA but applies specifically to issuer-app interactions Apple inspects during certification. (password plus biometrics).
• Complete card lifecycle managementCard Lifecycle Management The set of in-app card operations Apple and Mastercard expect an issuer app to surface so cardholders can self-serve without leaving the app. Typical operations: view card number / CVV / PIN, lock and unlock, freeze and unfreeze, replace, report lost or stolen, view balance, and view transactions. Issuer apps that omit any of these are flagged at lab certification. surfaced in-app.
• Apple-defined UX elements such as a splash screen, correctly branded "Add to Apple Wallet" button, and adherence to the Apple Wallet brand guidelines.
• Lab certificationLab certification The formal test pass run by an Apple-affiliated test centre that verifies an issuer app meets Apple Pay's functional, security, and brand requirements. The test exercises every Card Lifecycle Management operation, the in-app provisioning flow, and the Wallet Extension. A successful pass is required before launching Apple Pay on a card programme; most first-time integrations fail at least one item and need a remediation round. by an Apple-affiliated test centre before launch.
• A 30-day minimum gap between an Apple Pay launch and any subsequent Google Pay launch on the same product.

Next steps

• For most embeddersEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers., continue with the Primary mobile app guide.
• If a single-app integration is not feasible, see Primary + companion mobile app.
• For other paths, contact our support team.