Connecting an AI Agent to Stripe: Dunning, Recovery and Reconciliation

Automating payment collection with Stripe and AI means putting an agent in charge of the payment flow nobody currently watches: it catches the failed charge the moment it happens, decides whether to retry or contact the customer, writes the message using the real decline reason, reconciles what was collected against your invoices, and escalates to a human only when there's a commercial decision to make. Stripe already gives you the events; what's usually missing is somebody reacting to them.

In a business with subscriptions or recurring payments, the money that leaks isn't in the deals you don't close: it's in the charges that fail and nobody chases. An expired card, an insufficient-funds decline, a payment stuck waiting for authentication. Each of those is recoverable if somebody acts within hours, and practically unrecoverable after three weeks. This guide walks the full agent build on top of Stripe, what it costs, and what it must not touch.

Which Stripe events should the agent watch?

The ones that represent money at risk or manual work pending. Stripe emits events for practically everything that happens in the account, and the temptation to listen to all of them is the first mistake: the agent should react to a bounded set, with a defined action for each.

What separates this from ordinary automation is classification. A traditional flow treats every failed payment the same: retry in three days, send the same email. An agent distinguishes an insufficient-funds decline — solvable by retrying on the right date — from an expired card — only solvable if the customer updates the method — from an issuer decline for suspected fraud, which usually needs the customer to call their bank. Each case wants a different message and a different calendar.

How do you design failed-payment recovery?

By combining Stripe's automatic retries with a communication sequence the agent adapts to the decline reason. Stripe already retries intelligently based on the payment method's history; what the agent adds is the human layer: warn, explain, and make the fix easy.

A sequence that works well for subscription businesses looks like this:

1. Hour 0. The charge fails. The agent classifies the reason. If it's a temporary decline, it doesn't bother the customer yet: it lets the automatic retry do its job.
2. Day 1. If the retry didn't work, first message: neutral tone, the specific reason, and a direct link to update the payment method. No collections language in the first notice.
3. Day 3-4. Second notice on a different channel — if the first was email, now SMS or WhatsApp — shorter, same link.
4. Day 7-10. Notice that service will be affected, with a specific date. This is where most recoveries close.
5. Day 14. Escalate to a person. If the account matters, the call comes from a team member, not one more message.

What matters most is the clean exit: the moment payment lands, the sequence stops. It sounds obvious and it's the most common failure in hand-built dunning flows — the customer pays and keeps receiving reminders for days, which destroys more trust than the recovery gains. The same cadence design applied to B2B invoicing with due dates rather than subscriptions is covered in our guide to AI agents for collections and receivables.

Where does reconciliation fit?

It's the quiet half of the project and the one that gives back the most admin hours. Every payment that lands through Stripe has to match an invoice in your system, and the gap between what Stripe settles and what you invoice is where the manual work accumulates.

Three mismatches always show up. First, fees: Stripe settles net, your invoice is gross, and the difference has to be booked as a cost. At the published standard rate for EEA cards — 1.5% + €0.25 per transaction, checked in August 2026 — that difference is small per transaction and material over a month; for cards issued outside the EEA the published rate rises considerably, so check which one applies to you before trusting your reconciliation. Second, payout batching: Stripe transfers several payments in a single bank deposit, and matching that deposit to individual invoices by hand is tedious. Third, refunds and chargebacks, which appear days later and unbalance periods you'd already closed.

The agent resolves all three by reading both the Stripe detail and the bank statement and proposing the entry, with exceptions flagged for human review. The general approach is the same one we apply to automated bank reconciliation with AI, with the advantage that here one of the two sources is a clean API rather than a PDF statement.

And invoicing?

Stripe issues its own invoices, but they're rarely the ones your accounting needs: series, sequential numbering, complete tax details, withholdings where they apply. The usual build is that Stripe handles collection while your invoicing system issues the fiscal document, with the agent bridging the two.

That bridge does three things: it creates the invoice in your system when payment confirms, links it to the Stripe transaction ID so traceability runs both ways, and handles the awkward cases — partial credits, mid-period plan changes, proration — by flagging them for review rather than inventing a criterion. If your invoicing flow also includes inbound supplier invoices, the extraction and validation approach is in our guide to invoice automation with AI.

What should NOT be automated in collections?

Cutting off service, writing off debt, and responding to a chargeback. All three have direct commercial or legal consequences and none should depend on an automatic rule.

• Suspending a customer's service. The agent can warn that it's about to happen and prepare the decision; executing it belongs to a person, especially on accounts that matter.
• Forgiving, deferring or splitting debt. That's a commercial negotiation. The agent supplies the customer history and the amount at stake; the decision isn't delegated.
• Responding to a chargeback. The agent assembles the file — communications, delivery evidence, accepted terms — and has it ready. Submitting the response belongs to someone who understands the consequences of losing it.
• Retrying without limits. Retrying a charge too many times can count against you with issuers. Retries stay bounded and reasoned.
• Moving money. No agent should hold permissions to issue refunds or transfers without explicit approval.

On spotting suspicious patterns in payments, the line is the same: the agent flags, the person decides. We've covered it in AI payment fraud detection.

How it gets built, step by step

1. Measure the baseline. Failed-payment rate, how many you recover today and in how many days, monthly hours spent reconciling. Without this snapshot you can't prove the improvement.
2. Create a restricted Stripe key with minimum permissions: read events, invoices and customers; write only what's essential. Never use a full-access key.
3. Listen to events on your own endpoint and verify the signature on every notification. This is where most homemade integrations go wrong.
4. Start with failed-payment recovery only. It's the fastest-returning flow and the easiest to measure.
5. Add reconciliation once recovery is stable, and keep it in proposal mode — the agent suggests the entry, a person approves — for the first few weeks.
6. Review at 4-6 weeks against the baseline: recovery rate, average days to payment, and reconciliation hours.

Frequently asked questions

Does this replace Stripe's own recovery tools?

No, it sits on top. Stripe's smart retries and automatic emails cover the standard case and you should keep them. The agent adds what those tools can't: adapting the message to the specific decline reason, switching channel, checking the customer's history in your CRM, and deciding when insisting stops making sense and someone should call.

What does a build like this cost?

An agent scoped to one process — failed-payment recovery, say — builds for €3,000-15,000 in a small business depending on integrations and volume, with annual maintenance at 10-20% of that figure. The factor that moves the budget most isn't Stripe, whose API is excellent, but the invoicing system or ERP the payments have to be matched against.

What happens to card data?

It doesn't pass through the agent, and it shouldn't. Stripe holds the payment credential and your system works with identifiers, not card numbers. That's precisely why this build is viable without taking on a disproportionate compliance burden: the agent sees states, amounts and decline reasons — never the payment instrument.

Does it work if I collect by bank transfer rather than card?

The recovery logic works the same, but detection changes: with no decline event you have to rely on invoice due dates and bank reconciliation to know who hasn't paid. It's a slightly slower build with identical sequencing and escalation mechanics.

How much do you actually recover?

It depends on your customer base and on which decline reason dominates, so be sceptical of anyone quoting a percentage without seeing your data. What is consistent is the shape of the curve: the probability of recovering a payment falls sharply with elapsed days, so the gain comes mostly from reacting sooner, not from chasing harder.