Checkout Implementation

The Checkout (No-code Widget) feature streamlines the merchant’s checkout process by providing a simple, flexible and easily configurable checkout solution for merchants.

User and Access Token Permissions

The permissios required to use the Checkout feature are as follows:

Permission NameAPI EndpointExplanation
checkouts:create-intentPOST {{url}}/checkouts/intentIs required to create the intent_id required to render the Checkout widget.
checkouts:searchGET {{url}}/checkoutsIs required if the user wants to search all checkout sessions + hides/displays the checkout ‘history’ UI tab.
checkouts:getGET {{url}}/v1/checkouts/:idIs required to get further details about a specific intent_id + hides/displays the ‘actions’ drop down from the ‘history’ tab. This is used to get more detailed information for an intent_id.
checkouts:get-versionsGET {{url}}/v1/checkouts/versionsIs required to get the versions associated with the templates. If disabled, the feature will be available in a read-only context on the UI.
checkouts-templates:getGET {{url}}/checkouts/templates/:idIs required to get specific details about a template. If disabled, the ‘get actions’ dropdown next to each template in the ‘templates’ screen will be hidden, meaning existing templates cannot be updated.
checkouts-templates:searchGET {{url}}/checkouts/templatesIs required to view templates. If disabled, the list of created templates will be hidden from the UI.
checkouts-templates:createPOST {{url}}/checkouts/templatesIs required to create new templates. If disabled, the ‘create new’ template button will be hidden from the UI.
checkouts-templates:updatePUT {{url}}/checkouts/template/:idIs required to update an existing template. If disabled, the ‘get actions’ dropdown next to each template in the ‘templates’ screen will be hidden, meaning existing templates cannot be updated.
checkouts-templates:get-schemasGET {{url}}/v1/checkouts/templates/schemas/:type/:versionIs required to get the checkout template(s) schema by type and version. If disabled, the feature will be available in a read-only context on the UI.

Intent API

The intent call is made to the endpoint POST /v1/checkouts/intent

Each intent_token is active for a total of 15 minutes. The expectation is that from the point the intent_token is generated, the user must complete their payment within 15 minutes.

Intent API schema and validation

As there are various payment gateway types that are able to be surfaced within the Checkout widget, this means there are also different field validations applied per-gateway (as each PSP has different data they require in order to process a payment).

Note: If a merchant is attempting to render a set of payment gateway methods in the Checkout widget but does not provide the relevant fields in the intent request in order to meet minimum validation across all payment methods attempting to be rendered, an API validation error will be returned in response to the intent request.

Render the Checkout widget

Rendering the Checkout widget in the web application involves a series of straightforward steps:

  1. Create Configuration and Customisation Templates. These templates define the behaviour and appearance of the merchant's checkout process.

    1. Create a Configuration template
    2. Create a Customisation template (optional)
  2. Generate Intent Using the /intent API Endpoint. The Intent encapsulates the payment context for the transaction. To generate an intent token, an API request must be performed to the /checkouts/intent endpoint.

  3. Initialize the Checkout widget with the Payment Intent

    1. Use the following code: var widget = new cba.Checkout("#widget", "{{intent_token}}");
    2. Replacing {{intent_token}} with the intent token created in the previous step;
    3. Insert the code with the intent token value into the website's code to render the Checkout widget.

Note: If a merchant is adding any coupon codes or performing any actions that will change the total amount at checkout, the merchant must regenerate the /intent call and subsequently reinitialize the Checkout widget.

Example HTML Code

Please consult Paydock for the recommended SDK version, as it may vary depending on the timing of your integration with the feature.

Checkout widget events

The Master Widget in the checkout flow triggers specific events to inform merchants about the status of a customer’s checkout session. These events are essential to managing the cardholder experience, catering for the possible outcomes of checkout session such as: successful payment, payment failure/error or expired session.

onPaymentSuccessful

  • Description: This event is triggered when a payment is completed successfully. It allows the merchant to execute specific actions, such as updating the order status, notifying the customer of the successful transaction, and/or redirecting the customer to a confirmation page.

  • When it is triggered: This event occurs immediately after the payment gateway confirms that the payment has been processed successfully.

  • Event payload: intent_id: The unique identifier of the payment intent. charge_id: The unique identifier of the charge that was created as a result of the payment workflow.

onPaymentError

  • Description: This event is triggered when a payment fails. Merchants can use this event to handle payment errors, such as displaying error messages to customers or logging the error details.

  • When it is triggered: This event is fired when the payment gateway reports a failure during the payment process or any unexpected error scenarios during the Checkout session.

  • Event payload: intent_id: The unique identifier of the payment intent. charge_id: The unique identifier of the charge that was created as a result of the payment workflow (if it was created before the error).

onPaymentExpired

  • Description: This event is triggered when a payment workflow session expires. This typically happens if the customer takes too long to complete the payment (e.g after 15 minutes of inactivity).

  • When it is Triggered: The event is triggered when the session timeout is reached, and the payment is no longer valid.

  • Event Payload: intent_id: The unique identifier of the payment intent. charge_id: The unique identifier of the charge that was created as a result of the payment workflow (if created before the session expiration).