Yety

The AI decides, the merchant executes: legal checks on every refund

Yety is a payment-tooling prototype for small businesses. Merchants use it to set up instalment plans and savings goals for their customers, track the payments coming in, and handle money going back out again — refunds and redemptions. That last part is where small businesses get hurt, so it's where we put AI to work.

The problem: refunds are guesswork

When a customer asks for their money back, a small merchant has to answer a legal question without a lawyer. Are they obliged to refund in full? Can they offer a credit instead? Is the customer still inside a cancellation window? Does their own refund policy hold up against consumer-protection law?

The answer depends on where the customer is. Consumer-protection rules differ by jurisdiction, and a merchant selling into more than one market can't keep them all in their head. Get it wrong one way and you've given away money you didn't owe. Get it wrong the other way and you're facing a chargeback, a complaint, or a dispute you can't defend.

The capability: a decision API, not a chatbot

We integrated Stealth, an AI legal-decision API, directly into the refund and redemption workflow.

When a merchant starts a refund or redemption on a payment plan, Yety assembles the case automatically from data it already holds: the customer's request, the relevant dates, the product, the transaction amount, the merchant's policy, the jurisdiction, and any evidence attached. That case goes to Stealth for a legal assessment.

What comes back is not a paragraph of chat. Stealth returns one of ten fixed, structured outcomes — for example REFUND_REQUIRED, PARTIAL_REFUND, CANCELLATION_ALLOWED, CREDIT, REPLACEMENT or ESCALATION. Because the set of answers is fixed, our product can rely on it: every outcome maps to a known next step in the interface, and there's no free text to interpret before anything can happen.

Alongside the outcome, Stealth returns:

Plain-language reasoning the merchant can actually read.
The legal authority it relied on.
The facts it used, and the facts that were missing.
Merchant-policy considerations — where the merchant's own policy helps or conflicts.
An audit ID and rule version, so the decision can be traced later.

Keeping assessment and execution apart

The most important design decision was a simple rule: the AI decides, the human executes.

Stealth assesses the case. It never moves money. Nothing happens until the merchant has seen the full decision — outcome, reasoning, authority, facts — and clicked an explicit "Confirm and execute" gate.

If Stealth returns PARTIAL_REFUND, it tells the merchant a partial refund is required, but the merchant sets the amount themselves. The AI never specifies a sum and never initiates a transfer on its own.

We kept these apart for two reasons. First, the merchant is accountable for their business, so they should make the final call. Second, it keeps the failure mode safe. If an assessment is wrong, a person reads it before anything irreversible happens, and money stays where it is until they act.

A paper trail on every refund

Every action the merchant executes is linked back to the Stealth audit ID. Each refund or redemption carries its own record: which outcome was returned, under which rule version, relying on which facts and legal authorities.

All of this is surfaced to the merchant in the product, not hidden in a log. If a customer comes back months later, or a chargeback lands, the merchant can see exactly what was assessed and why they acted as they did. Recording the rule version matters because rules change, and a decision should be judged against the rules that applied when it was made.

Honest limits

This is a decision-support layer, not legal advice. It gives merchants a structured, traceable view of where they probably stand, which is a long way better than guessing, but it doesn't replace a solicitor for a genuinely contested case. That's what ESCALATION is for.

It's also only as good as the case it's given. When facts are missing — no delivery date, no evidence of the fault the customer describes — Stealth says so rather than assuming. That tells the merchant what to go and find before they act.

What's next

Two improvements will make the case stronger before it ever reaches Stealth:

Pulling in real merchant policies. We'll take each merchant's actual published terms, so policy considerations reflect what they really told their customers.
Automating evidence gathering. Instead of relying on the merchant to attach evidence, we'll collect what Yety already knows — payment history, plan changes, customer messages — so fewer facts come back missing.