Recurring payments

Note: To be used only for recurring transactions as per PSD2/SCA requirements With this flow, customer saves card details during initial transaction for later subsequent charges by the merchant. Transaction can be account verification (using 2. Register flow) or actual purchase. Due to PSD2/SCA requirements the initial transaction must always be performed with 3D-Secure.

The payment flow for recurring transactions is the same as the 1.2 easy payment flow, only a few parameters change as detailed below. You can refer to the sequence diagram presented in section 1.2 of this documentation.

Initial transaction of recurring payment flow

In the initial transaction of a recurring payment, PiA SDK should be started as with the basic payment flow and include additional parameters related to recurring use,

Important parameters for setting recurring payments:

  • Recurring Type = R
  • Recurring frequency indicates how often the merchant may 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, to allow for the 28 days in February. If more than one payment should be possible daily, a recurring frequency of “0” can be used.
  • Recurring expiry date is the date when the agreement between the merchant and the customer expires. This value must be registered on the format YYYYMMDD
  • updateStoredPaymentInfo = true, use this if the initial transaction is only a card registration
  • force3DS = true: For PSD2/SCA compliance, note that the initial transaction must always require 3D-Secure authentication.

Then if you make the transaction registration according to the above parameters, the SDK will trigger the recurring flow.

After your app gets the successful result from* PiA SDK*, you can start Netaxept call(s) to proceed the transaction and fetch and store the token in your backend which will be utilised for the subsequent recurring transaction.

Subsequent recurring transactions

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

  • panHash = [stored token]
  • recurringType = “R”
  • serviceType = “M”

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.

As per PSD2/SCA guidelines, 3D-Secure will be bypassed on all subsequent recurring transactions.

Netaxept backend integration request body - Registering Recurring Payment

Initial transaction

Test: https://test.epayment.nets.eu Production: https://epayment.nets.eu Path: /netaxept/register.aspx Method: POST

Request body:

{
    "merchantId" : "integer", 
    "token" : "string",
    "language" : "string", 
    "orderNumber" : "string",
    "amount" : "integer",
    "currencyCode" : "string",  
    "redirectUrl" : "string",
    "serviceType" : "M",
    "recurringType" : "R",
    "force3DSecure" : "true",
    "recurringExpiryDate" : "YYYYMMDD", 
    "recurringFrequency" : "integer"
}

If the initial transaction is merely to store card for further payments, add "updateStoredPaymentInfo" : "true" field to the request body.

Subsequent transaction

Subsequent recurring payment requires "recurringUse3DS" : "true" and the "panHash" : "string" additional fields.

{
    "merchantId" : "integer", 
    "token" : "string",
    "language" : "string", 
    "orderNumber" : "string",
    "amount" : "integer",
    "currencyCode" : "string",  
    "redirectUrl" : "string",
    "serviceType" : "M",
    "recurringType" : "R",
    "recurringUse3DS" : "true", 
    "panHash" : "string"
}

Note: Netaxept backend integration tips can be found in 5.4 Backend Tips, Registering Easy Payment section

Deprecated: system authentication is no longer used.