Skip to main content

Card Data & PIN Management

Once the card has been created—within the context of its specific customer and account—it can be managed by the end user according to a process that complies with PCI DSS (Payment Card Industry Data Security Standard) best practices.

The process is designed such that—with the exception of the Card Processor—sensitive card information is never exposed publicly and is never transmitted in cleartext over the communication channel.

To achieve this objective, the process utilizes a public/private key mechanism. This ensures that only the requester of the information — typically the end user — is able to read the data. In this flow, the public key is used to encrypt the information at the source, while the corresponding private key, held exclusively by the requester, is used for decryption.

Overview​

The following sections detail the process and the information exchange between the parties. As previously mentioned, the flow always begins with a request from the cardholder, who may need, for example, to retrieve his PAN, CVV, or the card's expiration date. For the sake of completeness, it is important to highlight that both the PIN recovery and PIN change processes adopt the same approach.

There are three primary actors involved in the workflow:

  • The Mobile App, which interacts with the cardholder and provides the functionalities for data visualization and card management.
  • The Affiliate Backend, which is responsible for authenticating the end user and providing the Mobile App with the necessary information.
  • The Issuer (P2 Platform), which holds the card data and ensures full compliance with PCI DSS standards.

A simplified version of the interaction between the parties can be summarized as follows:

  • (1) The Mobile App initiates a request for information from the Affiliate Backend.
  • (2) The Affiliate Backend requests an authorization token from the Issuer.
  • (3) The Issuer issues the authorization token to the Affiliate Backend.
  • (4) The Affiliate Backend forwards the token to the Mobile App.
  • (5) The Mobile App uses the token to retrieve the information directly from the Issuer.
  • (6) The Issuer validates the token and delivers the requested information to the Mobile App

The following section provides a complete example of the PAN recovery process, illustrating how the involved actors interact to achieve the use case objective. Please note that although this example focuses on 'PAN Retrieval', the same cryptographic approach applies to the recovery (or update) of all card information that should be accessible to the cardholder.

WARNING: It is important to note that when sensitive information is transferred from the Issuer to the Mobile App, it is always encrypted by the Issuer using the public key provided by the Mobile App. This process ensures that the data remains unaltered during transit. Conversely, when sensitive information travels from the Mobile App to the Issuer, the latter must provide a public key, and the Mobile App is responsible for encrypting the data. The system implements a bi-directional asymmetric encryption flow.