Skip to main content
Card class: Non-HeroCategory: Payment Gateway

At a glance

Total count of successful Klarna BNPL orders in the period. Klarna order-volume divided by this gives Klarna AOV (typically 30 to 45% above card AOV).
What it countsCOUNT(orders) where status = CAPTURED. Pay in 4, Pay in 30, Slice it all count as one transaction each.
API endpoint/ordermanagement/v1/orders.
CurrencyCurrency-neutral (count).
RefundsExcluded.
Failed / declined Klarna ordersExcluded.
Cancelled-by-merchantExcluded.
Klarna underwriting decisionCounted only if Klarna approved AND captured.
Pay in 4 vs Pay in 30 vs Slice itEach = one transaction.
Time window30D vsP.
Alert triggerdrop >15% vsP.
Rolesowner, finance, operations

Calculation

Calculated automatically from your Klarna data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.

Worked example

“Helle Mode” (German DTC fashion), 30 days ending 02 May 26.
Klarna productOrder countVolumeAOV
Pay in 30 days (DE)4,820EUR 612,400EUR 127
Pay in 4 (DE)1,840EUR 248,300EUR 135
Slice it320EUR 184,200EUR 575
Pay in 30 days (UK)480GBP 51,800GBP 108
Total7,460
What the merchant should notice:
  1. 7,460 Klarna orders is roughly 35% of total order count for Helle Mode, consistent with a German fashion brand at maturity of Klarna integration.
  2. Pay in 30 days dominates with 65% of order count. German consumer preference; Pay in 4 grows but slower.
  3. Slice it at 4.3% of count contributes 17.6% of volume. Higher AOV justifies the friction (consumer credit check).
  4. A 15% drop in count triggers alert. Common causes: Klarna approval rate dropped (issuer-side risk model tightening); checkout-page Klarna placement changed; competitive BNPL added (Afterpay).

Sibling cards merchants should reference together

CardWhy pair it
kla_total_volumeThe dollar-volume view.
kla_avg_transactionAOV.
kla_decline_rateWhat fraction of attempts failed.
kla_top_payment_methodsPay in 4 vs Pay in 30 vs Slice it split.
Stripe stripe_total_transactionsCross-rail count comparison.

Reconciling against the vendor’s own dashboard

Where to look: Klarna Merchant Portal at portal.klarna.comOrders → All orders with status filter “Captured”. Why our number may differ:
ReasonDirectionWhy
Time zoneBoundary days offCEST vs UTC.
Authorised vs capturedTheirs higherAuthorised-but-not-captured included in some Portal views.
Refresh lagOurs lower for “today”API sync lag.
Cross-connector reconciliation:
ComparisonExpectedWhy
kla_total_transactions ↔ commerce-platform Klarna order countApproximately equalBoth count same orders.

Known limitations / merchant FAQs

Are authorised-but-not-captured orders counted? No. Once captured, they count. Klarna order with multiple line items, one transaction or many? One. The Klarna order is the unit. Cancelled-by-merchant Klarna orders, counted? No. Klarna refunds, do original orders still count? Yes. Refund is separate event in kla_refund_volume. Slice it vs Pay in 4, distinguishable here? No, this is a single count. Use kla_top_payment_methods. Klarna in-app purchases counted? Yes if they redirect to merchant checkout and complete via Klarna Payments. Klarna NYSE listing 2025, operational change? None. Public-listed Klarna AB continues operations as before.

Tracked live in Vortex IQ Nerve Centre

Total Transactions is one of hundreds of KPI pulses Vortex IQ tracks across Klarna and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.