RecoverGuide
pickup_card vs restricted_card on Stripe: same words, opposite retry treatment
Last updated 13 August 2026 · written by Bruce McGinley, who builds RecoverFlow
Two codes, one description, two fates. Stripe's decline codes reference documents both pickup_card and restricted_card identically: the customer cannot use this card to make this payment, and it is possible it was reported lost or stolen. The next step for both is the customer contacting their card issuer.
The difference is what Stripe's retry engine does. pickup_card is one of the nine hard decline codes, so no retry executes until a new payment method is added. restricted_card is not on that list, and scheduled retries keep running.
On this page
What the documentation actually says
Both entries in the reference read the same way: the customer cannot use this card to make this payment, possibly because it was reported lost or stolen, and they need to contact their card issuer for more information.
The phrase possibly lost or stolen puts both codes adjacent to lost_card and stolen_card, where the report is definite. Here the issuer has declined without saying quite that much. We cover the definite versions in the guide to lost_card and stolen_card.
The retry treatment is where they split
The nine code list in Stripe's Smart Retries documentation includes pickup_card and does not include restricted_card.
For pickup_card that means the hard decline mechanics apply: scheduled retries continue and attempt_count keeps incrementing, but the payment only executes once a new payment method is obtained, and unexecuted retries create no charge.
For restricted_card, Stripe reattempts on your schedule like any other retryable code. Whether those retries have much to work with is another question: possibly reported lost or stolen is not a description of a timing problem, and a condition like that rarely improves because a week passed.
How to handle each one
For pickup_card, treat it as the lost and stolen family. The retry engine is parked, so the customer adding a card is the only active recovery channel. Given the documented description says possibly lost or stolen, we would also keep the email reason-blind, the way Stripe explicitly instructs for lost_card and stolen_card. That last step is our advice rather than a documented requirement for this specific code, but the reasoning carries over directly.
For restricted_card, let a retry or two run since Stripe will make them anyway, but do not build hopes on the schedule. The documented next step is the customer contacting their issuer, and a card update link in one plain email gives them the faster alternative. The dunning email generator produces reason-aware copy for exactly this kind of code.
Questions people actually ask
Is pickup_card a hard decline?
Yes. It is one of the nine codes in Stripe's Smart Retries documentation for which Stripe cannot automatically retry. Scheduled retries continue but only execute after a new payment method is added.
Is restricted_card a hard decline?
No. It is not on the nine code list, so Stripe retries it on your schedule. The documented description, possibly reported lost or stolen, is not a temporary condition though, so treat the retries as a bonus rather than a plan.
What does pickup_card mean on Stripe?
Per Stripe's decline codes reference: the customer cannot use this card to make this payment, and it is possible it was reported lost or stolen. The customer needs to contact their card issuer for more information.
What should I tell the customer?
Keep it generic. The documented next step for both codes is that the customer contacts their card issuer. Since the description says possibly lost or stolen, avoid naming that possibility in your email and offer a card update link instead.
Where this came from
Checked against primary sources on 13 August 2026. If Stripe changes something and this page has not caught up, tell us and it gets fixed.
- Stripe: Decline codes reference — the documented meaning and next steps for every code on this page.
- Stripe: Smart Retries — the source for the nine hard decline codes and what happens to scheduled retries after one.
If you would rather not build this yourself
RecoverFlow watches your Stripe account for failed subscription payments, stops retrying the ones that cannot succeed, and emails the customers whose card simply needs replacing. It charges 25% of what it can attribute to a specific action it took, with a $29 monthly floor and a $299 monthly ceiling, and the floor is waived for the first 30 days.
It is early. It is run by one person. If Stripe's own free retry settings are enough for you, use those instead, and there is a page on this site that says exactly when that is the right call.
See how the pricing works