By Greg Nowak. Updated 2 November 2026.
An AI assistant can save support staff time by finding an order, checking the refund policy and preparing a response. Before it moves money, though, someone needs to approve a specific payment and amount. That decision must survive a delayed review, a worker restart and a retry after a lost connection.
For a business owner or operations lead, the useful question is: can the system show exactly what was approved, execute it once and explain what happened? Here is how I would structure that workflow around Stripe and an AI assistant.
Put approval where the refund happens
A prompt saying “always ask before issuing refunds” expresses an instruction. Your application still needs to enforce it. Keep payment credentials on the server and expose a narrow refund function that checks authorization and the approved proposal before calling Stripe.
OWASP’s guidance on excessive agency recommends limiting tool functionality and permissions, requiring human approval for high impact actions, and enforcing authorization in downstream systems. For this workflow, every route to the refund function needs the same checks, including background jobs and manual retries.
If you use the OpenAI Agents SDK, its human review mechanism can pause a sensitive tool call before execution. In JavaScript, a function tool can declare needsApproval: true. Your application presents the pending action to a reviewer, records their decision and resumes the saved run state. Never approve all interruptions automatically in production; approval must follow an actual authorized decision.
Make the approval screen worth reading
“Refund this customer” gives a reviewer too little to work with. Show the customer and order, the associated Stripe Charge or PaymentIntent, original payment, previous refunds, remaining refundable amount, proposed amount, currency and reason. Link to the underlying order so staff can check the evidence without reconstructing it from chat.
Separate the assistant’s explanation from verified payment facts. Your order system and Stripe supply the payment references and amounts. The assistant can summarize the customer’s request and suggest a resolution.
Stripe’s refund API supports full and partial refunds against a Charge or PaymentIntent. Its amount is a positive integer in the currency’s smallest unit, limited to the remaining refundable amount. For example, DKK 250.00 becomes amount=25000. Use currency-aware conversion rather than assuming every currency has two decimal places.
I would send an explicit approved amount even for a full refund. Store an immutable proposal version containing the payment target and execution parameters. If anyone changes the amount, target or other material terms, create a new version and request approval again.
Give each stage an owner and a stopping point
Agree who can approve refunds, any value limits, who covers absences and when an unanswered proposal expires. For agencies managing several shops, bind each proposal to the correct client and payment account too.
| Stage | Owner | Required control |
|---|---|---|
| Prepare | Assistant | Draft a proposal; make no payment call. |
| Validate | Application | Check order ownership, payment account, policy and refundable balance. |
| Review | Authorized staff | Approve or reject the exact proposal version. |
| Execute | Payment worker | Recheck approval and current payment state; claim the proposal once. |
| Reconcile | Integration and operations | Store the refund ID, follow its status and investigate exceptions. |
Immediately before execution, check that approval is still valid and the payment remains eligible. If another staff member has refunded part of it meanwhile, stop for review. The assistant should never silently reduce the amount or select another payment.
Make retries repeat the same request
A connection can fail after Stripe receives a refund request. Treat that outcome as uncertain. Generating another request with a fresh key can create an additional partial refund if enough balance remains.
Persist one unique idempotency key for each approved operation before sending it. Reuse that key and identical parameters when retrying. A repeated click or worker restart must load the existing operation. An atomic database transition from approved to executing prevents two workers from independently starting it.
For the API v1 refund endpoint, Stripe’s idempotency documentation says it saves the initial response once execution starts, including 500 errors. The same key does not turn a saved error into a fresh attempt. Keys may be pruned after at least 24 hours; reusing a pruned key creates a new request.
Keep your own durable operation record. If the result remains uncertain, reconcile with Stripe before allowing another attempt. A separate proposal for the same customer request also needs a duplicate check: a new proposal ID alone does not establish that another refund is intended.
Track the refund after the API responds
Approval, submission and completion are separate states. Stripe documents pending and failed refunds, including card refunds held pending when the available balance is insufficient. Give support staff a status view so they can describe progress accurately.
Store the Stripe refund ID and process relevant refund.created, refund.updated and refund.failed events, verifying webhook signatures. Route exceptions to a named person. A failed refund should trigger investigation before any replacement payment is considered.
Start with a workflow your team can operate
Test a partial refund, an edited proposal, rejection, expired approval, simultaneous clicks, a changed refundable balance and a missing API response. Include a pending or failed refund so support knows what happens after submission.
The first release can cover one shop, one payment provider and a small reviewer group. Measure review waiting time, manual corrections and unresolved operations before expanding it.
If you want AI to prepare refunds within your existing support process, talk to me about your workflow. I can help define the approval rules, connect the order and payment systems, and give your team a clear way to handle exceptions.
Related on GrN.dk
- OpenAI Computer Use: What Browser Agents Need Beyond the Demo
- Your AI workflow has logs. Can they explain one bad decision?
- A Voice Agent Is Only Ready When the Human Handoff Works
Need help with this kind of work?
Discuss your refund approval workflow Get in touch with Greg.
