• France
status page
Demo shops
assistance
FAQContact support
Search
Categories
Tags
docs.
France
Spain
Europe (English)
India
Homepage
Use cases
Create a payment
Create an installment payment
Create a multi-card (split) payment
Create a payment by Alias (Token)
Create a payment link
Create a recurring payment
Manage subscriptions
Manage your transactions (refund, cancel...)
Analyze your reports
API docs
Embedded Form
REST API
Hosted payment
Mobile payment
File exchange
SDD mandates by REST API
Snippets
Payment methods
Plugins
Marketplace
Guides
Merchant Back Office
Back Office Expert
Functional guides

Creating a token during a recurring payment

In addition to the information used in the case of Creating a token without making a payment, this use case must also include information related to the recurring payment, such as:

  • the initial amount of the recurring payment (amount used for the first installment/s) if it is different (optional),
  • the amount of the recurring payment (amount of installments or the amount used for the following installments when the first one is different).
 

No payments will be made during the subscription. Only an information request will be made in order to validate the payment method details.

The first payment will be made once the due date is reached, between 12 a.m. and 5 a.m.

Simplified diagram

On the day of the order:

  1. The merchant site submits a request to create an alias and subscribe to a recurring payment.
     

    Note for stores with the "Currency Conversion" option:

    The currency is mandatory when creating an alias.

    Only contracts that support the currency passed in parameter will be selected. Currency conversion is therefore not taken into account.

    E.g.: For an alias creation request in USD currency, on a shop associated with an AMEX contract and a CB contract:

    if the AMEX contract only supports USD and the CB contract only supports EUR, then only AMEX cards will be accepted for the alias creation.

    The buyer selects the payment method that they would like to register, enters their payment method details and confirms the entry.

  2. The payment gateway initiates the cardholder’s authentication process with the issuer.
     
    • Regulations require strong authentication for this use case.
    • Authentication is performed for the amount of the first installment.
  3. Once the authentication is completed, the gateway proceeds with the registration request by providing the cardholder’s authentication details.
  4. The issuer generates a unique transaction identifier and transmits it in the response to the registration request.
  5. The payment gateway notifies the merchant website about the result.
    The response contains:
    • the unique transaction identifier generated by the issuer, for information purposes,
    • the newly created token,
    • the recurring payment details.
     This operation results in the creation of a VERIFICATION type transaction, visible in the Expert Back Office and possessing the following characteristics:
    • its amount is 1.00 EUR or 0 EUR if supported by the acquirer,
    • its status is either "Accepted" or "Refused",
    • it is never captured and remains in the "Transactions is progress" tab.
     The token will not be created if the authorization or information request is rejected.

    The gateway displays the receipt to the buyer. It contains:
    • the newly created token,
    • the amounts of the recurring payment.
    If you have configured the corresponding notification rules, the buyer will receive an e-mail with:
    • the banking details registration confirmation on the payment gateway of the shop,
    • the confirmation of the recurring payment registration.
 The issuer transaction identifier is stored by the payment gateway at the level of the alias.

Depending on how you use the alias (1-click payment, 0-click payment, recurring payment, etc.) the gateway will use the issuer transaction ID as the default chaining reference if necessary.

Upon each installment:

  1. The payment gateway performs an authorization request for the installment amount, providing the initial transaction identifier (ITC) as a chaining reference.
  2. The issuer recognizes the transaction as a MIT that is part of a series of payments for which the cardholder has previously authenticated themselves and proceeds with the authorization request.

    The transaction will not be rejected for lack of authentication (soft decline).

  3. If the merchant has enabled the notification rule Instant Payment Notification URL when creating recurring payments, the payment gateway notifies the merchant site of the payment result.

 In this use case, the way the chaining reference is handled is transparent to the merchant.

Jobs
Legal
GDPR
25.18-1.11