Dunning Optimization with SendGrid

What Dunning Optimization Actually Requires

Failed payments are not a billing problem. They are a communication problem. Your payment processor flags the card, but what happens in the next 72 hours determines whether that customer stays or disappears permanently.

Dunning optimization means two things: sending the right message before a payment fails (pre-dunning), and executing a precise retry sequence after it fails. SendGrid handles the email delivery side of this with high reliability, but you need to architect the logic yourself or pair it with your billing system.

Here is how to build a working dunning system using SendGrid.

---

How SendGrid Fits Into a Dunning Stack

SendGrid is a transactional and marketing email platform. It does not have native payment retry logic or billing event triggers. What it provides is a delivery infrastructure that is fast, reliable, and programmable.

Your dunning architecture will look like this:

• Billing system (Stripe, Chargebee, Recurly) detects the payment event
• Your backend or a middleware tool listens for webhooks from the billing system
• SendGrid receives an API call and delivers the email

SendGrid's role is mission-critical here. Dunning emails have some of the highest revenue-per-send of any email type. A deliverability failure is not an annoyance — it is lost revenue.

---

Step-by-Step Implementation

Step 1: Set Up Your Sending Infrastructure

Before you send a single dunning email, your SendGrid account needs to be configured correctly.

1. Authenticate your domain using SendGrid's Domain Authentication feature. This sets up DKIM and SPF records in your DNS. Without this, your dunning emails — which often contain payment-related language — are at higher risk of landing in spam.
2. Create a dedicated IP if you are on Pro or higher plans. Dunning emails should be isolated from marketing sends so that a suppression or complaint spike on one does not affect the other.
3. Set up a dedicated subdomain (e.g., `billing.yourdomain.com`) specifically for transactional billing emails. This protects your primary sending reputation.

Step 2: Build Your Email Templates in Dynamic Templates

SendGrid's Dynamic Templates feature is where you build the actual emails. Navigate to Email API > Dynamic Templates in the SendGrid dashboard.

Create separate templates for each stage:

• Pre-dunning alert — card expiring in 7–14 days
• Payment failed — attempt 1 — soft tone, direct link to update payment
• Payment failed — attempt 2 — urgency increases, service impact stated
• Payment failed — attempt 3 — final notice, account suspension warning
• Payment recovered — confirmation email when retry succeeds

Each template uses Handlebars syntax for dynamic data. For example:

```

Hello {{first_name}},

Your payment of {{amount}} on {{charge_date}} was declined.

```

Pass these values via the `dynamic_template_data` object in your API call. Keep the templates simple — one clear call to action per email pointing to your payment update page.

Step 3: Configure Suppression Groups

In SendGrid, go to Unsubscribe Groups under Email API > Unsubscribes. Create a group specifically for billing and dunning emails.

This matters for two reasons. First, it keeps billing communications separate from marketing opt-outs. A customer who unsubscribes from your newsletter should still receive a payment failure notice. Second, it helps you stay CAN-SPAM and GDPR compliant by giving users a clear mechanism to manage preferences.

Mark dunning emails as transactional where legally appropriate. In most jurisdictions, payment failure notifications tied to an existing service agreement qualify as transactional and do not require opt-in.

Step 4: Set Up the Sending Logic via API

SendGrid does not trigger emails on its own. Your backend needs to listen to billing webhooks and fire API requests.

Here is the core flow using the SendGrid v3 Mail Send API:

```python

import sendgrid

from sendgrid.helpers.mail import Mail, To, DynamicTemplateData

message = Mail(

from_email='billing@yourdomain.com',

to_emails=customer_email

)

message.template_id = 'YOUR_DYNAMIC_TEMPLATE_ID'

message.dynamic_template_data = {

'first_name': customer.first_name,

'amount': '$49.00',

'charge_date': '2024-06-01',

'update_payment_url': 'https://yourdomain.com/billing'

}

sg = sendgrid.SendGridAPIClient(api_key='YOUR_API_KEY')

sg.client.mail.send.post(request_body=message.get())

```

Build a retry schedule that aligns with how your billing system retries charges. A common pattern with Stripe's Smart Retries:

• Day 0: Payment fails — send email immediately
• Day 3: Second retry — send second email 1 hour before or after
• Day 5: Third retry — final warning email
• Day 7: Account suspension — send cancellation confirmation

Step 5: Monitor Deliverability With Event Webhooks

SendGrid's Event Webhook (under Settings > Mail Settings) sends real-time data about every email event back to your server. Events include `delivered`, `opened`, `clicked`, `bounced`, `spam_report`, and `unsubscribe`.

For dunning specifically, track:

• Bounces — a bounced dunning email means the customer never saw the notice. Flag this account for alternative outreach (SMS, in-app).
• Spam reports — if customers are marking dunning emails as spam, your messaging tone or frequency needs adjustment.
• Clicks — track clicks on your payment update link as a proxy for intent. Customers who click but do not convert need a different follow-up.

Log these events in your database and use them to decide whether to escalate to other channels.

---

SendGrid Limitations for Dunning

SendGrid is strong on delivery, but it has real gaps in a dunning context.

• No native billing event triggers. You build all the orchestration logic yourself. Platforms like Chargebee or Recurly have built-in dunning workflow builders that do not require custom code.
• No payment retry coordination. SendGrid cannot read your Stripe retry schedule and align send times automatically. You manage that synchronization.
• Limited behavioral branching in email sequences. SendGrid's Automation feature (available in Marketing Campaigns) allows drip sequences, but it is not designed for complex conditional logic based on external payment states. For sophisticated branching, you are better off using your backend to control when each API call fires.
• No built-in A/B testing for transactional templates. You can test subject lines and content manually by rotating template IDs, but it requires more setup than dedicated tools offer.

If your dunning failure rate is high and you need advanced retry coordination, consider pairing SendGrid with a dedicated dunning tool like Churn Buster or Stunning, which handle the retry logic and call SendGrid (or handle their own sending) for email delivery.

---

Frequently Asked Questions

Can I use SendGrid's Automation feature to build the dunning sequence?

You can use Automation under Marketing Campaigns to build a time-based drip sequence, but it is designed for marketing contacts, not transactional billing events. The trigger mechanisms are limited — you can trigger on contact list addition or specific dates, not on real-time billing webhooks. For dunning, the more reliable approach is to control the sequence through your own backend and fire individual API calls to SendGrid at each retry event.

How do I prevent dunning emails from landing in spam?

Three things matter most. First, complete Domain Authentication in SendGrid so DKIM and SPF are properly configured. Second, use a dedicated subdomain for billing email to isolate your sending reputation. Third, keep your email content clear and non-deceptive — avoid excessive urgency phrases that trigger spam filters. Payment failure emails that are plain, direct, and contain one clear call to action consistently outperform heavily formatted marketing-style templates.

What should the pre-dunning email say?

Keep it factual. Tell the customer their card on file expires on a specific date, explain what will happen if they do not update it, and provide a direct link to your billing page. Avoid vague warnings. Specific language converts better — "Your Visa ending in 4242 expires July 31" performs measurably better than "Your payment method may need updating."

How do I handle customers whose dunning emails are bouncing?

When SendGrid's Event Webhook returns a `bounce` event for a billing email, you have lost your primary channel. Flag that account in your system immediately. Your escalation options are SMS notification (via Twilio or similar), in-app banners triggered on next login, or a direct outreach from your customer success team for high-value accounts. Do not retry the email to a hard-bounced address — it will not deliver and will harm your sender reputation.