About Mobile Wallets

A mobile wallet is a specialized smartphone app that contains tokenized versions of payment cards.

Tokenization in the context of payment cards means that instead of storing and transmitting a card's PANPAN - Primary account number. The 16-digit number that is printed on a card, beginning with the BIN. This number is not the same as the account identifier, which is the PRN, or the card identifier, which is the CAD., a randomized string is substituted instead. The randomized string is generated by the card network, which keeps track of which tokens correspond to the PANs. The tokens can be specific to a particular merchant or mobile wallet, or be valid for only a specified number of purchases. Malicious actors who intercept tokens cannot use them to transact because they do not also have the associated mobile wallet, or they are not using the right token with the right merchant, or the token has already expired.

A mobile wallet, instead of containing a card's PAN, CVVCVV - Card verification value. A number that is included on a card to help verify that a cardholder has the actual card (physical or virtual) in hand. CVV1 is a value that is embedded in a card's magnetic stripe, CVV2 is a 3- or 4-digit number printed on the actual card, and iCVV is a number embedded in security chips. In most cases, "CVV" refers to CVV2., and expiry dateexpiry date - The date that a card expires. This date is displayed on a virtual or physical card and is randomly set at the time the card is created. The expiry date is encrypted in the Galileo system and cannot be retrieved by anyone who is not PCI compliant., contains only the token. The PAN, CVV, and expiry date are therefore not visible to the cardholder in the wallet interface.

Cardholder experience

  1. The cardholder installs or already has a mobile wallet app on their phone. If the cardholder intends to use the mobile wallet at physical points of sale, the phone's hardware must support NFCNFC - Near-field communication. A wireless transmission specification for two devices at a distance of 4 cm or less. Used for mobile wallet payments at physical points of sale. transmissions.
  2. The cardholder requests a payment card from the issuer or requests that an existing payment card be included in the mobile wallet.
  3. The card is provisioned to the wallet in one of these ways:
    • Using the mobile wallet's interface, the customer manually inputs the PAN, expiry, CVV and other information. The wallet tokenizes the card.
    • The issuer pushes the card to the wallet in the form of a card image and a token..
  4. At a point of sale the customer has these options:
    • Physical point of sale — "Wave" the phone near an NFC card reader
    • Virtual point of sale — Configure a merchant's app to use the card in the mobile wallet
  5. The merchant transmits the token to the card network, which correlates the token with the PAN.
  6. The network forwards the authorization request to the issuer.
  7. The issuer approves the authorization request.
  8. The merchant completes the transaction.

Options

To support mobile wallets you will need to decide among these options:

  • Which mobile wallets to support. In a typical implementation, all three wallet types are supported:
    • Apple Pay
    • Google Pay
    • Samsung Pay
  • Which card to tokenize:
    • A physical card. The tokenized version has the same PAN and PRN as the physical card. An existing physical card can be tokenized, or with the Digital First Program the tokenized card is made available for use before the physical version is mailed to the cardholder.
    • A digital-only card. A virtual card is tokenized but is never embossed and is not associated with a physical card. To provide an image of this card, with the PAN visible for use outside a digital wallet, see Presenting digital cards in the Digital Cards guide.
  • How to perform provisioning:
    • The cardholder manually inputs the card information in the wallet.
    • You push-provision the card to the cardholder's wallet. This method requires extra setup with Galileo so that cardholders can use your app to move their cards to their mobile wallets.
  • What to do for red-path verification attempts:
    • Customer service number
    • Other message
  • Who handles yellow-path verification:
    • Galileo
    • You. Your call center must be PCI compliant.
  • What to do for yellow-path verification attempts:
    • Send a one-time password (OTP)
      • Via email
      • Via text
    • Provide a customer-service number
  • Who sends mobile wallet messages to cardholders:
    • Galileo
    • You. See Events API messages for a list of possible messages to relay to cardholders.
  • How the messages are sent:
    • Text message (SMS)
    • Email
    • Both (giving cardholders the option)

Initial setup

Each card network has its own service for mobile wallets:

  • Mastercard Digital Enablement Services (MDES)
  • Visa Digital Enablement Program (VDEP)

This is the contact information for each wallet provider to obtain their documentation and SDKSDK - Software development kit. A set of tools to help developers of one system integrate with another system, usually by another vendor.:

Galileo will provide you with the full list of items to provide to Galileo and actions to perform before Galileo sends all of the information to the card network for processing. Below are some of the important setup items.

Manual provisioning

As a first step, you must set up manual provisioning for mobile wallets in general. If you desire also to provide push-provisioning, you will perform additional steps, as described in Push provisioning.

  • Ensure that there are contractual arrangements between the issuing bank, the wallet providers and card networks that are specific to mobile wallets.
  • Provide these things to Galileo:
    • Customer service number for yellow-path (partial success) verification, if Galileo is not handling yellow-path calls.
    • BIN range to tokenize
    • Terms and conditions documents as required by the networks and wallet providers, in TXT format.
    • Network-specific metadata, as shown below
    • Which mobile wallet events to set up

Mastercard metadata

For a Mastercard program you must provide these items to Galileo:

  • BPMS (Business Process Management System) Guide — An Excel document that contains questions to answer for setup
  • The tokenized card template, which is similar to a virtual card template except that it does not display the entire PAN, CVV, or expiry. All designs must be approved by the issuing bank.
    • Card image (1536 x 969 pixels) in PNG format; must include your logo and card network logo.
      • The image must not contain these elements:
        • Embossed attributes
        • Transparency overlays
        • Magstripe
        • EMV chip faceplate or contacts
        • Hologram
        • Rounded corners
        • Shading or three-dimensional effects
        • Labels for "Member since," expiry date, or cardholder name
        • Miniature BIN under the PAN
        • White or other color background behind the image
    • RGB values (255, 255, 255)
      • Card background, when the image cannot be rendered
      • Foreground, for the last four digits of the PAN
      • Label, for text on the front of the card
    • Your logo (1372 x 283 pixels) in PNG format
    • Mobile notification elements:
      • Smaller icon (100 x 100 pixels) in PNG format. Should be the primary brand associated with the card
      • A short card description (max 32 characters)

Visa metadata

For a Visa program you must provide these items to Galileo:

  • The tokenized card template, which is similar to a virtual card template except that it does not display the entire PAN, CVV, or expiry. All designs must be approved by the issuing bank.
    • Card image (1536 x 969 pixels) in PNG format; must include your logo and card network logo.
      • The image must not contain these elements:
        • Embossed attributes
        • Transparency overlays
        • Magstripe
        • EMV chip faceplate or contacts
        • Hologram
        • Rounded corners
        • Shading or three-dimensional effects
        • Labels for "Member since," expiry date, or cardholder name
        • Miniature BIN under the PAN
        • White or other color background behind the image
    • RGB values (255, 255, 255)
      • Card background, when the image cannot be rendered
      • Foreground, for the last four digits of the PAN
      • Label, for text on the front of the card
    • Mobile notification elements:
      • Smaller icon (100 x 100 pixels) in PNG format. Should be the primary brand associated with the card
      • A short card description (max 32 characters)
  • Contact information to put on the back of the card:
    • Contact name
    • Customer service phone number
    • Email address
    • Contact website

Manual provisioning workflow

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, CVV, and expiry in the mobile wallet interface, as well as other identifying information that the wallet requests.
  3. The wallet provider performs some initial checks. If the checks do not pass, the wallet provider informs the cardholder that the provisioning has failed.
  4. If the initial checks pass, the wallet provider sends an authorization request to the card network. The request contains an OTP, depending on how your program is set up.
  5. The card network forwards the authorization request to Galileo.
  6. Galileo performs the following checks. If any of these checks fail, Galileo returns response code 05.
    • CVV2 verification
    • Card or account in wrong status
    • Card not instant issue
  7. Galileo performs further checks. If any of these checks fail, Galileo returns response code 85 along with either the cardholder's mobile number or email or a customer service number, depending on your setup.
    • AVSAVS - Address verification service. An authentication method whereby the merchant submits a card's billing address in an authorization request. for address and zip
    • Last 4 digits of mobile
  8. If all checks pass Galileo returns response code 00 along with the AVS result.
  9. Based on Galileo's response and its own algorithms, the wallet provider determines whether the provisioning attempt should be on the red, yellow, or green path.
    • Red path means 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.
    • Yellow path means partial verification success. The wallet provider may send an OTP by the method that you have set up (email or text), or it may send a customer-service number.
      • If the additional verification is not successful, the provisioning attempt fails.
      • If the additional verification is successful, the provisioning request moves onto the green path.
    • Green path means that all verification checks are passed. The provider forwards the provisioning request to the card network.
  10. The network creates the card token and sends it to the wallet provider.
  11. The wallet provider activates the token to provision the card to the wallet.

Push provisioning

If you will be push-provisioning cards to mobile wallets, you must perform all of the steps in the manual provisioning section, and then you must obtain the SDKs and in-app provisioning documentation from each wallet provider.

Push provisioning workflow

The push-provisioning process involves these entities:

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

This is the workflow when you push-provision cards to mobile wallets:

  1. The cardholder requests a tokenized card in your mobile app.
  2. You send a provisioning request to the mobile wallet provider.
  3. The wallet provider returns certificates, keys, and other data.
  4. You send a Create Provisioning Request call to Galileo with the data supplied by the wallet provider. Follow the instructions in the Creating a Provisioning Request guide.
  5. Galileo encrypts the payload and returns the response to you.
  6. You create a tokenization request with the encrypted payload and send it to the wallet provider via its SDK.
  7. The wallet provider decrypts the payload and verifies whether the tokenization request is valid.
  8. Because the cardholder's identity has already been verified in your app, there are no red, yellow, or green-path checks. All provisioning attempts are by-definition on the green path.
  9. The card network creates the card token and sends it to the wallet provider.
  10. The wallet provider activates the token to provision the card to the wallet.

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
CodesNameDescription
ATCN
GTCN
STCN
mobile_activation TCNA card was successfully provisioned to a mobile wallet.
AYLP
GYLP
SYLP
mobile_activation YLPAn attempt to provision a card to a mobile wallet was unsuccessful and entered the yellow path.
AACN
GACN
SACN
mobile_activation ACNMastercard sent an activation code after an activation attempt entered the yellow path.
VAPImobile_activation APIVisa sent an activation code after an activation attempt entered the yellow path. The message code is VAPI for all wallet providers.
ATVN
GTVN
STVN
mobile_activation TVNMastercard only. An activation attempt using the mobile activation code was unsuccessful.
ARDP
GRDP
SRDP
mobile_activation RDPAn attempt to provision a card to a mobile wallet has failed and entered the red path.
TKUPtoken_updateMastercard only. A tokenized card was frozen, unfrozen, reissued, or cancelled, and the updated tokens have been synchronized with Mastercard.

Galileo setup

These internal parameters are set at Galileo according to your use case.

ParameterLevelDescription
APPAYProgram
Product
Required. When this parameter is set, the provisioning request is approved with 00 (green path) only if the following conditions are true: Account is active and contains sufficient funds, AVS check matches ZIP and address, Last 4 digits of phone number match, Is not an instant-issue card, CVV2 is present and matches
IPCIDProductMastercard only. Specifies the product configuration ID to be used for activation code distribution (ACN) methods for mobile wallet authorization. When this parameter is not set, Mastercard mobile wallet transactions are declined with authorization response code 05 (do not honor).
PPBBIProductVisa only. Required. Specifies which encryption key was used to encrypt provisioning data when performing a key exchange with Visa. This parameter should be set only after the key exchange has taken place. Set this parameter on the product that is to be tokenized.
PPNProgramVisa only. Contains the number that Visa cardholders can call to perform manual provisioning to a mobile wallet when a failed provisioning attempt is on the yellow path and Galileo is not providing yellow-path customer service.
PPUPCProductTokenize this card. Required for any product with a card that is to be tokenized.
TOKUPProductMastercard only. Controls whether Galileo synchronizes tokens with MDES when cards are frozen, unfrozen, reissued, or canceled. This parameter must be enabled to trigger the TKUP event.
XAACTProductSet this parameter to YNN to automatically activate the account and card upon creation.

Did this page help you?