No results

OneClick payments

The integration of this solution allows the end customer to save their card data, and use them later to make purchases faster.

OneClick payments are also identified with the term "CIT" (Customer Initiated Transaction).

The management of this solution is divided into 2 phases:

  • First payment
  • Subsequent payments

Both phases are subject to 3D Secure authentication.

Below, it will be explained how to perform first tokenization payments and subsequent payments in the integration modes:

  • Hosted Payment Page
  • Pay-by-Link

First payment

A first transaction must be generated, assigning a unique contract for each customer, an identifier that allows XPay to save the combination between the customer and the payment card used.

Hosted Payment Page

The payment flow remains the same as the Hosted Payment Page solution, as it is necessary to call the same API:

Valuing the "recurrence" object with the parameters:

action CONTRACT_CREATION
contractId Unique string
contractType CIT

Pay-by-Link

The payment flow remains the same as the Pay-by-Link solution, as it is necessary to call the same API::

Valuing the "recurrence" object with the parameters:

action CONTRACT_CREATION
contractId Unique string
contractType CIT

XPay Build

The payment flow remains the same as the XPay Build solution, as it is necessary to call the same API::

Valuing the "recurrence" object with the parameters:

action CONTRACT_CREATION
contractId Unique string
contractType CIT

Management of subsequent payments

In the next payment it is necessary to send a call to XPay with the contract registered in the first payment phase. This will allow the customer not to have to enter the card data on the checkout page, but to proceed with the 3D Secure authentication.

Hosted Payment Page

To proceed with the next payment, call the API:

Valuing the "recurrence" object with the parameters:

action SUBSEQUENT_PAYMENT
contractId Unique string used in the first payment phase
contractType CIT

Pay-by-Link

To proceed with the next payment, call the API:

Valuing the "recurrence" object with the parameters:

action SUBSEQUENT_PAYMENT
contractId Unique string used in the first payment phase
contractType CIT

XPay Build

To proceed with the next payment, call the API:

Valuing the "recurrence" object with the parameters:

action SUBSEQUENT_PAYMENT
contractId Unique string used in the first payment phase
contractType CIT

In response to the API call described above, the following object is returned with the "state" field set to "GDI_VERIFICATION":

You must create a new HTML page layout containing a single iframe to allow the 3D Secure server to collect the sensitive browser data needed to assess the transaction risk. The content of the iframe must be the URL specified in the "src" parameter:

At the end of the GDI phase, one of the following two scenarios may occur:

  • 3D Secure Authentication: the payment requires strong customer authentication (SCA - Strong Customer Authentication) by the cardholder. The onBuildFlowStateChange event containing the 3D Secure authentication address will be returned. The customer must be redirected to this address:
    • evtData.data.state: populated with "REDIRECTED_TO_EXTERNAL_DOMAIN".
    • evtData.data.url: 3D Secure authentication URL, to which the customer must be redirected.

    Redirecting to the external page will allow the customer to complete any authentication required by the bank and, at the same time, enable the XPay gateway to finalize the payment.

    To handle the outcome, the URLs configured in the parameters sent during the initial POST /orders/build API call will be used:

    • resultUrl
    • notificationUrl
    • cancelUrl
  • Payment result: the transaction does not require 3D Secure authentication by the cardholder, the payment is then completed. Parameters are returned:
    • "operation": object containing the detail of the operation. For details on the object's content, please refer to the response schema of the GET /operations/{operationId} API.
    • "state": set with "PAYMENT_COMPLETE". Please note: this status only indicates that the payment process has ended, not that the transaction was successful. To determine the actual outcome of the payment, check the "operationResult" parameter within the "operation" object mentioned above.

NOTES:

  • The following APIs are made available to be able to intervene on existing contracts:

  • The gateway does not allow payment execution when the “actionType” parameter is set to “PAY” and the amount is zero. To perform a card verification with a zero amount (“amount”: “0”) and simultaneous tokenization, the “actionType” parameter must be set to “VERIFY”.
  • Within the "recurrence" object, the value "action": "CARD_SUBSTITUTION" allows replacing the card associated with an existing contract (contractId). The payment flow for card substitution is identical to the initial tokenization flow.
    Important Note: this feature is available exclusively for payment cards. For alternative payment methods (APMs), substitution is not supported; therefore, it will be necessary to proceed with a new tokenization by generating a different contractId.