How to let an AI agent issue refunds through your payment gateway

A refund moves money, so it is depth 4 work. Give the agent a gateway credential that can only read charges and create refunds, set a per-refund and daily limit, and require refunds to go back to the original payment method. Inside those bounds a certified agent issues the refund; anything outside is held for a person or refused.

What does refunding through a gateway involve, and who owns it?

A payment gateway sits between you and the card networks or bank rails. A refund instruction tells it to return all or part of a captured charge to the instrument that paid. Once the refund settles, it cannot be called back.

Ownership is usually split. Customer service or payments operations decides that a refund is due. Finance owns the limits and reconciles the gateway's settlement reports to the general ledger. Security owns the credentials. All three need a say before an agent touches the refund endpoint, and connecting an agent to your payment gateway covers the connection itself. This piece is about the refund capability on top of it.

Which capabilities do you grant, and at what depth?

Split the gateway into capabilities and grant each one on its own.

The steps in order:

1. Agent, depth 1: finds the charge. It confirms the charge exists, how much was captured, how much has already been refunded, and whether a chargeback or dispute is open.
2. Agent, depth 1: checks the reason. Against the refund policy: return received, service failed, duplicate charge.
3. Agent, depth 2: drafts the refund. Amount, reason code, charge reference and an idempotency key generated once and reused on any retry.
4. Agent, depth 4: issues it, if inside every bound. Per-refund limit, daily total, cumulative refunds not exceeding the capture, original instrument only.
5. Person: releases held refunds. Anything over a limit, any partial refund the policy does not cover, and any refund on an order flagged for fraud.
6. Agent, depth 3: confirms to the customer. Using an approved template stating the amount and the expected timing.

What makes a refund held, refused or withheld?

Held means the refund is drafted and waiting for a named person. Over-limit amounts, refunds outside the policy window and refunds on flagged orders are held.

Refused means the action is outside the agent's bounds. Sending a refund to a card or account other than the one that paid is refused for every agent, because it is how fraudsters turn a refund into a payout. If the business needs to pay someone on a different instrument, that is a payout to a merchant or third party, a different capability with different controls. A refund on a charge under dispute is refused too, since the dispute process may return the money a second time.

Withheld applies where the platform floor blocks an action for every agent at any depth. Reversing a refund once it has settled is one such case: the agent cannot reach it, however it is configured.

How do you revoke the agent's access?

Revocation needs to work at three levels.

• The credential. A restricted gateway key scoped to read charges and create refunds, held in a secrets store, and rotated on a schedule. Revoking it stops everything at once.
• The capability. Removing the refund grant leaves look-up and drafting in place, so service continues while people release refunds by hand.
• The certificate. Certificates lapse after 90 days. A certification run that clears no depth drops the agent to depth 1 the same day, so it can still read charges but cannot issue refunds.

Test each one before go-live. A revocation nobody has tried is a hope, not a control.

What does the audit trail need to show?

For each refund, file the charge reference, amount, reason, idempotency key, who requested it, the five bounds checked, the bound that decided and the verdict. For held refunds, add the person who released or rejected it. The gateway's own refund identifier links the record to the settlement report, so finance can match every agent refund to a line in the ledger.

This is what lets straight-through processing and control coexist. Most refunds flow without a person touching them, and every one can still be reconstructed.

What should you measure?

• Refunds issued, held and refused per day. Watch the mix, not just the volume.
• Duplicate attempts caught by the idempotency key. Any duplicate that got through is an incident.
• Time from approval of a held refund to settlement.
• Refunds later disputed by the customer. A sign the agent is closing cases the customer did not agree with.
• Reconciliation breaks on agent refunds.

Where does it usually go wrong?

Retries create duplicates. A timeout, a retry and a second refund. Generate the idempotency key once, at drafting, and never regenerate it.

A key with too much reach. A full secret key can create charges and payouts as well as refunds. Scope the credential to the capability.

Daily limits nobody sums. A per-refund limit of 200 means little if the agent can issue a thousand of them. Set and test the daily total.

Partial refunds without a rule. Goodwill amounts drift without a policy. If partial refunds are allowed, write the rule into the agent's bounds. The same discipline applies when you let an agent set up payment plans.

The wider rules for agents that touch money are in AI agents in banking.