Card tokenization process and onboarding

The card tokenization process with Pismo involves the following participants:

  • Card network - The entity (Visa, Mastercard, and so on) responsible for generating the token using card sensitive information. The network manages the tokenization and authorization process and is involved throughout.
  • Token service providers (Pismo) - TSPs are responsible for token management. A TSP provides the APIs necessary for provisioning and lifecycle flow according to each network certification.
  • Token requestor - All entities that request payment tokens in return for a payment card. These entities include wallets, issuer apps, and e-commerce sites.
  • Issuers - Also known as Payment Service Providers (PSP). Makes decisions on each tokenization request based on several parameters to ensure that tokenized cards are issued to the rightful owners. As with physical cards, the Issuer must also handle the life cycle management of existing tokens. To be able to issue these cards and participate in these processes, the issuer must connect to a TSP such as Pismo.

As a TSP, Pismo provides network-agnostic API endpoints that can handle tokenization requests and responses for different networks. However, we also account for network-specific differences. Our solution provides different payloads for each network in the events stream, including network-specific metadata that provides additional context about the token and its status, such as the network identifier, tokenization scheme, and token expiration date. This approach helps simplify the development process for issuers and processors and improves the user experience for customers using digital wallets for payments.

Push provisioning

Card network push provisioning is a process that allows payment card provisioning onto mobile devices, enabling users to make contactless payments using their smartphones or other mobile devices. The term - push provisioning - refers to the method card networks (such as Visa or Mastercard) securely transfer card credentials to a mobile device.

Here is a simplified explanation of how card network push provisioning typically works:

  1. Enrollment - The user selects a payment card (credit, debit, or prepaid) from their financial institution or card issuer to be provisioned onto their mobile device.
  2. Request - The mobile payment application on the user's device sends a request to the card network or PSP to provision the selected card.
  3. Tokenization - The card network generates a unique digital token that represents the card details. This token acts as a surrogate value for the actual card information and is used to ensure security during transactions.
  4. Secure element or cloud storage - The tokenized card information is securely stored in the mobile device's secure element (a tamper-resistant hardware component) or a secure cloud-based storage solution.
  5. Verification - The card network or PSP verifies the user's identity and eligibility to use the selected card for mobile payments. This step typically involves authentication methods such as one-time passwords or biometric verification.
  6. Push provisioning - Once the verification is successful, the card network "pushes" the tokenized card information to the user's mobile device. This transmission occurs securely through an encrypted channel.
  7. Device storage - The mobile payment application receives the tokenized card information and stores it securely within the device's secure element or cloud storage. The actual card details are not stored on the device.
  8. Ready for use - The user's mobile device is now ready to make contactless payments using the provisioned card. The mobile payment application uses the token to initiate secure transactions with merchants' payment terminals.
  9. Transaction authorization - When the user makes a payment, the mobile payment application sends the tokenized card information, along with other necessary transaction details, to the card network or PSP for authorization.
  10. Transaction processing - The card network or payment service provider validates the token, authorizes the transaction, and initiates the payment process with the merchant's acquiring bank.
  11. Payment completion - Once the transaction is approved, the payment is processed, and the user receives a confirmation of the successful transaction.

It's important to note that the specific implementation and technical details may vary depending on the card network, mobile device, and payment service provider involved.

Tokenization onboarding

Follow these general steps to tokenize your cards for third-party wallets such as Google or Apple Pay and e-commerce card-on-file tokens:

  1. Enable Pismo tokenization - Talk to your Pismo representative and they will provide you with the necessary information and requirements to get started.
  2. Register with your digital wallet provider - Register with your wallet provider as a participating issuer. During the registration process, you will need to provide information about your company, your card products, and your technical capabilities.
  3. Implement the Pismo events stream - After enabling tokenization, you'll need to monitor the events stream for tokenization flows. This involves setting up your data reporting and monitoring to receive notifications about tokenization events such as token creation, suspension, and deletion.
  4. Obtain certifications - After registration, you need to obtain certifications from the card networks and your wallet provider to validate your integration and compliance with their respective standards. This can be part of Card network certification.
  5. Test and launch - After completing the integration, perform testing to ensure that your tokenized cards work correctly with your digital wallet provider.

πŸ“˜

Issuer anti-fraud webhook

While Pismo provides basic token provisioning validation, it is recommended issuers implement additional risk validation solutions such as anti-fraud measures to ensure deeper validation. You can provide Pismo with an anti-fraud webhook that gets called during the tokenization process.

Card token lifecycle

Pismo uses the following card token enums:

  • INACTIVE - Initial token status during provisioning. Can be activated or deactivated.
  • FAILED - Token was not provisioned due to error. Cannot be changed
  • ACTIVE - Activated token that can be used for transactions. Can be suspended or deactivated.
  • SUSPENDED - Token is temporarily disabled and cannot be used for transactions. Can be activated or deactivated
  • DEACTIVATED - Token is deleted. Cannot be changed.

Pismo tokenization endpoints