Checkout SDK
Build a custom Checkout experience but let Corefy handle the processing complexity.
What is Checkout SDK?
The Checkout SDK is a client-side library that simplifies payment integration for Merchants who want to build and maintain their own Checkout interface.
Instead of implementing payment orchestration, 3D Secure authentication, redirects, retries, cascading, and payment status polling manually, Merchants can use the SDK to submit a payment and receive ready-to-display payment states.
The SDK provides a consistent interface for handling the payment flow while Corefy remains responsible for the underlying payment-processing logic.
How it works?
The SDK replaces a sequence of separate payment-processing steps with a single submit() operation.
A typical payment flow consists of the following steps:
- The Merchant creates a Payment Request on the backend.
- The Merchant initialises Checkout SDK with the required payment identifiers.
- The Customer enters their payment details.
- The Merchant calls
submit(). - The SDK executes the required payment actions, such as 3D Secure authentication, Provider redirects, or status polling.
- The SDK provides the Merchant with the current payment state.
- The Merchant updates the Checkout UI based on that state.
- The Merchant receives the final payment result and handles the corresponding Customer experience.
The SDK can also restore a payment flow using the Payment Request ID, including after a page reload or a return from a 3D Secure or Provider redirect.
Checkout SDK VS Merchant input
Checkout SDK side
Checkout SDK is responsible for executing the payment flow and managing the actions required to reach a final payment state.
Depending on the payment response, the SDK can:
- Collect and tokenise payment details through a payment method addon.
- Submit the payment for processing.
- Execute 3D Secure authentication.
- Handle Provider redirects.
- Poll the payment status when required.
- Recover the payment flow after returning from a redirect.
- Handle payment cascading.
- Manage retry timing and retry-related states.
- Track pending and moderation states.
- Provide a payment result.
Merchant side
The Merchant remains responsible for the Checkout interface and the customer-facing experience.
The Merchant should:
- Create the Payment Request on the backend.
- Initialise the SDK with the required configuration and payment identifiers.
- Render the Payment method interface.
- Collect any additional information required by Checkout.
- Display the state provided by the SDK.
- Show appropriate messages, loaders, countdowns, or action buttons.
- Reinitialise the SDK on the return page when required.
- Verify the final payment result on the server before fulfilling an order.
Checkout SDK VS Hosted Payment Fields
Checkout SDK manages the complete payment flow through a single submit() operation. It executes the required payment actions, handles payment state transitions, and provides ready-to-display statuses, allowing Merchants to focus on the Checkout UI rather than implementing payment-processing logic themselves.
Hosted Payment Fields is a payment data collection and tokenisation solution. It allows Merchants to securely collect card details through Hosted Fields, but the Merchant must implement the rest of the payment flow, including payment processing, 3D Secure authentication, redirects, retries, cascading, and status polling.
What’s changing for Merchants?
| Aspect | Host-to-Host (H2H) integration |
Checkout SDK |
| 3D Secure knowledge | The Merchant must understand and implement the required 3D Secure flow and rules. | No in-depth knowledge is required. The SDK handles 3D Secure and related payment actions. |
| Payment flow | The Merchant builds and manages the payment flow independently. | The SDK manages the payment flow, including redirects, retries, and cascading. |
| Polling, timeouts, and retry attempts | The Merchant must implement polling, timeouts, and retry logic. | These processes are handled automatically by the SDK using server-defined parameters. |
| Return after 3D Secure | The Merchant must handle the return and resume the payment flow. | The Merchant only needs to call init() on the return page. No additional implementation is required. |
| Custom UI | Custom UI is supported but requires significant development effort and payment-processing logic. | Custom UI is fully supported. The Merchant controls the interface, while the SDK manages the payment logic. |
| Steps on the Merchant backend |
|
|
| PCI DSS | Required | Non-required |
Updated about 19 hours ago

