CreditKit Pro with HPOS and the Cart and Checkout Blocks
CreditKit Pro declares compatibility with High-Performance Order Storage and with the Cart and Checkout Blocks. Both declarations are made on every page load, before WooCommerce initialises, so a store owner has nothing to switch on and no compatibility setting to find. Turning HPOS on, or moving to the block-based checkout, needs no change inside CreditKit Pro.
Does CreditKit Pro work with HPOS?
Yes. CreditKit Pro calls FeaturesUtil::declare_compatibility( 'custom_order_tables', … ) on before_woocommerce_init, which is what WooCommerce reads for the compatibility report on the Plugins screen. The plugin behaves the same whether HPOS is authoritative, the legacy posts tables are authoritative, or compatibility-mode synchronisation is running.
Every order read and write goes through the WooCommerce CRUD layer, using wc_get_order(), $order->get_meta() and $order->save(), so WooCommerce decides which table the data lands in. The credit meta box, the order-list columns and the goodwill store-credit panel register against both the legacy shop_order screen and the HPOS woocommerce_page_wc-orders screen.
Does CreditKit Pro work with the Cart and Checkout Blocks?
Yes. CreditKit Pro declares cart_checkout_blocks alongside the HPOS flag and registers Pay with Credits as a Blocks payment method through AbstractPaymentMethodType. The classic checkout is served by the same gateway on the woocommerce_payment_gateways filter, so a store mid-migration gets the same payment method on both checkouts. The Blocks integration passes four values to the checkout script beyond the gateway title and description.
| Value | What it carries |
|---|---|
user_credits | The signed-in customer’s current credit balance |
required_credits | The credits the current cart will cost |
credit_breakdown | The per-line credit cost of each cart item |
available_for_cart | Whether the cart contains items that can be paid in credits |
Pay with Credits disappears from the Blocks checkout when an admin disables the gateway in WooCommerce → Settings → Payments. On a fresh install where the gateway settings have never been saved, the method is treated as enabled.
Cart figures reach the block tree through the Store API. CreditKit Pro extends the cart and cart-item schemas under the pcs_credits namespace with fields such as credit_price and credits_to_receive. The block creditsystem/credit-receive-row mounts itself without a merchant editing a template, and pcs/credit-balance and pcs/pdp-credit-card sit in the inserter.
How order data is stored
The balance sits in wp_pcs_user_credits and every movement is a row in wp_pcs_credit_transactions, so order storage never holds a balance. CreditKit Pro writes a small set of meta keys to an order recording what that order did with credits.
| Order meta key | Written when |
|---|---|
_pcs_credits_spent | An order is settled through Pay with Credits |
_pcs_user_balance_before, _pcs_user_balance_after | The same credit checkout, for the order-screen audit trail |
_pcs_transaction_ids | The ledger rows the credit checkout created |
_pcs_credits_granted | A money-paid order grants bundle credits |
_pcs_credits_refunded | Credits are returned on a refund |
_pcs_credits_clawed_back_total | Bundle credits are clawed back across partial refunds |
Those keys are read back with $order->get_meta(), so switching HPOS on after months of trading keeps the credit history working. Product-level data such as the credit price on a variation stays in post meta, because WooCommerce products still live in wp_posts under HPOS.
Verifying on your site
- Open Plugins → Installed Plugins. WooCommerce warns on the row of any plugin without an HPOS declaration, and the CreditKit Pro row carries no warning.
- Open WooCommerce → Settings → Advanced → Features and read the High-performance order storage section, which lists plugins by compatibility state.
- Place a test order through Pay with Credits, then confirm the order screen shows the credits spent and the before and after balance.
- Repeat that order on a page built with the Checkout block, where Pay with Credits appears with the customer’s balance below it.
What this doesn’t do
Splitting one order between credits and a card is not supported on either checkout. The Blocks integration reports partial_payment_enabled as false on both its normal and its fallback code path, so Pay with Credits settles the whole order. A customer whose balance is short sees the shortfall and pays by another method.
The order-summary row showing an order’s credit cost was removed from the block checkout in 2.2.0, leaving that figure to the Pay with Credits panel. The “credits you will receive” row still renders in both checkouts.