Tokenization in Response

E-commerce sites send a "Reservation with card data" request to a third party.
Once the e-commerce site initializes the request, the third party will send a response, with the card data.
The e-commerce site will receive the card URI that was saved in the database.

We recommend that you first review the guide for this method.

Once the response from the third party is received in PCI Booking. the card details will be extracted from the message body (the card details will be located by using the content filter specified in the target profile). The card will be tokenized, the card details in the message will be masked and the token URI will be added to the response header (the name of the header will be taken from the settings of the target profile).

If the eliminateCardDuplication parameter is set to True, the system will look up the card in the customer's stored cards and check if it already exists:

  • If it exists, then the card details will be masked and the token added to the response will be the token of the previously stored card.
  • If it does not exist, the card will generate a new token which will then be added to the response.

If the eliminateCardDuplication parameter is set to False or not added in the request, PCI Booking will generate a new token for any card processed.

📘

Access Token Vs. Session Token

Between the two options of using the Access Token or the Session Token, we would recommend using the Access Token.

📘

Multiple Authentication Methods allowed

This method accepts multiple forms of authentication methods (Session Token and Access Token). If more than one authentication method is provided, the Session Token will take precedence.

📘

All URLs should be https.

📘

Please note to urlEncode all components!

📘

CVV Retention Policy

Remember to set the CVV Retention Policy for this token.

Language
Click Try It! to start a request and see the response here!