This improves the customer’s experience by allowing immediate access to the PIN while bringing down your costs by making PIN letters delivered by mail unnecessary.

​
Key benefits of the service include:

  • Safe and convenient way for your customers to access payment data when needed. No need to write sensitive details on a post-it note, for instance, since the information is always available on the go.
  • A fully digital PIN process that enables a great customer experience while bringing down your costs by making PIN letters delivered by mail unnecessary.
  • Easy and fast implementation with a well-designed API.
  • Security and PCI compliance. Designed to avoid exposure of sensitive, PCI-categorised data to the web/app back-end. The functionality is developed, assessed, and certified for PCI DSS.

​
PIN retrieval process

Endpoint: Request PIN Control access token by plasticId.

This process generates an access token used to view the card data, enabling your customers to access their card data through their own devices, via an app or web interface.

  1. Your customer is authenticated using SCA after which they make a request to view their PIN.
  2. You will need the plasticId of the card. The plasticId is specific to each sequence of the card (to support situations where there are several cards with the same card number but different expiration dates). You should choose the plasticId that has “status": "ACTIVE"
  3. The plasticId is used to request a token and URLa. the request will fail if plasticId is not valid b. besides plasticId, no additional validation is done. This means that Enfuce will not validate open-to-buy, card status or usage limiters of the card when responding to the request. In order to validate if a purchase can be made with the card data in question, separate API calls need to be done to retrieve the real-time status of the card and its balance.
  4. The successful response from this endpoint returns an id and a pinURL a. Note that the id is valid for 30 seconds which is the deadline for the customer device to make the POST call to retrieve the HTML snapshot. b. Note as well that the token is a JWE (JSON Web Encryption) token, which keeps the content encrypted to keep it safe during transport.
  5. Your customer’s device (app/web interface) is instructed to access the returned URL to view card data.
  6. Your customer’s device retrieves an HTML snapshot by executing a POST call to the pinURL with the content of the id in a form field named controlId. a. <URL_GOES_HERE>?controlId=<ID_GOES_HERE> b. The request will fail if the token is not valid.
  7. The returned HTML contains JavaScript which will handle encryption and fetching of PIN data. a. A public key pair is generated on the device. b. The public key is sent to Enfuce. c. The PIN is encrypted with the public key and returned to the device.
  8. The PIN is decrypted by JavaScript on the device and added to the HTML snapshot. You can design the app to display the information in accordance with their own web/app design.

​
PCI and security considerations

The service is designed to avoid exposure of sensitive, PCI-categorised data to the web/app back-end, which is why the PIN data is sent directly from the service endpoint to the customer’s device. The functionality is developed, assessed, and certified for PCI DSS. PCI DSS regulations are very detailed, but here are a few that have an impact on this functionality:

  • Card data remains encrypted in transport.
  • No card data is stored in the process.
  • The software is code-reviewed.
  • The publicly exposed endpoint is protected by a web application firewall.

The customer device will not fall within PCI scope, as it will not have access to, be connected to, or be able to impact the Enfuce system where the PIN data resides. In other words, the device displaying the PIN data does not access the data itself, rather the content is rendered inside a browser widget (Webview or iFrame).

We recommend the following guidelines for issuer application development:

  • The app on your customer’s device and the related back-end should ensure that your customers are strongly authenticated (SCA) before being able to view the PIN data. It is recommended that each view be preceded by an SCA event, and this should be done every time the customer wants to view their PIN.
  • The app on your customer’s device must show the PIN data for as short as possible and it is recommended that there is a timeout of 1 minute until the PIN data view is automatically closed for your customer.
  • The app developers need to take the necessary precautions to stop other apps or processes from accessing or interacting with the PIN data view.
  • The app developers need to ensure that the communication between the app and the related back-end is done in an authenticated and encrypted session.

Have a look at the PIN Control API documentation for more technical details.