# A Stripe refund control proof, before live enforcement

Axiru checks supported refund requests routed through its integration, holds exceptions for a separate approver, and records the decision. Direct Stripe calls are outside that path. A later webhook is observation; it cannot block a completed transaction.

## 1. Review history locally

Open https://axiru.com/preview/csv. Try the labeled synthetic CSV first, then choose your own Stripe **Refunds** export when you are ready. The browser preview requests no credentials and does not upload the CSV. Use positive major-unit amounts, one supported two-decimal currency, dates and refund status. Only succeeded rows count toward confirmed totals. Failed, pending, canceled and unknown statuses remain separate.

Review exclusions before reading the totals. Adjust the browser sample approval threshold, apply it, and inspect the reasons. Download the local Markdown report. It includes amounts and dates while omitting raw identifiers and source free text; keep it private. A flagged row is not proven fraud, duplicate payment, recoverable loss or savings. Refund age is not purchase age. This sample policy is separate from the live policy and Gate sandbox.

## 2. Prove a synthetic deny and approve

In an existing Axiru source checkout with its dependencies available:

```sh
pnpm test:refund-sandbox
pnpm demo:refund-sandbox
```

These commands use synthetic fixtures and mocked execution. They need no Stripe keys, wallets, account signup, real customer CSV or provider connection. The demo covers a small allowed refund, a duplicate attempt, a larger request requiring a separate merchant approval, and a policy violation. The harness tests request binding, amounts, status, authority, expiry and duplicate behavior. Read the printed evidence rather than treating a green command as provider delivery.

This protocol-neutral sandbox is educational; it does not establish PAP compatibility, a production integration or live settlement. The production refund-service tests are a separate layer. Real test-mode deny/approve verification remains required in an authorized staging environment before live enforcement.

## 3. Choose what to build or buy

An internal approval script can be sufficient when your team can own the policy checks, approval identity, request binding, duplicate handling, provider reconciliation, current-policy rechecks and evidence retrieval. An approval inbox alone can work when execution stays correctly gated in your own workflow.

Evaluate Axiru for the maintained refund policy/replay/approval/evidence workflow you need. Compare the full operational path, not just the approve button. Test denied, pending, approved, stale, duplicate and uncertain-provider-response paths. No competitor is assumed unable to enforce a correctly integrated workflow.

## 4. Verify the actual caller path

Use an authorized synthetic/test-mode environment. Verify that a denied or pending request produces no provider execution; a valid separately approved request executes once; a duplicate retry does not execute or meter twice; stale approval, changed policy, pause and connection freeze stop execution. Simulate a lost provider response and confirm reconciliation before retrying. Preserve uncertainty rather than labeling it successful.

Inventory every refund writer, including support UI, jobs, API tools and manual Dashboard access. Decide which paths are governed and which are restricted or deliberately outside coverage. Do not claim that connecting read-only Stripe grants interception. Confirm the contracted commercial terms and entitlement mapping separately before activation.

Current coverage and security facts: https://axiru.com/security#coverage. Local CLI/IDE audit hosts have their own install/permission requirements; the browser preview does not imply a regular ChatGPT hosted app.