PSP Tokenization

Overview

PSP Tokenization is Netaxept's proprietary tokenization method. When a customer chooses to save their card details for future purchases, the sensitive Primary Account Number (PAN) and expiry date are securely transmitted and stored within the PCI DSS Level 1 compliant Nets Card Vault.

In return, Netaxept issues a unique PSP token to the merchant. The merchant stores this token and uses it to initiate subsequent transactions without handling or storing raw cardholder data.

Definition and use of tokens

We refer to saved payment details as tokens and storing a customer's payment details as tokenization.

After the initial transaction, Netaxept generates a token that represents the payment details used for the transaction. When performing subsequent transactions, refer to this token using the Register call panHash parameter to process payments without resubmitting the card information.

PSP Token lifecycle

PSP tokens stored in Netaxept's database become inaccessible in the following cases:

• The underlying card linked to the PSP token has expired.
• The PSP token is more than 1,100 days old and has been used at least once during the preceding 720-day period.
• The PSP token has not been used for 720 consecutive days.

Create a token without a purchase

You can create a token without charging the customer. This may be required, for example, if the customer does not make a payment during the card registration phase or when the card expiry date changes and you need to update stored card details. For this, pass updateStoredPaymentInfo=true parameter in the Register call. That will change the Netaxept hosted payment window, so that the customer card details can be entered without a related payment.

When using updateStoredPaymentInfo="true", the amount is no longer a mandatory parameter in the Register call. If an amount is sent with the Register call it will be ignored.

After the Terminal call, send Process(VERIFY) call. Verify makes a zero-amount authorization request to the card to verify a customer's account status.

After a successful process call, run the Query call on that specific transaction to retrieve the token from the panHash parameter of the Query call response.

You must store this token as part of your stored customer profile for later transactions.

In addition to that, we recommend you store the card issuer's name and the last 4 digits of the card number to give the customer an indication of the card you have stored. We also recommend to save the expiration date of the card and to make sure the card get's updated (or replaced) before that.

Easy payment

Saving customer payment information and allowing them to make future transactions with fewer clicks.

Initial transaction

Start the payment process by running the Register call, as with a regular transaction, and include the following parameters in the Register call.

• recurringType="S"
• updateStoredPaymentInfo="true" - use this if the initial transaction is only a card registration without a payment

After the successful Register call, perform the Terminal call to send the customer to the payment window.

Netaxept generates a token for the transaction, after the customer has successfully passed the Terminal phase.

After the Terminal call response, you send the Process call (AUTH, CAPTURE or SALE) as usually.

If it is a card registration with updateStoredPaymentInfo="true" specified in the Register call, perform process call VERIFY (or AUTH and ANNUL) instead.

Only after that has been accomplished, you can collect the token from the response to the Query call on this transaction.

Subsequent transactions

Now that you have the token, you can allow your customers to pay without entering their payment details again.

For this, the following parameters must be added to the Register call:

• panHash=[stored token]
• recurringType="S"
• recurringUse3DS="true", redirects the customer to 3D Secure authentication

as well as:

• serviceType="B" gets 3D Secure authentication triggered and the customer redirected to the terminal to enter their CVV/CVC OR
• serviceType="M", gets 3D Secure authentication triggered and both, terminal and CVV/CVC entry bypassed

After the successful Register call, perform the Terminal call to redirect the customer to 3D Secure or equivalent authentication. After the customer has successfully passed the Terminal phase, continue with the Process call and choose either operation AUTH and CAPTURE or SALE as with a regular transaction.

Recurring payments

The Recurring payments give you the ability to setup recurring charges on a periodical basis, such as monthly or weekly. The amount in recurring payments is fixed as well as the interval of the payment. It is based on the customer consent to allow you to initiate one or more future transactions.

Initial transaction

Start the payment process by running the Register call, as with a regular transaction, and include the following parameters in the Register call.

recurringType="R" recurringFrequency="X" recurringExpiryDate="YYYYMMDD" updateStoredPaymentInfo="true" - use this if the initial transaction is only a card registration

The recurringFrequency indicates how often you want to make subsequent payments on the card registered.: A frequency of "1" will indicate that one payment is allowed each day, while "28" would be the recommended value for monthly subscriptions (so that February with 28 days is included).

If more than one daily payment should be possible daily, a recurring frequency of "0" can be used.

recurringExpiryDate is the date when the agreement between the merchant and the customer expires. This value must be registered on the format YYYYMMDD.

After the successful Register call, perform the Terminal call to send the customer to the payment window. During this phase, the customer is also redirected to 3D Secure or equivalent authentication.

After the customer has successfully passed the Terminal phase, Netaxept generates a token for the transaction. However, do not fetch the token until you have received the successful response for the Process call.

After the successful Terminal phase, run the chosen Process call(s). The operation varies whether this is an actual payment or only a card registration.

If it is an actual payment, perform the operations AUTH and CAPTURE or SALE as with a regular transaction.

If it is a card registration with updateStoredPaymentInfo="true" specified in the Register call, perform the operation VERIFY (or AUTH & ANNUL only for cards that do not support VERIFY).

When this stage is done, run the Query call on the transaction, to find the token, as described above.

Subsequent transactions

When performing the subsequent transaction, send the following parameters to Netaxept with the Register call.

panHash=[stored token] recurringType="R" serviceType="C"

After the successful Register call, skip the Terminal phase and continue directly with the Process call choosing either operation AUTH and CAPTURE or SALE as with a regular transaction.

Merchant initiated transactions

A Merchant Initiated Transaction (MIT) refers to a card payment started by a merchant without the customer being actively involved, as part of an agreement made during an initial Customer-initiated Transaction (CIT). Payments done with changing amount and/or frequency, for example, Unscheduled Card on File (UCOF), delayed charge and no-show transactions.

Initial transaction

Consumer saves card details for later charges initiated by merchant. The first transaction can be either a card registration only (account verification with zero-value) or the actual purchase.

SCA is required for initial transaction. Netaxept redirects the customers automatically to SCA after you have performed the Terminal call. To make sure the issuer doesn't apply exemption and thus leave your initial transaction without SCA, send force3DSecure="true" in the Register call.

1. Register call:

force3DSecure="true" - SCA required to complete transaction

updateStoredPaymentInfo="true" - to just register the card (if omitted, the actual purchase is made).

recurringType=S - card details get saved for MIT transactions OR

recurringType=R - use this only if you have an existing recurring solution and you are in a process of changing it to PSD2 compliant.

2. Terminal call:

To redirect customer to terminal and get SCA triggered.

3. Process call:

operation="VERIFY" for account verification OR

operation="AUTH" with Process(CAPTURE) (or Process(SALE)) to follow.

4. Query call:

To fetch panHash=[token]

Subsequent transaction

You charge a payment using saved card details with the changing amount and/or time frequency according to agreement made with the consumer.

MITs are out of scope of the PSD2 SCA requirements and therefore SCA will be bypassed.

1. Register call:

recurringType=M - indicates MIT transaction

recurringTransactionType= 1 - UCOF OR 2 - Delayed charge OR 3 - No-show

panHash=[stored token]

serviceType="C" - terminal is bypassed OR

serviceType="A" - terminal bypassed, required for app payments, but recommended to be used also for other non-callcenter payments

2. Process call:

operation="AUTH" with Process(CAPTURE) (or Process(SALE)) to follow.

Best practices

• Remember to URL-encode all API parameters sent to Netaxept.
• You must always obtain the customer's permission to register their card and charge the card for later purchases. For example, you can require the customer to check a box stating similar to: "I approve that my card is stored and charged for later purchases. The card number is stored securely with our payment provider Nets and we will never have access to the actual card number".
• You should state clearly how the recurring agreement can be cancelled.
• It is recommended to send either a pre-notification email some days before the charge is done or an electronic receipt immediately when the charge is approved. This is to avoid unnecessary chargeback claims.
• The token is a valuable asset and must always be stored in a secure way. The merchant undertakes not to store tokens on a frontend system exposed to the internet or directly on mobile devices.
• Password requirements for customer profiles on applications in use must always use highest complexity requirements (including numbers, alphanumerics, special characters and upper/lower case). Do not store passwords in clear text on your application.
• Use logging of IP address and where applicable IMEI for mobile devices for purchases.
• Use transaction filter offered by Netaxept to limit the number of transactions per day and card.
• Be aware that transactions running on Checkout Payment and Recurring Payments mode without 3D Secure are not covered by the acquirers settlement guarantee so it is in your interest to build a secure solution.
• If you have a large amount of small transactions (like download of digital content), the acquirer might accept that you aggregate transactions to one single charge as long as they are not over 25 USD in total, and not collected over a period of more than 7 days.
• For Recurring Payments, you need to sign a separate agreement with your chosen acquirer.
• For Checkout Payment, you need a regular Internet agreement with your chosen acquirer. Make sure to agree with the acquirer whether the solution should run with or without entering CVV/CVC security code for each transaction.
• Merchants should manage authorization reattempts based on the response codes. Ensure that any automated authorization reattempt processing excludes response codes described here.