In wc_orders_meta on each WooCommerce order. Klarna for WooCommerce does not create its own custom plugin tables — every gateway field (order ID, payment category, reservation, environment) is a meta key on the standard order tables. SleekView reads those keys as columns, which works against both legacy CPT order storage and modern High-Performance Order Storage transparently.

Capture still flows through the Klarna plugin and ultimately through Klarna Order Management, because capture needs to update Klarna-side state, not just local meta. SleekView gives you the queue around capture — which orders are authorized, when their reservations expire, which need fulfillment first. The actual capture call goes through the existing order action so audit logs and Klarna's API contract stay consistent.

Yes. The _kp_payment_category meta key carries canonical values from Klarna (pay_now, pay_later, pay_over_time, financing, plus market-specific variants). Each value becomes a filter target, so Pay in 3 analyses do not get lumped together with longer-term financing. Stores running multiple categories in the same market — for example, Pay in 3 alongside Pay in 30 — see them as separate saved views.

Yes. Currency is treated as its own column you can group by, with locale-aware formatting in cells. Klarna orders in SEK, EUR, GBP and USD all show in the same grid with the right currency symbol per row. Cross-currency totals require explicit currency conversion in the export step — SleekView does not silently convert across currencies because that would hide rounding differences finance needs to see.

Yes. The _klarna_environment meta key is its own column with two canonical values, live and test. The default "production view" filters to live only, so test orders never accidentally inflate financial reports. Test-only views are useful during integration work and can be shared with developers without giving them access to live transaction data via per-role row scoping.

No. SleekView reads the same meta keys Klarna Order Management writes and reads. KOM still owns capture, refund, partial capture and order modification on Klarna's side. SleekView only reads the local database — it does not call Klarna's API at any point and does not modify Klarna-side state. Running both in parallel is the expected pattern: KOM for actions on individual orders, SleekView for queries across the whole order base.

When KOM extends a reservation (manually or via automation), the new reservation timestamp updates in meta and SleekView surfaces the latest expiry on the next grid load. Sorting by reservation expiry always reflects the current authorized window, not the original one. This matters for stores with long fulfillment cycles where reservations get extended several times before final capture.

Yes, when settlement timestamps are written to meta by your KOM configuration. Settlement date becomes a sortable column you can group by to reconcile against Klarna's settlement reports. Stores on a daily settlement cadence can build a saved view per day of orders that should appear in that day's settlement, then match the totals before flagging discrepancies.