# Payment API operations and recovery

Public documentation revision 3 · October 7, 2026
Applies to Payment API 0.1.0rc4 local evaluation.

## Supported environment

The complete evaluator requires Linux, Python 3.12+, OpenSSL, SQLite and
persistent private local storage. Use one operator-managed service on one
physical host. The SDK archives alone do not supply a running service.
The free SDK sandbox uses fixed HTTP fixtures and does not run the payment kernel.

Keep the same configured service and retained history across normal restarts.
Do not run competing service instances or create a fresh environment to recover
an existing payment. A directory copy does not transfer payment authority.

## Customer recovery actions

Persist the operation ID and exact request before creating an attempt.
After a lost create response, look up that original operation ID. After a lost
resume, cancel or recover response, read the existing attempt ID. Retain the
identity if lookup is absent or unavailable. Do not switch IDs, routes or
providers as a recovery strategy, and do not call a provider directly.

UNKNOWN keeps the full principal reserved and replacements on HOLD. PAID
consumes the obligation and a second full payment is REFUSE. Cancellation is
a request until authoritative evidence establishes that the exact original
has not paid and can no longer pay. Replacement then requires a newer signed
approval issued after closure and fresh validation. ACCEPT is not settlement.

Use read-scoped keys for inspection and original recovery. New attempts and
source ingestion require current execute authority. Cancellation additionally
requires current execute authority and an active evaluator session. Inspection
and original recovery remain available after commercial entitlement expiry;
new financial steps require current entitlement.

## Maintenance and support

Before maintenance, pause callers and follow the supplied evaluator runbook.
Retain the complete original history. If startup, integrity checks or recovery
fail, stop new financial work and contact the evaluation operator. Do not reset
history, repair private state by hand, or release an unresolved reservation.
Provide the release, operation/attempt reference and sanitized error through
the agreed review channel. Keep credentials, signing keys, private state and
raw provider records out of public forms and support attachments.

Installation, credential handoff and operator recovery procedures accompany
the pinned evaluator under agreed technical-review scope. Public SDK failure
instructions remain at https://haltseal.com/docs/payments/#errors.

## Unqualified boundaries

This release covers synthetic USD 10 own-account movement on one physical host.
Provider and recovery processes share that host's failure domain. It does not
qualify backup restoration, migration, recovery after a host or boot change,
joint-history rollback, distributed availability or production disaster recovery.
Do not assume any of those operations restores authority to execute.

Native provider calls, customer installations and independent operators remain
zero. Production is NO_GO; no live-money activation or uptime SLO is offered.
Production requires separately qualified provider evidence, complete path
coverage, retained history, recovery ownership, customer acceptance and an
agreed service/license scope. An uncovered bank portal remains outside control.