← Decline Codes
Hard Decline

Stripe Decline Code · Glossary

pickup_card

pickup_card is a hard decline with a serious security implication — the issuing bank has flagged this card as one that should be physically retrieved from the cardholder and returned to the bank.

Non-recoverable·15–25%·Updated May 2026

What It Means

What pickup_card actually means.

pickup_card is a hard decline with a serious security implication — the issuing bank has flagged this card as one that should be physically retrieved from the cardholder and returned to the bank. In the physical POS world, this code instructs merchants to confiscate the card. In online and subscription billing — where card confiscation is impossible — it translates to a single operational directive: do not process this transaction, do not retry, and treat the card as potentially compromised. It maps to two underlying network codes: 04 (pick up card, no fraud) and 07/41/43 (pick up card, fraud/lost/stolen).

Not sure if this code is recoverable for your specific situation? Use the Stripe Failure Lookup →

Why It Happens

The root causes.

  • 1Card reported lostThe cardholder has reported their card lost to their bank — the issuer has flagged it for retrieval and all transaction attempts are blocked; maps to network code 41 (lost card, pick up)
  • 2Card reported stolenThe cardholder or bank has flagged the card as stolen — all authorization attempts are hard-blocked with a retrieval flag; maps to network code 43 (stolen card, pick up)
  • 3Bank-initiated card cancellationThe issuer has administratively cancelled or deactivated this card — potentially due to account closure, fraud detection, compliance action, or card replacement — and flagged it for retrieval from any merchant attempting to process it
  • 4Fraud detected on the accountThe bank's fraud engine has confirmed suspicious activity on this card and issued a retrieval flag as part of its fraud containment response — maps to network code 07 (pick up card, fraud)
  • 5Card used in CNP context after physical compromiseIn e-commerce and subscription billing, pickup_card frequently indicates that compromised card data is being used — the card was flagged at a physical point of interaction and the same card number is now being used online, triggering the same retrieval flag

What NOT to Do

Common mistakes that make it worse.

Never retry — this is one of the hardest hard declines in the taxonomy

pickup_card is an absolute, non-negotiable, permanent hard decline. There is no retry interval, no bank contact resolution, no timing fix that changes the outcome — the card has been flagged for retrieval by the issuing bank itself. Retrying is not just futile; in a CNP context it raises a fraud signal against your merchant account.

Don't ask the customer to "contact their bank to authorize the charge"

Unlike call_issuer or do_not_honor, a bank call cannot lift a pickup_card flag. The card is physically flagged for retrieval — the issuer will not authorize further transactions on it regardless of what the cardholder requests. Routing a customer through a bank call for pickup_card wastes their time, creates false hope, and delays the only real fix: a new payment method.

Don't treat it identically to lost_card or stolen_card in your automation

While there is significant overlap — pickup_card frequently signals the same underlying cause as lost_card or stolen_card — the pickup_card code specifically carries the bank's retrieval instruction. Your automation must handle it with the same zero-retry, payment-method-switch-only logic, but the customer email framing differs slightly: pickup_card is softer in cause ambiguity, so your outreach should be neutral rather than alarming.

Retry Timing

Optimal retry schedule.

Zero retries — permanent. The response is entirely a new payment method capture sequence.

Recovery Benchmark

What good looks like.

MetricResult
Overall recovery rate15–25%
Recovery for long-tenure customers (card replacement)30–40% — genuine customers with a new card
Recovery for new or short-tenure accounts5–10% — higher fraud proportion
Recovery via alternate payment method (PayPal, bank transfer)+10–15% additional lift
Recovery with blind retries~0%
Fraud proportion of all pickup_card occurrences20–35% in CNP/subscription context

A 20–25% overall recovery rate is the realistic ceiling — long-tenure genuine customers whose card was lost or stolen will naturally seek to update their payment method once they receive your email; the key is a clear, fast, non-alarming communication that gives them an obvious next step. For new accounts, recovery rate is a secondary concern — fraud prevention is the primary KPI.

At Scale

How to handle it at scale.

Automated

  • Webhook trigger: invoice.payment_failed → check failure_code === 'pickup_card' → immediately execute: (1) mark card as permanently blocked — remove from all retry schedulers forever, (2) flag account for fraud review if account age < 60 days
  • Absolute no-retry lock: pickup_card joins lost_card, stolen_card, and fraudulent on your hardest no-retry blocklist — no automation, no manual override, no exceptions
  • Account tenure segmentation:
  • Long-tenure customer (>90 days, multiple successful payments) → standard payment method update email — genuine card loss/theft scenario, warm and direct
  • New account (<60 days, <3 successful payments) → route to fraud review queue before any customer-facing action — verify account legitimacy before investing in recovery
  • Email Day 0 — neutral, fast, clear: Subject: "Action needed — please update your payment method" — no mention of fraud, no alarming language; explain the card can no longer be used and provide a direct link to add a new card or alternate payment method; include PayPal and bank transfer as prominent options
  • Fraud review automation for new accounts: For accounts flagged by the tenure check, run automated fraud signals: email domain quality, IP geolocation match, signup device fingerprint, prior dispute history — if multiple signals are negative, pause the account pending manual review rather than sending a payment update email
  • Permanent card-level block: Store the failed card's fingerprint (via Stripe's card.fingerprint) in your blocked-card registry — prevent the same card from being re-added to any account on your platform

Manual Escalation

  • High-ACV long-tenure accounts: Personal outreach from a CSM within 2–4 hours — "Hi [name], we noticed there's an issue with your card on file — likely related to a lost or replaced card. Can we get you set up on a new payment method quickly so you don't lose access?" — warm, human, and action-oriented
  • New account fraud review: Manually review flagged new accounts before any outreach — check for: mismatched billing details, VPN/proxy IP, high-risk email domain, unusually large initial plan selection; cancel and refund any accounts showing multiple fraud signals proactively
  • Card fingerprint cross-reference: If the same card fingerprint is appearing across multiple accounts on your platform alongside pickup_card, escalate to Stripe Radar review — coordinated fraud using stolen card data across multiple signups is a platform-level risk requiring immediate action
  • Post-recovery card block: For customers who successfully update to a new payment method after pickup_card, monitor the new card for 60 days — a pattern of pickup_card followed by rapid card rotation may indicate account-level fraud rather than genuine card loss

FAQs

Frequently asked questions.

What does the Stripe pickup_card decline code mean?

pickup_card means the issuing bank has flagged this card for retrieval — in physical POS environments, merchants are instructed to confiscate the card. In online and subscription billing, it means the card is permanently blocked and cannot be used for any transactions. The card may have been reported lost or stolen, administratively cancelled, or flagged after confirmed fraud.

What are the most common causes of a pickup_card error in Stripe?

Common causes include the cardholder reporting the card lost or stolen, the bank administratively cancelling the card due to fraud detection, account closure, or card replacement, confirmed fraudulent activity triggering a retrieval flag, and compromised card data from a physical breach being used in an online or subscription context.

Should I retry a payment after a Stripe pickup_card decline?

Never. pickup_card is an absolute hard decline — the card has been flagged for retrieval by the issuing bank. No retry interval or bank contact will change the outcome. Add it to your permanent no-retry blocklist alongside lost_card and stolen_card, and focus entirely on capturing a new payment method.

Does pickup_card indicate fraud in Stripe subscriptions?

Not always, but it is a meaningful fraud signal — particularly on new accounts. In card-not-present and subscription contexts, pickup_card frequently indicates compromised card data being used online after the card was flagged at a physical point of interaction. For accounts under 60 days old with fewer than three successful payments, treat pickup_card as a fraud review trigger before sending any customer-facing outreach.

What is the recovery rate for Stripe pickup_card failures?

Overall recovery rates are 15–25%. Long-tenure genuine customers whose card was lost or stolen recover at 30–40% when contacted quickly with a clear payment method update prompt. New or short-tenure accounts recover at only 5–10% due to a higher fraud proportion. Alternate payment method options add 10–15% additional lift for genuine customers who engage.

Before you retry

Most pickup_card failures are retried on the wrong schedule — which recovers the payment about 30% of the time. The other 70% leaves permanently. See what this code is actually costing at your MRR before deciding how to handle it.

See what pickup_card costs me →

Stop leaving revenue on the table

pickup_card can't be retried — but it can be caught earlier.

Recurflux handles code-specific retry scheduling, adaptive dunning, and dispute intelligence across all 30 Stripe decline codes. Connect in under 5 minutes.