payinOPERATIONS MANUAL

Latest articles

A detached Stripe PaymentMethod cannot be restored: remove, recollect and reset defaults

Decide what to do before removing a saved card, stop reattaching a detached PaymentMethod, and verify replacement setup and intended default relationships separately.

Published; sources checked:

Stripe PaymentMethods and saved-card removal for Customer-based integrations; subscription replacement routes are subject to account and payment-method eligibility.

Detach is a destructive boundary, not a reversible unlink

Stripe states that detaching a PaymentMethod is permanent and irreversible: the object cannot be used for payments or attached to a Customer again.[1] Therefore, a saved-card removal workflow must not offer an “undo” that simply calls attach with the old identifier. Recovery means selecting another usable method or collecting payment details again, not resurrecting the detached object.

This guide addresses confirmed detachment. Editorial recommendation: inspect the removal operation and its result before diagnosing a missing card. A card disappearing from your interface is not, by itself, evidence that detach occurred. Do not turn an ambiguous support report into another destructive API request.

Decide what the customer intends before removal

Stripe warns that removing a saved method from the Payment Element also removes it from an ongoing subscription using that method. It recommends disabling saved-method removal there and managing methods on an account-settings page that shows existing subscriptions.[3]

  1. Ask whether the request means replacing a card, removing it without replacement, or ending a subscription. Treat these as separate business decisions.
  2. Inspect the customer, affected subscriptions, current defaults and any unresolved invoices. Record which relationships require a decision rather than assuming every subscription should receive the same replacement.
  3. For a requested replacement, complete and verify the new setup and intended default assignments before detaching the old object. This is an editorial safeguard, not a documented atomic Stripe operation.
  4. If the customer declines a replacement, explain the billing impact and route the subscription decision separately. Do not keep charging a removed method or claim removal itself settles an invoice.

After confirmed detachment, stop trying to reattach

The old identifier is no longer a recovery candidate under Stripe’s detach rule.[1] Editorial recommendation: remove it from selectable application state while retaining an access-controlled audit reference. If the customer wants to use the same physical card, route them through secure collection again; do not describe this as restoring the old PaymentMethod, and do not collect card details through support messages.

For a new PaymentMethod intended for future payments, Stripe recommends a SetupIntent or a PaymentIntent with setup_future_usage. Calling attach without that preparation does not optimize future use and can increase later declines and payment friction.[2] Choose an approved collection flow, let the customer complete its required steps, and verify the resulting method rather than copying the detached identifier into a default field.

Restore the intended default, not every default

Stripe documents setting Customer invoice_settings.default_payment_method to the PaymentMethod identifier for the customer’s invoice default; subscriptions can also specify their own default_payment_method.[2][4] Editorial recommendation: record the intended scope and read back each changed relationship. Attaching a replacement and assigning it as a default are separate acceptance checks.

For an automatically billed subscription, a Dashboard payment-update link can collect a replacement card. The link updates only that subscription, not the customer default; the subscription must be active, past_due or trialing. Each link is single-use and expires after 30 days if unused. This route is unavailable for manually sent invoices and is card-only.[4] If those conditions do not fit, use another supported collection workflow rather than promising that this link repairs the whole account.

A fictional recovery decision

A customer removes card A, then asks support to undo the removal because a renewal is approaching. In this illustrative scenario, the operation record confirms detach. Support must not retry attach on A. It requests secure recollection, obtains a new method B through the approved flow, and verifies the intended subscription now references B. If the customer also requests a customer-wide invoice default, that is a separate assignment and verification. The case note distinguishes “replacement configured” from “invoice paid.” This example was not executed against Stripe.

Boundaries and completion evidence

  • Proposed completion record: confirmed removal, replacement setup result, affected default relationships and unresolved billing actions.
  • Do not interpret detachment as proof of comprehensive personal-data erasure; the cited API page establishes payment usability, not a retention or legal-erasure guarantee.
  • Payment-method availability and subscription restrictions still require account-specific checks.[4] This is public-document research, not a live payment test, collection guarantee or PayIn feature claim.

Sources and dates

Official documentation supports technical behavior; community questions demonstrate qualitative demand only. Retrieved and checked on 2026-09-22. Retrieval is not publication. Unstated dates remain unknown. This is documentation research, not a live-account test, PayIn feature claim, or legal, tax or financial advice. Account eligibility and regional availability require separate confirmation.

More guides

All guides