GROUP BY paymentMethod WHERE paymentStatus=declined. Surfaces a single payment surface that’s failing disproportionately, candidate for tokenization, routing change, or alternative method addition.
At a glance
Declined-payment volume bucketed by the payment method the customer chose at checkout. Surfaces the single payment surface that is failing disproportionately, the candidate for tokenization, routing change, or alternative-method addition.
| What it counts | GROUP BY paymentMethod.keyword WHERE paymentStatus = 'declined', with each bucket carrying both the order count and the share-of-total-declines percentage. The accompanying chart sorts methods by decline count descending. |
| VAT / tax treatment | n/a, this is a count grouped by a string field. The dollar twin (planned) would use total_inc_tax (always tax-inclusive). |
| Shipping | n/a, count metric. |
| Discounts | n/a, count metric. |
| Refunds | Excluded. paymentStatus = refunded orders succeeded first; this card is about failed attempts. |
Incomplete orders | Excluded. Incomplete orders never reached the payment-decision step; they have no meaningful paymentMethod (it’s often blank or “Manual”). This card focuses purely on the gateway-side decline population. For the Incomplete cohort use BC Incomplete Rate. |
| Cancelled orders | Excluded. Cancelled orders typically had paymentStatus = captured first and were merchant-voided. |
| Currency | Currency-agnostic, decline counts are not money figures. The mix of methods varies by currency though, EUR stores see SEPA / iDEAL / Klarna; GBP sees more PayPal Express; USD sees more raw card. |
| Channels / sources | Not filtered. All channel_id values contribute. In practice marketplace channels (Channel Manager) rarely show declines because the marketplace pre-authorises payment, so this card mostly reflects Stencil web (channel_id = 1) and POS. |
| Method labels | The paymentMethod field is a free-form string set by the gateway integration. Common BC values: Credit Card, PayPal, PayPal Express, Authorize.Net, Stripe, Klarna, Apple Pay, Google Pay, Amazon Pay, Manual. Method labels are not normalised, so “PayPal” and “PayPal Express” appear as separate buckets even though they share infrastructure. |
| Time window | 30D (no vsP comparison; this is a snapshot distribution, not a trend) |
| Alert trigger | any method >2× base-rate share, fires when one method’s share of declines is more than double its share of total-method volume. Highlights structurally broken surfaces. |
| Roles | owner, finance, operations |
Calculation
Calculated automatically from your BigCommerce 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 UK fashion retailer on BigCommerce Plus. The 30-day window covers 14 Mar 26 to 12 Apr 26. Total declines: 142. Total successful orders: 2,860. Headline decline rate: 4.7%.| Payment method | Decline count | Share of declines | Share of all orders | Decline-share ÷ order-share | Verdict |
|---|---|---|---|---|---|
| Credit Card (Stripe) | 71 | 50.0% | 62.0% | 0.81 | Healthy |
| PayPal Express | 48 | 33.8% | 18.0% | 1.88 | Watch |
| PayPal (legacy) | 16 | 11.3% | 4.0% | 2.83 | Broken |
| Apple Pay | 4 | 2.8% | 8.0% | 0.35 | Healthy |
| Klarna | 2 | 1.4% | 6.0% | 0.23 | Healthy |
| Google Pay | 1 | 0.7% | 2.0% | 0.35 | Healthy |
| Total | 142 | 100% | 100% |
- PayPal (legacy) is failing 2.83x its expected rate. A 4% volume share is producing 11.3% of declines. This is the classic signature of a misconfigured gateway, an expired API certificate, an SSL handshake failure, or a fraud-rule mismatch. Legacy PayPal integrations on BC are notorious for silently rotating credentials; check the BigCommerce Settings → Payments → PayPal health indicator first.
- PayPal Express is also above 1.5x. Less alarming than the legacy variant, but still worth investigating. Often the same root cause (PayPal account-level issue propagating across both surfaces).
- Apple Pay, Google Pay, and Klarna are punching below their weight. Each shows a decline-share well below their volume share, exactly what you want from these surfaces. They handle authentication (3DS2 equivalent) on the wallet side before submitting to the gateway, so by the time BC sees the payment it has already passed the riskiest checks. Stores adding wallet payments typically see overall decline rates fall by 20-30%.
- Stripe / Credit Card is healthy at 0.81x. Most stores see this band sit between 0.7x and 1.1x. Above 1.3x suggests a fraud-rule issue (Stripe Radar mis-tuned) or a BIN-decline problem (a specific issuer rejecting your traffic).
- Open BC Settings → Payments → PayPal. Confirm credentials, certificate expiry, and live-vs-sandbox flag. PayPal credentials silently expire on 13-month cycles for many merchants, this is the single most common BC decline-spike root cause.
- Run a small test payment through PayPal (legacy) with a known-good card. If it fails, the merchant has a configuration emergency; route customers away from this method until it’s fixed.
- Disable PayPal (legacy) at the storefront if PayPal Express is healthy enough on its own, the legacy surface adds complexity without revenue upside on most modern BC themes.
- Add wallet payments (Apple Pay, Google Pay) more prominently if not already, the data here shows they convert dramatically better than the methods they replace.
Sibling cards merchants should reference together
| Card | Why pair it with Declines by Payment Method |
|---|---|
| BC Decline Rate | The headline number that tells you whether to look here at all. If decline rate is healthy (<5%) but one method is over-indexed, fix that method anyway. |
| BC Failed Orders Count | The combined headline (declined + incomplete). Use this card to drill into the declined half. |
| BC Failed Orders Value | The dollar twin. Lets you size the prize per method (a 50% decline rate on Klarna with 400k/method volume is). |
| Payment Methods | The volume-share denominator for the over-indexing math. Ratio of (decline share) ÷ (volume share) > 1.5 means a method is broken. |
| BC Size of the Prize | Recovery view, fixing the broken method directly shrinks the prize. |
| BC Failures by Channel ID | Cross-cut: is the broken method only failing on one channel (e.g. PayPal failing on Amazon-via-Channel-Manager but not on Stencil)? |
| Stripe Decline Rate | If Stripe is your processor, the Stripe-side view often surfaces the issuer / BIN dimension this card can’t see. |
| PayPal Decline Rate | Same for PayPal. Use when this card flags PayPal as broken to confirm the root cause. |
Reconciling against the vendor’s own dashboard
Where to look in BigCommerce Control Panel: Orders → All orders, filter statusDeclined, then group / sort by Payment Method column. BC doesn’t surface a native chart of this distribution; the merchant has to read the column manually or export to CSV.
Other BC Control Panel views that look adjacent but aren’t this card:
- Settings → Payments: shows which methods are enabled, not their failure rates.
- Analytics → Sales by payment method: shows successful revenue split by method, the inverse view of this card.
- Insights → Customer behaviour: doesn’t break down by payment method at all.
- Storefront → Payments report (Plus / Pro): only available on higher plans, partial overlap with this card.
| Reason | Direction |
|---|---|
Method label normalisation. BC stores paymentMethod as a raw string from the gateway. Some gateways write “PayPal” on Tuesday and “PayPal Express Checkout” on Wednesday after a plugin update. Our card aggregates exactly as stored, so a method-label change mid-period splits the bucket. | Inflates apparent number of methods |
| Time zone. BC export uses store timezone; we use UTC. | ±1 day boundary effect |
Cancelled-payment rows. Some merchants think a Cancelled order with paymentMethod filled in is a “decline”. This card excludes Cancelled. | Vortex IQ slightly LOWER than naive exports |
| Test orders. Not currently filtered by Vortex IQ. | Marginal |
paymentMethod blank rows. Incomplete orders sometimes carry a blank paymentMethod and sometimes carry “Manual”. We exclude Incomplete entirely from this card to avoid corrupting the distribution. | Vortex IQ LOWER than a count of “all non-successful orders” |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
stripe.stripe_decline_by_card_brand | Stripe shows the card brand dimension (Visa, Mastercard, Amex), this card shows the gateway surface dimension (Stripe vs PayPal vs Klarna). Complementary, not competing. | Stripe sees only Stripe-routed payments; this card sees all gateways. The two answer different questions. |
paypal.pp_decline_by_reason | PayPal exposes the reason code (10485, 10417, etc.). Use it to root-cause the PayPal slice of this card. | PayPal reasons are not visible in BC’s paymentMethod field, you need both connectors. |
google_analytics.ga_purchases_by_payment_method | GA4 ecommerce events carry payment_type, but only on successful purchases | Use as a sanity check on volume-share denominator, not on decline-share numerator. |
paymentMethod field is unique to BC’s data model, Shopify uses gateway and Adobe Commerce uses payment.method, both with different label conventions. Authoring per-gateway-surface decline analytics on Shopify and Adobe Commerce is on the CONNECTOR_BACKLOG.
Known limitations / merchant FAQs
One method dominates my declines, do I just turn it off? Almost never. Turn it off only if (a) it’s a marginal volume method (<5% of orders) and the customers it serves have an alternative they’d happily use, or (b) the method is structurally broken (e.g. SSL handshake failing 100% of the time). For high-volume methods showing elevated declines, fix the configuration first: credentials, fraud rules, 3DS toggle, currency support. Disabling a method that 30% of customers prefer will tank revenue more than the declines were costing. Why are PayPal declines often the worst? Three structural reasons specific to PayPal: (1) PayPal credentials and certificates expire on cycles BC doesn’t proactively surface in the admin; merchants discover the expiry only when traffic spikes. (2) PayPal’s risk model is opaque; some merchant accounts get flagged for “high-risk industry” without notice and start declining heavily. (3) BC’s PayPal integration is split across multiple plugins / surfaces (Express, legacy, BraintreePayments via PayPal); a config drift in one rarely propagates to the others. Open BC Settings → Payments → PayPal and click through every surface separately. Apple Pay shows zero declines, am I configured wrong? Probably not. Apple Pay handles authentication on-device (Face ID / Touch ID) before submitting to the gateway, so by the time BC sees the payment it has already passed every check that would normally trigger a decline. Genuine Apple Pay decline rates run 0.5-1.5%; if you have low Apple Pay volume the absolute count rounds to zero. The fact that wallet payments decline so rarely is exactly why merchants should add them prominently. Klarna / Afterpay / Affirm show high declines, what’s going on? Buy-now-pay-later providers do their own credit check before approving a transaction. Their decline rate is often 8-15%, which would alarm you on a card surface but is normal for BNPL. Compare against the BNPL provider’s own dashboard (Klarna Merchant Portal → Settlement → Declined applications). Don’t disable the surface, BNPL approvals carry significantly higher AOV than card payments. My credit-card decline rate is climbing month over month, where do I start? Three checks in order: (1) 3DS configuration. EU / UK PSD2 rules push more transactions through 3DS2; if your gateway is mis-configured (wrong MCC, missing risk data) issuers decline. (2) Fraud rules. Stripe Radar / Adyen Risk / Authorize.Net AFDS rules often get tightened over time and start blocking legitimate traffic. (3) BIN-level blocking. A specific issuer (often a niche bank or a corporate card issuer) may have started declining your traffic; check the Stripe / processor dashboard for the BIN dimension this card can’t see. I added a new payment method last week, the decline rate spiked, did I break something? Possibly, possibly not. New payment methods often have higher initial decline rates because (a) the merchant’s fraud profile with the new processor isn’t established yet, (b) configuration is rarely perfect first time, and (c) customer-side learning curve. Wait two weeks before judging; new methods typically settle to baseline within 14-21 days. If they don’t, audit the configuration. Multi-currency, does this card split by currency? No. Decline counts are summed across currencies. The accompanying BC Revenue by Currency gives the volume-side currency split. For currency-aware decline analytics, filter the OpenSearch view bycurrencyCode directly, per-currency decline distribution cards are on the BC roadmap.
Why don’t BNPL methods show up in my distribution at all?
You probably haven’t enabled them. BC supports Klarna, Afterpay (via Afterpay app), Affirm, and Sezzle but each is a separate install. If your store doesn’t carry a BNPL surface, this card won’t synthesise one. The opportunity-side question is in BC AOV Discount and Customer Segments: if your AOV is above $80 and you sell into US / UK / AU markets, adding BNPL typically lifts conversion 5-12%.
The card alert fires “any method >2× base-rate share”, what does that actually mean?
For each method, we compute (decline-share %) ÷ (volume-share %). A ratio of 1.0 means the method is failing exactly in proportion to how often it’s used. A ratio of 2.0 or higher means the method is failing twice as often as expected, which usually indicates a configuration or gateway-health problem. The alert cuts off at 2.0 because that’s the threshold at which a fixable root cause is almost always present.