Refund automation

Refund automation is the use of software to decide whether a refund is due under a business’s policy and to issue it through the payment processor, without a person handling each case.

How it works. A typical pipeline has four steps:

1. Request. A customer, a support agent or a customer’s AI agent asks for a refund, with an order reference and a reason.
2. Policy check. Rules decide eligibility: the return window, the item’s state, the amount, and how many refunds this customer or order has already had.
3. Execution. The system calls the processor’s refund API. Processors generally send the money back to the original payment method and allow partial refunds. Stripe, for example, allows several refunds against one charge but never a total above the original amount.
4. Record. The outcome, the rule that allowed it and the processor’s refund ID go into the order history and the books.

Requests outside the rules, such as high amounts or policy exceptions, go to a person.

What can go wrong.

• Duplicates. A retried request can refund twice. Idempotency keys on the refund call prevent that.
• Refund plus chargeback. If the customer has also disputed the charge, a refund pays them twice. Stripe fails a pending refund when the charge is disputed, and recommends responding to the dispute instead.
• Failed refunds. A closed account or cancelled card can make a refund fail and return the money to the merchant, so the customer still needs to be paid another way.

Refunds that prevent disputes. Card networks reward refunding early. Visa’s Merchant Purchase Inquiry lets a merchant answer an issuer’s inquiry by crediting the cardholder before a dispute is raised, and Visa’s dispute process checks for credits already issued so it can treat such disputes as invalid.

Between agents. When a customer’s agent asks a business’s agent for a refund, the business still needs proof that the customer authorized the request and a record both sides can check later. See Refunds, returns and order status between agents. Emissar’s Settle module is planned to run payments and refunds on AP2 and x402, checked against Mandate limits. Status: Planned.

Neighbouring terms. A chargeback is the issuer-side reversal that a timely refund avoids.