Design a WooCommerce payment method as one server-side payment process with two appropriate presentation layers for Classic Checkout and Checkout Blocks. Do not duplicate business logic across two frontends. Both versions must use the same availability, validation, order status and error handling.
WooCommerce stores often mix older shortcodes, new blocks and customised checkout templates. A method registered only in the admin screen does not automatically appear correctly in every checkout. Explicitly test which integration layer the active store uses and what changes during a theme or WooCommerce update.
Separate payment rules from checkout presentation
The server decides whether the method is available, validates input and starts payment. Classic Checkout renders fields and messages through PHP hooks; Blocks uses a registered frontend component and WooCommerce Store API data. Both ultimately lead to the same controlled server process.
Do not put essential location, amount or permission checks solely in JavaScript. A hidden button can still be invoked manually, and cached frontend code may be outdated. JavaScript improves the experience; the server enforces the rule.
Keep data contracts small and explicit. The frontend may need a title, description, availability reason and a few safe configuration values, not the entire provider object. Version changes that alter the data structure. This prevents Classic and Blocks from accidentally interpreting the same setting differently.
| Component | Shared core | Presentation difference |
|---|---|---|
| Availability | Server rule for order context | Classic hook or Blocks store data |
| Title and explanation | Administrator settings | Markup appropriate to the component |
| Start payment | Same service and checks | Different frontend call |
| Error status | Standardised error code | Notice or block message |
| Transition to paid | One idempotent server route | Only the status display differs |
Prevent silent degradation
If the Blocks integration is missing, the payment method may disappear completely without a visible administrator error. Add a compatibility check in administration and a release check opening the active cart and checkout pages. Conversely, incomplete frontend registration may show a title without correct processing.
Keep JavaScript and PHP versions together. A new server response with old frontend code can block payment inexplicably. Use file versions to refresh caches and test after deployment in a fresh browser session. For custom software that evolves with a changing platform, a maintenance agreement matters at least as much as the initial build. Read more in custom software for business processes.
Also check the editor experience. An administrator publishing a new Checkout Block page must be able to see before launch that the method is supported. Give a focused warning in plugin management if required blocks or dependencies are missing. Do not show it as a general banner on every admin page; place it where someone can resolve it.
Fictional example: phased migration to Blocks
Specialist store Atelier has used Classic Checkout for years. The team builds a terminal method for showroom orders and wants to move to Blocks later. Instead of creating a second plugin, it keeps the payment service separate from checkout markup. The Blocks component reads the same title, description and availability result.
Testing reveals that Classic receives the location choice as a form value, while Blocks updates it through checkout state. Both routes normalise this context on the server. If the location is invalid, they return the same error code but each shows an appropriate message. Order status and provider verification remain identical.
Atelier also builds a temporary parallel test route. A copy of checkout is visible only to employees, allowing real combinations of coupons, shipping and customer roles to be tested. Blocks replaces the old page only after the matrix passes. The old presentation is then removed so two checkouts do not remain unnoticed.
Compatibility matrix for acceptance
- Test Classic Cart with Classic Checkout.
- Test Cart Block with Checkout Block.
- Test a mixed migration setup the store actually uses.
- Check guest, logged-in customer and authorised employee.
- Change shipping method and location during checkout.
- Test success, rejection, timeout and reloading.
- Check keyboard use, error focus and screen reader announcements.
- Repeat after WooCommerce, theme and checkout plugin updates.
Include only combinations you actually support. A long list of theoretical compatibility without end-to-end testing creates false certainty. Record the active checkout in administration and make a missing integration apparent before customers discover it. For order data subsequently sent to other systems, Yindle Connect can organise transfer and exceptions.
Define regression tests around the business outcome, not just visible buttons. Both checkouts must create one correct order with the same payment metadata and recovery options. Presentation can then change later without silently changing payment rules.
Do not confuse “payment processed” with “order fulfilled”. WooCommerce can set a paid order to “Processing” when delivery is still to come and “Completed” when no further fulfilment is needed. Classic and Blocks must use the same server logic for this distinction too.
Discuss with Yindle a payment method that keeps working in your WooCommerce checkout.
When the payment method belongs to a physical Mollie terminal flow, see Yindle Terminal Payments. For the final classic order steps, Yindle Checkout remains a separate presentation layer.