Click here to search the entire website

Before you connect to Tokenisation

What to consider before you add Tokenisation:

Prerequisite:  You're connected to us via a Direct or Hosted integration, and have contacted your Relationship Manager to enable Tokenisation.

Tokenisable payment methods

Cards and wallets

You can tokenise these cards (optionally through the MASTERPASS-SSL wallet):

Cards

AIRPLUS-SSL

DISCOVER-SSL

AMEX-SSL

ECMC-SSL

CARTEBLEUE-SSL

JCB-SSL

CB-SSL

MAESTRO-SSL

DANKORT-SSL

UATP-SSL

DINERS-SSL

VISA-SSL

APMs

APMs

PayPal

SEPA Direct Debit

Choose token format(s)

You can choose from four token formats. Any tokens that you intend to share (across merchant codes) must all use the same format:

  • Alphanumeric token – this token uses an alternating sequence of upper case letters and numbers, and is always 15 digits long. The letters I and O are never used due to their similarity with numbers. Useful if you do not require a numeric token, and prefer the token to be clearly distinguished from card numbers.

  • Wrapped luhn fail token – this token consists of between 16 and 21 digits, and the first two digits are always 99. These tokens will not pass through luhn (modulus 10) checks. Useful if you want to avoid possible issues with regard to PCI DSS compliance checks, because tokens will not be mistaken for a PAN.

  • Wrapped luhn pass token – this token consists of between 16 and 21 digits, and the first two digits are always 99. These tokens will pass through luhn (modulus 10) checks. Useful if you have system validation that requires your token to be similar to a PAN.

  • Format preserving token – this token uses a part of the card number used to create it, and is always 20 digits long. The first two digits are always 99. The next six digits are the first six numbers on the card used. The final four digits are the last four numbers on the card used.

    For example: 99123456xxxxxxxx7890. The digits marked as ‘x’ are randomly generated. The 18 digits which follow the 99 prefix (e.g. 123456xxxxxxxx7890) will fail a luhn check.

    This is useful if you need your token to contain some information about the card associated with it, rather than getting information about the card from the separate obfuscated PAN already provided.

    Warning:  For the highest level of security we recommend using the maximum length of tokens your systems can accommodate (where the format allows variable length), and avoid use of the format preserving option unless you specifically require that functionality.

Shopper or merchant tokens

Best practice:  Which tokens to use:

  • Choose shopper tokens if you only intend to use tokens for your eCommerce channel

  • Choose merchant tokens if you intend to share tokens between your eCommerce and your Point of Sale (POS) channels (using Worldpay Total as your omni-channel solution)

Shopper tokens are created and used as part of a shopper account on a website, typically as part of an eCommerce transaction. Shopper tokens can be used to store a shopper's card details, even when a payment has not been made (such as storing card details for later use). Additionally, they can be used in conjunction with Client Side Encryption.

Merchant tokens can be created and used either through the eCommerce channel or through the POS channel. They can then be shared between these channels, enabling a holistic view of shopper activity (omni-channel). Merchant tokens can be used in conjunction with Client Side Encryption.

Token sharing

Depending on how your business is organised, you can create and use your tokens within a single merchant code, or across multiple merchant codes.

A merchant code is our terminology for a particular merchant account, and you can have one or more of these.

Token expiry

In production, tokens are created with an initial life of 4 years. In Sandbox, tokens are created with an initial life of 7 days.

Changing the token life

During your Tokenisation setup, you can have Worldpay change the default length of the token life by creating a new token group. This cannot be changed once you begin creating tokens. The maximum token life is 4 years (48 months). Speak to your Relationship Manager or Corporate Support Manager for more information.

Configure secure HTTPS URL

In order to receive token details in Order Notifications and Order Inquiry responses, your systems will need a secure HTTPS URL that will be able to interpret and process the information contained within the message. For more information, see the Order notifications section.

Sending batch orders

You can submit batch orders which contain create token requests, use token requests, and all other payment requests, all in the same batch.

Have tokens from a previous provider?

If you have tokens from another provider and want to use them with Worldpay, or you want to create tokens from a list of card details, you're able to do this through Bulk Token Migration. To do this, submit the card details to us in an XML file, and we'll create the tokens. For more information, contact your Relationship Manager.

Compatibility with Account Updater

Tokenisation works with our Account Updater service. To learn more, see Submitting token inquiry requests in the Account Updater guide.

Recurring transaction decline codes

If you use tokenisation for recurring transactions, Visa have 'stop payment' decline codes that aim to reduce cardholder complaints caused by recurring transactions appearing on shopper bank statements after they have cancelled a recurring agreement. These codes are:

  • R1 - Revocation of authorization order

  • R3 - Revocation of all authorization order

Both response codes are used by issuers to decline recurring authorisation requests.

In our authorisation response, we map these VISA codes to these numeric codes:

<ISO8583ReturnCode code="973" description="Revocation of Authorization Order"/>

<ISO8583ReturnCode code="975" description=" Revocation of All Authorizations Order"/>

What should I do if I receive one of these decline codes?

You must ensure that your systems can process these decline codes. This may require you to make changes to your systems.

If you receive a R1 or R3 decline code, you must stop any further authorisation attempts against the card used and notify the cardholder.

For more information about these decline codes, see Useful tables and Test values.

Create Tokens