Marketplace Payment

Marketplace payment is manual-first and enterprise-gated. The goal is to let a buyer choose a quote, create an order, have manual payment proof reviewed by operations, and open the production gate in a controlled way.

Marketplace payment and order mutations use server-side idempotency. Retrying the same action should return the first recorded response; reusing the same key with a changed request is rejected instead of creating duplicate work.

Manual-first flow

1. The buyer compares quotes.
2. The buyer chooses one quote.
3. The order is created with payment_pending and not_started production state.
4. The buyer shares proof or terms for bank transfer, open account, or agreed corporate payment.
5. Operations or finance admin manually approves or rejects the payment.
6. Approval moves the order payment status to approved and opens the production gate.
7. Production can move to in_production only after payment approval.
8. PrintTalk, print-shop bridge jobs, PDF Tools, Edge Hub, XJDF execution, and fulfillment remain out of scope for this phase.

Supported public methods

The public/self-service payment surface keeps methods narrow:

• Bank transfer
• Open account
• Manual payment approval by operations

document_payment, check, deferred_terms, and direct_deal exist as supplier-terms contract vocabulary in the marketplace package. They are not public checkout choices; they require an operator-approved corporate terms or import scenario.

Evidence and retry guarantees

Payment verification, supplier terms confirmation, and production-stage updates use server-side idempotency. A retry returns the first recorded response; reusing the same key with changed content is rejected. If a committed response carries x-marketplace-idempotency-recovery, keep the same key and exact request body: retryable means an exact retry may start immediately, while lease-pending means abandoned transport ownership will be reclaimed after its bounded lease. Response and audit summaries do not expose raw idempotency keys, actor ids, provider secrets, or local file paths.

Marketplace APIs also use a shared distributed admission limit before route processing. A 429 response includes Retry-After; wait for that duration and retry the same idempotent request without changing its key or body. A 503 MARKETPLACE_ADMISSION_UNAVAILABLE is fail-closed protection: do not start a new payment attempt, and retry the exact request after the indicated delay. No raw client IP is stored by this control.

Internally, a captured provider callback must produce one balanced settlement journal, reconciliation result, restricted audit record, and durable payment event in the same transaction. Provider tokens and callback bodies are stored only as hashes. This preparation is an integrity control; it does not mean card checkout is public-enabled.

Provider inbox records, settlement journal/posting records, reconciliation snapshots, and the settlement-event copy required for exact replay are classified as financial evidence. The delivery outbox may reset with pilot aggregates, but this evidence is excluded from bulk marketplace resets; corrections require new traceable records.

Not promised in this phase

• Card checkout
• Platform-held escrow funds or escrow release automation
• Automatic payment provider integration
• Automatic refund or payment dispute screens
• Automatic production or handoff after payment confirmation

Provider-neutral contracts may exist behind the gated package surface, but they are not public enablement. These capabilities are not part of the current public promise.

When does an order enter production?

An order existing does not by itself mean production has started. Payment approval opens the production-release gate; only after that can operations advance the production state. Automatic print-shop job creation and fulfillment integration are not promised in this pilot.