Tokenization

Services with stored cards

To store cards with your customers agreement allows you to offer the following services:

• Easy payment: recurring customers do not have to enter their payment details again
• Recurring payments: a transaction in a series of transactions. The amount of recurring payments is fixed as well as the intervals of the payment. Its based on the customer's consent to allow the merchant to initate one or more future transactions. Example: TV streaming subscription with the same monthly bill.
• Unscheduled Card on File: contrary to recurring payments, the amount and the schedule of the transaction can be flexible. Examples: Automatic top ups of railcards or mobile phone subscriptions, where the bill changes according to amount of minutes used.
• Delayed charge: allows supplemental acccount charge after the initial payment has been processed. Example: A hotel needs to charge minibar expenses on top of the (already paid) original bill.
• No-show: allows a no-show-transaction. Usually used for fees that occur because the customer does not meet the terms of an agreement. Example: Customer has booked a hotel room but does not cancel the booking according to the hotel's cancellation policy.

Definition and use of tokens

After the initial transaction, Netaxept will generate a token referring to the payment details used for this transaction. When performing subsequent transactions, you need to refer to this token with the Reference call's panHash parameter, to allow the card to be captured without sending all the card information again.

Please note: it is your responsibility to store tokens in a secure way and to restrict access to it. This data mustn't be exposed on the frontend.

Tokens can be created during a purchase as well as independently of a purchase. To create a token during a purchase, the regular payment flow for authorising and capture remains the same. Only the recurring payments related parameters have to be added to the calls. LINKS to payment flow

Create a token without a purchase

In order to create a token independently of a purchase, the Register call's updateStoredPaymentInfo parameter must be set to "true". That will change the Netaxept hosted payment window, so that the customer's card details can be entered without a related transaction.

When using updateStoredPaymentInfo="true", the amount is not 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, instead of AUTH, CAPTURE or SALE, the Process(VERIFY) call must be sent.

The token will be sent to you as a response to the Query call for that specific "transaction" (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

To create a token during a regular Easy payment, the Register call's recurringType parameter must be set to "S".

Initial transaction

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.

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

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 Process(AUTH) and Process(ANNUL) instead.

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.

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 Easy 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 Easy 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.