HPOS and Checkout Blocks: what payment plugin compatibility really means

Two compatibility axes, not one switch

A payment method can look correct on a checkout page and still mishandle a later order update. It can also store orders correctly while never appearing in a block-based checkout. Those are different failure modes. Treating them as one generic “WooCommerce compatible” label makes it harder for a merchant to judge the risk of a change.

WooCommerce describes HPOS as an order-storage architecture with dedicated order tables. Checkout Blocks have their own payment-method integration points. The practical conclusion is that a storage declaration cannot prove a working checkout experience, and a working button cannot prove correct order persistence.

When assessing an extension, start with two separate questions: which order-storage configurations were tested, and which checkout experiences were tested? Keep the answers visible in the release notes and support information. A merchant should not need to discover an unsupported combination during a real customer payment.

Order storage is a contract with the platform

The engineering goal is to let WooCommerce remain responsible for its order model. A gateway should use the supported order APIs for the operations it performs, rather than assume that a particular database table will always represent an order in every configuration. Otherwise, a checkout may appear to succeed while a refund or a background update reads a different view of the order.

Our review approach follows an order through its whole lifecycle. We look at creation, payment confirmation, notes, status changes, refunds and reconciliation. For every step we ask where the order is read and written, and whether that path is consistent with the supported platform model.

Compatibility declarations are useful communication, but they are declarations. The evidence comes from testing the relevant storage modes and checking the resulting records. If a release claims support for a configuration, its acceptance plan should include that configuration explicitly. An unchecked flag does not turn an assumption into evidence.

A checkout integration is more than rendering a logo

The checkout has to communicate availability, collect the required inputs, submit a coherent request and explain what happens next. A payment option that appears on screen but cannot complete the full interaction is not a complete integration. The same applies when error messages leave the customer uncertain about whether to try again.

Test the classic checkout and the block-based checkout separately when both are claimed. Look at a successful purchase, validation errors, a payment rejection, an abandoned provider page and the customer returning after an interrupted connection. Inspect how the cart, order and payment reference relate after each attempt.

Express options and wallets add further conditions. Their visibility can depend on the selected provider, account, device, browser and merchant configuration. A checkout integration should distinguish a method that is unavailable in the current context from a method that is misconfigured. Do not promise that every customer will see every payment option on every device.

Write a compatibility matrix people can use

A small matrix is more useful than a long unsupported promise. Record the plugin release, WordPress and WooCommerce versions, PHP version, checkout type, storage mode, theme and relevant extensions. Keep the provider environment and payment method alongside the scenario so another person can reproduce it.

For each supported combination, name the flows that were exercised. “Loaded the checkout” is different from “completed a challenged card payment, received provider confirmation and processed a refund”. A result should say what was tested and what remained outside the test, rather than compress everything into a green cell.

Not every possible combination can be checked. Choose a documented support range and prioritize combinations that real customers use. A newly released theme or extension should not be silently added to the support promise because it happens to share a platform name. Extend the matrix when you have evidence.

Store conditions expose the hidden assumptions

A clean development store is useful, but it does not reproduce every live store. Taxes, shipping, discounts, currency precision, caching, security tools and order-management extensions can change the conditions around a payment. Testing should focus on the combinations the product actually intends to support.

Use a staging store that represents the intended setup, with sanitized test data and the provider’s test environment. Check the order amount and currency shown to the customer against the server’s request. Exercise guest and logged-in purchases where supported, and inspect what happens when checkout details change before submission.

Caching deserves particular attention. A cart, customer session or payment response should not be treated like a public marketing page. Similarly, a security rule that works for browser visits can interfere with a server-to-server callback. Diagnose the exact path and response rather than disabling protections across an entire site.

Keep release evidence attached to the version

A useful release record includes the checked package, its integrity information, the declared requirements and a readable changelog. The support matrix should describe that exact package. Rebuilding something different after a successful test can make the earlier evidence less useful.

Updates need their own acceptance scenario. Begin with a supported older version, preserve its settings and test the path to the candidate version. Inspect the result before using the new release in a live store. A successful clean installation does not prove that an existing shop will migrate correctly.

A rollout plan should also explain how an operator can stop distributing a problematic package and investigate existing installations. Recovery depends on the particular change: a database migration cannot always be reversed by replacing plugin files. Make the limits clear before treating rollback as a universal safety net.

What this means for VivaGo today

VivaGo is our payment plugin in development for WooCommerce. We are publishing these criteria to explain how we think about compatibility, not to announce a completed support matrix. Supported releases, checkout types, provider methods and configuration limits will accompany the checked product release.

For a store owner, the practical question before launch is specific: “Has this exact product version been tested with my checkout and order-storage setup, and what happened when payment confirmation was delayed?” That is a better basis for a decision than an unqualified claim that a plugin works with every WooCommerce store.

If you are evaluating the upcoming product, tell us the versions and extensions that matter to your store. That helps make a compatibility discussion concrete. It does not replace testing or reserve a feature promise; it gives development and support a reproducible configuration to assess.

Sources and further reading

• WooCommerce: compatibility and interoperability for extensions
• WooCommerce: HPOS extension recipe book
• WooCommerce: Checkout block payment method integration