PAYMENT SDK · EVALUATION PRERELEASE

Install the SDK. Run recovery.

Follow one original payment through uncertainty, closure and a fresh replacement. Keep the synthetic result from the client you installed.

Choose Python or Node
Internet connection
No account or real funds

Prefer to start without a terminal? Try payment recovery in your browser.

1. Install and run one client.

Use Python 3.12+ or Node 22+ for your chosen language. Python RC2 is published on PyPI. JavaScript RC2 uses its pinned GitHub release file while npm registry publication is 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.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.

2. Inspect the recovery result.

A successful run completes six steps and writes python-sandbox.json or javascript-sandbox.json in your current directory. Open the file and keep it with the SDK version you ran.

Step	Expected result	What to inspect
Original lookup	Recover the original	Look up its retained identity without sending it again.
Original UNKNOWN	HOLD	The unresolved original keeps the replacement on hold.
Original closure	Closure recorded	Closure permits a fresh eligibility check; it does not authorize a replacement.
Stale approval	HOLD	An approval from before closure cannot release the replacement.
Fresh replacement	ACCEPT	A newer approval and exact validation permit one synthetic replacement.
Obligation paid	REFUSE	A paid obligation cannot create another full-principal payment.

Expected totals: two synthetic dispatches across the authored exercise, including the original and its replacement. Zero original-lookup redispatches. These are fixture actions; no money moves.

Keep the original identity. A lost reply is uncertainty. Recover the recorded operation before considering another financial action. Read the SDK recovery contract for the installed client's error and recovery instructions.

If the exercise stops.

Runtime requirement: check your Python or Node version. Only the runtime for your chosen client is needed.
Existing output file: choose a new filename with --output. Existing records are never overwritten.
Network or fixture failure: retain the reported error. Restore access to the fixed HTTP fixtures before rerunning the synthetic exercise with a new output filename.

For an application integration, preserve the SDK's recorded identity and recovery action after an uncertain response. Use the response and error guide before issuing another payment call.

3. Bring the contract to one workflow.

This quickstart runs published clients against fixed synthetic HTTP fixtures. Installation does not provision a payment account, run the payment kernel or qualify a bank or provider.

Evaluate your own code

Connect two application paths to the unchanged SDK. Request the scoped local evaluator and review one decision record.

See pricing and qualification

Production enforcement requires provider and workflow qualification, accepted operations and customer approval. The free exercise uses no real funds.

Component versions and release integrity

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 on PyPI SDK release and source SDK checksums Offline release files

Next stepUnderstand original recovery