How to automate refund processing: the policy is the hard part

Issuing a refund takes one API call. Everything difficult about refund processing sits before that call: whether this one should be granted, under which rule, and what happens to the rest of the customer's relationship with you.

Most teams discover when they try to automate this that they do not have a refund policy — they have a set of habits held by three experienced support people, who each apply them slightly differently. Automation forces that to become explicit, which is uncomfortable and is also the most valuable part of the exercise.

What we'll cover

• The policy you did not know you had
• What the law requires regardless
• The cases that can be fully automatic
• Building it with CodeWords
• What must reach a person
• Abuse, and how not to overcorrect
• The message matters more than the money
• What to do about the subscription underneath
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

The policy you did not know you had

Write down what currently happens before designing anything, by reading the last two hundred refunds and the reasons given.

Expect inconsistency. The same request will have been approved and declined depending on who handled it and what kind of day it was.

Find the real thresholds. There is usually an unwritten amount below which nobody argues, and it is worth knowing what it is.

Identify the categories: a billing error, a duplicate charge, a cancellation inside a window, dissatisfaction, and a goodwill gesture are five different decisions.

Decide what changes with tenure and value, because it already does informally and automating it without deciding makes it arbitrary.

Publish the result. A written policy is better for customers and for the support team than a consistent-ish practice nobody can point to.

What the law requires regardless

Consumer protection rules vary by jurisdiction, and in several the customer has statutory cancellation rights that your policy cannot reduce.

Subscription cancellation rules are specific in some markets, including what must be refunded on cancellation and how easily cancellation must be available.

Digital goods often have different treatment from physical ones, sometimes turning on whether the content has been accessed.

Card network rules apply too and are not the same as the law — a chargeback follows the network's timetable regardless of your policy.

Your terms cannot override statute, so an automation enforcing your terms strictly may be enforcing something unenforceable.

Get the position for your markets from whoever advises you, once, and encode it as a floor the automation cannot go below.

The cases that can be fully automatic

Duplicate charges, detectable and unambiguous, which should be refunded without anybody asking.

Billing errors you can verify — a charge after cancellation, a wrong amount, a failed provisioning.

Cancellation inside a stated window, where the policy is clear and the answer is not a judgement.

Small amounts below your threshold, where the cost of a human decision exceeds the amount.

Statutory rights cases, which should be granted immediately since the outcome is not optional.

Anything where declining would lose a chargeback, because contesting and losing costs the amount, the fee, and the relationship.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, so the payment processor, the support desk, the subscription system and the CRM can meet in one workflow.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: the categories, the thresholds, what auto-approves and what escalates.
3. Authorize the connections — the payment processor, the helpdesk, and the subscription or order system.
4. Describe the exceptions: a high-value customer, a repeat requester, a disputed charge already in progress, an amount above the threshold.
5. Run it in recommend-only mode alongside the support team and compare its decisions against theirs for a fortnight.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

What must reach a person

Amounts above the threshold, whatever you set it at.

Anything where the customer is upset rather than merely transacting, since the refund is not the thing that will resolve it.

A repeat requester, which needs a judgement about the relationship rather than a rule.

Partial refunds, which are almost always a negotiation and rarely a calculation.

Anything touching a dispute already in progress, where an uncoordinated refund can make the dispute harder to resolve.

Cases the policy does not cover, which should be visible as a category rather than forced into the nearest matching rule.

Abuse, and how not to overcorrect

A small number of customers account for most refund volume, and identifying them is straightforward.

Look at the pattern, not the instance — frequency, timing relative to usage, and whether the same reason recurs.

Most repeat refunders are not abusers. They are frequently customers with a real recurring problem you have not fixed, which is the more valuable finding.

Escalate rather than block, since automatically declining a legitimate customer generates a chargeback and a public complaint.

A chargeback costs more than the refund, always, which should inform every marginal decision.

Fix the cause. If one product or plan generates disproportionate refunds, that is product information and it is more useful than any tightening of the rules.

The message matters more than the money

Respond quickly, since speed does more for the relationship than the amount does.

Say what will happen and when — the amount, the method, and the realistic timeline for it to appear.

Set the timing expectation honestly. Card refunds take days to appear, and a customer who was not told this contacts you again.

Explain a decline in terms of the policy, with the specific reason, not a generic statement.

Offer the alternative where there is one — credit, an extension, a different plan — which frequently resolves the underlying issue better than money.

Never make the customer ask twice. The second request is where a refund becomes a complaint.

What to do about the subscription underneath

A refund on a subscription is rarely only about the money, and an automation that issues one without touching the subscription leaves the customer in an incoherent state.

Decide whether it cancels. A refunded period with the subscription still active means the customer is charged again next month for something they just asked to be refunded.

Handle access explicitly. Refunding a period and leaving access open is a decision, and so is revoking it immediately — but it should be a decision rather than whatever the code happens to do.

Prorate consistently. Mid-period cancellations need one rule applied every time, not a calculation somebody does differently each occasion.

Watch the upcoming invoice, since a refund issued days before a renewal is almost certainly meant to prevent that renewal too.

Record the cancellation reason alongside the refund reason, because they are usually different and the pair is more informative than either.

Offer the pause. For subscriptions, a pause resolves a meaningful share of refund requests better than a refund does, and it is almost never offered.

Making it survive

Make it idempotent. A double refund is worse than a slow one and is entirely possible with retried webhooks.

Check the current state before acting, since the charge may already be refunded or disputed.

Handle partial refund arithmetic carefully, including tax, and refuse rather than guess when the numbers do not resolve.

Cap the automated total per day, so a bug cannot refund everything before anybody notices.

Report the outcome: refunds issued, escalated, declined, and the value and rate by reason.

Limits worth knowing about

Refund windows exist at the processor level and a charge past the window needs a different mechanism.

The original fee is usually not returned, so a full refund costs more than the refunded amount.

Refunds can fail — a closed card, a changed account — and the failure handling is a real path rather than an edge case.

Timing is outside your control once issued, which is why the expectation must be set honestly.

Partial refunds interact with tax in ways that vary by jurisdiction and are worth confirming rather than deriving.

What to build first

Automatic refunds for duplicate charges and verifiable billing errors. There is no judgement involved, the customer is unambiguously right, and these are the cases where a delay does the most damage to trust for the least defensible reason.

Two habits make the difference. Cap the automated daily total from day one, since the failure mode of this particular automation is expensive and fast. And review the refund reasons monthly as product information rather than as a support metric, because a plan or product generating disproportionate refunds is telling you something no amount of policy tightening will fix.

Frequently asked questions

What is the hardest part of automating refunds?

Deciding whether to grant one. Most teams find they have no written policy, only habits held by a few experienced people who each apply them differently. Automation forces that to become explicit.

Which refunds can be fully automatic?

Duplicate charges, verifiable billing errors, cancellations inside a stated window, amounts below your threshold, statutory rights cases, and anything where declining would lose a chargeback.

Which refunds need a person?

Amounts above the threshold, upset customers, repeat requesters, partial refunds, anything touching a dispute in progress, and cases the policy simply does not cover.

Can my refund policy override consumer law?

No. Statutory cancellation and refund rights exist in several jurisdictions and your terms cannot reduce them. Encode the legal position as a floor the automation cannot go below.

How should I handle repeat refund requesters?

Escalate rather than auto-decline. Most are not abusers — they are customers with a real recurring problem you have not fixed, which is the more valuable finding. Auto-declining a legitimate customer produces a chargeback and a complaint.

Is a chargeback worse than a refund?

Always. It costs the amount, the dispute fee, and the relationship, and it counts against you with the card networks. That should inform every marginal decision.

What matters most in the refund message?

Speed, and an honest timeline. Card refunds take days to appear, and a customer who was not told that will contact you again — which is where a refund becomes a complaint.

What is the most important safeguard?

A cap on the automated daily total. The failure mode here is expensive and fast, and a cap is the difference between a bug and an incident.

Should a subscription refund also cancel the subscription?

Decide it explicitly. Refunding a period while leaving the subscription active means charging the customer again next month for what they just asked to be refunded, which is how a resolved ticket becomes a chargeback.

Is there an alternative to refunding a subscription?

A pause. It resolves a meaningful share of requests better than a refund does and is almost never offered, largely because nobody built it into the flow.

How do I find out what my current refund policy is?

Read the last two hundred refunds and the reasons given. The real thresholds and categories are in there, along with the inconsistencies — the same request approved by one person and declined by another.

Related reading

• Automating Stripe to accounting
• Zendesk and CodeWords
• Automating product feedback categorisation