Network Token Provisioning

How Network Tokens are created.

Token provisioning is the process of requesting a Network Token from the relevant card scheme for a specific PAN and for a specific purpose, domain or device. The diagram below shows how PCI Proxy is involved in provisioning Network Tokens.

Network Token Provisioning with PCI Proxy.

Network Token Provisioning with PCI Proxy.

Legend:

PAN: Credit card number

NT: Network Token

DT: PCI Proxy (Datatrans) Token

  1. Cardholder enters card details
  2. PCI Proxy requests a Network Token at the relevant card scheme
  3. Card schemes reach out to the card issuing bank of the cardholder
  4. Card issuing bank creates a Network Token and returns it via the card schemes to PCI Proxy
  5. PCI Proxy maps the Network Token to the PCI Proxy token which is returned to the merchant

📘

Mapping a Network Token to a PCI Proxy token allows you to continue to use PCI Proxy services without changing your code and not extending your PCI scope.

When does a Network Token get provisioned?

Once you are onboarded with Network Tokenization, we will automatically request a new Network Token each time a payment card gets captured and tokenized via PCI Proxy's APIs. As of December 2022, using one of the following integration methods supports Network Token provisioning:

As soon as a PAN hits one of the above APIs, we will create a Network Token and corresponding cryptogram in the background. We map the Network Token data and its metadata (cryptogram, expiry date, ECI value) to a PCI Proxy token, which is then returned to your servers.

📘

A CVC code is not required to create a Network Token.

How do I know if a Network Token was provisioned?

You will know if a Network Token has been provisioned if you see a networkToken object returned in the response of the relevant API call. When that object is present, a Network Token has been mapped to a PCI Proxy token in the background.

This means that you can continue to use your PCI Proxy tokens without changing your integration with us and without extending your PCI scope, all whilst benefitting from Network Tokens.

Secure Fields and mobile SDKs

If you use the Secure Fields or mobile SDK integration, you can call the Tokenization endpoint to check this. For example:

curl --request POST \
  --url https://api.sandbox.datatrans.com/v1/tokenizations/220112095131012129 \
  --header 'Authorization: Basic {{basicAuth}}' \
  --header 'Idempotency-Key: e75d621b-0e56-4b71-b889-1acec3e9d870'

as part of the response we will return a networkToken field.

{
    "paymentMethod": "ECA",
    "alias": "7LHXscqwAAEAAAGK9a-K2x3hgAOkAN3A",
    "fingerprint": "F-cg_iu0Xulk1UNMtL57hZW3",
    "maskedCard": "222285xxxxxx7008",
    "expiryYear": "25",
    "expiryMonth": "05",
    "cardInfo": {
        "brand": "MASTERCARD",
        "type": "credit",
        "usage": "consumer",
        "country": "US",
        "issuer": ""
    },
    "networkToken": {
        "expiryMonth": "11",
        "expiryYear": "26",
        "status": "ACTIVE"
    }
}

Alias Status

If you are using a PCI Proxy Alias you can use the Status API to check this. For example:

curl --request GET \
  --url https://api.sandbox.datatrans.com/v1/aliases/{{alias}} \
  --header 'Authorization: Basic {{basicAuth}}'

will return

{
    "alias": "7LHXscqwAAEAAAGLgKAf-F9X1QGrAHsa",
    "fingerprint": "F-f5AcNienVUz735BKis71pD",
    "type": "CARD",
    "masked": "489537xxxxxx6386",
    "dateCreated": "2023-08-30T12:47:39Z",
    "card": {
        "panRemoved": false,
        "expiryMonth": "05",
        "expiryYear": "25",
        "cardInfo": {
            "brand": "VISA",
            "type": "debit",
            "usage": "consumer",
            "country": "US",
            "issuer": "U.S. REGION"
        },
        "networkToken": {
            "expiryMonth": "05",
            "expiryYear": "25",
            "status": "ACTIVE",
            "paymentAccountReference": "V0010013020217426481676671969"
        },
        "last4": "6386"
    }
}

Vault API

When requesting a Network Tokens through the Vault API we return a tokenCreated boolean in the response indicating if a Network Token has been provisioned or not.

{
    "overview": {
        "total": 1,
        "successful": 1,
        "failed": 0
    },
    "responses": [
        {
            "type": "CARD",
            "alias": "7LHXscqwAAEAAAGK9XTQlTBAi4aeAGav",
            "maskedCC": "222285xxxxxx7008",
            "fingerprint": "F-cg_iu0Xulk1UNMtL57hZW3",
            "networkToken": {
                "status": "ACTIVE",
                "tokenCreated": true,
                "expiryMonth": "11",
                "expiryYear": "26"
            }
        }
    ]
}

Network Tokens and PANs

Although the final goal of Network Tokenization is to remove plain text card numbers completely, PCI Proxy will store the underlying PAN behind each PCI Proxy token in this transition period. This allows us to provide a fallback solution when Network Tokens can't be used, since not all parties in the payment ecosystem are accepting them.

🚧

For PCI DSS level 1 compliant merchants we also offer to the option to receive plain Network Tokens and cryptograms via the Vault API detokenisation endpoint.

By keeping the PAN on our secure server, we allow merchants to continue forwarding PANs to third-party receivers who are either not yet able to consume Network Tokens or whose issuing bank is not yet supporting Network Tokens.

Remove underlying PAN

Regulation requirements in some countries and markets prohibit the storage of any PAN, even for PCI CSS Level 1 certified organizations. If you no longer want PANs to be stored for a given PCI Proxy token you can remove it from storage by using the PATCH API.

If you don't want us to store the card number at all anymore by default, please contact our team.