Network tokenization

Card tokenization is a service that replaces the PAN (Primary Account Number) with a token, which is provided directly by the card brands. Although each brand has its own token model to generate unique tokens, they all follow the same format, adhering to the same structure as a PAN, consisting of 16 digits, including the BIN and a verification digit. As a result, the data remains in the same format and retains the same level of security, while simultaneously being interoperable and capable of being processed by any acquirers that support network tokenization.

Additionally, every transaction involving a card brand token requires the generation of a cryptogram, adding an extra layer of security to e-commerce transactions and ensuring that the token is valid and can be processed. In order to complete the transaction, both the token and cryptogram must be generated by the same provider.

Observations when using network tokenization during payments

In order to use the tokenization number, it should be placed as the number_token value, alongside its corresponding expiration date. To be able to read the information generated in the token request at the time of payment, the GetNet API expects to receive the following additional information (which can be found in the tokenization object, a third-level object inside any Authorization request):

In the Required column, Conditional means the field is required only in specific scenarios, described in the field’s row.

For more details, see the API reference

Transparent tokenization (internal)

In order for transactions to be carried out securely, the card data will be tokenized with GetNet’s internal authorization flow, without the need for a prior tokenization request. Therefore, when sending a payments request, the request body should contain the following properties inside the third-level card object:

Third-party tokenization (external)

It is possible to authorize payments with tokenized cards in solutions external to GetNet. In order to do so, when sending a payment request, the request body should contain the card data inside the card object and the already mentioned properties (type, cryptogram, eci, requestor_id) inside the tokenization object.