From the customer’s question to one outcome, with nobody waiting.
The assistant reads the request, the platform checks your policy and acts, and your team gets only what the policy leaves to people. Here is who does what, and in which order.
One outcome, on record
Executed at your provider once, handed to your team with the case written up, or denied with a reason the customer reads.
€29.00 refunded to Visa •• 4242
Three roles, kept apart on purpose.
The model is good at language and bad at being trusted with money, so it is given no way to move any. Each role has its own job.
The assistant
- Understands what the customer wants, in their words
- Asks when something is unclear
- Writes replies in your tone and language
Never Calls a payment provider, writes to your records or decides an outcome.
The platform
- Verifies who the customer is
- Reads the payment from your provider
- Checks your policy and records each action once
- Executes at the provider and reads the result back
Never Waits on a person, or lifts a limit you set.
Your team
- Publishes and tunes the policy
- Gets the cases the policy leaves to people, written up
- Can act beyond the policy with a second factor
Never Has to approve a routine refund.
Ten checks, in the same order every time.
The platform evaluates your published policy against stored facts, never against what the customer claims. The first check that fails decides the outcome, and the decision keeps the policy version and every result.
Your fallback is what you choose for requests outside the automatic rules: deny with a reason, or hand to your team.
- 01StopsYour kill switch, an operator hold or a global stop.If it failsTo your team
- 02IdentityThe customer is verified and bound to this payment.If it failsAsked to verify
- 03Payment stateNot already refunded or disputed, its connection live, its currency covered.If it failsDenied or to your team
- 04ReasonThe reason is one your policy refunds automatically.If it failsYour fallback
- 05WindowThe payment is inside your refund window.If it failsYour fallback
- 06AmountWithin what is still refundable, and within your limit for that currency.If it failsDenied or your fallback
- 07Customer velocityThis customer is under your refund count for the period.If it failsYour fallback
- 08Workspace velocityYour whole workspace is under its hourly and daily caps.If it failsTo your team
- 09Circuit breakerRefunds are not running unusually high right now.If it failsTo your team
- 10Your rulesYour own conditions, and your own decision service if you connect one.If it failsWhat the rule says
Every request ends in exactly one of three outcomes.
Executed
Done at your provider once, and confirmed from the provider’s answer.
“€29.00 refunded to Visa •• 4242. It can take 5 to 10 days to show.”
Denied, with a reason
A reason written from your policy, never an improvised answer.
“This payment was already refunded on 2 Nov, to Visa •• 1881.”
Handed to your team
A ticket with the summary, the payment, the facts and the check that stopped it.
Ticket #2087 · €640.00 above the €100 limit · in your queue
Every decision can be opened and explained.
Each case keeps who asked, through which channel, the policy version, the facts each check read and the provider’s result.
- The check that decided, in plain words
- The action’s key and the provider’s reference
- Replay any past request against a draft policy
- An audit trail of every change to the policy
Start with low limits. Raise them when the record shows it works.
Start in test mode, run your policy against your own history, and go live when the results meet your standards.
- 1A test workspace on your provider’s test mode
- 2Your past requests replayed against your policy
- 3Live with low limits, raised as the record allows