Refund Policies That Don't Kill Conversion

Most founders write their refund policy once, shove it into a Terms of Service page nobody reads, and move on. Then the chargebacks arrive, or a one-star review appears saying "stole my money," and suddenly the policy matters a lot.

The question is not whether to have a refund policy. The question is whether yours is doing any work for you, or just sitting there as legal decoration.

Why the Policy Language Itself Is a Product Decision

A refund policy is part of the purchase experience. Users read it, consciously or not, before they tap "Subscribe." A policy that reads like a legal threat signals that you expect disputes. A policy that reads like a fair agreement signals that you stand behind what you built.

This is not a soft, feel-good distinction. It affects conversion. If a user is on the fence about a $9.99 monthly subscription, a sentence like "all sales are final and no refunds will be issued under any circumstances" can tip them out of the funnel. A sentence like "not the right fit? Contact us within 7 days and we'll sort it out" tips them in.

You do not have to be infinitely generous. You have to sound like a person who built something they believe in.

The Three Decisions Your Policy Has to Make

Before you write a single sentence, settle these three things:

1. What is your refund window? Pick a number and publish it. "Contact us" with no time frame is worse than a short window because it creates ambiguity. Ambiguity invites arguments. A seven-day window, clearly stated, closes the argument before it starts.

2. What qualifies? Decide whether you will refund on any request, on documented technical failure only, or somewhere between. Most successful consumer apps land in the middle: refund freely on first purchase, apply more scrutiny to repeat requests, and always refund on a demonstrable bug that blocked core functionality.

3. Who handles it? The App Store and Google Play each have their own refund mechanisms, and they will issue refunds independent of your policy. Know this going in. Your policy governs direct purchases and web subscriptions. The platforms govern in-app purchases, and their rules take precedence over yours.

What the Platforms Actually Do

Apple and Google both have their own refund processes, and both will sometimes approve a user's request without telling you first. The refund just appears in your revenue dashboard.

Apple's App Store allows users to request refunds through reportaproblem.apple.com. Apple decides. You have no direct approval step. Google Play has a similar self-service refund tool, and Google can issue refunds for a window after purchase without requiring developer action.

This means two things for your policy:

First, your policy only directly controls what happens on the web, through Stripe or whatever payment processor you use. If your app is subscription-based and you sell through the app, plan for platform refunds to happen outside your control.

Second, writing a very strict policy does not actually prevent refunds on in-app purchases. It just means users who can't get a refund through you will go to the platform instead, or file a chargeback with their bank. Chargebacks are more expensive for you than refunds.

The Chargeback Math

A chargeback is not just a reversed payment. Payment processors charge a dispute fee on top of the refund amount, and a high chargeback rate can trigger account review or suspension. The threshold is low enough that a bad month of disputed purchases can cause real problems.

A refund, even one you did not technically "owe," is almost always cheaper than a chargeback. Write your policy with this in mind.

How to Write the Policy Itself

Plain language is not just friendlier. It also performs better in support contexts because customers can actually understand what they agreed to. Here is a structure that works:

What you offer. One or two sentences describing your product and pricing model. This anchors the reader before you get to the refund terms.

Your commitment. State what you will do proactively. "If our app has a technical issue that prevents you from using the core features, contact us and we will make it right" costs you almost nothing to say and builds significant goodwill.

The window. State your refund window clearly, in days. "Within 7 days of your initial purchase" is unambiguous. "Recently" is not.

What is not covered. Be specific rather than sweeping. "We do not offer refunds for partially used subscription periods after the 7-day window" is fair and clear. "No refunds for any reason whatsoever" reads as adversarial and will cause users to dispute via their bank instead.

How to request. Give a real email address or a support link. Do not make users hunt for how to reach you. Making the process opaque does not reduce requests; it increases chargebacks.

Platform note. A one-sentence acknowledgment that in-app purchases are subject to App Store and Google Play refund policies. This protects you legally and sets expectations honestly.

A Note on Free Trials

If you offer a free trial, the refund policy question mostly goes away for that user cohort, because they have not paid yet. However, free trials create their own support pattern: users who forget to cancel before the trial ends and then feel surprised by a charge.

The fix is operational, not just policy-level. Send a reminder email before the trial ends. Make cancellation easy and visible in the app. When someone contacts you within a day or two of being charged after forgetting to cancel, refund them without making it a process. That person will often re-subscribe later. The one who gets refused and writes a review will not.

The Review Risk Nobody Talks About

App Store ratings are public and permanent in a way that a single refund is not. A one-star review that says "asked for refund and got ignored" will sit on your product page and affect conversion for everyone who visits after.

The math here is uncomfortable but true: the cost of the review in lost conversions over time will almost certainly exceed the cost of the refund you refused. This does not mean you approve every request. It means you respond to every request with enough humanity that the user feels heard, even when the answer is no.

"We've reviewed your request and unfortunately we aren't able to issue a refund in this case because [specific reason], but here's what we can do instead..." is a sentence that ends disputes. A canned rejection with policy language quoted back at the user is a sentence that starts reviews.

When to Say No

There are legitimate reasons to decline a refund request:

• The user has been an active subscriber for several months. They are requesting a refund on the full billing history, not a recent charge.
• The request is a repeat refund from the same account.
• The account shows clear and heavy usage through the period they are disputing.

In these cases, decline clearly and specifically. Explain what you saw in their account. Offer a partial credit or a discounted renewal if you want to keep the relationship. Do not just cite the policy and close the ticket.

Subscription Apps Have a Specific Problem

Annual subscriptions create the sharpest refund conflicts. A user pays for a year, uses the app for two months, decides it is not for them, and asks for a pro-rata refund on the remaining ten months.

Your policy needs to address this explicitly. Options that work:

Full refund within the window, nothing after. Clear, simple, slightly harsh on edge cases.

Pro-rata refund within a longer window. Fairer to the user, more operational overhead for you.

Credit toward future purchases instead of cash refund. Works if your product has other offerings or tiers. Does not work if the user has already decided to leave.

Pick one. Publish it. Apply it consistently.

Putting It Together

A refund policy that works is short, specific, human in tone, and honest about the platform dynamics. It does not try to prevent every refund through language. It reduces unnecessary refunds through clear expectations and good support.

Write it once, then put it somewhere users actually find before purchase: the pricing page, the checkout flow, the app settings. Revisit it whenever you see a support pattern that the current version does not address well.

The next step is to read your existing policy out loud and ask whether it sounds like a founder who stands behind their product, or a company trying to avoid paying people back. That answer usually tells you what to fix first.