Payment Methods, Adobe Commerce

Metrics type: Supporting Metrics • Category: Ecommerce Platform

At a glance

Distribution of orders by payment method (payment.method code in Adobe Commerce). Adobe and Magento support a sprawling catalogue of payment methods: card-via-Stripe, Braintree, Authorize.Net, PayPal Express, PayPal Checkout, Apple Pay, Google Pay, bank transfer, cash on delivery, purchase order (PO), Amazon Pay, Klarna, AfterPay, plus per-merchant custom methods. The card surfaces the mix by count and by grand_total, helping the merchant spot routing failures and gateway dependencies.


What it counts	`COUNT(orders) GROUP BY payment.method` and `SUM(grand_total) GROUP BY payment.method` over the 30-day window. The `method` field is a Magento internal code (`stripe_payments`, `braintree`, `paypal_express`, `checkmo`, `purchaseorder`, etc.); the card maps to a friendly display label via the merchant’s payment-method config.
API field	`payment.method` and `payment.additional_information` from the orders index. Adobe Commerce REST: `GET /rest/V1/orders` returns nested `payment` object.
Why this matters	Payment-method mix changes are leading indicators of friction. A sudden drop in PayPal share usually means PayPal SDK script is blocked on the storefront (often after a CSP change). A sudden rise in `checkmo` (check) suggests card capture is failing and customers are switching to manual.
VAT / tax treatment	n/a for the count slice. Tax-inclusive `grand_total` for the value slice (matches Total Revenue).
Shipping inclusion	Included in `grand_total` per method.
Discounts	Deducted from `grand_total` per method.
Cancelled orders	Included by default. A cancelled order’s payment method still counts (it shows what the customer attempted). Toggle to exclude `canceled` for “captured-only” view.
Refunds	Not subtracted, this is order creation by method, not net contribution.
`pending_payment` quirk	Adobe Commerce sets `payment.method` at order creation, regardless of whether the gateway captured. A `pending_payment` order with `method=stripe_payments` shows under Stripe in the count, even if Stripe never captured. To see “actually-captured” mix, exclude `pending_payment` and `payment_review` states.
Multi-currency	The value slice mixes currencies in `grand_total`. Use `base_grand_total` for FX-neutral.
Multi-store scope	All Store Views by default. Per-Store-View slicing via legend. Different Store Views often have very different payment-method mixes (US allows ACH bank transfer; UK does not).
Time window	`30D` rolling.
Alert trigger	None on this card directly. Alert on a single method’s % share dropping >50% week-on-week (suggests outage).
Roles	owner, operations

Calculation

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

Worked example

A B2B+DTC apparel merchant on Adobe Commerce 2.4.7. UK + US Store Views. Snapshot 13 May 26, 30-day rolling. 4,820 orders, $950,000 grand total. Payment method distribution:

Method (Magento code)	Display label	Order count	% count	`grand_total`	% value	Avg AOV
`stripe_payments`	Card (Stripe)	2,890	60.0%	$462,000	48.6%	$160
`braintree_paypal`	PayPal	720	14.9%	$128,000	13.5%	$178
`purchaseorder`	Net-30 PO (B2B)	308	6.4%	$182,000	19.2%	$591
`applepay`	Apple Pay	480	10.0%	$74,200	7.8%	$155
`klarna_kp`	Klarna	180	3.7%	$38,400	4.0%	$213
`amazon_payment`	Amazon Pay	132	2.7%	$32,800	3.5%	$248
`banktransfer`	Bank transfer	78	1.6%	$26,400	2.8%	$338
`checkmo`	Check by mail	22	0.5%	$4,200	0.4%	$191
Other / custom	various	10	0.2%	$2,000	0.2%	$200
Total		4,820	100%	$950,000	100%	$197

Insight pattern:

Stripe is 60% of orders but only 48.6% of value. Stripe-paid customers have a lower AOV ( $160) than the average ($ 197) because Stripe is dominant for the lower-AOV DTC traffic. Higher-AOV B2B customers route through purchaseorder (PO).
PO is 6.4% of orders and 19.2% of value. Critical revenue contribution; one PO failure equals 30+ Stripe orders. Track Order State Distribution for pending_payment orders specifically on the PO method, those represent net-30 invoices in flight.
PayPal at 14.9% count, 13.5% value. Roughly mirroring; PayPal is broad-AOV. A drop here is often a SDK/script-block issue on the storefront. Cross-link with paypal.pp_total_volume to confirm Adobe and PayPal agree on the count.
Apple Pay at 10%. Significant; mostly DTC mobile-checkout. If iOS Safari traffic drops, Apple Pay drops with it. Check the storefront’s domain-association file (/.well-known/apple-developer-merchantid-domain-association); if expired, Apple Pay silently disappears from the checkout sheet.
checkmo (check by mail) at 0.5%. Tiny but worth watching, a sudden rise from 0.5% to 5% is the gateway-failure signature: card capture broke, customers fell back to “check by mail”. This is the most reliable canary for a card-payment outage.
Cross-link with Order State Distribution: if pending_payment is high specifically on stripe_payments orders, the Stripe-callback path is broken. Look at PayPal share, if PayPal share is rising while Stripe share is stable but pending_payment is rising, the Stripe success-callback is the issue (orders created, payment captured at Stripe, but Adobe never received the success webhook).
Action queue: (a) verify Apple Pay domain certificate not expiring, (b) audit PO pending_payment queue for stuck invoices, (c) set up alerts for checkmo share crossing 1.5%.

Sibling cards merchants should reference together

Card	Why pair it with Payment Methods
Gateway Revenue	Same data, slightly different lens (gateway-grouped).
Order State Distribution	`pending_payment` per method reveals callback failures.
Total Revenue	The denominator for value share.
Total Orders	The denominator for count share.
Revenue Drop Alert	Method-specific drops are the early signal of a gateway outage.
`stripe.stripe_charge_count`	Stripe-side count; should approximately match `stripe_payments` here.
`paypal.pp_transaction_count`	PayPal-side; should match `braintree_paypal` and any other PayPal methods.
`stripe.stripe_apple_pay_count`	If using Stripe-routed Apple Pay, this card’s `applepay` method should match Stripe’s tagged Apple Pay charges.

Reconciling against the vendor’s own dashboard

Where to look in Adobe Commerce Admin:

Sales > Orders with the Payment Method column displayed. Group manually by method to count. Adobe does not have a “payment method distribution” report natively in 2.4.x.

For per-method gateway settings:

Stores > Configuration > Sales > Payment Methods lists every configured method with its enabled state. A method that’s “enabled” in config but missing from this card has zero recent transactions (it’s either offline or customers aren’t selecting it).

Why our number may legitimately differ from a manual Admin computation:

Reason	Direction of divergence
Multi-Store-View visibility. A method enabled on US Store View only won’t appear in UK orders. The grand total here aggregates everything; per-Store-View slice exposes the difference.	None on aggregate
Method-code vs display-label. The card shows display labels (configured per method); Admin shows method codes. The merchant might think `braintree_paypal` and `paypal_express` are the same method when they’re separate codes; the card breaks them out.	Admin-grouping might collapse what we keep separate
`pending_payment` and `canceled` inclusion. Defaults to include. A merchant manually counting from “Sales > Orders” filtered to status=Complete will see a smaller count. Match the filters for like-for-like.	Card higher than captured-only Admin filter
Custom payment methods. A merchant with a custom-coded method needs an entry in the config-mapping for the friendly label. Until that’s added, the card shows the raw code.	Cosmetic, no count impact
Time-zone, sync lag. Standard.	Minor

Cross-connector reconciliation (when these connectors are connected for this merchant):

Card	Expected relationship	What divergence tells you
`stripe.stripe_charge_count`	Should match `stripe_payments` count here	If Stripe is materially higher, the merchant has direct-to-Stripe orders not flowing through Adobe (rare). If Adobe is higher, some `stripe_payments` orders are in `pending_payment` that never hit Stripe.
`paypal.pp_transaction_count`	Should match all PayPal-related methods (`braintree_paypal` + `paypal_express` + others)	Standard, gateway and Adobe should agree.
`amazon.amazon_pay_volume`	Should match `amazon_payment`	Amazon Pay has its own callback path; failures here flag the integration.

Known limitations / merchant FAQs

Why are PayPal Express and PayPal Checkout shown separately? Because they are separate Magento method codes (paypal_express and paypal_billing_agreement and braintree_paypal are three different things, all routing through PayPal’s API but with different checkout flows). The card keeps them separate; group them via the Vortex IQ workspace’s payment-method aliases if you want a unified PayPal view. A method is enabled in config but doesn’t appear on the card, why? No transactions in the period. Either the method is misconfigured (customers see it but the gateway returns errors), or customers aren’t selecting it (they prefer another option). Check Stores > Configuration > Sales > Payment Methods for the method’s “Title” and “Sort Order”; methods low on the list often get ignored. checkmo (check by mail) is rising, what’s happening? Almost always a card-payment failure. Customers’ card attempts are failing (invalid token, expired cert, gateway down) and they fall back to “pay by check”. Check the gateway’s status page and your Adobe Commerce error logs (var/log/payment.log). My multi-store has Apple Pay on US but not UK, why? Apple Pay requires per-domain certificate verification. Each Store View domain needs its own Apple Pay merchant ID and apple-developer-merchantid-domain-association file. UK Store View probably doesn’t have the cert. Stores > Configuration > Sales > Payment Methods > Apple Pay is per Store View scope; configure separately. Klarna and AfterPay show low share, are they worth keeping? Buy-Now-Pay-Later (BNPL) methods convert at 1.5-2x compared to standard card for high-AOV DTC. Even at 4% share, they may be saving 20-30% of would-be-abandoned high-AOV checkouts. Cross-link with google_analytics.ga_checkout_funnel to measure the BNPL incremental conversion. Why does the card include canceled orders? Because cancellation reflects what the customer attempted. A method showing high cancellation share (e.g. bank_transfer at 30% canceled) is a friction signal, customers start the bank transfer then give up. Toggle to exclude canceled for “captured-only” view. A custom payment method shows as a raw code, can I rename it? Yes via the Vortex IQ workspace’s payment-method label config. Map the raw Magento code to a friendly label; the card respects it on next refresh. purchaseorder (PO) orders sit in pending_payment for days, normal? Yes for B2B. PO orders intentionally wait for AP department approval and net-30 invoice payment. Adobe’s pending_payment state is the right place for them. Operations should monitor the residence time; over 35 days suggests a payment-collection issue (cross-link with stripe.stripe_invoice_aging or your AR system). Why doesn’t paypal.pp_transaction_count exactly match my PayPal share here? Three causes: (1) PayPal Adaptive Payments and PayPal Standard are separate paths; (2) some Adobe-side paypal_express orders never reach PayPal (customer abandoned mid-flow); (3) PayPal-side may include subscription billing not visible to Adobe. Aggregate over 30 days and they should match within 2-5%. Can I see method share over time? Yes via the time-series view of this card (toggle to “trend” mode). Useful for catching gradual mix shifts (e.g., Apple Pay rising over 6 months, PayPal slowly declining).

Tracked live in Vortex IQ Nerve Centre

Payment Methods is one of hundreds of KPI pulses Vortex IQ tracks across Adobe Commerce 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.

Get Started

The AI OS

At a glance

Calculation

Worked example

Sibling cards merchants should reference together

Reconciling against the vendor’s own dashboard

Known limitations / merchant FAQs

Tracked live in Vortex IQ Nerve Centre

​At a glance

​Calculation

​Worked example

​Sibling cards merchants should reference together

​Reconciling against the vendor’s own dashboard

​Known limitations / merchant FAQs

​Tracked live in Vortex IQ Nerve Centre

At a glance

Calculation

Worked example

Sibling cards merchants should reference together

Reconciling against the vendor’s own dashboard

Known limitations / merchant FAQs

Tracked live in Vortex IQ Nerve Centre