The WooCommerce First Data extension covers Payeezy (now Fiserv) integrations and stores per-order data such as transaction tag, auth number, bank response, AVS, and CVV into order meta on every checkout. On HPOS stores these land in wc_orders_meta as keys like _wc_firstdata_transaction_tag, _wc_firstdata_auth_no, _wc_firstdata_bank_resp_code, and _wc_firstdata_avs_response. The default Orders screen does not show them.

SleekView reads those keys as columns alongside the WooCommerce status and total. Authorised-but-uncaptured orders become a saved view sorted by auth age. Declines filter by bank response or AVS code, surfacing patterns that the default admin would only show as a per-order order-note. Tokens stored in woocommerce_payment_tokens join in for customer-rooted token-management views.

Inline edits route through WooCommerce CRUD, so woocommerce_order_status_changed fires and the First Data extension's own capture, void, and refund handlers continue to run from the order context. SleekView reads what the plugin writes, it does not bypass the gateway integration.

First Data (now Fiserv) sits behind a large share of US merchant card processing, and the WooCommerce Payeezy extension is widely deployed on North American stores. The card lifecycle through First Data has more states than the default WooCommerce Orders screen reflects: auth, capture, void, return, and the bank response and AVS dimensions wrapped around each. The plugin writes all of that into order meta.

The default admin reads almost none of it. Finance teams reconcile Payeezy batches by exporting CSVs and grep-ing through WordPress, risk teams spot AVS or bank response patterns only after the chargeback, and support teams hand dispute evidence to ops one order at a time. SleekView reads the meta the plugin already records and exposes it as columns ops can filter, sort, and bulk-update.

The plugin's gateway calls continue unchanged. The change is row-level visibility of data the admin has stored all along.