Primary mobile app

The primary mobile app path is the certification route we recommend, and the only path Weavr has a fully supported solution for as of Q1 2026.

In this path, your existing mobile app is the issuer appIssuer app Apple's term for the mobile app that authenticates a cardholder and provisions their card to Apple Wallet. Apple's certification, brand, and Card Lifecycle Management requirements apply specifically to this app. In a primary + companion architecture, your primary app remains the issuer app even if the provisioning step happens in a companion app.: it handles cardholder authentication, 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., and 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 — all in one binary. There is no companion app and no deep link to a separate experience.

This guide applies whether you build natively in iOS or with React Native — Apple's certification requirements are the same in both cases. The SDK references below cover both options.

Talk to our solutions team before you start

We strongly recommend consulting our solutions team before you start the Apple Pay certification process. They advise on the requirements, process, and timelines, and help you pass first time.

The journey from application to launch

A primary-app integration follows four stages. Use the checklist to track progress as you go — checked items persist in this browser. Stages backed by a detailed checklist further down (technical, marketing) tick automatically once every item in the underlying list is complete.

• Partner Hub steps completed (questionnaires answered, artifacts uploaded)
• App is compliant with Apple's technical requirements ↓
• In-app provisioning and Wallet Extension implemented and tested ↓
• Marketing materials reviewed against Apple's brand guidelines ↓
• Lab certification booked and passed

The rest of this page expands each stage. Where detail is still being consolidated, we link out or flag it explicitly so you know what to expect from our support team.

Completing the Partner Hub

Apple Pay onboarding starts in the Partner Hub. Each step has a defined owner — some are completed by you, others by our team — and several questionnaires require specific answers we have refined over previous certifications.

Detailed steps in progress

The full step-by-step Partner Hub guide, including who handles each step and the suggested answers to each questionnaire, is being prepared. In the meantime, work directly with our support team — we walk you through each item, share the recommended questionnaire answers, and flag anything Apple has changed recently.

What to expect at this stage:

• Setting up your card program details on the Partner Hub.
• Completing Apple's onboarding questionnaires (technical, marketing, fraud).
• Uploading any required evidence (BIN ranges, app metadata, screenshots).
• Coordinating sign-off between your team and ours before submission.

Project plan

We provide a customer-facing project plan that covers every milestone from kick-off to launch, derived from our internal Card Provisioning Setup playbook. The plan typically includes:

• Discovery and scoping.
• Technical integration milestones (SDK install, Wallet ExtensionWallet 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., 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., end-to-end testing).
• Sandbox certification and dry runs.
• 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. booking.
• Marketing and App Store readiness.
• Launch.

Project plan template in progress

Ask our support team for the latest version of the customer-facing project plan when you start your engagement.

Technical requirements

Your app must meet Apple's technical requirements for the issuer appIssuer app Apple's term for the mobile app that authenticates a cardholder and provisions their card to Apple Wallet. Apple's certification, brand, and Card Lifecycle Management requirements apply specifically to this app. In a primary + companion architecture, your primary app remains the issuer app even if the provisioning step happens in a companion app. before 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.. The high-level expectations are:

• 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) and MFA at least once before provisioning.
• 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 and controls (Apple Pay splash screen, branded "Add to Apple Wallet" button, correct copy).
• 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. via 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 (iOS native or React Native).
• 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. (UI and Non-UI) — see our Apple Wallet extension guide. React Native apps configure the same extensions at the native iOS layer; the React Native setup guide covers the wiring.

Use this checklist for the technical scope on your primary app:

• Password policy meets Apple's minimums (length, complexity, lockout, change-window re-verification)
• Multi-factor authentication completed at least once before provisioning, using OTP via SMS or biometrics
• Biometric authentication enrolled and used after first login
• Complete card lifecycle management surfaced in-app (view PIN, lock/unlock, freeze, replace, report lost/stolen, view balance, view transactions)
• Apple Pay launch announcement on first app open, with CTA into in-app provisioning
• Provisioning prompt shown during onboarding on devices with no eligible cards already in Wallet
• Post-provisioning return screen explaining how to use Apple Pay
• 'Add to Apple Wallet' button placed and styled per Apple's brand guidelines
• Push Provisioning SDK integrated
• Wallet Extension (UI and Non-UI) implemented and configured
• App and extension bundle identifiers shared with our support team for allow-listing
• End-to-end provisioning verified in sandbox

warning

Passcode is deprecated for biometric login flows. Use a password as the primary credential.

Password policy

Apple sets explicit minimums for the password used to access your app. Your sign-up and password-change flows must enforce them all:

• Length: more than six characters.
• Complexity: at least two of the following character classes — uppercase letters, lowercase letters, numerals, special characters.
• Lockout: the user account locks after a defined number of failed login attempts.
• Change-window re-verification: if the user's password has changed within a defined window before a provisioning attempt — typically 60 days — fall back to a tenured channel (OTP to a number on file, or call-centre verification) before approving the provisioning.

Our password secure UI component (for web; equivalent components for iOS and React Native) tokenises the password capture, but enforcing the policy itself — rejecting weak passwords, locking accounts, tracking the change window — is your app's responsibility. Confirm your policy with our support team before 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..

MultiMulti Weavr Multi is an embedded finance solution that allows you to integrate financial services into your own application, providing a seamless experience for your customers. It enables you to offer managed accounts, managed cards, and transactions without requiring financial expertise.-factor authentication

Apple requires the user to complete MFA at least once before a provisioning attempt is activated. Apple recognizes two patterns, either of which is acceptable:

• MFA at first install on a new device — when the user installs your app on an unrecognized device, send an OTP to a tenured channel (typically the SMS number on file). After this single MFA, subsequent provisioning attempts on the same device do not need to re-prompt.
• MFA at the time of provisioning — trigger an OTP step inline during the 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. flow.

In-App Verification is not an acceptable substitute for SMS, email, or call-centre MFA when Apple requires the issuer to verify the user.

This requirement is satisfied by our existing step-up authentication flow:

• SMS OTP step-up covers the MFA-at-install and MFA-at-provisioning patterns.
• Biometrics step-up covers re-authentication on returning users.

See Authentication overview for the broader picture, and the iOS biometrics SDK or React Native biometrics SDK for client-side enrolment.

Featuring and promoting Apple Pay

Apple's certification scope is broader than the provisioning flow itself. Once Apple Pay is live, your app must actively surface it to users with eligible cards.

The user-facing surfaces below are required. We provide the SDK glue for 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.; the splash screens, in-app banners, and notification copy live in your app and are reviewed at 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..

Apple Pay splash screen

On first app open after launch — and during onboarding on devices that do not already have an eligible card in Apple Wallet — your app must show a splash screen with a CTA that links directly into 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.. After a successful provisioning, the user must return to a screen that explains how to use Apple Pay.

Use the toggle to flip between the three required variants:

Shown on the home screen at app open after Apple Pay launches, to all users with eligible cards.

9:41

Your app

Apple Pay is here

Add your card to Apple Wallet and pay in stores, in apps, and on the web with a tap.

Add to Apple WalletMaybe later

Splash screen SDK component — coming soon

We're shipping a configurable Apple Pay splash-screen component for iOS and React Native to remove this from your scope. Track the placeholder pages: iOS and React Native. Until it ships, build the surfaces yourself against the variants above and run the copy past our support team.

User notifications and ongoing communications

Apple expects you to actively re-surface Apple Pay to users who have not adopted it. The following triggers are required:

• Launch announcement — within 3 days of go-live, send an in-app notification, SMS, or email to all eligible cardholders. The link must drop the user directly into 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. or an Apple Pay landing page.
• Quarterly nudge — once per quarter, notify any cardholder who has not yet activated Apple Pay, again linking directly into provisioning.
• Activation-pending follow-up — within 24 hours of a provisioning attempt that is pending activation, notify the user with instructions to request a new OTP or complete activation.
• Post-provisioning marketing — within 7 days of a successful provisioning, send marketing-opted-in users with no Apple Pay transactions yet a message explaining the benefits.
• Provisioning confirmation — when a user successfully provisions a card, send a confirmation through a tenured channel: email or SMS within 1 hour, a secure message in online banking with notification, or a paper letter within 7 calendar days as a last resort.
• In-app surfacing — link to Apple Wallet (or the Apple Pay provisioning experience) from in-app banking messages, service banners, and pop-ups, not just the splash screens above.

We help you scope the comms

Our support team reviews your notification and email copy alongside marketing assets before Apple sees them. Reach out early — the comms cadence is one of the first things Apple checks during 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..

Mapping requirements to Weavr building blocks

Each Apple requirement maps to a specific Weavr SDK component, secure UI component, or MultiMulti Weavr Multi is an embedded finance solution that allows you to integrate financial services into your own application, providing a seamless experience for your customers. It enables you to offer managed accounts, managed cards, and transactions without requiring financial expertise. API endpoint. Use this table to locate the building block that satisfies each requirement.

Apple requirement	Weavr building block
Password authentication (knowledge factor)	Password secure UI component — web, iOS login components, React Native login components
Biometric authentication (inherence factor)	Biometrics SDK — iOS, React Native
View card number, CVV, expiry	Card components — iOS, React Native, web
View PIN	Show Card PIN component — iOS, React Native, web
Lock / unlock card	MultiMulti Weavr Multi is an embedded finance solution that allows you to integrate financial services into your own application, providing a seamless experience for your customers. It enables you to offer managed accounts, managed cards, and transactions without requiring financial expertise. API: POST /managed_cards/{id}/block and POST /managed_cards/{id}/unblock
Replace card (lost / stolen / damaged)	MultiMulti Weavr Multi is an embedded finance solution that allows you to integrate financial services into your own application, providing a seamless experience for your customers. It enables you to offer managed accounts, managed cards, and transactions without requiring financial expertise. API: POST /managed_cards/{id}/physical/replace_lost_stolen and POST /managed_cards/{id}/physical/replace_damaged — see replace a card
Report card lost or stolen	MultiMulti Weavr Multi is an embedded finance solution that allows you to integrate financial services into your own application, providing a seamless experience for your customers. It enables you to offer managed accounts, managed cards, and transactions without requiring financial expertise. API: POST /managed_cards/{id}/physical/report_lost and POST /managed_cards/{id}/physical/report_stolen — see report a card
View balance	MultiMulti Weavr Multi is an embedded finance solution that allows you to integrate financial services into your own application, providing a seamless experience for your customers. It enables you to offer managed accounts, managed cards, and transactions without requiring financial expertise. API: GET /managed_cards/{id} (balance is returned in the card resource)
View transactions	MultiMulti Weavr Multi is an embedded finance solution that allows you to integrate financial services into your own application, providing a seamless experience for your customers. It enables you to offer managed accounts, managed cards, and transactions without requiring financial expertise. API: transaction list endpoints — see Transactions
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.	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 — iOS, React Native
Wallet ExtensionWallet 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. (UI + Non-UI)	Apple Wallet extension guide — React Native wires the same extensions at the native iOS layer via the setup guide
Card status surfaced in Wallet	Card status for iOS, Card status for React Native

For SDK-specific implementation, see:

iOS native:

• Push provisioning overview
• Push provisioning setup
• Push provisioning implementation
• Apple Wallet extension
• Card status
• Card components
• Biometrics

React Native:

• Push provisioning overview
• Push provisioning setup (covers Wallet ExtensionWallet 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. wiring at the native iOS layer)
• Push provisioning implementation
• Card status
• Card components
• Biometrics

Marketing guidelines

This is one of the most common reasons certifications get delayed

Apple's brand and language guidelines for Apple Pay are highly specific, and Apple reviews everything before launch — App Store screenshots, in-app banners, web landing pages, social posts, email copy, and the "Add to Apple Wallet" button itself. Most failures we see at this stage come from small wording or styling mistakes that look harmless but trip Apple's review.

Do not treat marketing as the last 5%. Loop our team in early so we can review your assets and copy against the current Apple guidelines before you commit them to print, App Store metadata, or external channels.

The two canonical references are:

• Apple Pay marketing guidelines — terminology, mark usage, visual treatment.
• Add to Apple Wallet button guidelines — button artwork, sizing, and placement (use the official button unmodified).

• App Store screenshots reviewed against Apple's brand guidelines
• In-app 'Add to Apple Wallet' button reviewed against Apple's brand guidelines
• Marketing copy reviewed against Apple's terminology requirements
• Web and social assets reviewed
• Pre-submission review completed with Weavr support

Contact our support team for a content review before you submit. We have walked previous customers through Apple's reviewer feedback and can flag the issues Apple has been catching most recently.

Going to 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.

Once the steps are complete, our team coordinates the 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. appointment with the Apple-affiliated test centre. Expect:

• A pre-cert review with our team to catch obvious gaps.
• A booked test slot with the Apple-affiliated lab.
• A test pass that exercises every CLM operation, the 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. flow, and the Wallet ExtensionWallet 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..
• A pass-or-fix report — Apple flags any non-compliant items, you fix them, and you re-test.

Plan for at least one round of remediation: most first-time integrations fail at least one item.

Considering a different path?

If a single-app integration is not feasible — for example, you would rather not take SDK and Wallet ExtensionWallet 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. work into your primary app — see Primary + companion mobile app for the fallback option.