Automatically allowed
- Proposed action
- Valid A$80 refund with no duplicate
- Policy match
- Within the automatic limit
- Outcome
ALLOW— proceeds without manual review.
Automate refunds. Enforce your returns policy.
Let routine refunds proceed automatically. Block prohibited requests and hold exceptions for review. HaltState checks connected agent actions against your rules before the payment request is sent.
Your returns policy. Automatic enforcement. Reviewable decisions.
Three requests. Three clear outcomes.
Example policy: automated refunds with a human-review threshold.
- Valid, non-duplicate refunds up to A$100 are permitted.
- Duplicate refunds are blocked.
- Valid, non-duplicate refunds above A$100 require human approval.
Automatically blocked
- Proposed action
- Another attempt to refund the same order
- Policy match
- Duplicate refund prohibited
- Outcome
DENY— the connected action does not execute.
Held for review
- Proposed action
- Valid A$350 refund with no duplicate
- Policy match
- Above the automatic limit
- Outcome
APPROVAL_REQUIRED— waits for the required authorisation.
Where configured, QUARANTINE can stop further governed actions for an affected agent or session.
Keep routine service moving
Apply the rules automatically
Evaluate the proposed action against the policy context your integration supplies, such as amount, duplicate status and allowed workflow.
Send exceptions to the right review path
Delegate eligible exceptions to the council. Bring in a human for unresolved decisions or the approvals your returns policy reserves for people.
Explain the decision later
Connect the recorded decision, any approval and the reported outcome through Signed Proof Packs.
Start with refunds. Extend to connected customer actions.
Once the integration fits your workflow, the same action-control pattern can be applied to other tools you connect:
| Workflow | Example policy question |
|---|---|
| Loyalty credits | Is the credit within the authorised allowance? |
| Order changes | Does this change fit the permitted workflow? |
| Customer messages | Does this message need review before sending? |
| Customer-data export | Is this recipient and destination authorised? |
What your teams do
Operations: choose the permitted actions, exception rules and approval owners.
Engineering: connect the service that makes the refund or customer-system call.
Security and governance: review the access boundary and the evidence needed for investigation and assurance.
AI assists policy drafting. An authorised operator reviews and activates the rules. Routine decisions then run automatically; per-action approval is a separate policy-defined path.
Watch refund governance in action
Follow the retail simulation through the live policy engine, council review and signed outcome evidence. The Control Room shows each recorded decision with its timestamp.
Bring your refund workflow under control
Start a workspace, connect your refund action and define the rules it should follow. Test the decision paths and explore the evidence with your team.
Need help planning a rollout? Discuss your refund workflow.
Retail buyer questions
How do we stop an AI agent issuing duplicate or ineligible refunds?
Connect the actual refund boundary, supply authoritative order and prior-refund data, enforce your eligibility rules, and retain payment-provider idempotency. HaltState controls the connected action; your commerce system remains the source of order truth. Follow the refund-policy implementation steps.
Can routine refunds run without manual review?
Yes. Your configured policies can permit valid requests automatically and hold the exceptions you choose for human authorisation.
Do we need to replace our payment or commerce system?
Integrate HaltState at the service or tool call that already performs the action. Your existing commerce system remains the destination.
Who sets the refund limits?
Your authorised team chooses and activates the limits that fit your returns policy.
What happens when a request is blocked?
The connected application follows the denial and does not perform that operation. Review the recorded reason and the relevant evidence through the product's existing workflow.
Build on your existing commerce stack
Follow the refund integration guide and Architecture & shared responsibility model for execution, retry handling and evidence capture.