PAYMENT API & SDKs Local evaluation

One obligation.
One right to pay.

Keep the original and its replacement under one payment authority. Connect signed approvals, retain uncertain outcomes and recover the exact original through an API your application can use.

Try payment recovery Read the API docs View SDK source

Synthetic USD 10 own-account movement · Python + JavaScript · No real funds

Connecting your Agent? Start with the Workspace and Agent guide. This page covers the separate local Payment API and SDK contract. Its fixture client does not enroll an Agent, provision a hosted payment account or install an execution host.

cash-request-4822USD 10.00

ORIGINAL / AThe reply was lost.

The original may still pay.

UNKNOWN

Full principal reserved: $10.00
Available for replacement: $0.00

REPLACEMENT / BSame obligation. Same authority.

A new route does not create another right to pay.

HOLD

Authored fixture scenario reproduced by the API. This page does not execute payments.

THE PAYMENT CONTRACT

Three outcomes.
One retained history.

The exact original's evidence determines whether a replacement can proceed.

01 / ORIGINAL UNRESOLVED

Keep the backup on hold.

A timeout, lost reply or stop request leaves the full principal reserved while the original can still pay.

HOLD

02 / ORIGINAL PAID

No second right to pay.

Authoritative paid history consumes the obligation. A new approval, route or operation ID cannot restore it.

REFUSE

03 / ORIGINAL CLOSED

Validate the replacement.

Confirm exact-original closure, obtain a newer signed approval issued after closure and revalidate the complete replacement.

ACCEPT IF VALIDATED

ACCEPT reserves and dispatches one exact attempt. It does not confirm settlement. Missing, stale, ambiguous or contradictory evidence blocks release.

Read the payment and recovery contract

LATEST PUBLIC SDK · EVALUATION PRERELEASE

Install SDK v2.
Keep the exact original.

Choose one language and run the free recovery exercise. Python RC2 is published on PyPI. JavaScript RC2 is available from GitHub while npm publication is pending. SDK v2 keeps exact response identity checks and total caller deadlines. Python 3.12+ or Node 22+ is required for its respective demo.

Python on PyPI0.2.0rc2 · published prerelease · MIT JavaScript on GitHub0.2.0-rc.2 · ESM + TypeScript · npm pending SDK v2 releaseSource, verification results and build attestation on GitHub

SDK v2 checksums SDK v2 manifest Upgrade from RC4 SDK v2 recovery contract

Installed SDK and related evaluation records

Current SDK: Payment SDK · 0.2.0-rc.2Python 0.2.0rc2 on PyPI · JavaScript 0.2.0-rc.2 from GitHub; npm publication pending. Exact response identity checks and total caller deadlines.
Local Payment API: API profile 0.1.0rc5Separately provisioned local evaluator for own-account USD movement. The current SDK matches this response contract; the RC4 OpenAPI remains a historical baseline.
Free browser exercise: Sandbox 1.0.0Fixed USD 10 HTTP fixtures with preserved RC4 clients. Installed Python and Node demos use the current SDK above.
Additional evaluation record: Evaluation 2.0.0-rc.1Historical RC4 client/engine checks and a separate Increase sandbox probe. Its version identifies that evidence record.

Evaluation only · no real funds in the free exercise · production NO_GO. SDK installation does not provision an API account or qualify a provider.

Python · PyPI

Python 3.12+. Install haltseal-payments 0.2.0rc2 in a fresh virtual environment.

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

On Windows, activate with .venv\Scripts\Activate.ps1 in PowerShell. Only Python is needed for this exercise.

JavaScript · GitHub release

Node 22+. Install the pinned 0.2.0-rc.2 release file in your project. npm registry publication is pending.

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

Import @haltseal/payments. Only Node is needed for this exercise.

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.

Verify release files or run both clients offline

The optional wheel and tarball mirrors retain the exact RC2 GitHub release bytes. Download the files and verify their SHA-256 before installing. Python users can also use the default PyPI path above.

RC2 offline Python wheel RC2 offline JavaScript tarball

printf '%s  %s\n' 'becd257048668520bec2ff13b31d62a36c14d0bd84ed65ed120b83825ed7d451' \
  'haltseal_payments-0.2.0rc2-py3-none-any.whl' | sha256sum -c -
printf '%s  %s\n' 'da620ee9432f7d124cb67364a620efb9e42f38948f19b9895d6dafc6ee84241c' \
  'haltseal-payments-0.2.0-rc.2.tgz' | sha256sum -c -
python -m pip install --no-index --no-deps \
  ./haltseal_payments-0.2.0rc2-py3-none-any.whl
npm install --offline --ignore-scripts --no-audit --no-fund \
  ./haltseal-payments-0.2.0-rc.2.tgz

For a deeper offline comparison, the pinned source quickstart builds and runs both installed clients against one local fixture. This optional path requires both Python 3.12+ and Node 22+.

git clone --branch v0.2.0-rc.2 --depth 1 \
  https://github.com/HALTSEAL/payments-sdk.git
cd payments-sdk
python3 tools/quickstart.py

Installing a client does not provision a payment evaluator, API account or signed approval.

Connect the separately provisioned local API

Request the RC5 local evaluator for a scoped technical evaluation. The server requires Linux, Python 3.12+, OpenSSL, SQLite and retained private storage. Preserve the operation ID, obligation ID and exact request before create. For a lost resume or cancel reply, read the existing attempt ID.

from haltseal_payments_sdk import UncertainDispatch

try:
    result = client.create_attempt(
        obligation_id,
        operation_id="cash-4822-original",
        route="A",
        approval_revision=1,
    )
except UncertainDispatch as lost:
    result = client.lookup_operation(
        lost.operation_id, obligation_id=lost.obligation_id
    )

Clients never select a fallback, follow redirects or automatically retry a financial call. HTTP 200 can carry HOLD or REFUSE. An earlier gateway that omits identity or complete record fields must upgrade its response contract before using SDK v2.

Preserved RC4 API baseline and fixture clients

These immutable records support the older API qualification and browser sandbox 1.0.0. They are separate from the latest SDK release. Archive metadata differs between the website and the historical GitHub RC4 release; use each release's own checksums.

RC4 Python fixture client RC4 JavaScript fixture client RC4 OpenAPI 3.1 RC4 failure contract RC4 customer acceptance RC4 checksums Current RC4 documentation manifest

Current RC4 documentation manifest SHA-256:

8f10ea0c4933c45f1e675fd14fb258afa9488c444d3ab782368317659a86c104

MIT applies to the published clients and fixtures. The kernel evaluator retains its separate rights. Commercial licensing, deployment and support require an agreed engagement.

PRESERVED RC4 API QUALIFICATION

The recorded API baseline.

The RC4 API record below is historical and separate from SDK v2 client checks. Its retained R2 regressions and API qualification used real loopback gateway, provider and witness processes.

Passing local tests: 144
Actual SIGKILL boundaries: 6
Fresh SDK installations: Python + JS

91 unchanged R2 tests + 53 payment API tests. Checks cover UNKNOWN → HOLD, PAID → REFUSE, closure plus a fresh approval → one eligible replacement, lost replies, restart, concurrent replacements, tenant access, source revocation and witness failure.

Local evaluation, production NO_GO.

Synthetic USD 10 own-account movement on one physical host. Native provider calls, customer installations and independent operators remain zero. Supplier payments, live bank/PSP integration, uncontrolled manual paths, distributed recovery and a 99.9% uptime SLO are not established.

Inspect the recorded qualification scope

FROM EVALUATION TO ACTIVATION

Start with one workflow.
Agree what comes next.

Bring the payment owner, the original path and every known replacement path. Start with a non-confidential description.

Developer evaluation
Try payment recovery for free and retain its synthetic record. Request the pinned local service to evaluate the payment kernel.
Shadow evaluation
Review the exact workflow and evidence without payment authority. Technical preparation is scoped separately.
Selective enforcement
Qualify provider evidence, path coverage and recovery. Obtain customer approval before activation.

See pricing and qualification Optional assessment brief

Start with the free Workspace Sandbox. Use the public SDK fixture to understand the API contract. Configured local evaluation and installed runtime access require their supported setup. Production pricing uses an agreed monthly base and new governed obligations after qualification and operating approval. Optional assistance is separately scoped. See pricing.