US$80 · 14 days after purchase
Within the limit and return window. The connected refund action can proceed without manual review.
Your agent can issue a refund. You set the rules.
Let routine refunds proceed, send exceptions for approval and block requests outside your policy. HaltState checks your connected refund action before your system moves the money.
No credit card required. Account first, guided connection next.
One policy. Three decisions.
Example store policy: refunds within 30 days and up to US$100 can proceed. Larger refunds within that window need approval. Requests after 30 days are blocked.
Illustrative rules and amounts. You choose and activate your own policy.
US$350 · 14 days after purchase
Within the return window, but above the automatic limit. The refund waits for the required human authorisation.
US$80 · 45 days after purchase
Outside the return window. The connected action is denied before your system issues the refund.
Your integration supplies the refund amount and order information used by the policy. HaltState evaluates those details; your refund service executes permitted refunds and reports the outcome.
Where HaltState fits
- Agent requests a refund
- HaltState checks your policy
- Your service acts on the decision
- You review the evidence
Connect HaltState to the backend tool or API that issues refunds. Keep your existing store, payment provider and agent. Signed Proof Packs preserve evidence of governed decisions and recorded outcomes.
How do you implement an AI agent refund policy?
- Connect the refund boundary. Place the HaltState check in the backend function that calls your payment provider. Protect every route to that function; a prompt alone cannot prevent an agent using an unconnected tool.
- Supply trustworthy order context. Read amount, currency, purchase date, remaining refundable balance and prior-refund state from your store or payment system—not solely from the agent's claim.
- Choose explicit rules. Permit routine eligible refunds, deny prohibited cases and select the review path for exceptions. Policy-defined council review can resolve delegated cases; mandatory human-review rules still require a person.
- Respect the decision before execution. Execute only an authorised operation. Keep held requests pending and do not execute denied requests. Define how the integration handles an unavailable policy service.
- Report and reconcile the result. Link the provider's refund identifier and actual result to the original activity. An allowed request is not evidence that money moved; an execution error may still require checking the payment provider.
Use the refund agent integration guide with your existing SDK. Python, TypeScript/JavaScript, Go, Java and Rust documentation describes language-specific APIs and capabilities.
How do you prevent duplicate refunds and return abuse?
Use an order-linked operation identity, check prior refunds and the remaining refundable balance, and apply payment-provider idempotency to the execution itself. Reuse the same operation identity when retrying that operation, not when starting a different refund. HaltState evaluates the context supplied to it; it does not discover undisclosed refund history or replace your provider's duplicate-payment controls.
What evidence should a refund investigation show?
Agent, order or customer reference, requested amount, recorded policy reason, review decision, provider reference and outcome. Keep sensitive context inside the account's access and retention controls. The verified synthetic refund example shows a signed council approval alongside its separately checked execution result.
Explore it with one refund action.
Create an account, then use the setup guide inside your workspace. A coding agent or your developer can help connect a test action. Review the policy and try all three outcomes before using it in production.
No credit card required. Ongoing plans start at US$500/month; choose your plan at signup.
Already registered? Continue setup.