PAYMENT SDK SANDBOX
Try the synthetic SDK demo.
One obligation. Two payment paths. Run six SDK steps to see why an uncertain original keeps the backup on hold.
Real HTTP. Fixed USD 10 fixtures. No real payment.
Browser exercise 1.0.0 · frozen RC4 client. Install and run SDK RC2.
The recovery exercise
Six steps. One retained history.
- 01Original
- 02Hold
- 03Closure
- 04Recheck
- 05Replace
- 06Refuse
YOUR NEXT SDK STEP
- 01
Recover the lost reply.
The original request loses its reply. Look it up with the same operation ID; a lookup sends no payment.
- 02
Hold a different route.
Submit B for the same obligation while A remains UNKNOWN.
- 03
Observe original closure.
Add a synthetic no-effect closure, then read the original through the SDK. The backup stays unsent.
- 04
Check the old approval.
Restored capacity alone does not approve the next payment.
- 05
Validate a fresh replacement.
Add fresh fixture approval, then submit the backup and observe its predefined PAID response.
- 06
Keep paid history.
A new operation and route cannot create another right to pay.
One obligation.
One right to pay.
You recovered the original, checked a fresh replacement and refused a second payment in this synthetic exercise.
Start a free session to enable your first step.
15-minute isolated session. You control each step.
WHY THIS DECISION
The original’s history stays with this obligation, even when the request or route changes.
- Available principal
- $10.00
- Synthetic dispatches
- 0
- Lookup redispatches
- 0
Inspect the SDK response
{"status": "Start a free session"}Inspect SDK request events
[]If a read or receipt is uncertain, the exercise pauses. Starting another synthetic session repeats this example; it does not recover a real payment.
Run it in your terminalLATEST CLIENTS · SDK V2 0.2.0-rc.2
Run the latest recovery clients.
Choose Python 0.2.0rc2 from PyPI or JavaScript 0.2.0-rc.2 from GitHub. Each installed demo runs the six recovery steps with only its own language runtime. npm publication remains pending.
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.jsonOn 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.jsonImport @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.
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.
PRESERVED BROWSER FIXTURE · 1.0.0 · RC4 CLIENTS
Replay the preserved
browser fixture locally.
Download one pinned bundle. It contains a dependency-free synthetic HTTP host, the existing MIT SDK archives and Python/Node recovery examples. The proprietary payment kernel is excluded.
Prefer a source checkout? The official SDK repository runs both installed clients with python3 tools/quickstart.py and includes shared failure checks and versioned releases. The current repository supplies SDK v2; the downloadable 1.0.0 bundle below retains RC4 clients. Both use fixed synthetic recovery fixtures.
1. Start the fixture host.
unzip HALTSEAL_SDK_Sandbox_1.0.0.zip
cd haltseal-sdk-sandbox-1.0.0
# Compare SHA-256 with the published release record.
node server.mjs --state ./private-demo-stateNode.js 22+ is required for the host. It listens only on 127.0.0.1:8799. Use a fresh private state directory.
2. Run your SDK.
# Python 3.12+, in another terminal:
python3 -m venv .venv
.venv/bin/python -m pip install --no-index --no-deps \
haltseal_payments_evaluation-0.1.0rc4-py3-none-any.whl
.venv/bin/python demo.py# Node.js 22+, in another terminal:
npm install --offline --ignore-scripts \
haltseal-payments-evaluation-0.1.0-rc.4.tgz
node demo.mjsEach example creates its own demo session, uses original lookup after 503 and writes a synthetic result file. No registry or provider account is needed.
Bundle identity and scope
Trusted bundle SHA-256: eca76eecdb19e967bfc9cf3c74168be8f205cfc35903ef6dac548c621614d9d3. The manifest pins the bundle contents and unchanged public SDK bytes. Fixture records contain generated demo identities and do not establish native-provider safety or customer savings.
SANDBOX V2 · BOUNDED EVALUATION
A deeper check.
A separate release.
Beyond the browser fixture: the recorded RC4 Python and Node SDKs were installed separately and exercised through the retained payment engine. A separate Increase sandbox probe checks the native cancellation boundary.
Retained engine · passed locally.
Lost create, cancel and resume replies. Restarted history. Eight competing replacements with one admitted release. Original and replacement created once each; lookup sent no payment. Paid history refused every further route.
The engine campaign uses fixed USD 10 own-account movements and synthetic provider effects. Two local installations are recorded; independent customer installations remain zero.
Increase contract · passed in sandbox.
Discarded create ID recovered by original lookup. Pending-approval original canceled and reobserved. Reapproval of the canceled original and cancellation of a submitted successor both rejected with HTTP 409.
One fictional entity, simulated funds, one provider. The submitted successor remains unresolved. Native engine integration and cross-provider recovery are not qualified.
Version 2.0.0-rc.1 · Production NO_GO. Engine source and the reproducible v2 bundle are available through restricted evaluation. Supplier payments, customer adoption, bank finality and an availability target are not established by these checks.
FROM THE EXAMPLE TO YOUR WORKFLOW
Does another path
reach the same obligation?
Open a free company Workspace Sandbox to set up one supported workflow, review Agent handoff and installation evidence, and identify what remains before qualification. This SDK demo uses fixed synthetic fixtures and does not qualify that workflow.