Testing Token Transactions

You can obtain tokens in two ways. The first method is explicit registration using the registerTokenRequest transaction. The second method is implicit registration, which is achieved by submitting the card or account information (for Direct Debits) in a normal payment transaction. This section provides test data sets using both methods for both credit card and Direct Debit tokenization.

Perform this test only if you plan to use the Vault feature.

The test data does not include values for all elements. You should use appropriate values for all elements as required to create a properly structured cnpAPI request.

To test explicit Token Registration transactions:

  1. Verify that your cnpAPI template is coded correctly for this transaction type (refer to Register Token Transactions.)

  2. To test credit card tokenization, submit registerTokenRequest transactions using the data for Order IDs 50 through 52 from Table 2-7.

  3. If you use Direct Debit transactions and have elected to tokenize Direct Debit account numbers, submit registerTokenRequest transactions using the data for Order Ids 53 and 54 from Table 2-7; otherwise, skip those two tests.

  4. Verify that your registerTokenResponse values match those shown in the Key Response Elements section of Table 2-7. The complete token values are not defined in the table, because the system generates the tokens dynamically.

  5. After completing this test, proceed to the next set of tests for implicit tokenization.

TABLE 2-7 Register Token Test Data

orderId

Supplied Data Elements

Key Response Elements

 

Element

Value

Element

Value

50

 

 

 

 

<accountNumber>

 

 

 

 

4457119922390123

 

 

 

 

<cnpToken>

<bin>

<type>

<response>

<message>

xxxxxxxxxxxx0123

445711

VI

801

Account number was successfully registered.

51

 

 

<accountNumber>

 

 

4457119999999999

 

 

<cnpToken>

<response>

<message>

none returned

820

Credit card number was invalid

52

 

 

 

 

<accountNumber>

 

 

 

 

4457119922390123

 

 

 

 

<cnpToken>

<bin>

<type>

<response>

<message>

xxxxxxxxxxxx0123

445711

VI

802

Account number was previously registered

53

 

 

 

 

<accNum>

<routingNum>

 

 

 

1099999998

011100012

 

 

 

<cnpToken>

<type>

<eCheckAccountSuffix>

<response>

<message>

xxxxxxxxxx

EC

998

801

Account number was successfully registered

54

 

<accNum>

<routingNum>

1022222102

1145_7895

<response>

<message>

900

Invalid bank routing number

To test the submission of card data in an tokenized environment using Authorization transactions, as well as the submission of tokens in transactions, do the following:

  1. Verify that your cnpAPI template is coded correctly for this transaction type (refer to Authorization Transactions.)

  2. Submit three authorization transactions using the Supplied Data Elements from Order Ids 55 through 57 from Table 2-8.

  3. Verify that your authorizationResponse values match those shown in the Key Response Elements section of Table 2-8 for Order Ids 55 through 57.

  4. To verify that your cnpAPI template is coded correctly for the submission of tokens in authorization transactions, submit authorization transactions using the Supplied Data Elements from Order Ids 58 through 60 from Table 2-8.

To test the submission of Direct Debit data in an tokenized environment, as well as the submission of tokens in Direct Debit transactions, do the following:

  1. Verify that your cnpAPI template is coded correctly for these transaction types as applicable (see eCheck Sale Transactions and eCheck Credit Transactions).

  2. Submit the four transactions, Order Ids 61 through 64, using the Supplied Data Elements from Table 2-8.

  3. Verify that your response values match those shown in the Key Response Elements section of Table 2-8 for Order IDs 61 through 64.

TABLE 2-8 Implicit Registration Test Data

orderId

Supplied Data Elements

Key Response Elements

 

Element

Value

Element

Value

55

 

 

 

 

 

 

 

 

<amount>

<type>

<number>

<expDate>

<cardValidationNum>

 

 

 

 

15000

MC

5435101234510196

1150

987

 

 

 

 

<response>

<message>

<cnpToken>

<tokenResponseCode>

<tokenMessage>

 

 

<type>

<bin>

000

Approved

xxxxxxxxxxxx0196

801

Account number was

successfully

registered

MC

543510

56

 

 

 

 

<amount>

<type>

<number>

<expDate>

<cardValidationNum>

15000

MC

5435109999999999

1150

987

<<response>

<message>

 

 

 

301

Invalid Account Number

 

 

 

57

 

 

 

 

 

 

<amount>

<type>

<number>

<expDate>

<cardValidationNum>

 

 

15000

MC

5435101234510196

1150

987

 

 

<response>

<message>

<cnpToken>

<tokenResponseCode>

<tokenMessage>

<type>

<bin>

 

000

Approved

xxxxxxxxxxxx0196

802

Account number was previously registered

MC

543510

58

 

 

 

 

 

 

<amount>

<cnpToken>

<expDate>

<cardValidationNum>

 

 

 

15000

xxxxxxxxxxxx0196

1150

987

Note: Use the token returned in Order ID 57.

 

 

<response>

<message>

 

 

 

 

 

000

Approved

 

 

 

 

 

59

 

 

<amount>

<cnpToken>

<expDate>

15000

1111000100092332

1150

<response>

<message>

 

822

Token was not found

 

60

 

 

<amount>

<cnpToken>

<expDate>

15000

1112000100000085

1150

<response>

<message>

 

822

Token was not found

 

61

 

 

 

 

eCheck Sale:

<accType>

<accNum>

<routingNum>

 

 

Checking

1099999003

011100012

 

<cnpToken>

<tokenResponseCode>

<tokenMessage>

<type>

<eCheckAccountSuffix>

 

xxxxxxxxxxxxxxxxx

801

Account number was successfully registered

EC

003

62

 

 

 

 

eCheck Sale:

<accType>

<accNum>

<routingNum>

 

 

 

Checking

1099999999

011100012

 

 

<cnpToken>

<tokenResponseCode>

<tokenMessage>

<type>

<eCheckAccountSuffix>

 

xxxxxxxxxxxxxxxxx

801

Account number was successfully registered

EC

999

63

 

 

 

 

eCheck Credit:

<accType>

<accNum>

<routingNum>

 

 

Checking

1099999999

011100012

 

<cnpToken>

<tokenResponseCode>

<tokenMessage>

<type>

<eCheckAccountSuffix>

 

xxxxxxxxxxxxxxxxx

801

Account number was successfully registered

EC

999

64

 

 

 

 

 

 

 

 

 

 

 

 

eCheck Sale:

<accType>

<accNum>

<routingNum>

 

 

 

 

 

 

 

 

 

 

Corporate

6099999993

211370545

 

 

 

 

 

 

 

 

 

 

<originalTokenInfo>

<accType>

<cnpToken>

<routingNum>

<newTokenInfo>

<accType>

<cnpToken>

<routingNum>

<tokenResponseCode>

<tokenMessage>

 

<type>

<eCheckAccountSuffix>

(parent element)

Checking

11190000001003001

211370545

(parent element)

Checking

11190000001154101

211370545

801

Account number was successfully registered

EC

993

Order ID 64 returns accountUpdater information. This test allows you to test responses you might receive when a NOC exists against the Direct Debit account, but you submit the old account information. In this case, the system provides the old token information, but issues a new token based upon the new account information and provides it as well.