Frequently asked questions

An Agent can lose a payment reply while another Agent prepares a replacement through a different software path. HALTSEAL is designed to preserve the same original payment authority, reserved capacity and attempt history before the exact next release.

The current local reference uses synthetic own-account USD movement. For example, a lost reply leaves the original USD 10 reserved and the replacement on hold. Supplier-payment and check-to-ACH workflows need separate qualification.

The work can move to Agent B while the original payment identity, approval limit and attempt history stay together. An unresolved original remains UNKNOWN and reserved. A recorded PAID outcome continues to consume capacity.

In the supported installed profile, revoke A before B takes over and verify B's own signed receiving proof. Handoff grants no fresh payment limit. A replacement still requires authoritative no-effect closure, fresh financial approval and exact request validation.

These are separate boundaries. Login establishes account access. Company roles govern permitted administration. A source connection observes records. Agent assignment and receiving proof establish who takes over the work.

Original financial approval and current release eligibility are checked separately. A valid identity, connected invoice, receiving receipt or subscription cannot create payment approval or restore reserved or spent capacity.

Start with one workflow and the release paths your team can govern. More Agents can share the same original authority where their payment paths use the accepted control boundary.

A separate credential, manual bank portal or unconnected provider may remain outside coverage. Identify every relevant path and govern, restrict, assign responsibility for or explicitly exclude it. Connecting an Agent does not discover hidden routes or qualify the whole company.

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.

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.

Start with a free company Workspace Sandbox and one supported workflow. Connect the permitted Sandbox source, select one invoice and review the original authority and Agent handoff records. Use the supported installed profile for its exact-host and retained-original checks.

The public SDK demo and published Python and JavaScript clients run fixed synthetic HTTP fixtures. Local kernel evaluation requires a configured evaluator. Installed native reference checks retain their own Increase Sandbox scope; none of these results supplies customer operating acceptance.

Your designated operator investigates the exact original and obtains authoritative outcome evidence. A timeout or cancellation request alone does not prove closure. After accepted closure, a newer signed approval and exact replacement validation are still required.

HALTSEAL does not make a bank confirm faster. Evaluate the cost of repeated manual recovery, control maintenance and unnecessary holds using your actual workflow. The amount of an own-account transfer is not automatically an avoided loss.

Select Start free, sign in with Google or an email code, and create a company Workspace in Sandbox. No card or pilot purchase is required. Set up one supported source, choose one invoice and keep its next action with the accountable owner.

The separate public SDK demo needs no account and uses fixed synthetic USD 10 HTTP fixtures. It is useful for understanding the recovery contract; it does not run the installed Agent journey or qualify your workflow.

Yes. Try the illustrative handoff on the Workspace entry page, or use the prepared Workspace demo with the shared credentials displayed there. Each prepared-demo login receives an isolated, expiring synthetic session with simulated Agents. No real funds move.

The separate SDK sandbox uses fixed synthetic HTTP fixtures. These learning examples provide no company financial approval, signed Agent custody or installation qualification. Create your own free company Sandbox when you are ready to prepare a workflow.

Prepare one supported workflow and inspect its source records, original authority, Agent assignment and receiving evidence. Connections, approvals, Agent receipts and installed checks remain distinct steps.

Some checks require the supported installed host and package, permitted connector access or scoped evaluator access. A connected source or a successful local test does not activate Production payment control.

Name a company Owner, technical owner and accountable payment owner. Choose one invoice in the supported Sandbox source and retain the same payment identity, original approval and all included release paths.

Follow the connector and selected profile requirements. Installed execution needs its pinned host, package and retained original state. A receiving Agent supplies its own signed receipt. Use permitted synthetic or sanitized inputs and keep credentials out of inquiries.

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.

The supported BILL Sandbox connection observes source records and lets an authorized company select an invoice. Source identity and observed approval status are evidence to review; connection does not issue a new financial approval or authorize payment.

Controlled installed BILL tests and the actual Increase Sandbox reference retain separate scopes. Native BILL payment execution remains NOT_QUALIFIED, external customer acceptance remains NOT_PERFORMED and real-money Production remains NO_GO. A connection or installation pass cannot change those statuses.

Start with a non-confidential workflow outline. Workspace Sandbox and installed profiles have their stated access requirements. The public SDK demo uses fixed demo identities. Use permitted sanitized or synthetic inputs; do not place customer records or payment credentials in initial inquiries.

Any confidential exchange or customer-system access requires separately agreed handling and authorization. Keep credentials, private keys, financial account details, customer identifiers and raw provider responses out of initial inquiries and the online setup form.

Hana is an AI-generated public product guide powered by Anam. It can explain the product and help you find a useful next step. It cannot inspect private Workspace records, bank outcomes, orders or inboxes, issue a real ACCEPT/HOLD/REFUSE, or grant payment authority or operating qualification.

Anam and its providers process conversation text and permitted microphone audio. Conversations may be recorded or transcribed; closing the guide does not delete records already processed. Keep questions non-confidential and share no credentials or payment records. Contact Scott for customer-specific matters.

No. Source connection, original financial approval, Agent receipt, installed execution verification and operating approval are separate. Completing an earlier step cannot mark the next one approved. Production remains preparation only and live payment control is not activated.

Qualify provider semantics, the exact release coverage, retained-original recovery, security, operational ownership and independent review. Agree the scope and operating responsibilities before activation. The next action may be to gather evidence or keep existing controls.

Your trusted source owner establishes the common business reference and binds the payer, beneficiary, currency and full principal. Approval revisions and route changes must refer to that same transfer when they describe the same obligation.

HALTSEAL does not infer hidden duplicate obligations or import uncontrolled historical payments automatically. Your team must document aliases, reconcile existing unresolved history and identify every included or excluded release path.

For an already accepted pilot order, the 10-business-day delivery period starts when both parties accept readiness and the agreed kickoff. Payment reserves the standard evaluation; it does not start the delivery clock by itself.

Readiness covers the payment owner, engineer, shared payment mapping, permitted nonproduction setup, access, records and written scope. New prerequisites or scope changes require written agreement.

For an existing order, save your non-confidential setup after payment is confirmed. We review readiness and confirm a kickoff date by email. New standard pilot sales have ended; your accepted order terms remain intact.

If confirmation or email is delayed, return to the order page in the same browser and select Check payment again. Check the existing order before starting another purchase. From another browser, use the workspace link on your order page or in your confirmation email and verify the checkout email.

Keep your order reference. If you cannot find the order or need help, contact scott@haltseal.com. Card details go directly to Stripe; share no card details or credentials with us.

New standard pilot sales have ended. These cancellation and refund provisions describe existing accepted orders; their originally accepted agreement governs.

Cancel before kickoff for a full refund. If readiness review finds the standard pilot cannot cover your workflow and no acceptable kickoff is agreed, we cancel and refund the pilot fee.

After kickoff, only work actually performed, delivered and materially conforming to the agreed scope earns its allocation: written workflow scope $500, recovery test records $1,500, written integration decision $500. Uncompleted or materially nonconforming milestones are refunded if work stops. Silence does not count as acceptance. Extra work requires a separate agreement.

Report a material defect within 30 days after delivery of the affected milestone. We correct or reperform it without extra charge within 10 business days after receiving enough detail to investigate, or a different period you accept in writing. If we cannot, the affected milestone fee is refunded. A correct adverse or inconclusive finding is not a defect merely because it is unfavorable. Mandatory rights remain intact.

Contact scott@haltseal.com with your order reference. Refunds return through the original payment method; bank posting time depends on the payment provider.

Workspace Sandbox is free and does not convert automatically to a paid plan. Production uses an agreed monthly base plus new governed obligations after scope qualification and operating approval. Platform uses an annual agreement and committed volume.

Current Sandbox metering records observations only. Live Production subscriptions and usage charging are not activated. Rates, scope, billing period and any commitment are agreed in writing before charges begin. Optional implementation assistance is separately scoped.

One new unique source-owned payment commitment admitted to the agreed operating scope counts as one obligation unit. The same payer, beneficiary, currency and principal remain tied to its canonical identity across included paths.

Retries, Agent handoffs, lookups, repeated HOLD decisions and a replacement for that same obligation do not create additional units. Sandbox exercises and imported historical records do not produce retrospective Production usage charges.