braintree subscription past due grace period exhausted: moves to canceled

Not specified by the original author.

TL;DR

Braintree retries a past-due subscription for the configured grace period, then cancels it automatically when the period exhausts. That is working as designed. To save the subscription, collect payment before the grace period ends; to restart after, create a new subscription. Check the retry settings to make sure the grace period matches your dunning policy.

subscription past due grace period exhausted canceled

Use this when

• A Braintree subscription moved from past due to canceled on its own.
• Failed retries exhausted and nobody intervened.
• You are setting the grace period and retry behavior.

Not for this skill when

• Someone canceled the subscription manually. That shows as a manual cancel.
• The subscription never went past due. Check the billing failures.

Steps

1. ('Confirm the subscription history: past due, retries attempted, then canceled at grace-period end. Verify: the timeline matches the configured settings.', 'Check your retry and grace-period configuration. Verify: the period length matches your dunning policy.', 'If the customer wants to continue, create a new subscription; the canceled one cannot be revived. Verify: the new subscription is active.', 'Collect any outstanding balance from the canceled subscription separately. Verify: the balance is resolved or written off.', 'Alert on subscriptions entering the final days of the grace period so the team can intervene. Verify: the alert fires before cancellation.')

Variant phrasings

braintree subscription canceled past due

Short search.

braintree past due grace period

Settings search.

subscription auto canceled braintree retries exhausted

Lifecycle search.

Compatibility: Braintree subscription API, retry and grace-period settings, all SDK versions.

Why it happens

The past-due state is a waiting room, not a destination: Braintree gives the customer the grace period to fix payment, retrying on schedule. When the period ends with no successful payment, keeping the subscription in limbo forever would accrue phantom billing, so Braintree cancels it. Automatic cancellation is the system refusing to bill a customer who has not paid for the entire grace window.

Edge cases / pitfalls

• A canceled-for-nonpayment subscription cannot be reactivated. New subscription only.
• Outstanding balances survive cancellation. Decide: collect or write off.
• Too-short grace periods cancel good customers over a single bad week. Tune deliberately.
• Dunning emails must escalate before the final retry, not after the cancellation.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2L0DDzf9xmVwzjMXRFt9JQ

Resolved from the public thread: https://vectle.com/posts/pst_2L0DDzf9xmVwzjMXRFt9JQ

Thread query: braintree subscription "past due" grace period exhausted: moves to canceled

TL;DR: Braintree retries a past-due subscription for the configured grace period, then cancels it automatically when the period exhausts. That is working as designed. To save the subscription, collect payment before the grace period ends; to restart after, create a new subscription. Check the retry settings to make sure the grace period matches your dunning policy.

Not specified by the original author.

braintree subscription failed processor declined error

TL;DR

The decline came from the customer's bank, not Braintree: read the processor response code and text on the failed transaction. Map the code (donothonor means the bank said no), ask the customer to contact their bank or use another card, then update the payment method and retry. Do not hammer hard declines with retries.

braintree subscription failed processor declined error

Use this when

• Braintree subscription transactions fail with processor declined
• The decline reason references the processor or the issuing bank
• Retrying the same card keeps failing

Not for this skill when

• Braintree gateway rejections (validation or risk rules, not the bank)
• Processor errors that are actually timeouts (try again, different cause)
• Subscription setup failures before any charge attempt

Steps

Step 1: Read the processor response

Open the failed transaction in Braintree and note the processor response code and text. Expected: you can quote the bank's reason.

Step 2: Map the decline code

Look up what the code means: donothonor, insufficient funds, lost card, and so on. Expected: you know whether it is soft (retryable) or hard (needs a new card).

Step 3: Contact the customer

Tell the customer the bank declined the charge and suggest contacting the bank or using another card. Expected: the customer acts on the actual cause.

Step 4: Update the payment method

Add the new card to the Braintree customer or subscription. Expected: a valid payment method is on file.

Step 5: Retry once, deliberately

Retry the charge a single time on the new method. Expected: the subscription goes active; no retry storms on hard declines.

Tool compatibility

Braintree subscriptions and transactions; processor response codes; Braintree control panel.

Variant phrasings

Variant 1

braintree processor declined subscription

Variant 2

braintree transaction declined donothonor

Variant 3

braintree subscription failed card declined fix

Why it happens

In card processing there are two layers of refusal, and they need opposite responses. The gateway layer (Braintree) rejects for validation, fraud rules, or configuration, and those are yours to fix. The processor layer is the issuing bank saying no, and no gateway setting overrides it. Processor declined with codes like donothonor is the bank's verdict, often for reasons it will not fully disclose: risk scoring, daily limits, or a flag on the account. Retrying the same card is the instinct and it is wrong for hard declines; the only path forward runs through the customer and their bank.

Edge cases / pitfalls

• AVS and CVV rules can turn soft mismatches into declines; check those settings before blaming the bank.
• Hard declines should never be auto-retried aggressively; that pattern looks like fraud testing.
• Some declines resolve when the customer approves the merchant with their bank; suggest that explicitly.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst9sb9V7xSM8VQg1EfASK_g

Resolved from the public thread: https://vectle.com/posts/pst9sb9V7xSM8VQg1EfASK_g

Thread query: braintree subscription failed processor declined error

TL;DR: The decline came from the customer's bank, not Braintree: read the processor response code and text on the failed transaction. Map the code (donothonor means the bank said no), ask the customer to contact their bank or use another card, then update the payment method and retry. Do not hammer hard declines with retries.

Not specified by the original author.

TL;DR

Decide data retention per your policy: keep the data for a grace window or delete it. Keep the record; you will want it for win-back campaigns and for answering "why was I charged" questions.

Steps

1. When this event arrives, the subscription has ended. Period.
2. Look up your user by the subscription id. Revoke the plan's entitlements: downgrade to free, suspend the account, whatever your offboarding is.
3. Decide data retention per your policy: keep the data for a grace window or delete it. Tell the customer which one you did.
4. Mark the subscription canceled in your records with the timestamp. Keep the record; you will want it for win-back campaigns and for answering "why was I charged" questions.
5. Return 200.
6. Deprovisioning on the cancellation request instead of on this event. When a customer cancels with cancel_at_period_end, you get customer.subscription.updated first and deleted only when the paid period actually ends. Cutting access at the request is both wrong (they paid) and a good way to manufacture disputes. The other trap: confusing a paused subscription with a deleted one. Pause is a different state; check pause_collection before you assume.
7. - Subscriptions deleted immediately (no period end) arrive here too. Same handling: the event means it is over now.

• If the customer resubscribes later, that is a new customer.subscription.created with a new id. Do not resurrect the old record; link them by customer.

When to use

You are seeing this: When this event arrives, the subscription has ended. Use this skill when you run into "Stripe event: customer.subscription.deleted, deprovision now, this is terminal".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Stripe's event reference says customer.subscription.deleted occurs whenever a customer's subscription ends. Verified live at https://docs.stripe.com/api/events/types.