Add contract-to-backend-to-client payment journey tests #284

Objective

Deliver add contract-to-backend-to-client payment journey tests as a production-ready capability for QuickEx. This is an advanced issue: preserve self-custody, the documented API contracts, and the financial invariants while handling failure and rollback paths.

Scope

• Trace the owning implementation across app/frontend, app/backend, app/mobile, and app/contract as applicable.
• Replace mocks or placeholders with the smallest maintainable production design.
• Define authorization, idempotency, validation, observability, and degraded-mode behavior.
• Update the relevant capability map, contract map, or release documentation.

Acceptance criteria

• The behavior is implemented end to end for the supported network and is explicitly feature-gated where it is not ready for mainnet.
• Unauthorized, duplicate, expired, malformed, and dependency-failure cases are covered with stable errors.
• Tests cover the happy path, boundary conditions, retries, and recovery or rollback behavior.
• Metrics and structured logs make success, latency, and failure diagnosable without exposing secrets or unnecessary personal data.
• Documentation names the changed contract, configuration, migration, and operational procedure.

Workstream

Testing and quality engineering

References

Start with docs/CAPABILITY-MAP.md, docs/BACKEND-CLIENT-CONTRACT-MAP.md, and docs/INVARIANTS.md; use the owning module and neighboring tests as the implementation authority.

Contributor notes

Before opening a PR, record assumptions about network, custody, and backward compatibility. Include test commands and any follow-up migration or rollout issue in the PR description.