Reference
Glossary.
Plain-language definitions for the vocabulary used across Axiru: outflow control, governed decisions, shadow mode, decision ledger, Stripe DAA, x402, and forty-plus other terms. Useful for finance, support, and engineering teams aligning on what gets governed and how.
A to Z
Outflow control vocabulary.
If a term shows up in our docs, in the policy editor, or in an audit export, you should be able to find it here.
- Outflow Control
- The canonical Axiru noun. The discipline of governing every outbound money movement (refunds, credits, payouts, transfers, disputes, application-fee refunds) before it executes. Replaces the older, narrower term refund control. Outflow Control →
- Governed Decision
- A single outbound money-movement request (a refund, credit, payout, dispute response, etc.) that has been evaluated against an active policy, routed to the right approver if needed, and sealed in the decision ledger with the policy version that decided it. Axiru's primary billable unit.
- Shadow Mode
- Read-only simulation: Axiru replays your last 90 days of Stripe activity against a proposed policy without touching real money. You quantify leakage and policy fit before turning on enforcement.
- Live Enforcement
- The mode after shadow mode where Axiru actually intercepts outbound API calls (refund, payout, transfer) and either allows, blocks, or routes them for approval according to the active policy version.
- Decision Ledger
- An append-only, tamper-evident record of every governed decision: the request payload, the policy version that decided it, the approver identity (if any), the outcome, and a Merkle-sealed hash. Designed to satisfy SOX/ICFR evidence requirements. Decision Ledger →
- Approvals Policy Engine
- The plain-language rule layer that decides whether a request executes automatically, escalates for approval, or is blocked. Policies are versioned (every edit creates a new immutable version) and human-readable. Approvals Policy Engine →
- Policy Version
- An immutable snapshot of the policy at a point in time. Every governed decision references the exact policy version active when it ran, so auditors can reproduce why any historical decision went the way it did.
- Refund Leakage
- Money that left the business as a refund or credit but should not have (duplicate refunds, out-of-policy goodwill, over-credits, AI agent over-corrections). Shadow mode quantifies this against your historical Stripe data before you commit to enforcement.
- Pre-Execution Control
- Policy evaluation that happens before the outbound API call (the refund, payout, or transfer) is made. Distinct from post-hoc analytics or after-the-fact dispute. Axiru's core architectural commitment.
- Decision Receipt
- A signed, structured record emitted for every governed decision. Includes the policy version, decision inputs, outcome, and approver chain. Exportable as evidence for SOX/ICFR audit.
- Stripe DAA
- Stripe Direct Agent Authorization. Stripe's surface for letting AI agents initiate payments under merchant-defined rules. Axiru governs DAA-initiated outflows the same way it governs human-initiated ones.
- x402
- Emerging payment protocol that uses HTTP 402 Payment Required for agent-to-agent commerce. Axiru can sit upstream of x402-initiated payments and apply policy before the payment is released.
- Agentic Payment
- A payment initiated by an AI agent (chatbot, autonomous worker, RAG-driven CS bot) rather than a human. The policy and audit requirements are identical to human-initiated payments; Axiru treats them as one surface.
- Kill Switch
- A single-action operator control that pauses all outbound money movement (or a scoped subset) without re-deploying code. Available on Control and Scale plans.
- Goodwill Credit
- A credit issued to retain a customer rather than to remedy a specific refund-eligible event. Frequently abused by AI support agents without governance; the canonical example of why outflow control matters.
- Refund Reason Code
- The structured rationale attached to a refund request (e.g. duplicate, fraudulent, requested_by_customer). Axiru policies typically read reason codes as a primary input.
- Approval Routing
- The logic that sends an escalated decision to the correct human approver based on amount, customer, reason code, or any other policy input. Includes Slack DM, email, and in-app channels.
- Compliance Controls
- Axiru's pre-built control set mapped to SOX 404 / ICFR. Covers segregation of duties on outbound payments, approval thresholds, evidence retention, and audit export. Compliance Controls →
- SOX 404
- Section 404 of the Sarbanes-Oxley Act, which requires public companies (and many late-stage privates) to document and test internal controls over financial reporting. Outbound payment controls are a recurring SOX 404 gap.
- ICFR
- Internal Control over Financial Reporting. The framework auditors use to evaluate the controls that produce a company's financial statements. Refund and payout governance lives here.
- Segregation of Duties
- The principle that the person initiating a payment cannot also approve it. Frequently violated when a single CS agent (or AI agent) both decides and executes a refund. Axiru enforces this at the policy layer.
- Stripe Connect
- Stripe's multi-party payments product. Axiru governs Connect application-fee refunds and transfers as first-class outflow surfaces.
- Application Fee Refund
- On Stripe Connect, the platform's portion of a refund (the application fee). A common leakage point because it's frequently refunded automatically without policy review.
- Dispute Evidence
- The structured response a merchant submits to Stripe when contesting a chargeback. Axiru's governance covers dispute response decisions as part of outflow control.
- Chargeback
- A forced reversal of a card payment initiated by the cardholder's bank. Different from a refund (which the merchant initiates). Axiru governs the merchant's response decision, not the chargeback itself.
- Refund vs Reversal
- A refund returns money to the original payment method via Stripe's refund API. A reversal is a payout reversal (clawing back a transfer). Axiru governs both as distinct decision surfaces with separate policies.
- Payout
- A transfer of accumulated balance from Stripe to a bank account. Manual payouts and automatic payouts are both governable outflow surfaces in Axiru.
- Transfer
- On Stripe Connect, a movement of funds from the platform to a connected account. Frequently the largest single outflow surface for marketplaces; Axiru applies policy here the same way it does to refunds.
- Idempotency Key
- A client-supplied token Stripe uses to deduplicate repeated API calls. Axiru attaches a decision-ledger reference to every idempotency key so a retried refund and its original share a decision record.
- Webhook
- An HTTP callback Stripe sends when an event happens (refund created, payout failed, dispute opened). Axiru subscribes to relevant outflow webhooks to keep the decision ledger in sync with reality.
- Read-Only Stripe Connection
- The Stripe permissions Axiru uses during shadow mode: it can read transaction history to simulate policy outcomes, but cannot create, modify, or refund any payment. Activated by default during the 90-day audit.
- Live Stripe Connection
- Read/write Stripe permissions Axiru uses once live enforcement is on. Required scopes are documented in the developer docs; least-privilege is the design intent.
- OAuth Scope
- The permission boundary on an OAuth-issued token. Axiru requests narrow Stripe scopes (refunds:write, payouts:write, etc.) rather than the platform scope, so a compromised Axiru token cannot drain your account.
- MCP
- Model Context Protocol. The open standard Axiru implements at /api/mcp so AI agents (Claude, GPT, custom) can query Axiru's policy state, decision ledger, and approval queue programmatically.
- Plain-Language Policy
- Axiru policies are authored in human-readable sentences (e.g. 'refunds over $500 require manager approval') rather than code. Each saved policy compiles to an executable rule set and gets a new immutable version.
- Threshold Rule
- A policy rule that triggers on a numeric threshold (refund amount, daily volume per agent, % of order value). The most common rule type for refund governance.
- Identity-Based Rule
- A policy rule keyed to the actor initiating the request (specific CS agent, AI agent, API key). Used to apply tighter controls to higher-risk identities.
- Customer-Lifetime Rule
- A policy rule that reads cumulative customer history (lifetime refund count, lifetime credit total) before deciding. Catches repeat-refund abuse without blocking legitimate cases.
- Tamper-Evident Ledger
- A ledger where any modification to a past record breaks a cryptographic hash chain, making the modification detectable. The decision ledger is tamper-evident, not tamper-proof; the distinction matters for auditor language.
- Merkle Seal
- The hashing technique used by the decision ledger to chain records. Each decision's hash incorporates the prior decision's hash, so a single retroactive change invalidates every subsequent hash.
- SIEM Export
- A stream of structured decision events Axiru pushes to a security information and event management system (Splunk, Datadog, etc.). Available on Control and Scale plans.
- Slack Approval
- An escalated decision delivered as an interactive Slack message; the approver clicks approve/deny in Slack and the outcome is recorded in the decision ledger.
- Role-Based Approval
- Approval routing keyed to a role (Manager, Director, Finance Lead) rather than a specific person. Roles resolve to actual users at decision time via your team directory.
- Audit Export
- A structured download of decision-ledger records for a date range, formatted for direct ingestion by audit firms. CSV and JSON; PDF on request.
- Free Audit
- Axiru's permanently-free starter plan: 90 days of shadow-mode simulation on your Stripe history, leakage quantification, and a written policy recommendation. No card required.
- Governed Decisions per Month
- The metered unit on paid Axiru plans. One inbound refund/payout/transfer request evaluated end-to-end (policy + routing + ledger) equals one governed decision.
- Overage
- The per-thousand-decisions rate charged when monthly governed-decision volume exceeds the plan's included quota. Decreases per-unit as plan tier increases.
- Decision Latency
- The wall-clock time from a refund/payout request hitting Axiru to a decision being returned. Target is sub-100ms p95 for auto-approve; escalated decisions take as long as the approver does.
- Policy Conflict
- What happens when two rules in the same policy version reach contradictory verdicts on the same request. Axiru resolves by most-restrictive-wins and surfaces the conflict to the policy author at edit time.
- Refund Storm
- An unusual concentrated burst of refund activity, often signalling a broken AI agent, a bad code deploy, or a coordinated abuse attempt. Axiru's volume rules detect and pause storms automatically.
- Why Axiru Exists
- AI agents now move money. Stripe-native businesses run a growing share of outbound payments without a policy layer, an approval chain, or an audit trail. Axiru is the missing decision layer. Why Axiru →
Next step
Ready to see what outflow control looks like on your own Stripe data?
Connect Stripe read-only and replay your last 90 days against a draft policy. No enforcement, no card required.
Start in shadow mode first. Move to live enforcement later.