Braintree's Recurring Billing genuinely retries failed subscription charges on a schedule you configure, and it genuinely fires a webhook every time one of those retries fails — both of those mechanisms are real, working, and reliable. What Braintree does not do, unlike Chargebee, Stripe Billing, or Recurly, is turn that webhook into a customer-facing reminder email by default. The retry logic and the customer-communication logic are two separate systems everywhere else in the industry; Braintree ships the first and leaves the second for you to build.
That is a meaningfully different starting point for a “Braintree dunning” guide than for a Chargebee or Stripe one, and it is worth being precise about it rather than describing a feature Braintree does not actually have. This guide covers exactly what Braintree's Recurring Billing retry configuration does, which webhooks fire and when, what building the missing email layer actually involves, and where a connected recovery tool fits without overstating what it replaces. Revova connects to Braintree directly alongside Stripe, Paddle, Chargebee, and Recurly, so this is a gap we have had to design around ourselves.
Key takeaways
- Braintree's Recurring Billing retries failed subscription charges on a schedule you configure in the Control Panel — the retry mechanics are real and built in.
- Braintree fires a webhook (like a charged-unsuccessfully or went-past-due event) on each failure — but does not send a customer email automatically the way Chargebee, Stripe, or Recurly do.
- Building the missing email layer means writing a webhook handler that looks up the customer and invoice, then sends through your own email service — a real engineering task, not a settings toggle.
- Braintree's retry schedule, like Chargebee's, does not automatically branch by decline reason — a hard decline still consumes retry attempts that were never going to succeed.
- A recovery layer connected to Braintree can take over exactly the missing piece — turning the existing webhook signal into a decline-aware customer email — without replacing Braintree as the processor or subscription engine.
How Braintree Recurring Billing actually handles failed payments
Braintree's Recurring Billing feature lets you set up subscription plans with their own billing cycle, price, and — relevant here — a retry configuration for failed charges. In the Control Panel, you can set the number of times Braintree will automatically re-attempt a failed subscription charge and roughly how far apart those attempts fall. When a charge fails, Braintree runs that configured retry sequence against the same payment method, exactly the way Chargebee's dunning schedule or Stripe Billing's retry logic does.
The difference shows up at the next step. Chargebee, Stripe Billing, and Recurly all pair their retry schedule with a default reminder-email sequence sent to the customer alongside each retry. Braintree pairs its retry schedule with webhooks — events your own systems can subscribe to — but ships no default customer email. The charge gets retried; the customer, absent something else you build, never hears about it until the subscription is cancelled or they notice the product stopped working.
The webhooks Braintree actually fires
Braintree's subscription webhooks are a real, dependable part of its API — this is not a case of Braintree failing to signal that something went wrong. The relevant events for failed-payment handling generally include a charged-unsuccessfully event fired each time a scheduled or retried charge fails, and a went-past-due event fired once a subscription has remained unpaid past whatever threshold you have configured. Braintree's own webhook documentation is the authoritative source for the exact event names, payload fields, and configuration options current to your account and API version.
A webhook is not an email
Where the gap actually costs recoverable revenue
This gap matters more than it might first appear, because the businesses most likely to be running subscriptions on Braintree rather than a dedicated subscription-billing platform are often teams that adopted Braintree first for its payment-gateway strengths (broad payment-method support, PayPal and Venmo, strong developer tooling) and added Recurring Billing later, sometimes without fully building out the customer-communication layer that a purpose-built subscription platform would have shipped by default.
| Platform | Retry schedule | Default customer email |
|---|---|---|
| Chargebee | Configurable in dunning settings | Yes — configurable templates ship by default |
| Stripe Billing | Smart Retries / configurable schedule | Yes — default dunning emails included |
| Recurly | Configurable dunning schedule | Yes — default templates included |
| Braintree Recurring Billing | Configurable in the Control Panel | No — webhook only, email is built separately |
The practical consequence is straightforward: a subscription customer on a Chargebee- or Stripe- billed product who has a card decline typically receives at least one reminder before their access lapses. The same customer on a Braintree-billed product, without additional engineering work, may receive nothing — the charge silently retries in the background, then the subscription silently goes past due or cancels, and the first the customer hears about it is when the product stops working or they notice a missed renewal.
What building the missing email layer actually involves
If you want to keep this entirely in-house rather than adding a connected tool, the shape of the work is fairly well defined, even if the implementation details depend on your stack.
- Subscribe to the relevant Braintree webhooks(charged-unsuccessfully, went- past-due, and cancelled, at minimum) and verify each incoming webhook's signature per Braintree's documentation before trusting its payload.
- Look up the customer and subscription contextthe webhook payload references — typically you need the customer's email address, name, plan, and the amount due, which may require a follow-up call to Braintree's API depending on what the webhook payload includes directly.
- Decide your own retry-and-reminder cadencefor the emails themselves, separate from Braintree's charge-retry schedule — for example, sending a reminder on the first failure, a second on the last retry, and a final notice when the subscription goes past due.
- Write decline-reason-aware copywhere possible — Braintree's processor response includes a decline code, and branching your email copy on it (per our soft decline vs. hard decline guide) meaningfully improves how actionable each message is.
- Send through a transactional email provider and confirm SPF, DKIM, and DMARC are correctly configured for your sending domain — a technically correct pipeline still under- recovers if the emails never clear deliverability checks, covered in full in our dunning email deliverability guide.
- Handle the historical backlog separately — subscriptions that already went past due or cancelled before this pipeline existed will not be caught by new webhook events, since webhooks only fire on new state changes going forward.
What a recovery layer honestly adds on top of Braintree
Braintree remains the payment gateway and the subscription engine — that does not change. What a recovery layer like Revova adds, specifically for a Braintree merchant, is the customer- communication step Braintree's Recurring Billing does not ship: listening for the same subscription webhooks, generating decline-reason-aware email copy automatically instead of requiring custom engineering, and scanning historical subscription data for past-due accounts that predate any webhook pipeline you build.
✓ Pros
- +Braintree's retry mechanics and webhooks already work — no need to change how charges are retried.
- +A recovery layer removes the need to design, build, and maintain a custom webhook-to-email pipeline from scratch.
- +Connecting a recovery layer is typically much faster than an in-house engineering project covering webhook handling, templating, sending, and deliverability.
✕ Cons
- –Building the email layer yourself costs engineering time but no subscription fee, which may be the right tradeoff for a small volume of failed charges.
- –A recovery layer cannot fix deliverability problems in your sending domain by itself — SPF/DKIM/DMARC configuration is still required regardless of who sends the email.
- –Historical subscriptions that already went past due before any pipeline (custom or connected) existed need a specific backfill or historical scan, not just new webhook handling.
Full plan details, including exactly what's included on Starter versus Pro, are on the Revova pricing page.
How to check where your Braintree setup actually stands
- Check your Recurring Billing retry settings in the Braintree Control Panel and confirm the retry count and interval match what you would actually choose today.
- Confirm whether any customer email currently goes out when a subscription charge fails — if the answer is no, that is the core gap this guide describes, live in your account.
- Check whether your webhook endpoint actually verifies signatures and handles retries/duplicates correctly if you have already built custom logic — a webhook handler with the same reliability issues covered in our webhook reliability guide (written around Stripe, but the failure modes — missed, late, duplicate, out-of-order events — generalize to any webhook-based integration, Braintree included).
- Count how many subscriptions are currently past due or cancelled due to payment failure, and multiply by average subscription value for a rough floor on what this gap has already cost.
- Decide deliberately whether to build the missing email layer in-house or connect a recovery tool — either is a legitimate choice, but leaving it undecided by default is the one option that guarantees the gap stays open.
For Braintree's own documentation on Recurring Billing configuration and webhook events, see Braintree's Recurring Billing documentation.
Frequently asked questions
Does Braintree have built-in dunning management?
Braintree's Recurring Billing lets you configure a retry schedule for failed subscription charges directly in the Control Panel — a number of retry attempts and the interval between them — so the retry mechanics themselves are real and built in. What Braintree does not do out of the box is send a customer-facing dunning email when one of those retries fails. It fires a webhook so your own system can react, but the email itself is something you have to build, unlike Chargebee, Stripe Billing, or Recurly, which ship default reminder emails alongside their retry schedules.
What webhook does Braintree send when a subscription payment fails?
Braintree sends subscription-related webhooks such as a charged-unsuccessfully event when a recurring charge fails, and a went-past-due event once a subscription has been unpaid long enough to cross whatever past-due threshold you have configured. These are real, reliable signals — the gap is not that Braintree fails to tell you a payment failed, it is that nothing downstream of that webhook automatically becomes a customer email unless your own code (or a connected tool) is listening for it and generates one.
Why doesn't Braintree send dunning emails like Chargebee or Stripe does?
Braintree was built primarily as a payment gateway and processor — originally for one-off and card-present transactions — with Recurring Billing added as a subscription layer on top, rather than being designed from the ground up as a full subscription-management platform the way Chargebee or Recurly were. That history shows up in the feature gap: the retry mechanics exist, but the customer-communication layer that platforms built specifically around subscription billing include by default was never part of Braintree's core product.
Can I build my own dunning emails on top of Braintree?
Yes, and many merchants using Braintree for subscriptions do exactly this — a webhook handler listens for the relevant subscription events, looks up the customer and invoice details via Braintree's API, and triggers an email through whatever sending service you already use (Postmark, SendGrid, Resend, and so on). It is a real engineering project, not a checkbox in a settings panel, which is the central practical difference from a platform with dunning management built in.
How many retry attempts should I configure in Braintree Recurring Billing?
There is no single correct number, and it depends on your billing cycle length and how many total attempts feel proportionate to your transaction value — the same tradeoff that applies to any rule-based retry schedule, which we cover in more depth in our Chargebee dunning guide (the retry-schedule mechanics there generalize to Braintree's Recurring Billing settings too). Too few attempts spread too close together mostly catch hard declines that were never going to recover; too many spread too far apart leave a subscription in a past-due state for a long stretch before anything decisive happens.
Does Braintree distinguish between soft declines and hard declines?
Braintree's gateway response includes a processor decline code that indicates the reason for the failure, and that code does map to the same soft-decline-versus-hard-decline distinction that applies across the industry — insufficient funds is recoverable with time, an expired or stolen card is not. What Braintree's Recurring Billing retry schedule does not do automatically is treat those two categories differently: by default the same retry count and interval applies regardless of the specific decline reason, so a hard decline still consumes retry attempts that were never going to succeed unless you build logic to skip them.
What happens to a Braintree subscription after all retries fail?
Once Recurring Billing exhausts the configured number of retry attempts, the subscription status changes (commonly to Past Due or Canceled, depending on your configuration), and Braintree fires the corresponding webhook. From that point, nothing in Braintree itself keeps attempting to charge the card or re-engage the customer — whatever happens next, whether that is a manual outreach, a cancellation flow, or a recovery tool taking over, has to be built or added separately.
Is PayPal Braintree the same as PayPal Recurring Payments?
They are related but distinct — Braintree is a full payment gateway (owned by PayPal) that supports cards, PayPal, Venmo, and other methods, with its own Recurring Billing subscription feature and API. PayPal's own separate recurring/subscriptions products are a different integration surface. This guide is specifically about Braintree's Recurring Billing and its webhook-based failed-payment handling, not PayPal's standalone subscription tools.
Can a recovery tool like Revova work with Braintree if Braintree has no native dunning emails?
Yes — this is precisely the gap a recovery layer is positioned to fill for a Braintree merchant. Revova connects to Braintree (alongside Stripe, Paddle, Chargebee, and Recurly) and listens for the same failed-charge and past-due signals Braintree already generates, then handles the part Braintree does not: writing and sending the decline-reason-aware customer email, on a schedule, without you having to build that webhook-to-email pipeline yourself.
How is this different from your Chargebee dunning guide?
The two platforms sit at different points on the same spectrum. Chargebee ships a configurable retry schedule and default dunning emails together, so the gaps discussed in our Chargebee guide are about the schedule's rigidity and blind spots, not about whether emails exist at all. Braintree's gap is a layer earlier and more fundamental: retries exist, webhooks exist, but the customer email step is absent by default and has to be built from scratch or added through a connected tool.
Braintree tells you a payment failed. It won't tell your customer.
Revova connects to Braintree, listens for the same subscription webhooks Braintree already fires, and writes and sends the decline-reason-aware customer email Braintree doesn't. 14-day free trial, no credit card, 30-day money-back guarantee.
Start my 14-day free trial →No credit card · Free Lost Revenue scan · 30-day money-back guarantee
