HALTSEAL
Start free

Payment control for AI agents · guided example

Many agents.
One approval.

One invoice. Two agents. One $10 payment limit.
Follow the handoff. Keep the original in view.

Illustrative walkthrough · predefined synthetic scenarios · no live payment calls.

One shared approval ILLUSTRATIVE-1042

Illustration · No money moves

One payment obligation

Invoice #1042 Example supplier

$10 USD · authorized once

Reserved
$10
Confirmed paid
$0
Available
$1,000
Agent A
Assigned
Agent B
Not assigned
Original · Provider A
Not submitted

ONE ORIGINAL OBLIGATION

Change the Agent.
Keep the original limits.

Illustrative scenario · No money moves

Follow one fictional invoice through a lost reply, an Agent handoff and a restart. No account or connection needed.

Invoice #1042 · Example only$10 USD

Original approved limit

ILLUSTRATIVE-1042
Original outcome
Not submitted
Reserved amount
$0
Agent A
Assigned
Agent B
Not assigned
Replacement request
Not proposed

A new Agent or route cannot create another approved limit.

    Step 1 of 6

    Invoice #1042 · Original limit $10

    One original approval.

    Agent A starts with the work. The original approved limit belongs to the obligation.

    What stays the same

    The original obligation, its approval and its limit remain together.

    Continue with your own Sandbox.

    Sign in when you are ready. This example carries no financial approval or installation evidence.

    Start free and keep your placeInspect recorded tests and their scope

    Only example learning progress can be saved in this browser for seven days. No account or payment data is stored here.

    Scenario activity 1 action
    1. One original approval. No request submitted; $10 available.

    Latest 32 actions in this tab. This illustrates a history; it is not an engine-produced audit record.

    Scope and preview settingsNo live execution

    Provider A, Provider B and Bank C are fictional connected paths. An unconnected bank portal remains outside real control. Live enforcement requires verified coverage, reliable evidence and operating approval.

    Decision only. No payment authority.

    Shadow ACCEPT illustrates a proposed decision. Enforcement concept ACCEPT illustrates one modeled allocation. Both send nothing. Available capacity is not release permission. The moving marker is a request, not delivered money.

    A lost reply keeps the original amount reserved. Changing the agent, path or host does not create another right to pay.

    Handoffs, receiving proof, restarts and decisions are modeled here. Inspect recorded installation tests and their exact scope.

    Your workflow comes next

    Keep the work moving.
    Keep the authority intact.

    Start your free Workspace Sandbox. Sign in, create your company and prepare one workflow. No card required.

    Start free and keep your placeExplore the interactive console

    Only your example learning step continues. Example approvals, receipts, payment state and installation evidence never carry over. Live payment control requires separate qualification and operating approval.

    Prefer to start with your code?

    Run the SDK quickstart or review the local evaluation setup. These have their own supported scope.

    Optional assessment brief. Scope, deliverables and fees are agreed before paid work. No purchase is required to start Sandbox.

    Go deeper · optional examples

    The same principle.
    Different payment paths.

    Each disclosure starts a separate fictional example. It does not change the $10 Agent walkthrough above.

    Explore check to ACHA separate $50,000 fictional example · conditional eligibility only

    Start here · check to ACH

    The supplier asks for ACH.
    The check can still clear.

    Try the ACH. Resolve the check. Recheck the exact payment.

    1. Unresolved original: HOLD.
    2. Check cannot pay later: restore capacity; ACH stays unsent.
    3. Fresh exact-payment check: conditional ACCEPT.
    What if approval changes before release?

    After adding closure evidence, model a revoked approval. Restored capacity alone is insufficient.

    Review a workflow

    Original and replacement payment paths

    ONE SUPPLIER OBLIGATIONFICTIONAL MODEL
    $50,000Authorized once · Supplier invoice #5001

    BANK A

    Check #10482

    OUTSTANDING

    The supplier says it hasn’t arrived.

    PAYMENT PLATFORM B

    ACH replacement

    PROPOSED

    Same supplier. Same $50,000 obligation.

    HALTSEALHOLD

    The original check can still pay.

    NEXT STEP

    Confirm that the original check cannot pay later.

    Reserved
    $50,000
    Available capacity
    $0
    Backup eligible
    $0
    Fictional example. No live payment calls. An ACCEPT here sends nothing. It shows conditional eligibility only, without reserving capacity.
    What this example assumes

    The original check is matched to the obligation. Closure means it cannot pay later; a temporary stop, cancellation request or ERP status is insufficient. Current approval, the unchanged ACH and a connected release point are checked separately. Live check closure and payment integrations still require validation.

    Evidence and limits
    Explore the provider lifecycleA separate $10,000 fictional example · 11 guided steps

    Explore the full lifecycle

    Provider to provider.

    A separate fictional $10,000 example. Try other routes, revocation and protected retries.

    Key moment preview · not running

    1. 01 Hold
    2. 02 Recheck
    3. 03 Release
    HOLD

    The original outcome is unresolved.

    No second dispatch.

    Invoice #8472 $10,000 Authorized once
    HALTSEAL
    OriginalRoute 1 · Provider A
    UNKNOWNMay have paid. May still pay.
    BackupRoute 2 · Provider B
    HOLDRequest held.
    Request markers · synthetic · no live calls. The backup request stays before the boundary.
    From control behavior to team reviewTry the interactive Console

    Follow one fictional invoice through evidence, fresh checks and protected retries.

    Step details & request records

    Current step

    The company authorized the invoice to be paid once. Route 1 remains unresolved, so Route 2 is not eligible for release.

    Same authoritative state · Route 1 unresolved

    HOLD No release while Route 1 remains unresolved.

    Route 1 outcome
    UNKNOWN
    Route 2 disposition
    HOLD

    Request context

    The backup changes worker, credential, provider, request key and idempotency domain. The payment obligation stays the same.

    Original: Worker A · Credential A · Key A-104

    Second dispatches
    0
    Release authority created by evidence
    false
    Replay additional effects
    0
    Read the eleven steps

    One stable payment obligation. Changing execution paths. One deterministic control point before release.

    1. Initialize the payment obligation for Invoice #8472, ten thousand dollars, authorized to be paid once.
    2. Evaluate Route 1. HALTSEAL returns ACCEPT and Route 1 receives one bounded dispatch.
    3. Mark Route 1 UNKNOWN. Money may or may not have moved.
    4. Present fresh Route 2 with a new worker, credential, provider, request key, and idempotency domain.
    5. Evaluate Route 2. HALTSEAL returns HOLD.
    6. Confirm no second dispatch. Second dispatches: zero.
    7. Apply authoritative NO EFFECT evidence: in this synthetic case, Route 1 did not pay and cannot complete later.
    8. Recompute eligibility without dispatch and without creating release authority.
    9. Request a fresh explicit Route 2 release.
    10. Evaluate the fresh release. HALTSEAL returns one bounded ACCEPT.
    11. Replay the consumed release. HALTSEAL returns REFUSE with no additional effect.
    Read the evidence summary

    ACCEPT records one simulated dispatch for an exact request; it sends no money. This illustrates governed paths in a predefined synthetic scenario. It does not establish a live integration, customer validation, or production readiness.

    Review installed recovery and authority-history evidence, with each tested profile and its limits. This walkthrough supplies no customer installation evidence or operating approval.