Implementing Apple Pay: Key Steps and Best Practices

Michael Chernyakov
Apr 6
6 min read

While developing a banking app for 1.3 million credit card accounts, Apple Pay was a key feature of the user experience. It was my first time working with Apple Pay guidelines, which proved less straightforward than expected. I must admit, we greatly overestimated the effort due to limited knowledge, as no one in the team had integrated Apple Pay within an app before. What was also challenging was the Apple Pay documentation. This article explains key Apple Pay features for 2024 and clarifies Apple’s user experience requirements. I emphasize 2024 because Apple frequently updates its certification requirements, and banks that introduced Apple Pay years ago had fewer requirements to meet in order to pass certification.

This article focuses solely on frontend implementation and the certification requirements. Apple mandates that any card issuer wanting to offer Apple Pay must undergo certification with a third party. Only when all applicable requirements are met does Apple grant permission to use Apple Pay. While Apple’s documentation outlines the requirements, deciphering what’s really needed can be challenging. In the following, I highlight the lessons we learned while integrating Apple Pay and explain the requirements of Apple Pay integration for a banking app.

The basics features

Apple Pay relies on two main features: Verification and Provisioning. In-App Verification verifies a card via the banking app after initiating manual card addition in the Wallet app. In contrast, In-App Provisioning enables card addition to Apple Pay directly from the banking app without manual entry of card details. In-App Provisioning is more convenient, as users don’t need to enter card information or have a physical card. Each process serves a different use case and has specific Apple requirements.

In App Verification

If you go to add your card in the Wallet app, you will enter a manual process of adding your card to Apple Pay. You will first need to add your card details by scanning the card or manually entering your card information, including the name of the cardholder, expiration date, card number, etc. Finally, after you agree to the terms and conditions, you will reach a verification step. This verification step is very important to prevent fraud. The verification step is a security measure with various verification methods, each varying in security level. The confirmation methods are email, SMS, calling a call center, or in-app verification. Apple has its own security logic that defines which security method will be presented to the user; this logic is kept unknown to prevent cheating. However, banks can also define which methods can be used by the end user. The most secure method is in-app verification, as call centers and SMS are more vulnerable to scams and fraud.

Once the user initiates the In-App Verification for the Wallet, the banking app should open. If the user does not have the app on their device, it should redirect them to the app store. After the user successfully logs in, the app should directly offer the option to verify the card. The in-app verification process adds a security layer, as the user needs to know the credentials of the banking app to log in. Additionally, most banks today are required to follow two-factor authentication, which may include biometrics or an SMS in the login process. These steps help prevent fraud and card theft.

Learning: Apple provides the design for various buttons that you need to use based on the different scenarios and paths the user takes to add their card. However, this is not clearly specified in the documentation. In the in-app verification case, you should display a “confirm” button using your own app design.

However, the story does not end there, as Apple has several other requirements for verification.

Users can dismiss the verification request but should be able to confirm it again later. Therefore, inside the app — preferably under a card management page — you should offer the user the option to verify the card if they do not complete the process when they first see the screen to verify the card.
Users should also be able to confirm a verification based on their device. If there are pending verifications from an Apple Watch or iPhone, there should be an option to verify them individually, so a button for each individual verification is needed. You may end up requiring two separate verifications.

In App Provisioning

In-App Provisioning enables banking app users to add their cards to their Apple Wallet without needing to enter any card information manually. In this flow, after users log in to their banking app, they should simply be able to click on the “Add to Apple Wallet” button, and the provisioning flow of the card starts.

Learning: The button for push provisioning should not be removed until all potential devices of the user are connected. For example, if the user has an Apple Watch but has only provisioned their card to their iPhone, the “Add to Apple Wallet” button still needs to be displayed to the user. After the card is provisioned on all devices, you can add the “Added to Apple Pay” label.

There is a situation where users have one card but multiple Apple devices. In this case, the card can also be in different states: added to the wallet, provisioned, or waiting for verification. What we discovered is that we need to enable the user to verify and provision a card at the same time. This situation occurs when you start manually adding a card in the Wallet for your iPhone but do not finalize verification for the card on your Apple Watch. Therefore, the app needs to show two buttons: one for verification and one for provisioning.

You will need to show the following buttons:

Add to Apple Wallet: Always show this button when there is a device to which the card can be provisioned. Example: The card is provisioned to an iPhone, but the user also has an Apple Watch.
Verify: Display this button when there is a card that needs verification.
Added to Apple Pay: Show this label when the card is provisioned to all devices

First Login Prompt

Another requirement for Apple Pay is to offer the user the option to add their cards to the Wallet when they first log in to the app. In this case, the user should only see cards that are not yet tokenized in their Wallet. The first prompt becomes more complex when the app offers more than one card product, and the card products have different user experiences. In this case, users usually need to select the card they would like to add — for example, choosing between their Gold or Silver card.

Therefore, the question arises: where should the prompt be positioned? Before the card product selection or after? There are arguments to be made for both cases, but positioning the prompt before any card product selection makes it a part of the onboarding process. This way, you only have to show it once when the user first logs in on the device, rather than twice.

Challenges

Unfortunately, there were some challenges; the most significant one is that there is no sandbox environment. There are countries where there is no option for a sandbox environment, and all testing needs to be done on production. Germany is one of those countries, and this made it much harder to test because of the following:

Blocked Cards: There is a limited amount of card tokenization you can do on a card, so you need to have a high number of cards. There are ways around this, but it does hinder the process.
Blocked Devices: Your test device might get blocked. As you push, provision, or verify cards multiple times, it might be detected as fraud, and your device will be blocked. Apple can help unblock this. However, this is a significant challenge because you do not know if it is an issue with your device, app, or Apple.
Unclear Process: What is not known to the user, but you find out as you develop, is that depending on some unknown factors on Apple’s side, you might end up in a different flow than you expected. For example, you are testing to verify your card with the app but end up needing to enter an SMS. This benefits the end user as it aims to prevent fraud, but as a developer, not so much.

During development, we experienced issues with no clear solution after reviewing the implementation and code multiple times. This led to a lot of frustration, especially when one day it worked, and the next, it did not. We felt it was a great achievement for us when we finally passed the certification. While the frontend of the app is just the tip of the iceberg that users interact with, it is supported by a robust banking system working seamlessly behind the scenes. Although Apple imposes stricter requirements than its competitor (Google), it also offers valuable personal technical support throughout the process. I take great pride in what we have accomplished, as along the way, it seemed like we couldn’t figure it out, but we just tried again, again and again, and in the end it worked.