Last updated: 2026-07-22
Direct answer
To show payment details in the WooCommerce Orders list, add one read-only column that uses the WC_Order already bound to the current row. Free can display the saved payment-method title. A narrowly scoped Pro add-on can place the saved transaction ID inside a closed disclosure. Neither path should contact the payment gateway, change an order, or present a local identifier as proof of settlement.
Payment Details for WooCommerce Orders follows that boundary. Free shows the saved payment-method title in classic and HPOS Orders lists. Pro can reveal the saved transaction ID in a native keyboard-operable control. The planned Pro offer is $39 per year for one site after a 14-day no-card trial; checkout remains a separate release step.
Choose the smallest suitable approach
| Approach | What it changes | Main tradeoff |
|---|---|---|
| Focused read-only column | Shows local saved payment information | Does not verify gateway settlement or add finance workflows |
| Custom PHP snippet | Adds code you maintain | HPOS hooks, row binding, escaping, permissions, and rollback become your responsibility |
| Gateway or order-management suite | Adds status, filters, exports, or actions | Broader credentials, liability, configuration, and support surface |
The problem appears in real support threads
A merchant reported that a payment-method column stopped working after switching to HPOS and was told the replacement fell outside WooCommerce core support.
Another merchant expecting many orders asked to see payment method, phone, and transaction ID on the Orders page instead of opening each order, then disabled HPOS to keep a legacy workaround working.
A separate operator reported that shipping and payment columns disappeared after a WooCommerce update and asked how to support both storage modes.
These reports establish a repeated administrative problem. They do not prove broad demand, paid conversion, or StoreFixKit sales.
Separate local order data from gateway truth
WooCommerce can save a payment-method title and a transaction ID on an order. Those values are useful for recognition and lookup, but they are not a live gateway response.
A safe display column must not infer that:
- the payment settled;
- funds were captured;
- a refund completed;
- a dispute is closed;
- a payout reached the merchant; or
- the saved ID is current in every external system.
The gateway dashboard or its documented API remains authoritative for gateway state. A list-column plugin should not capture, retry, refund, void, reconcile, or repair a payment.
Why HPOS-aware row binding matters
WooCommerce's High-Performance Order Storage documentation explains that extensions must be compatible with the newer order-storage system. A legacy posts-table snippet can disappear after HPOS is enabled or rely on the wrong row context.
The narrow implementation should:
- register native classic and HPOS order-column hooks;
- use only the current row's
WC_Order; - verify the legacy row ID before reading;
- require WooCommerce order-view capability;
- escape and bound both displayed values; and
- return no added output when the row or value is uncertain.
It should issue no gateway request and no extra order query.
Install and use it safely
- Confirm WooCommerce 8.9 or newer is active.
- Install and activate Free 0.1.13.
- Open WooCommerce > Orders.
- Enable Payment details under Screen Options if the column is hidden.
- Compare one test row with the payment-method title saved on that order.
- Confirm Free does not show a transaction ID.
- Deactivate Free and confirm the added column disappears.
Free has no settings page and does not contact the gateway.
What Free and Pro display
Free shows only the escaped payment-method title saved on the current order.
Licensed Pro may add the saved transaction ID inside a native <details> element. The element starts closed and can be opened from a keyboard. An empty, malformed, or over-limit ID is omitted while the Free payment title remains.
Pro does not copy data to an external service, query a gateway, or create sorting, filtering, export, refund, capture, retry, or reconciliation controls. If Pro or licensing is unavailable, the complete Free payment-method column remains local and active.
Know the support boundary
The supported surfaces are WooCommerce's native classic and HPOS Orders lists. This release does not change:
- gateway dashboards or APIs;
- payment, refund, dispute, or payout state;
- WooCommerce Analytics or reports;
- frontend account or checkout pages;
- REST responses, feeds, emails, or exports; or
- third-party order tables that do not run the native hooks.
The column helps identify an order's locally saved payment information. It is not a payment operations or accounting product.
Troubleshoot by symptom
| Symptom | Check first | Safe expected result |
|---|---|---|
| Column is missing | WooCommerce version, role, and Screen Options | Unsupported or unauthorized screens stay unchanged |
| Payment title is blank | Whether that order saved a title | Missing or unsafe values stay blank |
| Transaction ID is absent | Whether Pro is active and the order has a saved ID | No gateway request is made to fill it |
| Gateway status differs | Which system is authoritative for the question | Use the gateway dashboard for live state |
| Old snippet broke after HPOS | Whether it used legacy post-list hooks only | Use an HPOS-aware implementation instead of disabling HPOS |
Roll back without touching payments
- Deactivate Pro and reload the Orders list.
- Confirm the Free payment-method title remains and the transaction disclosure is gone.
- Deactivate Free.
- Confirm the Payment details column disappears.
- Open the test order and confirm its payment method, transaction ID, and status are unchanged.
- Install a previous deterministic ZIP only for a version rollback.
Normal uninstall preserves Pro license/update state for accidental recovery. Defining STOREFIXKIT_DELETE_DATA as true before deleting Pro removes only this product's three owned Pro options. Free stores no settings, and neither package deletes orders, payments, transaction IDs, customers, or gateway data.
Privacy, security, and resource boundary
- Only users with WooCommerce order-view capability see the column.
- Values are escaped, bounded, and tied to the current order row.
- Free makes no remote request.
- The Orders screen makes no StoreFixKit request and no gateway request.
- Only an explicit, authorized Pro license action sends the license key, site URL, and product key to StoreFixKit.
- No order, customer, phone, item, payment-method, transaction, gateway, or payload data is sent.
- There is no telemetry, custom table, cron, queue, JavaScript, stylesheet, order query, or payment/order write.
Support material should state only whether a transaction ID exists and replace payment titles with neutral examples. Do not send a full transaction ID, gateway payload, payment credential, customer record, order export, password, API key, or complete license key.
Market evidence boundary
The July 21, 2026 evidence capture found an exact free Payment Method Order Column listing at 10 reported active installs. It also found a 10-install broader bundle and a broad admin-column plugin at 100,000 installs. Broad installed stock is not narrow-feature demand or sales.
The same capture found OrderFusion: Filters and Columns Manager offering a Payment Type column at a captured price of $89 per year. That proves a paid offer existed in the broader category on the capture date. It does not prove purchases for this narrow display feature.
The exact-intent US keyword check returned no reportable numeric search volume for the three tested payment-column phrases. No narrow paying-market floor or measured StoreFixKit acquisition capacity has been verified.
At a hypothetical $39 annual price, a $10,000 MRR target requires about 3,077 active annual customers. The selection model assumes 180 new customers per month, 1.5% free-to-paid conversion, and 20% annual churn. Those assumptions and the modeled support load are unverified. The $10,000 MRR figure is a product-selection hypothesis, not a forecast, promise, or sales claim.
Frequently asked questions
Does this verify a payment with the gateway?
No. It displays values already saved on the current WooCommerce order.
Does a transaction ID prove settlement?
No. Use the gateway's authoritative dashboard or documented API for live status.
Can the plugin refund or retry a payment?
No. It has no payment mutation or gateway-request feature.
Are payment details sent to StoreFixKit?
No. Explicit license actions send only the license key, site URL, and product key.
What should I send support?
Use StoreFixKit Support and include plugin versions, WordPress and WooCommerce versions, HPOS state, role, gateway name, whether a local transaction ID exists, expected and actual behavior, and repeatable steps. Remove all customer, order, transaction, credential, license, and payment data. After an official WordPress.org listing exists, support can provide the correct review link.
Focused plugin
Use the one-job implementation.
Show the payment-method title saved on each classic or HPOS WooCommerce order, with an optional Pro transaction-ID disclosure and no gateway request.