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 Name | API Endpoint | Explanation |
---|---|---|
checkouts:create-intent | POST {{url}}/checkouts/intent | Is required to create the intent_id required to render the Checkout widget. |
checkouts:search | GET {{url}}/checkouts | Is required if the user wants to search all checkout sessions + hides/displays the checkout ‘history’ UI tab. |
checkouts:get | GET {{url}}/v1/checkouts/:id | Is 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-versions | GET {{url}}/v1/checkouts/versions | Is 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:get | GET {{url}}/checkouts/templates/:id | Is 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:search | GET {{url}}/checkouts/templates | Is required to view templates. If disabled, the list of created templates will be hidden from the UI. |
checkouts-templates:create | POST {{url}}/checkouts/templates | Is required to create new templates. If disabled, the ‘create new’ template button will be hidden from the UI. |
checkouts-templates:update | PUT {{url}}/checkouts/template/:id | Is 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-schemas | GET {{url}}/v1/checkouts/templates/schemas/:type/:version | Is 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:
Create Configuration and Customisation Templates. These templates define the behaviour and appearance of the merchant's checkout process.
- Create a Configuration template
- Create a Customisation template (optional)
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.Initialize the Checkout widget with the Payment Intent
- Use the following code:
var widget = new cba.Checkout("#widget", "{{intent_token}}");
- Replacing {{intent_token}} with the intent token created in the previous step;
- Insert the code with the intent token value into the website's code to render the Checkout widget.
- Use the following code:
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).