No. Recurly Recover is designed as a standalone retry engine for merchants using other billing platforms. Combining Recurly Recover with Recurly Subscriptions is not recommended.

Recurly creates an account (without a subscription), a charge invoice, and one or more failed transactions. Billing information is stored and Recurly automatically calculates the next collection attempt date based on your submission.

Yes. While an invoice is in a past-due state, you can cancel all future collection attempts by marking the invoice as failed or paid using the Recurly Invoice API.

The invoice is marked as failed and a webhook event fires. No further retries are made. You can then handle the outcome in your system — for example, suspending access or triggering a win-back campaign.

Mark the in-flight Recurly invoice as successful (if payment was collected) or as failed (to stop the current attempt), then submit a new recovery request with the updated payment method token.

Recurly Recover is not intended to work alongside Recurly Subscriptions — payment recovery is already included in your Recurly Subscriptions plan. For questions about which solution fits your needs, contact Recurly Sales or email [email protected].

No. The Recover API response doesn't include a next-retry date or time. Track retry progress through webhook notifications instead — a new_dunning_event notification is delivered each time an invoice enters or hits a milestone in the retry schedule.

• successful_payment — delivered after a retry transaction is created and successfully collected by the gateway. Expected once per invoice.
• failed_payment — delivered after a retry transaction is created and declined by the gateway. Multiple notifications can fire per invoice depending on the retry window.
• new_dunning_event — delivered when an invoice enters or hits a milestone in the dunning retry schedule, per the schedule's configured event count.
• closed_invoice — delivered when a previously past-due invoice moves to a final state, either by being paid or by exhausting the retry schedule.

You'll receive a new_dunning_event notification marking the schedule milestone, followed by a successful_payment or failed_payment notification confirming the outcome of that retry attempt. A closed_invoice notification is delivered for the invoice's final state, confirming that no further collection attempts will occur.

closed_invoice. It includes a state parameter reflecting either collected/paid or failed/unpaid, and confirms that no other collection attempts will occur.

Use the invoice_id parameter — it's a shared identifier that links all related invoices and their transactions across both object types.

Treat webhooks as triggers, not as the source of truth: verify they're genuine, ignore repeats, and always confirm state through an API query before acting.

• Authenticity — verify the recurly-signature header (HMAC-SHA256) on every JSON webhook using your endpoint's secret key. You can optionally add HTTP Basic Auth and IP allowlisting.
• Duplicates — Recurly resends on delivery failure, so expect repeats. Use the recurly-notification-id header, which stays identical across retries of the same notification, to detect and skip ones you've already processed. Reply with a 2XX within 5 seconds so Recurly doesn't retry unnecessarily.
• Out-of-order events — never act on the payload alone. Use the webhook as a signal to call the Recurly API, compare the result to your local record, and update only if the API confirms a change. This handles delayed retries arriving after the resource has already changed.

Use Stripe test cards configured to trigger declines and successes. Testing both types in your sandbox triggers and delivers the corresponding notifications to your configured endpoint.

• A successful Stripe test card triggers new_dunning_event, successful_payment, and closed_invoice.
• A declining Stripe test card triggers new_dunning_event and failed_payment. If tested with a shortened retry window, closed_invoice also fires once the schedule reaches its final milestone and the invoice automatically updates to a failed state.

Only a user with the Admin permission category can create roles and invite or assign users. Every user granted access — regardless of role — automatically has access to the Recover dashboard.