> For the complete documentation index, see [llms.txt](https://docs.roadmap.so/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roadmap.so/subscriptions/managing-subscriptions/marking-a-subscription-as-failed.md). # Marking a subscription as Failed When and how to manually move a subscription contract into the Failed status — and how it's different from waiting for dunning to exhaust. Mark as Failed is an admin-only override that immediately moves a subscription contract into the Failed status without waiting for dunning to play out. It's a sharp tool. Most stores never use it — they let dunning run its course. But when you need to stop billing on a contract right now and you don't want pause/cancel for the situation, this is the right action. This article covers when to use it, how it differs from related actions, and how to recover a contract you've manually failed. #### Where to find it 1. Open the contract from Subscriptions → Manage Subscriptions. 2. Click Manage subscription ▾ in the contract header. 3. Choose Mark as Failed (shown in red, second-to-last in the menu). 4. Confirm. The contract status flips to Failed immediately. No further automatic billing runs. #### When to use Mark as Failed **You know the customer's payment method is bad and you don't want to wait for retries** If you've already confirmed (via support chat, declined-by-issuer email, etc.) that the card on file won't work, there's no value in letting dunning try three more times. Mark as Failed stops the retries and signals to your team that this contract needs intervention. **Incident response** If a payment processor is down or you've discovered a billing data error, you may want to manually fail a batch of contracts to stop charges going through, then recover them once the underlying issue is fixed. **Customer requested a stop and pause/cancel don't fit** Pause is recoverable by the customer themselves; cancel is terminal and untraceable. If you specifically want a contract that requires merchant intervention to come back online — for example, a fraud-flagged contract pending verification — Mark as Failed creates that gate. #### When not to use Mark as Failed * As a substitute for cancel — Failed contracts still appear in your reporting as pending recovery. Use Cancel Subscription if the customer is gone. * To temporarily pause billing — use Pause Subscription instead. Pause is recoverable by the customer; Failed isn't. * For ongoing dunning recovery — let dunning run. The retry logic exists for exactly this situation. #### How Mark as Failed differs from automatic Failed Both end up at the same place — contract status Failed, no further automatic billing — but the path is different. | | Automatic Failed (dunning exhausted) | Manual Mark as Failed | | ------------------------- | ---------------------------------------------------- | --------------------------------- | | Triggered by | Last dunning retry fails + 1-hour grace passes | Merchant action | | Activity Timeline records | Dunning exhaustion + status change | Status change with merchant actor | | Billing Attempts log | Full history of retry attempts | Empty (no retries were run) | | Recovery path | Same: update payment method → Order Now → Reactivate | Same | If you're recovering a manually-failed contract, the Activity Timeline will show you as the actor of the failure — useful for auditing later. #### Recovering a manually-failed contract Same as recovering an automatically-failed one: 1. Update the customer's payment method using one of the three options in the Update payment method modal — see [Updating a customer's payment method](/subscriptions/managing-subscriptions/updating-a-customers-payment-method.md). 2. Run Order Now to verify the new payment method works — see [Manually charging a subscription (Order Now)](/subscriptions/managing-subscriptions/manually-charging-a-subscription-order-now.md). 3. Once Order Now succeeds, Manage subscription ▾ → Reactivate to bring the contract back to Active. #### What customers see Customers don't see a "this was manually marked failed" message — they see a Failed-status contract on their account page, the same as if dunning had exhausted. If you've configured failure notifications, they receive that email. If the situation is one where you want the customer to know what's happened and what to do, follow up with a personal message — Mark as Failed itself doesn't communicate context. #### Common scenarios **"I marked the wrong contract as Failed"** Recover it with the standard flow: update payment method (no change needed if the method was fine), Order Now to confirm, Reactivate. The accidentally-failed status is logged in the Timeline, but the contract can be brought back to Active without losing data. **"The customer says they were 'cancelled' but the contract shows Failed"** Failed and Cancelled are distinct. Failed means billing stopped pending merchant action; Cancelled means billing stopped permanently. If the customer's intent was Cancel and you accidentally marked Failed, you can either Reactivate then Cancel cleanly, or leave the contract Failed and let it sit (it won't bill). #### Related guides * [Failed payment retries](/subscriptions/pricing-and-billing/failed-payment-retries.md) * [Updating a customer's payment method](/subscriptions/managing-subscriptions/updating-a-customers-payment-method.md) * [Manually charging a subscription (Order Now)](/subscriptions/managing-subscriptions/manually-charging-a-subscription-order-now.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.roadmap.so/subscriptions/managing-subscriptions/marking-a-subscription-as-failed.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.