Your first governed workflow.

Start with one company, one supported BILL Sandbox invoice and its separately approved original authority. Then assign the review work to an enrolled Agent, verify its own receiving proof and preserve the original through handoff.

Source access is separate from financial approval. Agent receiving proof is separate from payment permission. An installed execution check has its own profile, evidence and acceptance requirements.

Follow the complete Agent connection guide for the people, access, host setup, evidence gaps and next owner at every step.

Production remains preparation only. The controlled installed reference is a supported Sandbox profile, not customer acceptance or native production qualification. The public synthetic SDK demo needs no account and exercises fixed USD 10 HTTP fixtures; it does not run this installed Agent journey. Read each evidence scope.

Separate API path. These examples exercise the local Payment API contract; SDK installation does not enroll an Agent or install the Workspace execution profile.

Choose Python or JavaScript to run the free recovery exercise from your terminal, or try the browser sandbox. Python RC2 is on PyPI; JavaScript RC2 uses the GitHub release until npm publication is complete.

python3 -m venv .venv
. .venv/bin/activate
python -m pip install haltseal-payments==0.2.0rc2
python -m haltseal_payments_sdk.sandbox --output python-sandbox.json

npm install --ignore-scripts --no-audit --no-fund \
  https://github.com/HALTSEAL/payments-sdk/releases/download/v0.2.0-rc.2/haltseal-payments-0.2.0-rc.2.tgz
npx --no-install haltseal-payments-demo --output javascript-sandbox.json

Each demo connects to fixed HTTP fixtures at haltseal.com. No HALTSEAL account, provider credentials or real funds. Use a new output filename for each run; existing records are never overwritten.

Expected: original lookup → UNKNOWN HOLD → closure → stale HOLD → fresh ACCEPT → PAID REFUSE. Two synthetic dispatches. Zero original-lookup redispatches.

The payment attempt examples below require a separately configured local evaluator and a signed obligation. Retain the operation ID before dispatch.

from haltseal_payments_sdk import Client

client = Client("http://127.0.0.1:8790", api_key)
result = client.create_attempt(
    obligation_id,
    operation_id="invoice-1042-attempt-1",
    route="A",
    approval_revision=approval_revision,
)

import { Client } from "@haltseal/payments";

const client = new Client({
  baseUrl: "http://127.0.0.1:8790",
  apiKey,
});
const result = await client.createAttempt(obligationId, {
  operationId: "invoice-1042-attempt-1",
  route: "A",
  approvalRevision,
});

Requires the running evaluator, provisioned keys and imported approval. Request the local evaluator. The free diagnostic Lab is a separate tool you can run immediately.

The code-only Linux workflow kit installs the reviewed components for a selected company and Sandbox workflow. The installed application adapter and native reference have separate evidence; customer acceptance binds the agreed release and test paths.

1. Agree the scope. Identify the payment owner, integration engineer, approved source, common transfer reference and two controlled software paths.
2. Bind and install. Use a current Workspace Owner, independently obtained package pins and the host-generated public collector key. Keep its private key on the host.
3. Exercise one retained history. Observe a lost original reply, replacement HOLD, exact-original recovery and same-release reinstall. Keep the original identifiers, runtime and witness history.
4. Compare the evidence. Review installation, treasury and operations acknowledgements for the same workflow and retained checkpoint. Verify native authority history using the independently obtained source, provider observations and witness evidence required by that profile.

A failed or incomplete observation remains unresolved. Neither a package download, a report nor an offline verification authorizes another payment. Run a fresh fictional reference only in a new test fixture; it cannot replace an existing obligation's history.

Current native reference: Linux, Python 3.11+, Increase Sandbox, fictional own-account USD 10, one execution host and two paths using Increase. Actual Owner-to-host-to-public-Workspace acceptance and customer operating scope remain separate checks. Remote-control and native-authority profiles are separately qualified.

An issuer-signed source binds the real payment, its payer, beneficiary, currency and full principal. Every attempt draws on that same retained obligation.

A new operation ID, approval alias or route cannot create another right to pay. Recover the exact original before considering a replacement.

Inspect decision and current attempt state, including after HTTP 200. Preserve the original operation or attempt identity after a lost response.

ACCEPT

The exact proposed payment passed the release check. Its attempt state describes the outcome; ACCEPT does not establish settlement.

HOLD

Resolve missing evidence or eligibility. An unresolved original keeps the full principal reserved.

REFUSE

The proposal cannot pass the current contract. A confirmed paid original leaves no second full-principal right to pay.

Read the activation requirements. The current release supplies local evaluation; production payment control and hosted availability remain unqualified.

AI Execute

A local exploration of approved-job cost budgets, provider-job recovery and final cost evidence. A cost envelope may have room for more than one job; it uses different economic rules from a payment obligation.