Card tokenization & push provisioning

Card tokenization refers to the creation of a secure digital "copy" of a preexisting card (either physical or virtual). The copy is then added to a token network, such as Apple Pay or Google Pay. In the case of Apple Pay and Google Pay, a token can be provisioned manually (i.e., a tokenization request is initiated from the Apple or Google wallet) or via push provisioning (i.e., the request is initiated from your application).

This page explains how to use the Solaris API to tokenize a customer's card using push provisioning.

Implementation steps

To initiate a push provisioning, call the respective endpoint for Apple Pay or Google Pay:

Note that you must retrieve the following information from Apple or Google and then provide it to Solaris via the API:

Apple Pay:

  • nonce: A one-time-use nonce provided by Apple. You must hex-encode this value before providing it to the API.
  • nonce_signature: Nonce signature provided by Apple. You must hex-encode this value before providing it to the API.
  • certificates: An array of leaf and sub-CA certificates provided by Apple. Each object contains a DER-encoded X.509 certificate, starting with the leaf and followed by the sub-CA. You must encode this value in Base64 format before providing it to the API.

Google Pay:

  • client_wallet_account_id: Unique 24-byte identifier for each instance of a [Android user, Google account] pair wallet. The ID is computed as a keyed hash of the Android user ID and the Google account ID. The key to this hash lives on Google's servers, and the wallet ID is created during user setup as an RPC.
  • client_device_id: Stable identifier for a physical Android device. Google refers to this attribute as a "Stable hardware ID" in their SDK documentation. The method getStableHardwareId describes how you can retrieve this value.
  • client_app_id: Unique identifier for the client application. Use value SolarisPushProvisioning.

The API will return a wallet_payload that you must then submit to the wallet provider (Apple Pay/Google Pay) as part of a push provisioning request to their respective API. Please refer to the Apple Pay/Google Pay developer documentation for more details on this process.

Apple Pay In-app verification

The Solaris API supports in-app verification for Apple Pay using Cryptographic OTP (Method A). The process works as follows:

  1. Call the POST Fetch activation payload for Apple Pay in-app verification endpoint for the relevant card.
  2. The Solaris API will create a change request. Have the customer complete the change request following the standard process.
  3. The Solaris API will return an activation payload. Submit this payload in your request to the customer's Apple Wallet via the Apple Pay API. See the Apple Pay developer documentation for more details on how to do so.