Checkout SDK
Last updated
Last updated
If you are planning to use the Checkout SDK for your application, it is important to note that you will need to first implement the on your backend server. This is because the Checkout SDK requires a in order to function, and the is obtained through the .
The is responsible for generating a , which is a unique identifier that is used to initiate the Checkout SDK. This is required to be passed to the Checkout SDK in order for it to work properly.
It is important to keep in mind that the Checkout SDK cannot work without a backend implementation, as it relies on the to generate the necessary . Therefore, it is recommended that you first implement the on your backend server before integrating the Checkout SDK into your application.
By following this process, you can ensure that your application is able to properly leverage the features and functionality provided by the Checkout SDK, while also maintaining a secure and reliable payment processing system for your users.
Ottu-checkout is a seamless, confidential and flexible payment checkout. Allows the merchant(s) to proceed the payment either single or bulk payment by a few steps. Ottu-checkout gives the merchant(s) the possibility to utilize many multiple payment gateways, simply generate the payment link and share it by different ways such as Email, WhatsApp, and SMS.
After rendering the page, SDK will be fetched and embed from CDN (content delivery network). Then initiating the checkout SDK, and the SDK will render all the available payment methods.
The customer has the option of choosing from different payment methods.
Card: Customer enters the card details directly.
Saved card: tokenization.
Ottu redirect: Will guide to the required payment gateway page.
Apple Pay: A type of payment service, Apple Pay is only available for iOS devices.
e.g., After selecting the payment method, the response will be proceeded to one of the three below flow. Form error: for example when customer enter invalid card expiry dates, error message will be appeared, then the customer can try again. (this is only for multiple trial payment). Error: The cancel callback will be executed when the payment has an error. e.g., the session has expired. Success.
Depending on the customer's selected payment method, there are different cases after success flow.
1- Redirect: where the payment URL is generated.
2-3DS required: when the customer decides either the tokenization or card payment method. The 3DS page will be displayed > customer fills the required information Then proceed to either success call back or cancel call back.
3-Payment success: Just success call back and then end.
After Passing the 3DS
In the event the due amount is determined, the merchant should be notified to initiate the payment transaction. The merchant server calls the , then it goes to process the response. The API needs to be updated each time the amount changes. In case there is a validation error while updating the API, the current session will be ended and a new payment transaction should be created once again.
If the returns success, it will render the page after providing the .
If the returns error, the admin should be notified, then redirect to an error page and end the session.
