Model a program.
Inspect its decisions.

Start with the recipient and funding relationship. Run an approval, decline and review in the sandbox, then inspect the same declarative rule kinds over HTTP.

Available capabilities

Decision API

This is a synthetic decision API, not a Usio webhook adapter. The wire protocol, request authentication, retries, message types and approved response format still need validation against the actual External Auth specification.

POST /api/decide on this site. Send a rulebook array and an intent object. The current decision route does not require an API key. Send only synthetic purchase facts, never card numbers.

Amounts are integer cents. Optional history entries use merchant, amount_cents, status and epoch-millisecond at. Counted spend statuses are approved, captured and settled.

human: true is an evaluation input for sandbox gate tests, not an authorization to spend or a production approval credential. Do not expose it as a way to bypass real approval permissions.

{
 "decision": "approve",
 "approved_cents": 400,
 "results": [
   {"kind": "amount_ceiling", "status": "pass", "detail": "…"}
 ]
}

This demonstration endpoint evaluates the synthetic facts you supply. It does not load a saved program, issue a card, or move money.

Full-program synthetic test

The sandbox’s Check API round trip button uses this shape. program is the complete versioned JSON model from Export JSON; scenario is one of that model’s scenarios. Supply exactly these two top-level fields. Program mode checks cardholder and card status, modeled balance, temporary unlocks and scoped controls without recording a purchase.

const program = await (await fetch('/programs/subscriber.json')).json();
const response = await fetch('/api/decide', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ program, scenario: program.scenarios[0] })
});
console.log(await response.json());

Successful responses use mode: "sandbox-program-evaluation", a unique request_id, the decision and trace, and timing. All model data remains caller-supplied. There is no bank authentication, trusted balance lookup, reservation or payment side effect. The diagnostic converts review and partial results to an immediate decline because those response types have not been approved for External Auth.

Rule spec · v1

16 kinds, evaluated in engine order. Every applicable rule has a trace. Failures take precedence over human review; a human gate does not bypass other failures. Conditional branches retain skipped traces. Amounts are cents and timestamps are milliseconds.

Known limits

time_window uses hour boundaries; a temporary 15-minute unlock is a separate program-model check. spend_cap day, week and month are rolling 24-hour, 7-day and 30-day windows, not calendar resets. MCC allowlists use mcc_block with allow; there is no separate allowed_mccs rule kind. Browser external webhooks are unexecuted and the program workspace fails closed.

The current engine matches merchant allowlists by a case-insensitive substring. This is a modeling limitation, not a secure network merchant-identity guarantee. Unknown configuration fields can be permissive in the raw engine; the workspace validates them before saving.

Branches, repeats and execution limits

Every successful request returns a request_id and X-Request-Id. Server-Timing measures the handler only. The sandbox Performance panel can separately measure a browser round trip with a strict 1,000 ms diagnostic deadline; late or unavailable responses never produce an approval there.

Programs use declarative controls, not uploaded JavaScript. A condition selects branch children. A repeat control limits eligible purchases across the supplied history; its children run once for each purchase evaluation. It does not execute a JavaScript loop inside one request.

The limits above are enforced before evaluation. Oversized and unknown rules are rejected.

Shared spend caps default to whole-program history. Behavioral controls default to the current cardholder; branches inherit their root control’s scope. You can change a program control’s history scope. The raw rule API uses exactly the history you supply and does not fetch balances, enforce workspace scope or reserve funds. Full-program mode applies workspace checks to the model you supply; it does not verify that model against an account or reserve real funds.

Production integration requirement: under 1,000 ms. Appen runs the configured controls together against a shared budget. The collapsed Performance panel shows browser rule evaluation time, individual control durations and the slowest recorded decision. Simulation only; excludes network, issuer, data access and saving. Production performance has not been measured. Untaken branches are labeled skipped; program checks without an individual measurement are included in the total.

The /api/decide response includes timing.elapsed_ms, budget_ms and a Server-Timing header for its handler. Browser rule evaluation and handler measurements exclude network transit, platform startup and persistence. The separate round-trip diagnostic includes the browser-to-API request and response, but still excludes any bank or card network. They do not establish live authorization latency. The legacy AWS /v1/decide route is a demonstration, not the canonical API.

Results measured at or above 1,000 ms are declined; the workspace reserves no modeled funds. These bounded synchronous evaluators reject a late result after it finishes. They do not interrupt JavaScript or provide an isolated custom-code runtime. A production authorization service still needs its own deadline, network margin and partner timeout handling.

Decisions and approvals

Under the proposed External Auth contract, APPEN must answer every authorization within 1,000 ms and cannot assume Usio-side transaction filtering. Review cannot hold a network request open. Until separately approved, modeled review and partial outcomes are treated as decline in the binary API diagnostic.

approve passes the rules; decline fails at least one deciding control; review waits at a human gate; partial returns a lower allowed amount when configured.

Program approvals are bound to the exact modeled request and expire after 15 simulated minutes. Returning an approval runs current controls again. A pending human response does not hold a card authorization open: the immediate decision and later approval/retry are separate steps. Network partial authorization, approval routing, notifications and timeout behavior require partner integration.

External decisions and events

The decision API evaluates provided JSON. The separately deployed AWS route is a legacy demo. It does not deliver notification webhooks or execute webhook_check. In the program workspace, an external decision rule produces a fail-closed untested result. Do not infer a successful remote check from a raw browser-engine pass.

Contribution, approval, authorization, clearing, reversal and refund events in the workspace are modeled ledger events. They are labeled separately from card-network events.

A Program Brief for partner review

Branding and proposed client/sub-client structure are included in saved models and briefs. These are modeling controls, not permission to change the issuer product, artwork or bank setup.

Export a versioned model, funding relationships, responsibilities, rules, scenario decisions and open questions. Use the print view to save a PDF, or export Markdown and JSON. This is not an approval package or a readiness score.

October 27, 2026

Recipient-first templates; explicit cardholder and funding models; a controllable scenario clock; current-rule approval checks; immutable private snapshots and expiring read-only shares; program brief export; additive lead-capture backend.

Independent scenario previews, account-scoped saves, saved card branding, client-structure modeling, per-call API diagnostics and expiring private drafts are available. Production issuing is not connected.