Adding a Payment Gateway to the WooCommerce Checkout Block

The WooCommerce Checkout Block is not a restyled version of the classic checkout. It is a different implementation with a different extension model, and payment gateways written for the old one do not automatically work in it. Plenty still do not. If you moved to block checkout and your payment method vanished, this is why.

Two checkouts, two integration models

The classic checkout is a PHP-rendered form. A gateway hooks into WooCommerce actions, echoes its fields into the page, and processes on submit. The Checkout Block is a React application. Payment methods have to register themselves through the blocks registry in JavaScript and render as components, and the server-side processing contract is separate from the classic one.

Which means a gateway has to implement both to work everywhere. Supporting one is roughly half the work, so partial support is common.

What a gateway must do for block checkout

• Register a payment method type with the blocks registry, including its label, an edit-mode preview for the block editor, and a canMakePayment check.
• Render its fields as a component rather than echoing markup, which for a card gateway means mounting the processor iframe inside a React tree and tearing it down properly on unmount.
• Take part in the block's validation lifecycle so WooCommerce validation and stock checks still run before the card is charged.
• Return data through the blocks payment result contract instead of relying on classic redirect responses.
• Handle the express payment area separately if it offers wallet buttons, because that is a distinct registration.

The iframe-inside-React part is where integrations get subtly wrong. The frame gets mounted twice, or never torn down when the customer switches payment method, and you end up with a form that works on first render and breaks on the second.

Symptoms of a classic-only gateway

1. The payment method does not appear at all in block checkout, though it works in classic.
2. It appears, but the card fields stay blank or never load.
3. It works until the customer switches payment method and back, then breaks.
4. Place Order submits and nothing happens, with a console error about a missing payment method registration.
5. It works on the front end but shows an error placeholder in the block editor.

How to verify support properly

Do not trust a compatibility badge. Test it:

1. Create a page with the Checkout Block and set it as your checkout page.
2. Check the gateway appears in the block editor preview without an error.
3. On the front end, switch between payment methods several times and confirm the card fields still render.
4. Submit with a deliberately invalid billing field and confirm validation fires before any charge.
5. Complete a sandbox order and confirm it reaches a paid status via webhook.
6. Then do the whole sequence again on classic checkout, because you may need to switch back.

HPOS is the other half of the same question

High-Performance Order Storage moves orders out of the posts tables into dedicated ones. A gateway that writes order meta with post-meta functions instead of the WooCommerce CRUD API will look fine and then lose data once HPOS is on. Anything you evaluate for block checkout should be HPOS compatible too. The two together are the marker of an integration somebody still maintains.

The Whop gateway supports classic checkout, the Checkout Block and HPOS, with the same embedded card form and the same verified webhook confirmation across all of them. The embedded behaviour is in WooCommerce checkout without redirecting, and the confirmation path in double-confirm webhooks.

If you are stuck mid-migration

Stay on classic checkout while you verify each plugin on staging, then switch. Whatever you do, do not migrate your checkout and your payment gateway in the same change. If something breaks you will have no idea which one did it.