Inventory checkout extensions before you change them
Before you change checkout, list each extension that touches the cart, checkout, payment, tax, shipping, or order, with its version and the vendor's compatibility statement for that version. WooCommerce's system status report shows the WooCommerce version, the WordPress version, and the active plugins. WooCommerce's developer documentation says extensions declare whether they work with Cart and Checkout blocks so merchants can see a conflict. One vendor page can say a named extension is not compatible with those blocks. That sentence does not decide the same question for every other extension, and it does not tell you to turn off fraud or payment controls. Confirm any checkout installation or update responsibilities in the engagement scope. Describe the work you need. Prism will confirm scope, responsibilities, fees, and terms before work begins.
For: An owner or developer of a research-use-only peptide store who needs to know which extensions a checkout change depends on.
Updated 2026-09-21
Write down the stack that is installed now
A checkout change fails or succeeds with the plugins that are actually active, not with a generic WooCommerce store. WooCommerce's system status report, opened from WooCommerce, then Status, includes the WooCommerce version and the WordPress version in the WordPress environment, and an Active Plugins section that lists the plugins installed and active, with their versions and whether updates are available. Inactive plugins are listed separately. Copy that list before you update anything.
Mark the plugins that can change the cart, the checkout form, payment, tax, shipping rates, or the order that is created. A plugin that only changes a catalog page may still matter if the vendor says it declares checkout compatibility. A plugin with no vendor statement is an unknown, not a compatible plugin.
Read the vendor's statement for that version
WooCommerce's developer documentation says declaring Cart and Checkout block compatibility helps merchants understand whether an extension supports those blocks when a conflict arises. An extension can declare that it is compatible, declare that it is incompatible, or have no effect on checkout and therefore no need to declare anything. WooCommerce says it only checks block compatibility for extensions that declare the WC tested up to header. A declaration is the extension author's statement. The absence of a declaration does not prove the extension works.
The Checkout Add-ons documentation, checked on 2026-09-21, says that as of WooCommerce 8.3 the Cart and Checkout blocks are the default experience, and that Checkout Add-ons has not yet been updated to be compatible with those blocks. It recommends shortcodes for that plugin. That is one extension's documentation. It is not a reason to switch every store, and the choice between blocks and classic checkout is a separate decision. For every other extension, open that extension's current page and match it to the version in your system status report.
Decide the recovery before you release the change
WooCommerce's self-service guide says to make a full backup of the site, data, and files before the update steps it describes. Record who will make the change, which other plugin or theme must be released with it, and how you would return to the backed-up version. A change with no recovery note is not ready.
The same guide describes a conflict test that temporarily deactivates plugins. Do not use that test on the live checkout as a casual step, and do not disable fraud controls, required customer notices, or the payment method in order to make a new feature appear. WooCommerce's Health Check document says troubleshooting mode can test a theme and plugins without changing what visitors see, and it also says troubleshooting mode does not put a payment gateway into a sandbox. An order placed in that session can take a live payment. If you test, use a method that cannot capture a customer payment, or accept that a real order is a real payment.
The self-service guide also says WooCommerce cannot support a third-party plugin conflict and that you contact that plugin's developer. Compatibility you have not read on the vendor's page stays unknown.
Who can decide that the change is safe
You can decide whether the inventory is complete and whether each vendor statement matches the installed version. The person who maintains the site can decide whether to release the change. The extension vendor decides what its documentation says. None of those decisions is a promise that checkout will keep working after a later update.
Prism's public pages describe a consultation about the website and processing questions. Confirm the installed versions and requested work before deciding the implementation scope. An inquiry alone does not authorize a change. There is no published response time. Whether a payment provider will accept the checkout after the change is the provider's decision, not a result of the inventory.
Checkout dependency inventory
One row is one installed extension or theme that can affect checkout. Copy versions from the system status report. Leave the vendor statement blank until you have opened it. Worksheet entries are not submitted by this worksheet or saved by this site. Use only non-sensitive summaries; do not enter credentials, government identifiers, card or bank-account numbers, private receipt links, or customer details.
Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.
Checkout dependency inventory. The last column is for temporary notes.
Checkout dependency
What to record before the change
What not to assume
Your note
WooCommerce and WordPress versions
What to record before the changeCopy both from the system status report before any update.
What not to assumeA newer version on a different site is not the version you are changing.
Each active checkout, payment, tax, or shipping plugin
What to record before the changeRecord the name, version, and whether the report says an update is available.
What not to assumeAn inactive plugin is not the same row. The report lists it separately.
The checkout function it performs
What to record before the changeSay whether it changes the cart, the checkout fields, payment, tax, shipping, or the created order.
What not to assumeA plugin with no checkout role does not need a checkout declaration, which is not proof about a plugin that has one.
The vendor compatibility statement
What to record before the changeOpen the vendor's page for the installed version and note whether it mentions Cart and Checkout blocks.
What not to assumeCheckout Add-ons' incompatibility sentence applies to Checkout Add-ons. It does not decide another plugin.
What else must change with it
What to record before the changeName the theme, WooCommerce version, or second plugin the vendor says is required.
What not to assumeUpdating one plugin while leaving a required companion behind is not the vendor's stated setup.
Who owns the release and the recovery
What to record before the changeName the person who can publish the change and where the full backup is.
What not to assumeA backup you have not made is not a recovery path. WooCommerce's guide says to make one before its update steps.
What the test is allowed to touch
What to record before the changeState that fraud controls, required notices, and the live payment method stay on.
What not to assumeHealth Check troubleshooting mode can still take a live payment. Do not treat it as a sandbox.
These are temporary notes. Leaving or reloading this page may clear them. The consultation form does not include these entries.
Limits
A Prism consultation can help you organize the facts and discuss the website or processing question. The payment provider decides eligibility, pricing, reserves, and whether an account is opened or closed.
Do not disable fraud controls, required notices, or payment protections to force a checkout change.
This page does not choose between Cart and Checkout blocks and classic checkout.
Confirm implementation, update, or hosting responsibilities separately; verify the actual extensions and versions involved.
WooCommerce system status report — checked 2026-09-21. The report shows the WooCommerce version, the WordPress version, and active plugins with their versions and available updates. Inactive plugins are listed separately.
WooCommerce Cart and Checkout blocks extensibility — checked 2026-09-21. Extensions declare compatibility or incompatibility with Cart and Checkout blocks so merchants can understand conflicts. WooCommerce only checks that declaration for extensions with the WC tested up to header. An extension that does not affect checkout need not declare compatibility.
WooCommerce Checkout Add-ons — checked 2026-09-21. That extension's documentation says it has not yet been updated for the Cart and Checkout blocks that became the default in WooCommerce 8.3, and it points that plugin back to shortcodes.
WooCommerce self-service guide — checked 2026-09-21. The update steps begin with a full backup. The guide also describes a plugin-deactivation conflict test and says third-party conflicts go to that plugin's developer.
WooCommerce Health Check troubleshooting — checked 2026-09-21. Troubleshooting mode can test plugins without changing the site visitors see, and it does not put a payment gateway into sandbox mode. An order in that session can take a live payment.
Prism features — checked 2026-09-21. Published support is a storefront review and help preparing for a processing review. Specific requested work is confirmed through the inquiry.
Request a consultation
Describe the business and this specific question. Prism follows up by email to discuss fit and scope. An inquiry is not a processing application or an approval.