# Payment workflow and installation acceptance

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

Downloading an SDK or passing a local fixture is not customer acceptance.
Agree the workflow, supported environment, evidence and accountable owners
before evaluating an installation. An optional paid workflow assessment is
separate from access to the local evaluator.

## Define the customer boundary

Record the payment owner, source-approval owner and recovery owner. Identify
the real obligation and its payer, beneficiary, currency, full principal and
maximum debit. Declare every original, retry, fallback and manual release path,
including portals, file uploads, scheduled work and emergency overrides.

Agree the provider account and product, permissions, supported payment actions
and authoritative outcome evidence. Preserve existing paid and unresolved
history. A new reference, approval alias, route or installation cannot create
another right to pay. Hidden duplicate source records or uncovered payment
paths remain outside the control's premise.

Use the published SDK version and verify its checksums. Retain request identity
before calling it. Document application retry behavior, access scope and who
can approve a new attempt. The evaluator's installation and operator runbook
are supplied within the agreed technical review.

## Required customer-visible results

- Lost create reply: look up the same operation ID; do not create a new payment.
- Lost resume, cancel or recover reply: read the existing attempt ID.
- UNKNOWN, pending, empty, ambiguous or conflicting observations: retain the
  full principal and keep a replacement on HOLD. Absence is not closure.
- Repeated requests and concurrent payment paths: no additional full payment
  against the same remaining principal. Inspect decision after HTTP 200.
- Cancellation: wait for authoritative evidence that the exact original did
  not pay and cannot pay later. Submitting cancellation alone releases nothing.
- PAID: another full-principal payment is REFUSE.
- CLOSED: replacement requires a newer signed approval issued after retained
  closure and fresh validation. Closure alone does not authorize dispatch.
- Approval expiry or revocation: no new financial step; original inspection
  and recovery remain available under the documented access contract.
- Supported restart: preserve the existing obligation, attempt and uncertainty.
  Failed integrity or recovery checks require operator review, never a reset.

Retain sanitized requests, decisions and authoritative outcome evidence for
the agreed acceptance review. Keep credentials, private state and raw provider
records out of public forms. Detailed reproduction procedures and evaluation
records are supplied only within the agreed technical-review scope.

## Sign-off and repeat installation

The customer owner records the reviewed paths, evidence, exclusions and recovery
actions before approving that workflow. Customer approval must not be inferred
from owner-run tests. A repeat installation uses the same published SDK archives
and agreed instructions; a patched package requires a new reviewed version.

The current release records two local installations on one physical host, not
two customers or independent operators. Native provider calls, customer
installations and independent operators remain zero. Production is NO_GO.
Backup restoration, joint-history rollback, host migration, distributed
recovery and production disaster recovery are not qualified. No general
crash-recovery, durability or availability guarantee is established.