Introduction

In the fast-paced realm of online payments, the key to success lies in adaptability and innovation. At Celeris, we pride ourselves on keeping abreast of industry changes and are thrilled to announce a significant update to our tokenisation payment process. This enhancement introduces new parameters, injecting greater flexibility and control into subsequent transactions.

Understanding the Update:

The crux of this update centres around the incorporation of additional parameters in the tokenisation payment flow. You can find more detailed information in our documentation.

We’ve introduced a new object named “recurring,” featuring the following key attributes:

• Recurring Type:
• Specifies the type of recurring payment.
• Possible values: UNSCHEDULED (default) / RECURRING
• Reason:
• Describes the reason for subsequent transactions.
• Possible values: REAUTHORIZATION, RESUBMISSION, INSTALLMENT, DELAYED_CHARGES, NOT_SHOW
• Source:
• Distinguishes between Cardholder-Initiated Transactions (CIT) and Merchant-Initiated Transactions (MIT).
• Possible values: CIT / MIT

Use Cases and Scenarios:

Merchant-Initiated Transactions (MIT):

• Specify MIT as the source for scenarios where the merchant initiates subsequent tokenisation payments.
• Choose the recurring type to identify whether subsequent transactions are periodic (RECURRING) or un-periodic with different amounts (UNSCHEDULED).

Cardholder-Initiated Transactions (CIT):

• When initiating a series of subsequent recurring payments for a card-not-present CIT, populate the recurring type indicator along with the type, a requirement from most Acquirers.
• Choose the recurring type (RECURRING) for periodic and (UNSCHEDULED) for un-periodic rebillings with different amounts.

Implementation Steps/Process:

Dynamic Subsequent Fields Setup and Acquirer Support:

• Connect with us to verify whether the connected Acquirer supports these features.
• Our integration team will ensure that this feature is enabled for your accounts.

Update your API Calls:

• Ensure your tokenisation payment API incorporates the new “recurring” object.
• Populate values for source, recurring type, and reason based on your transaction scenario. If additional development isn’t feasible on your end, we’ll configure the required setup from our side.

Validation and Testing:

• Thoroughly validate API calls against updated specifications.
• Verify changes in the staging environment before implementing them in the production environment.

Support

Stay ahead in the realm of online payments with our enhanced tokenisation process. For a detailed implementation guide and personalised assistance, reach out to our support team.