No. The WooCommerce Eway gateway writes everything (transaction ID, Beagle score, Customer Token, card brand, last4) into wc_orders_meta on HPOS or wp_postmeta on legacy storage. SleekView reads those meta keys as columns; no extra plugin schema.

Yes. _eway_beagle_score is exposed as a numeric column you can sort and threshold. A saved view of "Beagle score above 70 in the last 7 days" gives the risk team a daily review queue without per-order clicks.

Yes. SleekView reads from wc_orders and wc_orders_meta on High-Performance Order Storage. Sites on legacy CPT storage are also supported; the grid detects the active layer. Saved views carry over across the HPOS migration.

_eway_token_customer_id is promoted as a groupable, filterable column. Grouping by token assembles each saved-card customer's order history in one view; filtering to a specific token pulls just that customer's orders.

No. _eway_trans_id is immutable on Eway's side; SleekView marks it read-only. Editing it locally would silently desync the order from the real transaction. Notes and explicitly-editable meta keys can still be inline-edited and route through WooCommerce's CRUD layer.

No. SleekView reads only what the gateway already wrote to your database. Refunds, voids and captures still run through the gateway's existing order actions because they need to update Eway-side state, which keeps both systems consistent.

Currency is its own column with locale-aware formatting. Eway-AU and Eway-NZ are commonly run together, and currency as a filter splits AUD and NZD flows for separate reconciliation against region-specific settlement reports.

Yes. Filter to whatever risk or finance asked for, then export the visible slice as CSV. Column-level masking applies on export, so last4 and email hide for users without the right capability. Common exports are weekly Beagle-flagged orders and monthly token-customer renewals.