Define the boundary of a refund agent
Scope Stripe refund actions by account, currency and environment, with explicit review, shared capacity and recovery responsibilities.
A refund agent needs a narrower capability than a general-purpose Stripe credential. Decide which account, currency and operation it may use, then route the action through a definition that fixes that boundary. The agent still holds an Anlyon credential or authorized session; it does not become authority-free.
The Anlyon Stripe adapter supports a refund of an explicit amount on a payment intent. Its configuration names the account, mode and currency, and references a provider secret. Live and test keys are supported when they match the configured mode. Use test mode for integration exercises.
Configure the business controls
Choose an applicable money limit in integer minor units and the intended period. Keep it in the same environment as the refund action. Decide which refunds require approval and who can decide them. Give ordinary agent credentials invocation privileges without the ability to raise their own allowance.
| Boundary | Review question |
|---|---|
| Account and mode | Is this the intended merchant and test/live environment? |
| Currency and amount | Does the integer quantity match the displayed refund? |
| Shared limit | Which other agents and actions consume it? |
| Operation key | Does it identify one persisted refund request? |
| Provider evidence | Which refund record will establish completion? |
Interpret review freshness correctly
The preview shows refundable state as observed during review. It is not an atomic lock on Stripe's payment state. Another actor can change what remains refundable. The adapter relies on provider behavior for the eventual refund and records the result.
Approval binding protects the reviewed request. It does not promise that the provider will accept it or that external state cannot change.
Prepare the recovery route
Keep the payment and refund-operation identifiers. A pending provider result is not completion. An unknown outcome keeps exposure held and should not trigger a new refund under another key. Supported lookup and bounded same-key replay have their own documented rules.
Start from the existing OpenAI refund example, adapter configuration and the reconciliation runbook. Validate the complete flow in your own test account before moving to live credentials.