Approve refunds before they run
Use this pattern when an agent is about to issue a refund, credit, adjustment, or billing change that a person should review first.
When to use this
Use this pattern when an agent is about to issue a refund, credit, adjustment, or billing change that a person should review first.
Where Stacksona fits
Place Stacksona after the agent has prepared the refund request and before the payment, billing, or commerce API is called.
What the reviewer should see
- amount
- currency
- customer
- order or invoice
- refund reason
- policy threshold
- prior refund history if available
- agent recommendation
- consequence of approval
Minimum fields to send
agent_idworkflow_idtool_name: issue_refundaction_type: refund- amount
- currency
customer_idorder_id or invoice_id- reason
policy_thresholdcallback_url, if using async review
Example request
json
{
"agent_id": "billing-agent-01",
"workflow_id": "refund-review-flow",
"tool_name": "issue_refund",
"action_type": "refund",
"amount": 500,
"currency": "usd",
"customer_id": "cus_99",
"order_id": "ord_8821",
"reason": "Carrier shows no movement after 14 days.",
"policy_threshold": "manual_review_required_over_100_usd",
"callback_url": "https://app.example.com/stacksona/refund-callback"
}How to branch after the decision
| Status | Behavior |
|---|---|
allowed or approved | Issue the refund. |
pending_review | Pause, poll, or wait for callback. |
rejected | Do not issue the refund. |
expired or error | Fail closed and do not issue the refund. |
What to log after execution
- decision_id
- refund_id
- payment provider id
- amount
- currency
- execution_status
- executed_at
Common mistakes
- issuing the refund before validation
- omitting the amount or customer history from reviewer view
- not validating signed approval for high-impact refunds
- retrying after a rejected decision