Start with the reason the payment failed, because it decides everything else. An expired card needs a secure update link; a lack of funds may need support, not a reminder; a failure on your side needs no customer contact. The agent sorts the reasons and sends approved messages. People approve suspensions, fee waivers and payment arrangements.
What is the process, and who owns it?
Subscriptions depend on recurring payments, and some fail every cycle. Cards expire or are replaced. Accounts lack funds on the day. Banks decline for fraud checks. Customers cancel a payment instruction without cancelling the subscription. And sometimes the failure is the firm's: a processing error, a bad file, an outage. The response, often called dunning, usually combines automatic retries, reminders, and eventually suspension.
Billing or revenue operations owns the dunning policy and retry schedule. Collections or a financial support team owns customers in difficulty. Customer support owns conversations. Operations or IT owns failures on the firm's side. The agent's job is to send each failure down the right path, without pressure and without ever touching card details, as our guide to the AI support agent that knows when to say no requires.
What does the agent prepare, and what does a person approve?
- Agent, depth 1: reads the failure reason from the payment processor's response: expired card, insufficient funds, declined by the bank, instruction cancelled, technical error.
- Agent, depth 1: checks for firm-side failure. If many payments failed at once with technical codes, it flags a likely incident and pauses customer contact for those payments.
- Agent, depth 3: sends the approved reminder for customer-side reasons, in the sequence your policy sets, with a secure link to update the payment method.
- Agent, depth 1: never takes card details. Customers update cards through the secure link or your app. Can an AI agent update a customer's payment details? explains why the agent stays out of that step.
- Agent, depth 3: answers questions about the failure, the next retry date and what happens if payment is not made, from the billing system.
- Agent, depth 1: watches for difficulty signals: repeated insufficient-funds failures, a customer saying they cannot pay, mention of job loss or illness.
- Agent, depth 2: drafts a support referral with the history, for the financial support team.
- Person, financial support: decides payment arrangements, pauses and fee waivers.
- Agent, depth 2: drafts suspension notices when the sequence ends without payment. A person approves suspension where your policy requires, and always for customers flagged as vulnerable.
- Person, operations: handles firm-side failures and decides whether affected customers need contact or compensation.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Reason | Reads decline code | 1 | Nothing |
| Firm-side | Flags likely incident | 1 | Incident handling |
| Reminder | Sends approved sequence | 3 | Wording and timing |
| Card details | Nothing; sends secure link | 1 | Customer updates |
| Questions | Answers from billing | 3 | Nothing |
| Difficulty | Spots signals | 1 | Nothing |
| Referral | Drafts for support team | 2 | Arrangements and waivers |
| Suspension | Drafts notice | 2 | Approval |
Which controls matter, and what evidence does each leave?
Reason drives path. Evidence: the decline code and the path taken for each failure.
No card data in the conversation. Evidence: transcript scans and secure link completions.
Firm-side failures stop dunning. Chasing customers for your own error causes complaints and may need redress; see handling compensation claims for service failures. Evidence: paused sequences linked to the incident.
Approved wording, no pressure. Reminders state facts and options. They do not threaten or use alarming language. Evidence: template versions sent.
Suspension is a decision. Evidence: approvals for suspensions where required.
What should you measure?
- Failures recovered, by reason and step in the sequence.
- Secure link completion, and where customers drop out.
- Difficulty referrals and how quickly the support team made contact.
- Firm-side failures caught before any customer was contacted.
- Complaints about reminders, read in full.
Where does it usually go wrong?
Everyone gets the same sequence. A customer with an expired card and one who cannot afford the payment receive identical reminders. Branch by reason.
Your own outage triggers dunning. A batch processing failure sends thousands of "your payment failed" messages. Check for patterns before sending. For financial entities in the EU, a failure like this may also need assessing as an ICT incident under DORA; DORA major ICT incident classification for agent failures covers how that works when an agent is involved.
Retries cause fees. Repeated retries on an account without funds can trigger charges from the customer's bank. Keep retry schedules modest and owned by billing, not the agent.
Messages reach the wrong person. A deceased customer's family receives dunning reminders. Respect bereavement and vulnerability markers before any message is sent.
Reminders go to stale contact details. The email on file bounces, so the customer never learns the payment failed until the service stops. The agent should notice undelivered reminders and try the other channels your policy allows.
The agent negotiates. Asked "can I pay half now?", it agrees. Payment arrangements belong to the support team.
Where Pryme fits
In Pryme, decline codes arrive from the payment processor as signed data, which the agent uses to choose the path. Payment details are never in the support agent's role, and arrangements, waivers and suspensions for flagged customers are held for named people. Paused sequences are filed with the incident that caused them.
Questions people ask
Can the agent suspend a subscription automatically when payment fails?
The billing system can apply suspension under your policy. The agent drafts and explains notices; a person approves where your policy requires, and always for vulnerable customers.
Should the agent tell the customer why the bank declined?
It can say what the processor reported, such as "declined by your bank", and suggest the customer contact their bank. It should not guess the bank's reasons.
What about customers who say they never authorised the subscription?
That is a dispute, not a payment failure. Route it to the team that handles unauthorised payment claims.