Chargebee payment method not present for the subscription: dunning retry failed and the account churned
Fixes Chargebee dunning failing with payment method not present for the subscription so retries can run before an account churns. Use when dunning stops at the first retry. Not for a card that is present but declined by the gateway.
TL;DR
Dunning cannot retry a card that is not attached. When Chargebee reports payment method not present for the subscription, the subscription or customer record the retry runs against has no usable payment source, usually after a gateway migration, a card removal, or invoices being created under a second customer record. Reattach a valid payment method through the customers own update flow, resume dunning for the affected invoices, and audit how the method went missing so the next renewal does not walk into the same wall.
Chargebee payment method not present for the subscription: dunning retry failed and the account churnedUse this when
- Chargebee dunning or invoice retry logs name payment method not present
- The customer insists a card is on file, often because a second record holds it
- The failure started after a gateway change, import, or subscription migration
Not for this skill when
- The payment method exists and retries fail with gateway declines, which is a decline strategy problem
- The subscription was intentionally set to be paid offline or by wire
Steps
- Open one failing subscription in Chargebee and inspect its payment source section, the parent customer record, and the invoice the retry targeted. Note whether the method is missing at subscription level, present on a different customer record, or present but unusable because the gateway reference behind it belongs to a retired gateway account. Verify: the exact level where the method is missing is identified for the sample subscription
- Check for duplicate customer records created by imports or self-serve signups. Search by the customers billing contact details and external ids from your CRM, because dunning faithfully retries the record the subscription hangs from, even when the good card sits on a duplicate the customer actually uses. Verify: duplicates are found and merged or ruled out for the affected accounts
- Send the customer a Chargebee hosted payment method update link or direct them through your in-app billing portal, and have them re-enter the card so a fresh gateway-backed source is created. Do not collect card details by email or phone and type them in yourself, and do not copy gateway references between records by hand. Verify: the customer completes the update and the subscription shows a current payment source from the active gateway
- Resume dunning for the affected invoices from the point it stopped, rather than restarting the whole cadence, and confirm the first retry actually reaches the gateway and returns a real gateway response, success or decline, instead of the missing method error. Verify: the retry produces a gateway response and the invoice moves out of the missing method state
- Sweep for every subscription in the same state, filtering subscriptions and unpaid invoices by the missing method condition across the site, prioritising enterprise accounts and invoices nearest the final dunning step where cancellation is automatic. Contact those customers before the last retry date, not after cancellation. Verify: the sweep count, owners, and outreach status are recorded per affected account
- Fix the upstream cause you found, such as an import template that created subscriptions without payment sources or a gateway migration step that dropped vault references, and add a pre-dunning check that flags subscriptions with an upcoming renewal and no payment method thirty days ahead. Verify: the upstream fix is shipped and the thirty day warning list generates in a test run
Why it happens
Dunning is an automated retry engine over stored payment sources. If the source was never migrated, was removed during a card cleanup, or lives on a duplicate customer record, the engine has nothing to retry and the subscription rides the dunning timeline to cancellation even though the customer never refused to pay. The error is precise, the method really is absent where the retry looks for it, but the reason it is absent is an upstream records problem.
Compatibility: Chargebee subscriptions, payment sources, dunning management, and hosted pages, in current Chargebee versions, with connected payment gateways.
Variants and edge cases
Chargebee dunning retry no payment method on file
['The dunning-first phrasing. Separate missing method from declined method early, because the outreach, the fix, and the owner are completely different.']
payment method not present Chargebee subscription after migration
['The migration variant. Gateway vault references rarely survive a gateway switch untouched, so sample migrated subscriptions for usable sources before the first renewal wave.']
customer card on file but Chargebee says none
['The duplicate-record variant. Believe both sides, the customer does have a card and the subscription does not, because they are looking at different records.']
Edge cases to work through before you close the incident:
- Some plans legitimately pay by invoice and wire. Exclude offline payment subscriptions from the sweep or you will alarm good enterprise accounts.
- A card can be present but expired or replaced at the issuing bank. If the retry returns a gateway decline after reattachment, switch to decline handling rather than repeating the missing method steps.
- Chargebee test sites and live sites hold separate records. Confirm you are sweeping the live site before reporting counts to leadership.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_09wrRSG8BudGs9BTx97-xw