Welcome to our new developer portal! Use the "Ask" button to chat with our AI Agent.
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Apple wallet extension

Apple wallet extension

Use Apple Wallet extensions to let end users discover and provision cards directly from the Apple Wallet application, in addition to the issuer application.

Through application extensions, you can expose custom functionality and content outside the issuer application and make it available while the end user interacts with Apple Wallet or the system.

Provisioning cards within the Apple Wallet application improves the in-app experience by avoiding manual entry of payment card details.

Refer to the Apple extension overview for general information about iOS extensions.

User experience

The end-to-end Apple Wallet extension flow has two main phases:

  1. Apple Wallet discovers that the issuer application has cards available for provisioning.

  2. The end user authenticates and selects which cards to add; Apple Wallet then requests the provisioning payload from the issuer application via the D1 SDK.

Discovery and authentication

Apple Wallet showing issuer application option for adding a card
Apple Wallet shows the issuer application as an option when cards are available for provisioning.
1

Discover issuer application in Apple Wallet

Apple Wallet checks with the issuer application to determine whether cards are available. If cards are available, the issuer application appears in the list of options.

2

The end user selects the issuer application

When the end user selects the issuer application, Apple Wallet triggers the issuer application UI extension to authenticate the end user.

3

Authenticate the end user

The issuer application’s UI extension authenticates the end user using the same credentials and methods (for example, manual login and biometrics) as the main issuer application.

Selecting and provisioning cards

Apple Wallet showing available cards from the issuer application
Apple Wallet fetches and displays the cards available from the issuer application.
1

Apple Wallet fetches available cards

Apple Wallet requests the list of available cards from the issuer application through the non-UI extension. The end user sees a list of cards to add.

2

View card details

The end user can review card details (for example, card art, product title, and last four digits) before adding the card.

3

Accept terms and conditions

The end user reviews and accepts the issuer’s and payment network’s terms and conditions.

4

Provisioning payload and tokenization

For each selected card, Apple Wallet requests a provisioning payload from the issuer application and then initiates the tokenization flow with the payment network TSP.

Extensions

The Apple Wallet integration requires two types of extensions from the issuer application:

  • Non-UI extension Reports the status of the extension flow and card availability. This covers the card discovery and provisioning payload steps. It is implemented by extending the D1 SDK base class D1IssuerProvisioningExtensionHandler.

  • UI extension Authenticates the end user. This is a separate screen that uses the same login credentials as the issuer application. It implements the D1IssuerProvisioningExtensionAuthorizationProviding protocol.

Apple Wallet extensions are installed at the same time as the issuer application. For Apple Wallet to detect that there are passes to add and to show the extension, the end user must launch the issuer application at least once.

D1 SDK provides a base implementation for the non-UI extension so that you do not need to implement the complete logic yourself. The issuer application calls D1Task.configure() with WalletExtensionConfig during application launch to share card details with the extension. While this configuration is required only once after installation, we recommend calling it on every application launch to keep card information up to date.

High-level flow for configuring the Apple Wallet extension via D1 SDK
High-level flow: the issuer application configures the D1 SDK so Apple Wallet can discover cards.

After a successful authentication in the UI extension, the issuer application must call D1IssuerProvisioningExtensionAuthorizationProviding.login() so that the SDK can continue with the non-UI extension steps.

Sequence diagrams

1. Apple Wallet shows the issuer application button

Sequence diagram showing how Apple Wallet discovers the issuer application
Apple Wallet discovers that the issuer application has cards available for provisioning.

2. End user authentication

Sequence diagram showing Apple Wallet triggering issuer UI extension for authentication
Apple Wallet launches the issuer application UI extension for authentication.

3. Available cards are displayed

Sequence diagram showing Apple Wallet requesting card list from issuer
Apple Wallet requests the list of available cards and shows them to the end user.

4. Tokenization

Sequence diagram showing Apple Wallet requesting provisioning payload and tokenizing
Apple Wallet requests provisioning payloads and tokenizes the selected cards.

Integrate Apple Wallet via the D1 SDK

SDK configuration

When you perform iOS SDK initialization, the issuer application must also call configure(ConfigParams.walletExtensionConfig(...)) and provide:

cardParamsList

Use this variant when you have a single consumerId and a single issuerId:

  • cardParamsList – List of card IDs, card art, product titles, and last four digits. Card art and product title are displayed in Apple Wallet.

  • appGroupID – The shared container ID so the D1 SDK can share data between the issuer application and its extensions.

issuerParamsList

Use this variant when you support multiple combinations of issuerId and consumerId:

  • issuerParamsList – List of cardParamsList with the corresponding issuerId and consumerId.

  • appGroupID – The shared container ID so the D1 SDK can share data between the issuer application and its extensions.

We strongly recommend using the last4 parameter.

Without last4, the SDK may misinterpret tokenization status in shared-device scenarios. For example, if User A tokenizes a card and then User B logs into the same issuer application on the same device, the SDK might incorrectly assume tokenization is already complete for User B.

App Group ID

By default, the issuer application and its extensions do not share storage. Use app groups to share storage between them. See the Apple extension overview for more details.

appGroupID identifies the shared container between the issuer application and its extensions. You configure it in Xcode under Capabilities.

Xcode configuration for app groups used by issuer application and extensions
Example of configuring an app group in Xcode for the issuer application and its extensions.

Ensure that the App Group ID is correctly added to Xcode before using it in configure(ConfigParams.walletExtensionConfig(...)). Otherwise, the D1 SDK returns the invalidAppGroupID error.

Apple Pay entitlement

Similar to in-app Apple Pay provisioning, you must add the entitlement com.apple.developer.payment-pass-provisioning to both the UI and non-UI extension targets. For onboarding details, refer to your Apple Wallet provisioning documentation or Push provisioning onboarding for wallets.

UI extension

Create a UI extension

Xcode dialog for creating an intents UI extension
Create an Intents UI Extension target in Xcode for the Apple Wallet UI extension.
1

Add a new target in Xcode of type Intents UI Extension.

2

In the new target, enable the same App Group ID and entitlement values as in the issuer application. If the App Group ID differs, the login API returns the walletExtensionAppGroupIDNotFound error.

3

Update the extension Info.plist:

  • Set NSExtensionPointIdentifier to com.apple.PassKit.issuer-provisioning.authorization.

  • Set NSExtensionPrincipalClass to a class that conforms to D1IssuerProvisioningExtensionAuthorizationProviding.

Example entitlements and extension configuration:

Integrate the SDK for the UI extension

The D1 SDK provides the D1IssuerProvisioningExtensionAuthorizationProviding protocol, which extends Apple’s PKIssuerProvisioningExtensionAuthorizationProviding and adds a login API.

In the UI extension, implement a view controller that conforms to D1IssuerProvisioningExtensionAuthorizationProviding, authenticates the end user, and calls login with a D1 access token (for example, a JWT from your backend). See your SDK login documentation for token generation.

Login with a single issuerId

Login with multiple issuerIds

If cards share the same issuerId but have different consumerId values, generate a single issuerToken for that issuerId.

Non-UI extension

Create a non-UI extension

Xcode dialog for creating an intents extension without UI
Create an Intents Extension target in Xcode for the Apple Wallet non-UI extension.
1

Add a new target in Xcode of type Intents Extension. Clear Include UI Extension because the UI extension was created previously.

2

In the new target, enable the same App Group ID and entitlement values as in the issuer application. If the App Group ID differs, D1 SDK operations return the walletExtensionAppGroupIDNotFound error.

3

Update the extension Info.plist:

  • Set NSExtensionPointIdentifier to com.apple.PassKit.issuer-provisioning.

  • Set NSExtensionPrincipalClass to a class that extends D1IssuerProvisioningExtensionHandler.

Example entitlements and extension configuration:

Integrate the SDK for the non-UI extension

The D1 SDK provides the base class D1IssuerProvisioningExtensionHandler, which extends Apple’s PKIssuerProvisioningExtensionHandler and implements the required APIs. In most cases, you only need to extend this class.

Error handling

Optionally, override errorEncountered(_:) in the non-UI extension to log or track errors received during the extension flow.

Typical error cases include:

  • The appGroupID is invalid or not found.

  • The D1 backend returns an error.

Apple functional requirements

To align with Apple’s functional requirements, the D1 SDK D1IssuerProvisioningExtensionHandler and the issuer application adopt the following practices:

  • Display card art and cardholder name.

  • Determine whether cards are available (eligibility) within 100 ms of Apple invoking the API.

  • Provide card art and app icons with squared edges.

  • Support both manual and biometric login methods for authentication in the UI extension.

FAQ

How can the issuer application provide card availability to Apple Wallet before the end user logs in?

The end user must log in to the issuer application at least once so that the extension can be updated with card status. The issuer application calls configure(ConfigParams.walletExtensionConfig()) to provide the list of cards to the D1 SDK.

If a login fails, where is the error shown?

We recommend showing login errors directly in the UI extension’s login screen. The UI extension should follow the same UX guidelines as the issuer application’s login.

What are the size and resolution requirements for card images?

The digital card image should follow Apple’s functional requirements:

  • Provide images as PNG (recommended) or vector PDF.

    • Wallet extensions have stricter memory limits than main apps.

    • PDF files increase memory usage because the OS converts them to PNG.

  • Use a resolution of 1536 × 969.

  • Ensure the image size is less than 4 MB.

  • Use squared (not rounded) corners.

  • Exclude physical-card-only elements (for example, PAN, embossed characters, hologram, chip contacts).

  • Use landscape orientation. If the physical card is portrait, reorient it to landscape.

  • Optionally add the contactless indicator when NFC payments are supported.

Do extensions require new bundle identifiers?

Yes. The new bundle identifiers must be included in the associatedApplicationIdentifier of the payment network operator (PNO). iOS supports wildcard bundle identifiers.

Issuers must also update existing passes in Apple Wallet using PNO APIs. If the bundle ID is not included, cards added through the Apple Wallet extension cannot be accessed by the issuer application (for example, for digitization state checks).

What could be wrong if the issuer application icon does not appear in Apple Wallet?

Check the following:

  • The issuer application is installed and has been opened at least once.

  • The issuer application calls configure(ConfigParams.walletExtensionConfig()) to update the card list.

  • The issuer application and both extensions use the same appGroupID in configure(ConfigParams.walletExtensionConfig()) and in Xcode capabilities.

Is in-app provisioning required for Apple Wallet extensions to work?

Yes. The issuer application must first implement in-app push provisioning to wallets before adding Apple Wallet extensions.

Last updated

Was this helpful?