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 Pay

Phase 1: Apple Onboarding

1

Request special Entitlement and Whitelist from Apple

Request special Entitlement and Whitelist from Apple: The issuer must request the Entitlement and Whitelist for their application by sending the specific information to apple-pay-provisioning@apple.com.

Along with the confirmation about granting the entitlement the issuers should receive from Apple a set of documents which should guide them in their application UX and functional design. It is essential to review those documents early in the project to avoid any rework of the issuer's integration.

2

Configuring the Entitlement in Apple Developer Website

Configuring the Entitlement in Apple Developer Website: The issuer must configure Entitlement in Apple Developer Website to get aproval to use In-App Provisioning Service.

3

Configuring the Entitlement in Xcode

Configuring the Entitlement in Xcode: The issuer must configure Entitlement in Xcode to declare that the app whants to use In-App Provisioning Service.

4

TSP system configuration

Configure necessary settings on the TSP system according to Apple Pay's requirements, paying close attention to the associatedApplicationIdentifiers.

Phase 2: Thales D1 Backend Integration

1

Onboarding

Onboarding: The Thales integrator provides the Thales D1 Onboarding Form to gather all necessary configuration parameters to connect to D1, including Connectivity, Keys, D1 Services Configuration, and Card Products.

The issuers are required to open a project with TSP(s) (Visa/Mastercard) for their push provisioning integration projects. This activity is recommended to be initiated in parallel to the onboarding with Thales.

2

Connectivity

Connectivity: The APIs exposed by D1 require TLS mutual authentication for all API calls, necessitating explicit setup for both pre-production and production environments with a client certificate signed by Thales CA.

3

Backend authorisation

Backend authorisation: Incoming D1 APIs are secured by OAuth JWT Bearer Credentials Flow, where your backend sends a signed JWT to obtain a D1 access token for accessing D1 APIs.

4

Data encryption

Data encryption: Sensitive information exchanged with the D1 backend must be encrypted using the standard JWE format with specific algorithms and the recipient's EC public key.

5

Consumer and Card Registration via API

Consumer and Card Registration via API: As a prerequisite for most D1 services, you must register end users, accounts, and cards in D1 via backend-to-backend APIs using unique identifiers.

6

Batch Registration

Batch Registration: D1 offers a service to execute certain operations (such as consumer & card registration) in batch mode using batch files uploaded via SFTP.

Phase 3: Thales D1 SDK Integration

1

Binary Integration

Binary Integration: The issuer must integrate the D1 SDK binary into its application project.

2

SDK Initialisation

SDK Initialisation: The issuer app must initialize the D1 SDK before it could call its APIs.

3

User Authentication

User Authentication: The issuer application must provide a proof of the end user authentication before it could consume D1 services.

4

Check Card State in Apple Pay Wallet

Check Card State in Apple Pay Wallet: The issuer app must check the card's digitization state in the Apple Pay wallet using the d1Task.cardDigitizationState() API to determine the next action.

5

Pushing Card to Apple Pay Wallet

Pushing Card to Apple Pay Wallet: When the user taps "Add to Apple Pay", invoke the d1Task.addDigitalCardToOEM() API to tokenize the card.

6

Apple Wallet Extensions

Apple Wallet Extensions: Card issuers with an iOS mobile banking app must support Wallet Extensions to enable card issuer mobile app customers to provision new cards directly from the iOS Wallet app for all eligible Apple iOS devices.

Phase 4: Testing & Troubleshooting

1

Apple Pay sandbox testing

The issuer is required to test their integration using first Apple Pay sandbox mode.

2

Error management and reporting

If issuers face errors in their tests they are required to first consult common errors before reporting the problem to Thales.

3

Production testing

Once issuers complete testing on Sandbox they should move to production environment and test there as well.

Phase 5: Certification & Launch

1

E2E certification by independent lab

The issuers are required by Apple to get their application end-to-end certified by an independent certification lab, which the issuers need to contract and which will validate that all Apple's functional requirements are met.

2

Submit app for App Store review

Once the E2E certification is complete the issuers could submit their final version of the app for review to the App Store.

3

Plan go-live with Apple

After the final version of the app is approved by the App Store for publication the issuers could plan their go live date with Apple.

Last updated

Was this helpful?