Server-to-Server Network Tokens

Standalone tokenization

The merchant collects card data from shopper and initiates tokenization. No payment request/flow involved. A registration token is synchronously provisioned and returned to the merchant. The registration token can then be used in subsequent payments. In the background, a network token is being provisioned by the card network with Issuer involved in the token approval process to make it active for payments.

---

How it works

Transactions:

---

1. Create the token

Perform a server-to-server POST request with the required customer data, but excluding paymentType. The response to a successful request is an id that should be stored and used in subsequent payments.

A token transaction history is provided in the response to let you know that the network token provisioning kicked-off with the card network. The provisioning request takes time with issuer involved in the token approval process. The network token will be fetched with the subsequent payment attempt.

"transactions":[
  {
	"reason":"tokenization",
	"transactionId":"<UUID>",
	"clearingInstituteName":"TokenVault",
	"paymentType":"TK",
	"result":{
	  "code":"000.000.000",
	  "description":"Transaction succeeded"
	}
  }
]

Sample request:

2. Send payment using the token

Perform a server-to-server POST request over the registration token retrieved in the previous step.

A token transaction history is provided in the response to tell you that the network token is attempted to be fetched from the card network. The payment authorization continues with real card data if no network token is yet active for payments.

"transactions":[
  {
	"reason":"tokenization",
	"transactionId":"<UUID>",
	"clearingInstituteName":"TokenVault",
	"paymentType":"TF",
	"result":{
	  "code":"000.000.000",
	  "description":"Transaction succeeded"
	}
  }	
]

The network token BIN (Bank Identification Number) is different than the original PAN (Primary Account Number) BIN. However, the original PAN BIN is provided in the response to help you with a better post-authorization real issuer BIN management.

"card":{
  "bin":"<bin>",
  "last4Digits":"<last4>",
  "holder":"<holder>",
  "expiryMonth":"<month>",
  "expiryYear":"<year>"
}

Sample request:

Tokenization during payment

The merchant collects card data from shopper and initiates tokenization along an account verification (zero amount auth) or initial purchase. A registration token is synchronously provisioned and returned to the merchant once the payment is complete. The registration token can then be used in subsequent payments. In the background, a network token is being provisioned by the card network with Issuer involved in the token approval process. The payment is authorized with real card data or with the network token if available and active.

---

How it works

Transactions:

---

1. Create the token during payment

Perform a server-to-server POST request with createRegistration=true and all required payment and customer data, including payment type, amount and currency. The response to a successful request is a registrationId that should be stored and used in subsequent payments.

A token transaction history is provided in the response to let you know that the network token provisioning kicked-off with the card network. The network token is then attempted to be fetched before the payment authorization beggins. If no network token is yet active for payments then the payment authorization continues with real card data.

"transactions":[
  {
	"reason":"tokenization",
	"transactionId":"<UUID>",
	"clearingInstituteName":"TokenVault",
	"paymentType":"TK",
	"result":{
	  "code":"000.000.000",
	  "description":"Transaction succeeded"
	}
  },
  {
	"reason":"tokenization",
	"transactionId":"<UUID>",
	"clearingInstituteName":"TokenVault",
	"paymentType":"TF",
	"result":{
	  "code":"800.900.303",
	  "description":"No token created"
	}
  }	
]

Sample request:

Switching to network token

A merchant initiated (MIT) payment is submitted based on the available card-on-file agreement with the shopper. Card is already on file, but as it's not yet network tokenized then a provisioning of a network token is kicking-off. The current payment is authorized with real card data. The subsequent payments will attempt to fetch a network token from the card network before payment authorization beggins.

---

How it works

Transactions:

---

1. Switch to network token

Perform a server-to-server POST request over the stored registration token with all required payment and customer data, including payment type, amount and currency.

A token transaction history is provided in the response to let you know that the network token provisioning kicked-off with the card network. While the network token is being provisioned by the card network with issuer involved in the token approval process, the payment authorization continues with real card data. The network token will be fetched with the subsequent payment authorization.

"transactions":[
  {
	"reason":"tokenization",
	"transactionId":"<UUID>",
	"clearingInstituteName":"TokenVault",
	"paymentType":"TK",
	"result":{
	  "code":"000.000.000",
	  "description":"Transaction succeeded"
	}
  }
]

Sample request:

CIT payment with network token

A shopper returns on the merchant’s website (card is already tokenized). Network token is provisioned and active for payment. An unscheduled purchase with the saved token is performed. A cardholder initiated (CIT) payment is then authorized with the active network token if the acquirer supports it.

---

How it works

Transactions:

---

1. Send payment initiated by the cardholder

Perform a server-to-server POST request over the stored registration token with all required payment and customer data, including payment type, amount and currency.

A token transaction history is provided in the response to tell you that the network token is attempted to be fetched from the card network. The payment authorization continues with real card data if no network token is yet active for payments.

"transactions":[
  {
	"reason":"tokenization",
	"transactionId":"<UUID>",
	"clearingInstituteName":"TokenVault",
	"paymentType":"TF",
	"result":{
	  "code":"000.000.000",
	  "description":"Transaction succeeded"
	}
  }	
]

The network token BIN (Bank Identification Number) is different than the original PAN (Primary Account Number) BIN. However, the original PAN BIN is provided in the response to help you with a better post-authorization real issuer BIN management.

"card":{
  "bin":"<bin>",
  "last4Digits":"<last4>",
  "holder":"<holder>",
  "expiryMonth":"<month>",
  "expiryYear":"<year>"
}

Sample request:

MIT payment with network token

A merchant initiated (MIT) payment is submitted based on the available card-on-file agreement with the shopper. Card is already tokenized. Network token is provisioned and active for payment. MIT payment is authorized with the network token if the acquirer supports it.

---

How it works

Transactions:

---

1. Send payment initiated by the merchant

Perform a server-to-server POST request over the stored registration token with all required payment and customer data, including payment type, amount and currency.

A token transaction history is provided in the response to tell you that the network token is attempted to be fetched from the card network. The payment authorization continues with real card data if no network token is yet active for payments.

"transactions":[
  {
	"reason":"tokenization",
	"transactionId":"<UUID>",
	"clearingInstituteName":"TokenVault",
	"paymentType":"TF",
	"result":{
	  "code":"000.000.000",
	  "description":"Transaction succeeded"
	}
  }	
]

The network token BIN (Bank Identification Number) is different than the original PAN (Primary Account Number) BIN. However, the original PAN BIN is provided in the response to help you with a better post-authorization real issuer BIN management.

"card":{
  "bin":"<bin>",
  "last4Digits":"<last4>",
  "holder":"<holder>",
  "expiryMonth":"<month>",
  "expiryYear":"<year>"
}

Sample request:

Payment with your network token

The merchant has its own Token Service Provider (TSP) and wants to submit payments with its existing network token authorization data. The merchant provides all the required network token data including dynamic cryptographic data when necessary. The payment is authorized with the network token if the acquirer supports it.

---

How it works

Transactions:

---

1. Send payment using your network token

Perform a server-to-server POST request with your available network token and required payment / customer data, including payment type, amount and currency.

Sample request: