Hyvä Checkout Integration Development
Integration development is about building a reusable module for Hyvä Checkout: a payment method, a shipping method, an address finder, or any other extension that many stores install. This chapter covers the integration APIs of Hyvä Checkout and how to build an integration that runs on both release lines.
Building the checkout of one specific store instead? Head to Checkout Development, starting with custom checkouts and steps and form customization.
Check the existing integrations first
Many payment providers, shipping carriers and address finders already support Hyvä Checkout. See Available Payment Methods, Available Shipping Methods and Available Address Finders before you build your own.
Supporting Hyvä Checkout 1.x and 3.x in One Integration
Stores run both Hyvä Checkout release lines: Checkout 3.x on Magewire 3, and Checkout 1.x on Magewire 1. Write the integration for Magewire 1 to support both with one codebase: it runs on Checkout 1.x, and on Checkout 3.x through the v1bc module, which Checkout 3.x installs. In these docs, follow the "Checkout 1.x (Magewire 1)" tabs. The v1bc module is supported for the whole Checkout 3.x release line, so Magewire 1 code stays a safe base for an integration.
Many integrations need no change to run on Checkout 3.x, but payment methods often need one, e.g. for a status or wait page of their own, or for a script that a re-render adds once the method is selected. Here's where to find the cases:
- Supporting Checkout 1.x and Checkout 3.x With v1bc - the short list of what an integration does and doesn't need to change
- Maintaining an Extension for Checkout 1.x and 3.x - which version tabs to follow in these docs, and how to test
Test the integration on both release lines: on Checkout 1.x, and on Checkout 3.x with the v1bc module enabled.
What Is in This Chapter
Payments
- Payment Integrations Introduction - offline payment methods, gateways and Payment Service Providers (PSPs)
- Payments in Hyvä Checkout - how a Hyvä Checkout payment integration and the Magento payment method share the work
- Payment Integration API - registering a payment method template, its icon and subtitle, and gating Place Order with the Evaluation API
- Dynamically Determining Available Payment Methods - filtering the payment methods by a PSP response
Place Order Service API
- Place Order Service API - how Hyvä Checkout places orders, and when a payment method needs its own Place Order Service
- Place Order Service Abstraction Layer - the base class to extend for a custom Place Order Service
- Place Order Service Processor - how order placement, redirects and exceptions are handled
Shipping
- Shipping Integration API - registering a shipping method template for pickup points, delivery slots and other customer input
Abstraction Layers
- Abstraction Layers - ready-made UX integrations that a third-party module plugs an adapter into
- Autocomplete Abstraction Layer - address autocomplete with providers such as PostcodeNL or Google Places
- Guest to Customer Abstraction Layer - turning guest checkouts into customer accounts
Examples
- JS-driven Payment Method - a payment method built on the frontend Payment API, from a minimal registration to validation and redirects
- Example PSP Integration: Iframe Payment Form - a Magewire payment method that loads a PSP SDK into an iframe
Related Topics
- Evaluation API - tell the frontend what to do next from PHP, used by payment and Place Order Service integrations
- Frontend API - the
hyvaCheckoutJavaScript namespace, including the Payment API - Form Modification Hooks - change the address and guest details forms from an integration, e.g. for an address finder
- Content Security Policy - Hyvä Checkout runs under a strict CSP, so an integration's scripts must be CSP compatible