No. The WooCommerce Bambora (Worldline) gateway writes all gateway-side references (transaction ID, AVS, CVD, recurring profile) into wc_orders_meta on HPOS or wp_postmeta on legacy CPT storage. SleekView reads those meta keys as columns, no extra schema to join.

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

Yes. SleekView reads from wc_orders and wc_orders_meta on High-Performance Order Storage. Legacy CPT storage is also supported; the grid detects the active layer. Saved views and column promotions migrate transparently.

_bambora_avs_response is promoted as a typed column with canonical Bambora codes (matches, mismatches, partials, unsupporteds). A filter on it surfaces the cohort most likely to dispute, which becomes the daily risk-review queue.

Yes. _bambora_recurring_id appears as a groupable, filterable column. Grouping by profile assembles the renewal history for each subscriber in one place; filtering to a specific profile pulls only its orders.

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 Bambora-side state, which keeps both systems consistent.

Bambora supports Interac Online for Canadian shoppers, and the gateway writes Interac-specific meta keys (separate from credit card meta). SleekView surfaces them as their own column group, so Interac reconciliation runs as its own saved view alongside card-funded orders.

Yes. Filter to risk or finance criteria and export the visible slice as CSV. Column-level masking applies, so PII fields hide for users without the right capability. A common pattern is weekly AVS-flagged exports for the risk team.