Designing Refunds and Disputes Before the First Sale

When teams build a new way to take payments, they usually focus on the moment of purchase: the form, the confirmation, the access that turns on afterward. Refunds and disputes get handled later, often in a hurry, after the first customer asks for their money back.

We design refunds and disputes before a checkout launches. They are part of selling, not exceptions to it, and getting them wrong causes some of the most painful problems in payment software. Here is what we think through.

Refunds go back the way the money came

A refund must travel back through the same route the payment took. If a sale went to an organization's own connected payment account, the refund comes from that account. If a charge went through our shared payment hub, the refund goes back through the hub. Knowing the route requires that every payment record clearly states how it was processed, which is one reason we avoid silent fallbacks, as explained in no silent fallbacks in payment code.

Fees are unwound fairly

Payments involve fees: processor fees and, for sales on our platform, a platform fee. When a sale is refunded, the platform fee for that sale is returned and recorded, so organizations do not pay a platform fee on a sale that did not stand. The details are covered in letting customers get paid directly.

Access and records change together

A refund often means access should end: a membership, a course enrollment or a paid add-on. Designing the refund flow first means deciding how those records change along with the money, so a refunded customer does not keep paid access by accident and a customer who keeps access is not refunded by mistake. Partial refunds need their own clear rules about what they affect.

The books stay current

Every refund is recorded in the books against the original sale, including any fees returned. Nobody has to remember to adjust the accounting after a difficult conversation with a customer. We describe that principle in every payment lands in the books.

Disputes have a known process

A dispute, or chargeback, happens when a customer asks their bank to reverse a charge. Disputes follow rules set by card networks and processors, with deadlines and fees. For sales that belong to an organization, the dispute is that organization's responsibility, as it would be without our platform. Our system handles the mechanics: recovering the disputed amount and fee from the organization's account, recording each step, notifying the owner and our administrators and returning funds if the dispute is won.

Designing this in advance means organizations know the rules before they need them.

Uncertain refunds wait for review

If a refund request to a processor ends without a clear answer, retrying could refund twice. Uncertain refunds are held for review rather than retried automatically, and a person confirms what actually happened with the processor before anything else is done.

Permissions for refunds

Refunds move money out of an account, so not everyone who can view orders should be able to issue them. Refund actions are limited to roles with that responsibility and recorded with who issued them and why. Support access alone does not authorize refunds.

Test refunds before the first sale

A refund flow that has never been exercised is a refund flow that will surprise someone. Before a checkout is considered ready, its refund path is tested in the processor's test mode: full refunds, partial refunds where supported, the effect on access and the resulting records. That way the first real refund follows a path that has already been walked, which we discuss in keeping test money and real money apart.

Customers deserve clarity

From the customer's side, a good refund experience is simple: they are told when the refund was issued, roughly when it will appear and what happens to their access. Clear communication prevents many disputes in the first place, because customers who understand what happened rarely escalate to their bank.

Frequently asked questions

How do refunds work for sales on VoVo?

Refunds go back through the same payment route as the sale, any platform fee for that sale is returned and the refund is recorded against the original sale.

Who is responsible for a chargeback?

For sales that belong to an organization, the organization is responsible, as it would be with its payment processor directly. The platform handles the steps and notifications.

Can a refund be issued twice by mistake?

Refunds with uncertain outcomes are held for review instead of being retried automatically, which prevents duplicate refunds.