foxhound
Sign in

Decline code

Pickup Card

Stripe declined this payment with an instruction that in card-network terms means the card should be physically retrieved from the customer. It is one of the more unusual codes a SaaS merchant will ever see, since it originates from point-of-sale card handling rather than anything relevant to an online subscription charge. Stripe's official definition is: "the customer can't use this card to make this payment (it's possible it was reported lost or stolen)." Under the hood, `pickup_card` is a card-network response code that historically instructed a merchant's payment terminal to physically confiscate the card during a swipe or dip, on the theory that the card is stolen, lost, or otherwise compromised badly enough that the network wants it out of circulation. For an online business with no physical terminal, there is obviously no card to retrieve. What matters is the underlying signal: the network considers this card unsafe to use.

Back to decline codes
pickup_cardNever retried
Draft content: this page's explanatory copy is Pass 3 template writing pending a dedicated content pass. The classification badge above and the recovery behavior described below are live, not draft: both come directly from the recovery engine.

Why it happens

This code is genuinely rare in an online SaaS context, since it is fundamentally a point-of-sale signal. When it does show up on a recurring charge, it usually means the same underlying problem as `lost_card` or `stolen_card`: the card has been reported to the network as compromised, and the network's response code happens to be one built for physical retrieval rather than one of the more common online-decline variants. Treat it as seriously as those two codes.

How to fix it

No. This is a hard block from the card network reflecting a card the network wants out of use. Retrying is pointless and, as with other permanently-blocked-card codes, repeated attempts can draw unwanted attention from the network toward the merchant account making them. Stop retrying the card immediately. Because the underlying signal overlaps heavily with lost or stolen cards, apply the same account review before reaching out to the customer: check how old the account is, whether the subscription started shortly before the decline, and whether other cards on file were also declined. If the account looks legitimate, ask the customer for a new payment method with a plain, factual message. If the account looks new or shows other red flags, hold off on outreach and get a human to look at it first.

How Foxhound recovers it

Fraud and security declines are never retried, silently or otherwise. Foxhound sends a gentle, clearly worded email sequence across 30 days that names the situation plainly and points the customer to their card issuer, rather than repeating the same charge against a flag the issuer already raised.

Questions

  • Card networks reuse the same response codes across in-person and online transactions. `pickup_card` is a network-level instruction tied to lost or stolen cards, and it can surface on an online charge even though there's no terminal to act on the "pickup" part.

  • Yes. It signals the card network considers the card compromised enough that it wanted it physically removed from circulation in an in-person context, which is a strong signal in an online context too.

  • No. The card is not going to work again. The customer needs a different payment method entirely.

  • Yes. Given the overlapping signal, check account age, subscription timing, and other declined cards before reaching out to the customer.

  • No. It's in the fraud bucket, so Foxhound stops automated retries and skips the standard automated email sequence in favor of flagging it for careful handling.

See what this looks like on your account

The free audit shows what Stripe already recovered and what is still dying, no signup required.

Run your free audit