Network Tokenization
What is a network token?
Tokenization is an act of replacing plain PAN with enrcypted / alternative version of the PAN with usage limited to merchant & card holder combination. This translation is managed by card scheme networks, thus this program is referred to as Network Tokenization and replaced PAN is a Network Token.
Network tokenization is applicable to credential-on-file transactions, both consumer initiated (where consumer is in session) and Merchant initiated (recurring & subscription payments). Please refer this article to understand how to save card details for future payments.
| VISA | MasterCard | |
|---|---|---|
| Network tokenization | ✅ | ✅ |
Key terms & definitions
- Token requestor : Business requesting for a token to be issued, generally a merchant.
- Token service provider : Gateway who manages provisioning & processing of the token on behalf of token requestor. Airwallex is a registered token service provider with VISA & MasterCard
- Token user : Initiates payment requests with token, generally the cardholder.
Why should a business use network token?
Network tokenization comes with multiple benefits
Increase your conversion - Network tokens add an additional layer of security to transaction with a cryptogram associated to each transaction (Consumer Initiated Transaction), thereby increasing the probability of approval compared to transactions without Network tokens. Airwallex will also handle life-cycle updates to your consumer cards to keep the credential information latest (to cover for replacements), avoiding declines & manual overhead at merchant side.
No more friction during checkout - Cardholders can pass through checkout process without a need to enter card details & card verification value (CVV2 / CVC2). Merchants can enable one-click checkout to make the checkout process swift.
Reduce your processing costs - Card schemes are implementing measures to increase the processing fee (scheme Fee) for Credential-on-file transactions (Consumer initiated / merchant initiated) which do not have a network tokenized PAN.
Below is a simple illustration of how Network Tokenization in general works along with it's benefits
How to use network tokenization?
Network tokenization feature is enabled for all merchants using Payment Consents with Airwallex, please reach out to customer support or account manager if you would like to opt out of this service. Please note that there is no additional cost associated with this feature.
There are two different models to use this feature
Airwallex is the token service provider - Airwallex will take the responsibility of handling the replacement of PAN with a network token, fetch additional cryptogram during each transaction & receive updates for credential underlying tokens to ensure seamless processing. Merchants integrated to Airwallex can take advantage of this feature without making much changes in their integration. Refer integration section below for more details.
Using external token service provider - Airwallex is capable of accommodating network tokens provisioned by merchant outside Airwallex. It can be merchant acting as a token service provider with integration to schemes directly or an external entity handling it for the merchants. Since a network token is a secure replacement of clear PAN, it can be stored outside Airwallex as well. Refer code sample provided under integration section.
Integration changes
Airwallex supports network tokenization feature via below integration modes:
| Integration Type | Supported |
|---|---|
| Hosted Payment Page | ✅ |
| Embedded Elements | ✅ |
| Drop-in Element | ✅ |
| Native API | ✅ |
As a merchant integrated with Airwallex, you do not need to make any changes in general to support network tokenization feature, it is enough to setup payment consents by following this guide. However, if you would like to take full advantage of one-click checkout then minor changes are required as below.
Airwallex as token service provider : one-click checkout
- Using CVC element - If you are currently using the cvc element in CIT subsequent transactions then you should decide whether to show the cvc element according to the number_type field in the PaymentIntent response. If the number_type field is set to value 'AIRWALLEX_NETWORK_TOKEN', you should not render the cvc element, otherwise you should render it.
The number_type field is part of the Card object. If a payment intent is created with a customer id (referring to saved payment method for future payments) then it will be in the Confirm PaymentIntent API API response. See below sample
- Using native API integration - As a Merchant you can understand whether you can enable one-click checkout (not collecting CVC) during checkout based on the Payment intent response (see above code sample).
External token service provider
As a merchant using external token service provider you should provide details about token & requestor entity so that Airwallex can manage the authorization & clearing steps identifying the transaction as per scheme guidelines. Network token information can be provided in two ways:
- External recurring - As a merchant you are capable of storing the card information on file, provide the recurring data during processing and have PCI attestation of compliance. In such case, you can follow general transaction processing steps with additional data (recurring identifiers & Network token data) input during processing Confirm PaymentIntent API. Please see below code sample:
POST api/v1/pa/payment_intents/{{payment_intent_id}}/confirm
- Internal recurring - As a merchant you are using Airwallex to store all the information related to recurring transactions. Steps are explained to process credential on file transactions with cards. Please find below brief explanation of steps combining it with network tokenization:
- Create payment consent A PaymentConsent should be created first including the information about the Payment Method, optionally you can start with create Payment Method API and then proceed to consent creation referring to payment method id. See how to create a payment consent API with the Airwallex API for an example of consent details. See below code sample:
POST api/v1/pa/payment_consents/create
- Verify payment consent Use this step when verification only is required without charging to the cardholder, charged amount will be reversed. See how to verify a payment consent API with the Airwallex API for an example. See below code sample:
POST api/v1/pa/payment_consents/{{payment_consent_id}}/verify
- Confirm payment intent If you would like to charge cardholder then you should use Confirm PaymentIntent API referring to the payment consent id created in step#1. Please see below code sample:
POST api/v1/pa/payment_intents/{{payment_intent_id}}/confirm
If you are an external token service provider or working with one then you can receive updated credential information from issuing banks via schemes. In this case, you should use Update PaymentConsent API API request to update the credential information stored at Airwallex to process subsequent transactions.
Currently only API integrated clients can function as a external token requestor with Airwallex.
FAQs
Will we receive liability shift with network tokens?
No, Network tokenization alone will not secure merchant with liability shift. Transaction still has to go through 3DS process to receive liability shift advantage.
Are there any charges associated with network tokenization?
No, Airwallex doesn't charge any additional fee for this feature. Card schemes (VISA & MasterCard) also do not have a scheme fee for using this service, which means no additional cost of using Network Tokenization service.
How to enable network tokenization?
Airwallex automatically enrolls clients with active payment consents to use Network Tokenization feature. You can reach out to your account manager or technical support if you would like to opt-out of this service.
What is the difference between Airwallex token & network token?
Airwallex replaces the clear PAN provided by merchants with encrypted gateway token, this token is internal to Airwallex and cannot be understood outside Airwallex. Network token is in EMV format which can be understood by all parties outside Airwallex as well.
How does network tokenization & account updater features work together?
Given a credential-on-file transaction, Airwallex will always try to tokenize the PAN. It may not always be successful since some issuing banks do not support token activation yet. In such cases we will leverage Account updater feature (given the merchant account is enabled with this feature) to keep the credential information up-to-date.