Connect the source.
Select a BILL Sandbox invoice. Source access identifies the record; the original financial approval is supplied separately.
Payment authority across systems
Change the Agent.
Keep the authority.
One payment. One authority.
For financial teams and engineers handing work between Agents.
Free Workspace Sandbox
Sign in. Set up one workflow.No card. Live payment control requires qualification.Different paths. One shared limit.Illustrative
One shared transfer statecash-request-4822 · USD
Own-account transferAuthorized once · synthetic
$10.00Original requestSoftware path AReply lost. May still pay.
UNKNOWN
Backup requestSoftware path BSame transfer
HOLD
HALTSEALBefore release
- Reserved
- $10.00
- Paid
- $0.00
- Available
- $0.00
Choose an original outcome
Each outcome starts a new fictional example.
HOLDOriginal outcome unresolved. No second dispatch.
The original may still pay. Its $10.00 stays reserved.
Available capacity is not release permission.
The path can change. The right to pay stays bounded.
ONE INVOICE. ONE CONTINUOUS AUTHORITY.
Agents change.
The approval stays.
Follow one company approval through source setup, Agent handoff and recovery. The original approval and payment history stay together.
Hand over the work.
Revoke A’s new access. B supplies its own signed receiving proof. The original payment may still settle, so its reservation remains.
Keep the history.
UNKNOWN stays reserved. PAID stays consumed. Verify the installed host, current authority and exact request before another release.
Workspace shows the next action and accountable owner. Live payment control requires separate qualification and operating approval for the exact workflow.
ONE ORIGINAL OBLIGATION
Change the Agent.
Keep the original limits.
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.
What is needed next
- Retrieve the exact original outcome.Payment operations
- Establish that the original cannot still pay.Qualified source or provider reviewer
- Reconcile the original and obtain fresh financial approval.Authorized financial approver
- Recheck the exact proposed replacement.The qualified execution control
Elapsed time, a handoff and a cancellation request do not prove that the original cannot pay. No automatic retry follows this example.
FROM FIRST LOOK TO OPERATING SCOPE
Start with one workflow.
Keep every next step clear.
Explore in Sandbox, review the evidence, then qualify the exact scope you intend to operate.
- 01
Start free.
Sign in and create your company Sandbox. No card required.
Start free - 02
Set up one workflow.
Connect the supported Sandbox source, select one invoice and name its owner. Source access is separate from financial approval.
See the setup steps - 03
Review the evidence.
Check original authority, Agent receipt, installation and recovery evidence. Missing evidence stays visible.
What is verified today - 04
Qualify operations.
Agree coverage, recovery ownership and operating approval. Live payment control remains gated.
Request qualification
Sandbox use is free. Production pricing is a monthly base plus new governed obligations after an agreed scope and operating approval. See pricing and what counts.
The decision at release
One payment.
Three decisions.
HALTSEAL checks whether the exact proposed payment is still eligible for release. Your banks and platforms move the money.
Release once.
One bounded release under current conditions. Settlement and future eligibility remain unconfirmed.
Wait for required evidence.
Keep the request before release while required evidence or state remains unresolved.
Keep an ineligible request out.
The request is ineligible under current conditions. This does not by itself indicate fraud.
No generative model decides ACCEPT, HOLD, or REFUSE.
Start with what you have
Keep your stack.
Keep one payment limit.
Your existing controls may already be sufficient. Check whether every connected path preserves the same payment limit through uncertainty and recovery.
Within one provider
One key.
One guaranteed scope.
RequestSame keyProvider A
Provider idempotency protects retries within its guaranteed scope.
Across independent paths
New paths.
The same obligation.
Provider AProvider BBank portalOne reservation to verify
Check whether every relevant path preserves the same payment limit. An unconnected path remains outside coverage.
Existing controls can pass without HALTSEAL. Findings apply to the paths and conditions tested.
Who resolves a HOLD?
Your operator owns the investigation. Retrieve exact-original outcome evidence, confirm whether it can still pay and obtain a newer signed approval after accepted closure. Revalidate the proposed replacement before release.
What makes the evaluation useful?
A recovery project, repeated manual decisions or controls maintained across several software paths. Evaluate engineering work, operational effort and unnecessary holds. HALTSEAL does not make a bank confirm faster; transfer size alone is not an avoided loss.
Review the next qualificationRead the full payment workflow
Understand idempotency across providers
How it fits your payment stack
Existing controlMay be sufficient whenWhat to verify
Provider idempotency
May be sufficient whenRetries stay within the provider’s guaranteed key scope.
What to verifyDoes another provider or manual path escape that scope?
Shared reservation
May be sufficient whenEvery payment path enforces the same reservation through uncertainty and recovery.
What to verifyDo concurrent requests, restarts and rescue paths preserve it?
Manual recovery
May be sufficient whenReliable outcome evidence gates every replacement payment.
What to verifyDoes the rule hold across operators and bank portals?
| System | Remains authoritative for | HALTSEAL does not replace it |
|---|---|---|
| Identity provider | Actor identity | Authentication |
| Authorization and approvals | Permitted scope | Approval workflow |
| Risk and fraud system | Risk judgment | Fraud scoring |
| Orchestrator | Route selection | Routing |
| Bank or payment provider | Provider-local execution and outcome evidence | Fund movement |
| Provider idempotency | Repeated key within its domain | Provider-local deduplication |
| Ledger and reconciliation | Recorded and authoritative outcome state | Accounting or settlement record |
| HALTSEAL | Cross-route obligation eligibility immediately before release | Any of the above |
Explore integration, request scenarios and technical scope
See it in your workflow
Different paths.
One approved amount.
A replacement can look like a new payment. Follow the obligation to see whether it has the right to pay.
Available to evaluate today
Evaluate your code
Connect your recovery code for local, synthetic USD 10 movement between owned accounts. Live bank/provider integration and production control require separate qualification.
One cash-movement obligationOwned accounts · CASH-4822
Illustrative authority$10 USD
- Reserved
- $10
- Paid
- $0
- Available
- $0
Original · Path A
UNKNOWNNo confirmation. The original may still move the funds.
Replacement · Path B
HOLDA separate USD 10 movement for the same obligation.
- Same obligation?
- Yes
- Could the original still pay?
- Yes, unresolved
- May a new effect proceed?
- No, capacity reserved
HOLD
The original may still move the funds. A different path does not create another USD 10 of authority.
Illustrative decisions. No provider calls or money movement. ACCEPT reserves one simulated release; settlement remains unconfirmed.
PUBLIC SDKs · SYNTHETIC EVALUATION
See the recovery contract run.
Recover the original. Hold an uncertain replacement. Refuse another payment after the obligation is paid. Run the published clients against fixed HTTP fixtures and keep the result.
Published on PyPI
Python
0.2.0rc2 · Python 3.12+
Install the pinned package, then run recovery from your terminal.
Run the Python quickstartGitHub release
JavaScript / TypeScript
0.2.0-rc.2 · Node 22+
Install the release file. npm registry publication is pending.
Run the JavaScript quickstartNo installation
Browser
Free recovery exercise
Follow the six-step fixture flow and download its synthetic record.
Try payment recoveryNo HALTSEAL account, provider credentials or real funds. Installation supplies an evaluation client; it does not connect a bank or activate payment control.
Workflow Evaluation Kit
Your code.
One decision record.
Connect the original and replacement paths in your recovery code. Evaluate their behavior against the supplied local engine.
Review the integration map, recovery observations and next decision with your engineer and payment owner.
Evaluator supplied by request for its supported scope. No pilot purchase is required to start Sandbox.
Current profile: synthetic USD 10 between company-owned accounts. Live bank/provider integration and production control require separate qualification.
- 01 / ConnectYour recovery codeOriginal software pathReplacement software path
One shared transfer reference.
- 02 / EvaluateHALTSEAL local evaluator
Published SDK · synthetic fixtures
HOLDACCEPTREFUSE - 03 / ReviewOne record for your team
Integration map · execution report · next decision
No real funds or live bank connection. ACCEPT does not confirm settlement.
Exact-original recovery in the Python SDK
A lost create reply does not justify another financial request. Look up the operation your application retained, then recover that exact attempt. The local evaluator supplies a scoped key, signed source and configured fixture routes; the public SDK install supplies the client.
Python SDK · configured local evaluator
from haltseal_payments_sdk import Client
client = Client("http://127.0.0.1:8790", api_key)
original = client.lookup_operation("cash-4822-original")
observed = client.recover(original["attempt_id"])
# Recovery does not resend the financial create.Prerequisite: the original operation was saved before sending. Set up the evaluator and read the recovery contract.
From evidence to authority
Earn the right
to enforce.
Each stage is a separate decision. Keeping your existing controls may be the right outcome.
- 01
Developer evaluation
Start with the interface.
Inspect the payment contract and SDKs, or run the free Lab. Evaluate original recovery and replacement decisions against local fixtures before scoping your installation.
Local evaluation · paid assessment optionalRead the payment API docs - 02
Shadow
See what HALTSEAL would decide.
Review proposed payments beside existing decisions. HALTSEAL has no payment authority.
Offline review availableInspect a decision record - 03
Selective enforcement
Grant authority where justified.
Technical validation and your approval are required before HALTSEAL can gate a defined payment class.
Future · separate qualificationReview the conditions
Live Shadow capture, native bank/provider integration and production control remain unqualified. Broader authority requires its own evidence and approval.
Would HOLD
Preview the consoleSee the decision in a team’s workflow.Console design preview · fictional data · no payment authority.
INSTALLED WORKFLOW EVALUATION
Install once.
Keep the original through recovery.
Evaluate one own-account USD workflow on Linux, with an agreed source of approval and two software paths.
Your workflow, bound to the installation.
The Workspace records the selected company, Sandbox environment, workflow and registered host key. The reviewed kit installs code; your retained runtime and original provider identities stay with the same workflow.
Recovery and evidence your team can inspect.
Exercise a lost original reply, a held replacement, exact-original recovery and same-release reinstall. Review incident controls and independently verifiable authority history under the selected release profile.
Current native reference: Increase Sandbox, fictional own-account USD 10, one Linux execution host and two paths using Increase. Customer installation, the public Workspace journey and any combined control profile require their own acceptance evidence.
Read the illustrative pilot report for the path map, recovery observations and assigned next work.
Optional enterprise review / Paid workflow assessment
One payment exception.
Four written outputs.
Know what to keep, fix or investigate before changing the workflow.
Start with one payment exception or a planned fallback change. Review the agreed records with the payment owner, then use the findings to decide the next step.
Scope, timing and fees are agreed before paid work. Document review requires no installation. Technical testing is scoped separately.
Timeline
What happened, in what order, from the agreed records.
Path map
The original path, known replacements, manual handoffs and review boundaries.
Evidence and gaps
What the records support, what is missing, and what remains inconclusive.
Next action
The next action, responsible owner, and condition to resolve.
Labs · AI execution preview
One job. One budget.
Keep the approved budget attached to the same AI job across retries, agents and provider changes. Inspect the SDKs and the recovery contract. Request a local evaluation for one workflow.
Python + JavaScript/TypeScript SDKs · Local evaluation · RC15.3 candidate
THE FINAL EXECUTION BOUNDARY
Control immediately before release.
Final execution boundary: the last controlled point before a payment can be sent. HALTSEAL checks the exact payment and returns ACCEPT, HOLD, or REFUSE.
HALTSEAL does not move funds. Evidence can restore eligibility. It does not authorize release. Explore the control model.
What the release check examines
- 01
Buyer-defined payment obligation
Your source owner establishes one authorized transfer across requests, workers and routes. Changing a request or route does not create another right to execute it. HALTSEAL cannot discover hidden duplicate obligations or control an unconnected path.
- 02
Exact final payment
What complete payment is about to be released?
- 03
Current authority
Is the relevant authority current at the time of release?
- 04
Prior outcome
Can an earlier attempt still complete?
- 05
Governed route
Does this path enforce the same payment limit?
These inputs are evaluated deterministically. The decision may change when authoritative state or evidence changes.
EVIDENCE BEFORE OPERATING AUTHORITY
Know what is proved.
Know what comes next.
Review the evidence for the exact workflow, then qualify its connected payment paths, recovery ownership and operating conditions.
Recorded engineering checks: Original recovery, uncertain replacements and retained authority have separately scoped records. Inspect the cases and exact scope.
Installed reference evidence: Later releases add native Sandbox recovery, retained incident controls and independent authority-history verification. Review the installed release scope.
Current stage: Free Workspace Sandbox and supported, scoped evaluations are available. Production enforcement requires separate qualification; real-money production is not approved.
Run the SDK quickstart for fixed synthetic HTTP fixtures. Read the Workspace setup guide for the separate source, approval and installation requirements.
Buyer review contents and integration requirements
What you receive
A buyer brief, reported local results, evaluation questions and blank workflow and decision worksheets.
Before an integration
An identified need, reliable outcome evidence, complete in-scope path coverage and an accepted recovery plan with accountable owners.
The Payment API's local reference concerns own-account USD cash movement: synthetic USD 10 inputs, fixed economic binding and a preserved R2 principal ceiling of USD 20. Supplier invoices, real transfer amounts and live bank or PSP paths need separate qualification. Inspect the published API baseline.
RC15 R1 engineering and the API local reference do not qualify a customer workflow. The earlier separate Increase sandbox probe is a provider-contract check. Later installed native reference results have their own release scope and evidence; they do not qualify a customer or cross-provider payment path. Customer safety and economic value require workflow-specific evidence.
See Evidence for scope exclusions and unqualified capabilities.
For separately scoped testing, review preparation and testing conditions.
Before an integration
Questions about your existing stack?
We already use idempotency. Do we need HALTSEAL?
Your existing controls may already be sufficient. Provider idempotency protects retries within its guaranteed scope. A shared ledger or reservation can also be sufficient when every relevant software path preserves it through uncertainty and recovery.
Evaluate whether new request IDs, replacement paths and restarts preserve the original identity and shared reservation. A workflow review can recommend keeping your current controls. It does not establish that your existing software is inadequate.
Link to this answerDoes HALTSEAL move money or replace our payment platform?
Banks and payment platforms move the money. HALTSEAL's role is to check the exact proposed payment immediately before a governed release. Your team retains its payment systems and defines which release paths are included.
The public SDK demo sends no real payments. Workspace Sandbox setup does not connect a live bank account or activate Production payment control.
Link to this answerWhich source and execution paths are qualified?
Source access, controlled financial-bridge tests and installed native reference results have different evidence scopes. Connecting BILL source records does not qualify native BILL payments. A bank or provider name alone does not prove coverage of every release path.
The native installed reference uses fictional own-account USD 10, one Linux execution host and two Increase Sandbox paths. Customer acceptance, cross-provider production control and a production availability commitment require separate qualification. Any manual or external path must be governed, restricted, owned or explicitly excluded.
Link to this answerSTART WITH ONE WORKFLOW