Before you can begin testing network token provisioning and transactions, you will need to have been issued Token Requestor IDs by the card networks.
Once your TRIDs are available (one or all), Spreedly support can assist you in enabling network tokens for your production environment. The TRIDs will be used when making requests to provision network tokens and for transactions with network tokens; these requests will involve communication with the networks and issuing banks.
Provisioning a Network Token for a single payment method
Please refer to the Provisioning Network Tokens section of our guides for detailed code examples.
Once your product environment has been enabled for network tokens, you’re ready to start requesting network tokens. Network token provisioning can be completed on a per payment method basis. As such, you’re able to test provisioning network tokens with individual payment methods and single API calls.
Please note that the networks do not supply test cards.
Since this is the case, we recommend you test provisioning on a handful of trusted payment methods, be them personal cards or QA cards you use for testing transactions.
Once you’ve identified the cards you’d like to test, you can provision a network token by setting the "provision_network_token": true in your API requests. For testing we recommend this in two ways:
- For an existing payment method, you can include the "provision_network_token": true in an authorization call to the Spreedly test gateway. This requests an actual token, while replying with a mock authorization
- For a new payment method, you can include "provision_network_token": true while retaining the payment method
Once you’ve submitted your API request, please note network_tokenization element of the response body. A successful tokenization will include ”provisioned": true.
We recommend trying this process multiple times as not all issuing banks will provide tokens. This should result in several tokens issued and also the display error messages as well when tokens cannot be issued.
Testing transactions with a single network token.
Please refer to the Transacting with Network Token section of our guides for detailed code examples.
Much like provisioning a network token, transactions with network tokens can also be made on a per-transaction basis. This will allow you to make single API requests using network tokens without needing to change your existing flows.
Once you’ve issued a network token for a payment method, you can now use that payment method to complete a transaction on a gateway that supports network tokens.
We recommend making several low dollar amount transactions such as authorize, purchase, and verify transactions with your gateway of choice to test these transactions. Setting the element "attempt_network_token": true in the requests will pass the network token to the gateway.
Should the network token not be used for the transaction, our response will return "attempted": false in the network token section of the response and an error code provided to explain why NT was not used. In this event, the transaction will have used the PAN to attempt to complete the transaction.
For those curious to test this functionality, we recommend routing the transaction to a gateway that does not support NT transactions, while also leaving the element "attempt_network_token": true in the request. Since the gateway does not support NT, the transaction will always fall back to the PAN.
A/B Testing with Network Tokens
Since transactions with network tokens can be enabled or disabled per transaction, this allows your engineering team to A/B test network tokens vs PAN transactions.
As an example, if I want to test network token transactions with 10% of my transactions, then I can have my application set element "attempt_network_token": true for every 10th transaction.
The analysis of the success of NT over PAN can be conducted by reviewing the responses.
Transactions that request NT be attempted will contain the element
"network_tokenization": {
"attempted": true/false,
...
}
For any transaction with "attempted":true, Spreedly sent the network token to the payment gateway for processing. It’s the success or failure of these transactions that show the impact of network tokens on success rates.
Alternatively, if "attempted":false is in the response, then Spreedly completed the transaction with PAN instead and will have supplied a reason why NT could not be used.
The method above can be used for your own data analytics. However, we recommend partnering with your Spreedly customer account manager to let them know of any testing you plan. Our product team can run aggregated reports for your transactions that can assist in analyzing the success of network tokens. (Note that these reports are planned to be added to your Spreedly dashboard in the future)