Setup for Mobile Wallets

This guide describes the requirements you must meet and actions you must perform to set up a mobile wallet program. For general information, see Mobile wallet support in the Choose a Card Strategy guide.

Determine your mobile wallet experience

There are three ways to provision a card to a mobile wallet:

• Manual — A cardholder manually inputs the PAN, expiry date, CVV2 and other card data directly into their mobile wallet app.
• In-app — A cardholder initiates provisioning a card to a mobile wallet app from their banking app.
• Web — A cardholder initiates provisioning a card to their mobile wallet app from their banking website.

As a first step, you must complete the setup for manual provisioning, as instructed later in this guide. After successfully implementing manual provisioning—including going live in Production—you can integrate with the wallet providers to offer in-app or web push provisioning to your customers.

Initial setup

Obtain these items in preparation for deploying mobile wallets.

Bank and network approval

You are responsible for ensuring that there are mobile wallet–specific contractual arrangements between the issuing bank, the wallet providers, and card networks. The issuing bank must also provide specific metadata to Galileo and confirmation that the digital enablement contracts are in place with the card networks for Apple, Google, and Samsung, authorizing Galileo as the processor. This is a one-time submission required by the card networks, if the issuing bank has not previously been established.

MSA/SOW

To coordinate with Galileo to set up mobile wallets, you need to execute a Statement of Work (SOW) or a Master Services Agreement (MSA). Contact Galileo to update your MSA/SOW.

Verify the BIN range

To support a mobile wallet program, the BIN range must be programmed to enable card tokenization. Your issuing bank assigns the BIN account range to you. Once that is confirmed, the issuing bank works with Galileo to install the range. This should be complete prior to mobile wallet setup with Galileo.

Provide required metadata

The following is required metadata that you must provide to Galileo. This information will be reviewed with you and your bank during the initial mobile wallet program kickoff call with Galileo.

Card template

To start setting up the configurations, you must provide a tokenized (mobile wallet) card template. All designs must be approved by your bank partner. See Tokenized card design in Design a Card for a detailed list of design elements and network-specific requirements.

Customer terms and conditions

Terms and conditions (T&Cs) are documents required by the card networks and wallet providers. These are the wallet terms that cardholders review on their mobile device when provisioning their card to a wallet. You are responsible for providing the T&C to your bank partner for review and approval. Once they are approved, you provide them to Galileo. The T&C file must be supplied as a UTF-8 encoded TXT, HTM, or HTML file.

Customer service requests

You determine the customer service contact information that is displayed in the mobile wallet, should a customer need to contact you with questions about their account or card. This includes the following information:

• Required
  • Contact (program) name. Example: "ABC Card" or "ABC Bank"
  • Customer service phone number
• Optional
  • Email address
  • Website URL

Yellow-path (partial success) verification

Yellow-path routing occurs when a cardholder passes only some of the verification checks when they attempt to provision their card to the wallet. You are required to display to the cardholder two methods of verification, and the cardholder must select from one of those options to complete verification. These options include SMS (text) OTP, email OTP, or a call center.

Yellow-path verification is required for Visa and Mastercard programs. Galileo can manage the yellow-path calls on your behalf. Work with Galileo to determine the correct verification methods for your program. If your product is an instant-issue card, make sure your verification method takes into account the information that you will gather about the cardholder at the time you issue the card. For example, if you will not be asking for a phone number, you cannot use SMS (text).

Mobile wallet events

You can arrange with Galileo to receive mobile wallet–related Account Events messages via the Events API. You have the option to manage relaying information to your cardholders or having Galileo send cardholders via SMS text message and/or email. If you choose for Galileo to send messages to your cardholders you must provide a no-reply email address that is hosted by you or a third party. See the Events API messages section for details.

Implement manual provisioning

As a first step, you must complete the setup for manual provisioning and deploy it in Production. See the workflow steps in the following section for details.

If you choose to provide in-app or web push provisioning, you will perform additional steps, including obtaining the necessary documentation to integrate with the mobile providers' APIs, after you complete the manual provisioning process and go live with the manual provisioning. See Setup for Push Provisioning for details.

Manual provisioning workflow

This section describes how manual provisioning proceeds. The manual provisioning process involves these entities:

• The cardholder's mobile wallet
• The card network
• The mobile wallet provider
• Galileo (or you, if you are using the Auth API)

This is the workflow when cardholders provision their cards manually:

1. The cardholder obtains a card from you.
2. The cardholder manually inputs the PAN, CVV2, and expiry date in the mobile wallet interface, as well as other identifying information that the wallet requests.
3. The wallet provider performs some initial checks and assigns a device_score from 1–5, with 5 being the most trusted.
4. The wallet provider sends an authorization request for tokenization to the card network along with the device_score.
5. The card network forwards the authorization request to Galileo.
6. Galileo performs the checks described in Galileo validation checks.
7. Galileo returns a response code and other information to the wallet provider.
8. The wallet provider combines the Galileo response code with its own algorithms to determine the path for the request:
   • Red path — Hard fail. The wallet provider presents a message to the cardholder, depending on how you are set up with the network. The message may tell the cardholder to contact the card issuer or it may contain a customer-service number to call. Galileo sends the xRDP: mobile_activation RDP event message.
   • Yellow path — Partial verification success. The wallet provider sends the contact information that Galileo provided for additional verification, and Galileo sends the xYLP: mobile_activation YLP event message.
   • The cardholder follows the instructions to provide additional verification: either call support or request an OTP. When the network sends the OTP, Galileo sends one of these event messages:
     • xACN: mobile_activation ACN — Mastercard. activation_code contains the OTP, and send_type indicates how the code was sent.
     • VAPI: mobile_activation API — Visa. passcode contains the OTP, and send_type indicates how the code was sent.
       • If the additional verification is successful, the provisioning continues on the green path.
       • If the additional verification is not successful, the provisioning attempt fails. For Mastercard, Galileo sends the xTVN: mobile_activation TVN event message (not shown in diagram). (There is no notification for Visa.)
   • Green path — All verification checks passed. The provider forwards the provisioning request to the card network.
9. The network creates the card token and sends it to the wallet provider. Galileo sends the xTKC: mobile_activation TKC event message to indicate that Visa sent the card token to the wallet provider. (There is no message for Mastercard.)
10. The wallet provider activates the token to provision the card to the wallet. Galileo sends the xTCN: mobile_activation TCN event message.

📘

Note

These event messages are triggered by notifications from either the network or the wallet provider rather than by events inside the Galileo system; therefore, the Galileo event messages may not be emitted consistently if there are communication failures upstream of the Galileo system.

Galileo validation checks

These are the checks that Galileo performs upon receiving a tokenization request from the wallet provider. As it performs checks, Galileo keeps a list of red-path and yellow-path violations and then returns the appropriate response code to the wallet provider. Galileo does not determine the response code until it has finished performing all of the checks.

1. Galileo checks the value of APPAY :
   • Y — Continues the procedure
   • N or not set — Adds a red-path violation to the list.
2. Galileo checks the value of CHKAL :
   • Y — Checks the DOB parameter against the cardholder age.
     • If the cardholder is too young, adds a red-path violation to the error list.
   • N or not set — Continues the procedure.
3. Galileo checks the device_score from the wallet provider.
   • 1 — Adds a red-path violation to the error list.
   • 2 — Checks the value of DSVCK :
     • Y — Adds a yellow-path violation to the error list.
     • YR — Adds a red-path violation to the error list.
     • Not set — Continues the procedure
   • 3–5 — Continues the procedure
4. Galileo performs AVS and checks the CVV2:
   • If both pass, continues the procedure.
   • If AVS information or CVV2 do not match, adds a red-path violation to the error list.
   • If AVS or CVV2 are not present, checks the value of BPAVS :
     • N — Adds a red-path violation to the error list.
     • Y — This is an instant-issue card that is authorized for provisioning. Continues the procedure.
5. Galileo verifies that the card and account are active (status: N). If either is not active, adds a red-path violation to the error list.
6. Galileo verifies that the last 4 digits of the mobile number match. If they do not, adds a yellow-path violation to the error list.
7. Optional. If you have enabled any of the enhanced provisioning rules parameters, Galileo applies all of the rules that you have set and adds any red- or yellow-path violations to the error list.
8. According to the error list, Galileo determines which response code to return to the wallet provider:
   • If one or more red-path violations are present in the list, Galileo returns 46 (Visa) or 05 (all other networks).
   • If one or more yellow-path violations are present in the list—but no red-path violations—Galileo returns 85 along with the information for the additional verification method (OTP or customer-service number, depending on your setup).
   • If there are no red- or yellow-path violations, Galileo returns 00 and the AVS result to the wallet provider.

Enhanced provisioning security

Galileo offers additional security measures to help prevent provisioning abuses, such as provisioning a zero-balance card to a wallet and using it for transit fare—taking advantage of the delay in authorizations—and then reprovisioning the card later and repeating the fraud.

These new security measures can deny provisioning requests that exceed limitations on deleting and reprovisioning during a specified period. Other rules that you can enable will leverage information from the card network about the wallet, suspicious transactions, and device risk scores. Many of these rules are based on the information in the tar_info object in the Auth API message.

These enhanced rules are fully configurable. You can choose from among various rules to enable that will send the provisioning request along either the red or yellow path, which can help reduce provisioning abuses and fraud.

See Enhanced Provisioning Rules for your options.

Reissuing and replacing tokenized cards

When you reissue or replace a card that has been provisioned to a mobile wallet, the card in the wallet may not be automatically updated. For example, a cardholder provisions a physical card to a mobile wallet. Later, the card expires, the cardholder receives a new card (with new CVV and expiry date) in the mail, and activates it. Because the card in the wallet has the old CVV and expiry, it cannot be used for transactions until the card network updates the information for tokenized cards, which may be several hours or a day later.

When you replace a Digital First card that has been provisioned to a mobile wallet, the digital card in the mobile wallet is not automatically replaced—you must either push-provision the new card to the wallet or the cardholder must enter it manually.

Viewing mobile-wallet transactions

To distinguish mobile-wallet transactions from other transactions, these fields are populated:

For example, the BAUT: auth message for a mobile-wallet transaction would contain something like:

• token_type: PayPal
• token_requestor_id: 400100xxxxx

The Posted Transactions RDF would have

• MOBILE TRANSACTIONS: Y
• TOKEN REQUESTOR ID: 400100xxxxx

Events API messages

You can make arrangements with Galileo to receive these mobile wallet–related Account Events messages, which you can then relay to your customers. For these events you can arrange with Galileo to customize the message that is displayed to the cardholder, provided that you are doing the messaging instead of Galileo.

The first letter of the message code indicates the wallet provider:

• A — Apple Pay
• G — Google Pay
• S — Samsung Pay

Galileo setup

See the Mobile wallets table on the Parameters page for details on these parameters. Also see Enhanced Provisioning Rules.