For compatible issuing banks and third-party receivers, Network Tokens can be used like regular FPANs to authorize payment transactions. Our Forward Proxy can be used to forward Network Tokens, including cryptograms, to the receiver of your choice. Depending on what your receiver is able to receive (Network Token or FPAN) and the format of the payload which you send to PCI Proxy, we can determine which of the two to send to the target.

PCI Proxy to Network Token

When converting in this direction, we also request a new cryptogram at the schemes on the fly. Additionally, we also create other required values and populate them directly in your API request before forwarding it to the receiver. Such values may include the expiry rate, the ECI value of a Network Token, or token type.

Customer initiated payments

For these transactions, a cryptogram needs to be created at the point of authorization. This is because a cryptogram has a limited lifespan and must be sent to the payment service provider along with the Network Token. Merchant initiated transactions don't require a cryptogram.

Example: forwarding Network Tokens to the Datatrans Payment Gateway

1. Add the integration

Navigate to the Integrations menu in the Dashboard and add the relevant receiver for your project.

2. Check the integration

Check the Integration settings to see if it is ready to accept both Network Tokens and PANs. Review the payloads listed in the settings.

📘

If there is no Network Token payload in the integration, request a new integration.

Alternatively, reach out to us to provide us with the required information.

3. Build your request

Prepare your request payload according to what the receiver expects and send it to the forward proxy. The following examples convert a PCI Proxy token to either a Network Token or a PAN.

curl --request POST \
  --url https://sandbox.pci-proxy.com/v1/pull \
  --header 'Authorization: Basic {Datatrans merchantId}:{Datatrans password}' \
  --header 'Content-Type: application/json' \
  --header 'X-CC-MERCHANT-ID: {{pciProxyMerchantID}}' \
  --header 'X-CC-URL: https://api.sandbox.datatrans.com/v1/transactions/authorize' \
  --header 'pci-proxy-api-key: {{pciProxyApiKey}}' \
  --data '{
	"currency": "EUR",
	"amount": 1000,
	"refno": "test_nt",
	"card": {
		"type": "NETWORK_TOKEN",
		"token": "7LHXscqwAAEAAAGECbvb7UQKOtZpAL2C",
		"expiryMonth": "",
		"expiryYear": "",
		"tokenType": "",
		"cryptogram": "",
		"3D": {
			"eci": ""
		}
	}
}'

curl --request POST \
  --url https://sandbox.pci-proxy.com/v1/pull \
  --header 'Authorization: Basic {Datatrans merchantId}:{Datatrans password}' \
  --header 'Content-Type: application/json' \
  --header 'X-CC-MERCHANT-ID: {pciProxyMerchantId}' \
  --header 'X-CC-URL: https://api.sandbox.datatrans.com/v1/transactions/authorize' \
  --header 'pci-proxy-api-key: {{pciProxyAPIKey}}' \
  --data '{
  "currency": "EUR",
  "amount": 1000,
  "refno": "test_PAN",
  "card": {
    "number": "7LHXscqwAAEAAAGECbvb7UQKOtZpAL2C",
    "expiryMonth": "02",
    "expiryYear": "23"
    }
}'

As you can see, the payload structure is different if the target (in this case, the Datatrans Authorize endpoint) consumes Network Tokens or PANs.

For the Network Token example, you only need to send us the PCI Proxy token and leave the other Network Token fields empty in the payload, as we will take care of them. When cryptogram and eci value are requested, we write them, along with the rest of the missing values, such as expiryMonth, expiryYear and tokenType , all to empty fields before forwarding them to the target URL configured on the receiver.

📘

When testing in our sandbox, we recommend using the Traffic Inspector feature to see what PCI Proxy is converting to and what is being forwarded to the target's endpoint.