The official Amazon Pay extension persists each transaction's amazon_charge_id, amazon_charge_permission_id, amazon_reference_id, and capture state on the order row via WooCommerce order meta. With HPOS enabled, that data lives in wc_orders_meta against wc_orders; on legacy stores it sits in wp_postmeta against shop_order posts.

The default WooCommerce orders screen shows none of those IDs as columns. Reconciling Amazon settlement reports against the store currently means exporting orders, joining the CSV against the Amazon dashboard, and chasing mismatches one order at a time. There's no built-in filter for "authorized but not yet captured" or "declined by Amazon".

SleekView reads wc_orders joined with wc_orders_meta and surfaces amazon_charge_id, amazon_charge_permission_id, and capture status as first-class columns. Inline edits to order status route through the WooCommerce CRUD layer so capture, refund, and notification hooks fire exactly as the gateway expects.

Amazon Pay sits in a category of WooCommerce gateways that record their own external transaction IDs against each order, and the operational question for every store running one is the same: which orders did the gateway actually take money for, and which are still in an in-between state. With Amazon Pay specifically, the authorize-then-capture flow creates a window where an order is authorized but not yet captured, and that window is exactly when finance needs to act before the authorization expires. The default WooCommerce orders screen surfaces none of that on the row, so finance teams export CSVs, join them against Amazon's settlement report by hand, and chase exceptions in a spreadsheet.

SleekView's job here is to put amazon_charge_id and capture state on the row so the same audit becomes one filtered table. Inline edits route through the gateway's CRUD path so captures, refunds, and webhook fires behave exactly like manual admin actions. The merchant still has the standard Orders screen if they prefer it; the audit surface is what changes.