The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.
| # | Surface | Action | Capability | Expected | Provenance |
|---|---|---|---|---|---|
| 1 | /console/{tenantId}/accounting/payments/receive | Select the customer, invoice, card method and merchant destination, then open hosted entry. | CAP-ACC-TRX-007 | The selected processor supplies its collection fields. | test |
| 2 | /console/{tenantId}/accounting/payments/receive | Enter the instrument through the processor and confirm payment. | CAP-ACC-TRX-007 | The attempt precedes capture and successful money becomes a numbered receipt. | test |
| 3 | /console/{tenantId}/accounting/payments/{paymentId} | Inspect the resulting payment. | CAP-ACC-TRX-008 | Instrument display context accompanies its application and the settled invoice. | test |
| Path | From step | Condition | Path taken | Outcome | Provenance |
|---|---|---|---|---|---|
| alternate | 2 | The capture response is lost after external success. | Repeat the original request or allow scheduled lookup to establish the outcome. | The existing capture becomes one receipt without another charge. | test services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it answers the payment to a replay of the same key, from what the processor holds, with no second charge |
| alternate | 2 | All scheduled lookups remain inconclusive. | An attention item asks staff to verify and decide failure or settlement. | Definite failure permits another attempt and confirmed settlement records the receipt once. | test services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it frees the invoice and the card for a new attempt under a new key, charged once |
| failure | 2 | The processor definitely declines. | The dialog explains the response and retry starts fresh hosted entry. | Debt remains outstanding and another instrument can be tried. | test |
| failure | 1 | The merchant account became inactive after page load. | Financial validation stops the attempt before charging. | No collected money results. | test |
| Id | Statement | Provenance |
|---|---|---|
01 | One attempt cannot create duplicate captured receipts. | test services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it replays the same key and body as the same payment, charging nothing more |
02 | A definite decline retains debt without recording payment. | test services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it refuses processor_declined and fails the intent with the processor’s code, writing no payment |
03 | Uncertain response recovery queries the prior attempt rather than charging again. | test services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it answers the payment to a replay of the same key, from what the processor holds, with no second charge |
04 | Successful capture supplies payout-reconciliation evidence. | test services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it records the capture as one eligible settlement item keyed payment:<id>:capture, on Stripe’s timing (the account names no processor) |
End-to-end policy: required: Hosted instrument entry needs browser proof; interrupted-response recovery is proved through service integration because the development stand-in does not retain cross-process lookup state.