In-App provisioning - ApplePay In-App provisioning - ApplePay Tokenization of payment cards in the issuing bank's app Apple's In-App provisioning feature allows issuing banks of payment cards to transfer data to Apple Wallet directly from the issuer's iOS app. Users find the ability to tokenize cards in the bank's app a very convenient way to prepare cards on iOS devices, as it allows avoiding manual data entry. Issuers consider tokenization in the bank's app an effective way to interact with Apple Wallet, which creates an interface for card tokenization and a unified gateway for interaction with other services. For banks that issue cards without embossed card numbers, this tokenization option becomes a very important way to promote their product. For products based on virtual card issuance, the tokenization option through the app is a practically functional-necessary continuation for use in the merchant network. Below is an example of preparing a payment card in the issuer's app, where the user clicks the "Add to Apple Wallet" button, and the process begins. Since the process starts and ends in the app, it ensures a seamless user experience. Tokenization process through the bank's app Below is an example of the tokenization process in the issuer's app for a payment card, where the user clicks the "Add to Apple Wallet" button, and the process begins. Since the process starts and ends in the app, it ensures a continuous user experience. Add to Apple Wallet After selecting the card and clicking the button, users will see a screen with a request to confirm activation of card tokenization. After user confirmation, they will need to accept the issuer's terms of service for this card to be added to Apple Wallet. Then a confirmation screen about tokenization will appear. During the card tokenization process in the app, the user can select the device to which they want to add the card if they have paired Apple Watch and the card hasn't been added to any device. iOS automatically offers this option; the issuer app cannot control it. The app needs to correctly initialize the iOS API so that device selection is displayed only if the card hasn't been added to any device. After this screen, there is a return to the issuer's app. In the bank's app, such a card will be marked with a special icon. Fig. Tokenization process through the bank's app Security To use the In-App Provisioning feature, the issuing bank's app must meet the following requirements: A. Security Control Requirements; B. Multifactor Authentication Requirements; C. Upgrade to Green Path - Recommendations when transitioning to green data processing path. Let's focus only on the first two. These requirements apply to the issuing bank's app. During functional testing, these requirements will be verified. Security Control Requirements use of different characters in the app password (Aa_*.;23); minimum password length of 6 characters; control of incorrect password entry attempts (usually 3); use of additional channels or call center verification if the app user's credentials (username and password) were changed within 60 days prior to the card tokenization attempt. Multifactor Authentication Requirements Implementation of In-App Provisioning requires multifactor authentication of the user at least once before activating a tokenization attempt. There are two approved approaches to implementing multifactor authentication: - Multifactor authentication on unrecognized devices. Use multifactor authentication with a one-time password (OTP) that the system transmits through a persistent channel (MFA) for new and unrecognized devices to ensure user verification during the first access attempt to a newly installed app. If the user subsequently uses the same app on the same device to prepare a card for Apple Pay, the initial MFA satisfies the MFA requirements for In-App Provisioning. - In-app verification using a one-time code. If the issuer doesn't perform multifactor authentication (MFA) during app installation, they need to perform it during verification to confirm the identity of the user wishing to obtain a card. The issuer can do this using standard platform capabilities (one-time password via persistent communication channel or, if such a channel is unavailable, the app can enable it in the call center). Note that in-app verification can be used instead of SMS, email, or call center if the verification result is in-app verification (as this doesn't provide additional security). Tokenization process through the app In the issuing bank's app, customers can see a list of cards they use. If the card is not tokenized, the customer can start this process directly from the bank's app. In the issuing bank's app, customers can see a list of cards they use. If the card is not tokenized, the customer can start this process directly from the bank's app. Fig. Tokenization procedure from the bank's app. Benefits of tokenization through the bank's app For the issuing bank's customer who has everyday experience using the bank's app, initiating card tokenization won't be stressful. All Apple Pay requirements come down to actually pressing one button. For the customer 1. Instant card linking to wallet. No need to manually enter PAN, expiration date, CVV. The card is tokenized in Apple Wallet in a few clicks. Ability to tokenize the card on other devices. 2. Enhanced security. Data transfer goes in encrypted form from the bank's app to MDES/VTS, eliminating the risk of compromise during manual entry. 3. Best user experience (UX). The user performs tokenization in their familiar app. Token generation is possible immediately after card issuance, and the customer can pay with their smartphone even if the physical card hasn't been delivered yet or the card is virtual. For the issuing bank 1. Increased card activity. Customers can use the card immediately. 2. Reduced rejections. Fewer errors when entering details manually. No unactivated cards. 3. Token lifecycle management. The bank gets more control over the token: activation, blocking, deletion through its app.