# One obligation, one full principal

Public documentation revision 3 · October 7, 2026
Applies to Payment API 0.1.0rc4. SDK and OpenAPI bytes are unchanged.

## Source authority and identity

An issuer-signed source binds the organization, workflow, canonical business
reference, payer, beneficiary, economic effect, currency, full principal and
maximum source debit. The source uses the evaluator's Ed25519 approval contract.
Unsigned amounts and AI cost budgets cannot create payment approval.
Approval revisions cannot change the obligation's immutable economics.

Use the returned obligation_id for every attempt. Approval aliases, request
IDs and routes do not create principal. The trusted source owner must establish
which records describe the same real obligation. HALTSEAL cannot discover
hidden duplicate invoices, payments outside coverage or duplicate authority
created in independent installations. Customer and role scope come from the
provisioned key; callers cannot select another customer's authority.

## Interface

Read https://haltseal.com/docs/payments/ for endpoint purposes and examples.
The unchanged versioned OpenAPI defines exact paths, schemas and parameters:
https://haltseal.com/developers/payments/releases/0.1.0-rc.4/openapi.json

Create an attempt with the obligation_id, a durably retained operation_id,
reviewed route and current approval_revision. Recover and cancel require {}.
Resume requires the current approval_revision. Amounts use integer minor units;
signed-source timestamps use integer nanoseconds. JavaScript must send the
issuer's original signed JSON string without parsing or rewriting it.
Unknown fields, duplicate JSON keys, invalid revisions and oversized bodies
are refused. Keep API and issuer keys on the trusted backend.

## Decisions and original recovery

Inspect decision and the retained attempt state even after HTTP 200.
ACCEPT records a release decision; it is not a new grant on every read or
proof of settlement. Exact repetition reads the existing decision without
redispatch. Changed route, revision or obligation under the same operation ID
produces HOLD for request-reuse mismatch.

UNKNOWN retains the full principal. A replacement is HOLD. Recovery refers to
the exact original and does not resend creation. Empty, ambiguous, stale or
conflicting observations cannot establish closure or restore principal.
PAID consumes the obligation. Another full-principal payment is REFUSE.

CLOSED requires authoritative evidence that the exact original did not pay
and cannot pay later. Cancellation submission, timeout, fee refunds and final
AI-job cost do not establish it. Replacement needs a newer signed approval
issued after retained closure and fresh checks of the original evidence,
current approval, expiry, revocation, route and full amount. Closure restores
eligibility for those checks; it does not automatically authorize replacement.

The unchanged SDK_RECOVERY.txt defines retained caller identity and failure
actions under the original 0.1.0-rc.4 release URL. This documentation revision
provides INTEGRATION_ACCEPTANCE.txt for customer workflow and installation
gates, and OPERATIONS.txt for safe actions and supported deployment boundaries.

## Qualification

This is local, synthetic, one-host evaluation, not production payment control.
Native provider calls, customer installations and independent operators are
zero; production remains NO_GO. Backup restoration, history migration,
joint-history rollback and distributed recovery are not qualified. Preserve
history and unresolved exposure through any separately reviewed cutover.
An independently executable path outside the boundary remains a coverage gap.