# Practical Refunds and Chargebacks for Solo SaaS Founders > A practical, non-advice process for deciding on refunds, issuing them cleanly, responding to chargebacks, and keeping records so one person can handle payment disputes without chaos. Source: https://indiefounder.me/finance/practical-refunds-and-chargebacks-for-solo-saas/ Published: 2026-11-09 Solo founders eventually face the request: a customer wants their money back, or a bank reverses a charge without warning. These moments are rare early on but stressful when they arrive because the same person who ships code also has to interpret the payment processor dashboard, update the account, and decide what is fair. A short written policy and a repeatable process turn the event into ordinary work instead of an emergency. This guide covers the practical minimum for early SaaS, AI tools, and developer products that charge via a standard payment processor. It is not legal or financial advice. Rules differ by country, processor, and contract. Use it to organize your own steps and then check them against your processor’s documentation and any local requirements. ## Decide your refund stance before the first request Write a one-paragraph policy that matches what you can actually operate. Common practical positions for micro-SaaS: - Full refund within a short window (for example, 14 or 30 days) if the customer has not used the core feature heavily and asks for a clear reason. - Prorated refund for annual plans if the customer cancels early and you can calculate the unused portion easily. - No refund after the window except for clear product failures that you cannot fix in a reasonable time. Put the policy in your terms of service and link to it from the billing page or help center. State whether refunds are issued to the original payment method and roughly how long the processor takes to post them. Vague language (“we will consider refunds”) creates more work later because every request becomes a negotiation. Illustrative example only: a solo founder offers a 14-day full refund for monthly plans if the user has not generated more than a small number of core actions, and a prorated refund for annual plans with a fixed cancellation fee that covers processor costs. The exact numbers are choices, not requirements. ## Process a refund in a fixed sequence When a request arrives, follow the same steps every time so nothing is forgotten: 1. Confirm the request in writing (email is enough). Note the date, the amount, the plan, and the reason given. 2. Check usage or account status against your policy. If the request is outside the window or the account has heavy use, reply with the policy and offer a partial alternative only if you have decided in advance to do so. 3. Issue the refund through the payment processor’s dashboard or API. Prefer the processor’s native refund action so the original payment method is credited and the transaction is linked. 4. Immediately revoke or downgrade access in your application (or schedule the end of the current period if that is your rule). Do not wait for the money to clear. 5. Send a short confirmation that includes the refund amount, the expected timeline according to the processor, and a link to any remaining data export if the account is being closed. 6. Record the event in your bookkeeping system or a simple spreadsheet: date, customer identifier, amount, reason, processor reference, and whether access was revoked. Most processors show the refund status and the final amount after fees. Note any non-refundable fees so your books stay accurate. If you use a bookkeeping tool, create a separate line for refunds rather than editing the original income entry; this keeps the audit trail clear. ## Handle chargebacks differently from voluntary refunds A chargeback is a bank-initiated reversal. The customer contacts their bank, the bank contacts the processor, and you receive a notification with a deadline to respond. The process is adversarial and the evidence rules are strict. Practical steps when a chargeback notice arrives: - Read the reason code and the response deadline immediately. Deadlines are often short (commonly a few days to a couple of weeks depending on the network and processor). - Gather evidence that matches the reason code. Typical useful items include: the original receipt or invoice, proof of delivery or access logs showing the customer used the product after payment, your terms of service acceptance timestamp, any prior support conversation about the charge, and a clear statement of your refund policy. - Submit the response through the processor’s dispute portal before the deadline. Keep a copy of everything you send. - If the chargeback is for a service the customer already received and used, respond with the evidence. If it is for a clear mistake on your side (duplicate charge, unauthorized access), consider issuing a voluntary refund instead and noting that in the response; some processors allow this to resolve the case faster. - After the outcome is known, update the account (revoke access if the charge was reversed and the customer still has it) and record the final status in your books. Do not contact the customer to pressure them to reverse the chargeback; that can violate processor rules. You may send a neutral note that you received the dispute and are responding with the records you have, but keep it factual. ## Keep records that survive a dispute Chargeback responses and tax audits both need the same underlying facts. Store the following for every paid customer for at least the period your processor and local rules require (often several years): - Original payment confirmation and any invoices you issued. - Terms acceptance record (timestamp and version of the terms). - Usage or access logs for the period covered by the payment (even high-level counts are useful). - All support emails or tickets related to billing. - Refund and chargeback correspondence, including the processor’s case ID. A simple folder structure or a dedicated table in your database is enough at small scale. Export the data periodically so it is not only inside the processor’s dashboard. When a dispute arrives you should be able to assemble the package in under an hour. ## Practical checklist before you process the next refund or chargeback - [ ] Written refund policy exists, matches what you can operate, and is linked from the billing page and terms of service. - [ ] Payment processor account has refund permissions set and you have tested a small refund on a test charge. - [ ] Application code or admin tool can revoke or downgrade access immediately when a refund is issued. - [ ] Bookkeeping system or spreadsheet has a clear place to record refunds and chargebacks separately from new revenue. - [ ] You know where the processor’s dispute portal lives and what the typical response window is for your account. - [ ] Terms of service include an acceptance timestamp that you can retrieve for a given customer. - [ ] Support email or ticket system keeps billing conversations searchable. - [ ] You have decided in advance whether you will ever offer partial refunds or only full ones, so decisions are not made under pressure. ## Common pitfalls - Issuing a refund in the processor but forgetting to revoke access, so the customer continues to use the product for free. - Editing the original income transaction in your books instead of recording a separate refund, which makes tax and reporting messy later. - Missing the chargeback response deadline because the notification went to an email address you rarely check. - Sending an emotional reply to the customer that admits fault in a way that hurts your evidence package. - Offering a long refund window that you cannot afford once volume grows, then having to change the policy after customers have already signed up under the old terms. - Treating every chargeback as a personal insult instead of a process with a fixed evidence list. ## When the simple process is no longer enough Revisit the setup when: - Refund or chargeback volume becomes large enough that manual dashboard work consumes more than an hour or two per month. - You sell in markets with mandatory cooling-off periods or consumer-protection rules that require automatic refunds in certain cases. - You accept payments through multiple processors or marketplaces that have different dispute flows. - Annual or usage-based plans make prorated calculations frequent enough that you want them automated. Until then, a clear written policy, a fixed sequence for issuing refunds, a prepared evidence package for chargebacks, and consistent record-keeping will cover most situations a solo founder encounters. The goal is to make the event boring: look up the policy, run the steps, update the books, and return to building. Payment disputes are part of taking money online. Handled with a short process and clear records, they stay small interruptions instead of open-ended problems.