--- id: ATS-ACC-TRX-007 scope: CAP-ACC-TRX-007 product_area: accounting module: transactions revision: 1 status: proposed approved_by: null approved_at: null source_sha: services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f scenarios: - id: ATS-ACC-TRX-007-01 title: Invalid merchant destinations cannot charge level: api proves: - BR-CAP-ACC-TRX-007-01 preconditions: Inactive and foreign-unit merchant accounts exist. steps: - do: Tender through each and then omit the merchant account. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it refuses an inactive merchant account (merchant_account_inactive), charging nothing expected: Every request fails before any charge. negative: true data_needs: Merchant destination variants. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it refuses an inactive merchant account (merchant_account_inactive), charging nothing - >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it refuses a merchant account of another unit (cash_account_mismatch) - >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it refuses a card payment with no merchant account (cash_account_mismatch) - >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0324.spec.ts#ACT-ACC-0324 - TST-ACC-TRX-082 - TST-ACC-TRX-258 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it refuses an inactive merchant account (merchant_account_inactive), charging nothing category: validation test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js assertion: >- it refuses an inactive merchant account (merchant_account_inactive), charging nothing provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it refuses an inactive merchant account (merchant_account_inactive), charging nothing - file: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js assertion: it refuses a merchant account of another unit (cash_account_mismatch) provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it refuses a merchant account of another unit (cash_account_mismatch) - file: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js assertion: >- it refuses a card payment with no merchant account (cash_account_mismatch) provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it refuses a card payment with no merchant account (cash_account_mismatch) - file: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0324.spec.ts assertion: ACT-ACC-0324 provenance: test source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0324.spec.ts#ACT-ACC-0324 binding_review: - binding: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0324.spec.ts#ACT-ACC-0324 completeness: not-verified provenance: observed source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0324.spec.ts#ACT-ACC-0324 note: >- This citation remains component evidence. A browser request driven through an API helper does not establish direct database checks or every branch of the combined scenario. - id: ATS-ACC-TRX-007-02 title: Eligibility precedes repeat-safe capture level: api proves: - BR-CAP-ACC-TRX-007-02 - BR-CAP-ACC-TRX-007-03 - INV-DOM-ACC-TRX-003-06 preconditions: The invoice line owes 70.00. steps: - do: 'Plan 70.01, then capture 70.00 and repeat its request.' provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it resolves the intent succeeded, naming the payment, claimed and resolved, with the batch chosen at initiation expected: >- Excess fails without charging; the eligible request captures once and replays its receipt. negative: false data_needs: A scripted development processor. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it refuses a planned allocation over the line’s balance (over_application), charging nothing - >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it resolves the intent succeeded, naming the payment, claimed and resolved, with the batch chosen at initiation - >- 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 - >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0302.spec.ts#ACT-ACC-0302 - TST-ACC-TRX-082 - TST-ACC-TRX-241 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it resolves the intent succeeded, naming the payment, claimed and resolved, with the batch chosen at initiation category: invariant test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js assertion: >- it refuses a planned allocation over the line’s balance (over_application), charging nothing provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it refuses a planned allocation over the line’s balance (over_application), charging nothing - file: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js assertion: >- it resolves the intent succeeded, naming the payment, claimed and resolved, with the batch chosen at initiation provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it resolves the intent succeeded, naming the payment, claimed and resolved, with the batch chosen at initiation - file: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js assertion: >- it replays the same key and body as the same payment, charging nothing more provenance: test source: >- 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 - file: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0302.spec.ts assertion: ACT-ACC-0302 provenance: test source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0302.spec.ts#ACT-ACC-0302 binding_review: - binding: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0302.spec.ts#ACT-ACC-0302 completeness: not-verified provenance: observed source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0302.spec.ts#ACT-ACC-0302 note: >- This citation remains component evidence. A browser request driven through an API helper does not establish direct database checks or every branch of the combined scenario. - id: ATS-ACC-TRX-007-03 title: Definite failures permit another attempt level: api proves: - BR-CAP-ACC-TRX-007-04 preconditions: The test processor supplies a declining card and unavailable mode. steps: - do: >- Repeat a declining request, substitute a valid card under its key and test unavailability. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it frees the key: the same key sent again is tendered again, as a new intent (declined again here) expected: >- Failed intents remain recorded, valid retry succeeds and unavailable capture records no collected money. negative: true data_needs: Decline and availability processor scripts. bound_to: - >- 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 - >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it frees the key: the same key sent again is tendered again, as a new intent (declined again here) - >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it takes the same key with another card: the payment is made, the failed intents kept as history - >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it refuses processor_unavailable and fails the intent: nothing was charged - TST-ACC-TRX-082 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it frees the key: the same key sent again is tendered again, as a new intent (declined again here) category: failure test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js assertion: >- it refuses processor_declined and fails the intent with the processor’s code, writing no payment provenance: test source: >- 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 - file: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js assertion: >- it frees the key: the same key sent again is tendered again, as a new intent (declined again here) provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it frees the key: the same key sent again is tendered again, as a new intent (declined again here) - file: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js assertion: >- it takes the same key with another card: the payment is made, the failed intents kept as history provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it takes the same key with another card: the payment is made, the failed intents kept as history - file: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js assertion: >- it refuses processor_unavailable and fails the intent: nothing was charged provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it refuses processor_unavailable and fails the intent: nothing was charged binding_review: [] - id: ATS-ACC-TRX-007-04 title: Concurrent settlement cannot reject captured value level: api proves: - BR-CAP-ACC-TRX-007-05 - INV-DOM-ACC-TRX-003-07 preconditions: Another receipt settles the target before card capture returns. steps: - do: Complete the card capture. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it is capped at what the line owes then and the rest stays unapplied: the charged money is never refused expected: >- Recorded money is capped against current debt and otherwise retained unapplied. negative: false data_needs: A processor callback that introduces competing payment. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it is capped at what the line owes then and the rest stays unapplied: the charged money is never refused - >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0319.spec.ts#ACT-ACC-0319 - TST-ACC-TRX-082 - TST-ACC-TRX-254 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it is capped at what the line owes then and the rest stays unapplied: the charged money is never refused category: concurrency test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js assertion: >- it is capped at what the line owes then and the rest stays unapplied: the charged money is never refused provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it is capped at what the line owes then and the rest stays unapplied: the charged money is never refused - file: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0319.spec.ts assertion: ACT-ACC-0319 provenance: test source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0319.spec.ts#ACT-ACC-0319 binding_review: - binding: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0319.spec.ts#ACT-ACC-0319 completeness: not-verified provenance: observed source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0319.spec.ts#ACT-ACC-0319 note: >- The deployed processor’s recovery result is conditional. This browser file does not establish that every lost-answer attempt reaches a captured receipt. - id: ATS-ACC-TRX-007-05 title: Uncertain capture is recovered by lookup level: api proves: - BR-CAP-ACC-TRX-007-06 preconditions: The scripted card captures while losing its response. steps: - do: Tender and repeat the identical request. provenance: test source: >- 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 expected: The initial intent processes and lookup recovers the existing payment. negative: false data_needs: A lost-response processor script. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it refuses tender_uncertain and leaves the intent processing, the charge made once - >- 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 - >- services-accounting:modules/transactions/tests/e2e/service-functions-gateway-lost-answer.e2e.spec.js#it finds the one capture with the lookup and answers the succeeded payment - >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0318.spec.ts#ACT-ACC-0318 - TST-ACC-TRX-082 - TST-ACC-TRX-015 - TST-ACC-TRX-253 provenance: test source: >- 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 category: transition test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js assertion: >- it refuses tender_uncertain and leaves the intent processing, the charge made once provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it refuses tender_uncertain and leaves the intent processing, the charge made once - file: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js assertion: >- it answers the payment to a replay of the same key, from what the processor holds, with no second charge provenance: test source: >- 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 - file: >- services-accounting:modules/transactions/tests/e2e/service-functions-gateway-lost-answer.e2e.spec.js assertion: >- it finds the one capture with the lookup and answers the succeeded payment provenance: test source: >- services-accounting:modules/transactions/tests/e2e/service-functions-gateway-lost-answer.e2e.spec.js#it finds the one capture with the lookup and answers the succeeded payment - file: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0318.spec.ts assertion: ACT-ACC-0318 provenance: test source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0318.spec.ts#ACT-ACC-0318 binding_review: - binding: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0318.spec.ts#ACT-ACC-0318 completeness: not-verified provenance: observed source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0318.spec.ts#ACT-ACC-0318 note: >- This citation remains component evidence. A browser request driven through an API helper does not establish direct database checks or every branch of the combined scenario. - id: ATS-ACC-TRX-007-06 title: Lookup exhaustion produces review level: api proves: - BR-CAP-ACC-TRX-007-07 preconditions: >- A processing charge has no provider reference and key lookup stays inconclusive under the development recovery schedule. steps: - do: 'Sweep at thirty, sixty, ninety and one hundred eighty seconds.' provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it hands the intent to a person at the last lookup: needs_review, the item published with its facts expected: >- Only due key lookups count; their absent answers retain processing, and the last due lookup hands the attempt to review. negative: false data_needs: An overridden lookup cadence. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it asks at the first step (30 s) and counts it: a not_found changes nothing else - >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it hands the intent to a person at the last lookup (180 s), not before - >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it hands the intent to a person at the last lookup: needs_review, the item published with its facts - >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it stops looking once it is with a person: further sweeps do not touch it - TST-ACC-TRX-076 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it hands the intent to a person at the last lookup: needs_review, the item published with its facts category: boundary test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js assertion: >- it asks at the first step (30 s) and counts it: a not_found changes nothing else provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it asks at the first step (30 s) and counts it: a not_found changes nothing else - file: >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js assertion: 'it hands the intent to a person at the last lookup (180 s), not before' provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it hands the intent to a person at the last lookup (180 s), not before - file: >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js assertion: >- it hands the intent to a person at the last lookup: needs_review, the item published with its facts provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it hands the intent to a person at the last lookup: needs_review, the item published with its facts - file: >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js assertion: >- it stops looking once it is with a person: further sweeps do not touch it provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it stops looking once it is with a person: further sweeps do not touch it binding_review: [] - id: ATS-ACC-TRX-007-07 title: Human decisions require review eligibility level: api proves: - BR-CAP-ACC-TRX-007-08 preconditions: One uncertain attempt awaits review and another is still scheduled. steps: - do: >- Resolve with a reference, repeat resolution and decide the early attempt. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it refuses both decisions before the last lookup (lost_answer_not_in_review) expected: >- One receipt and resolved attention item result; repeat and early decisions fail. negative: false data_needs: Attempts in review and pre-review states. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it is settled by a person under the processor’s reference: the payment recorded, the item resolved settled - >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it refuses a second decision once it is settled (lost_answer_not_processing) - >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it refuses both decisions before the last lookup (lost_answer_not_in_review) - >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it fails the intent with the person’s reason, frees its key and resolves the item failed - TST-ACC-TRX-076 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it refuses both decisions before the last lookup (lost_answer_not_in_review) category: permission test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js assertion: >- it is settled by a person under the processor’s reference: the payment recorded, the item resolved settled provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it is settled by a person under the processor’s reference: the payment recorded, the item resolved settled - file: >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js assertion: >- it refuses a second decision once it is settled (lost_answer_not_processing) provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it refuses a second decision once it is settled (lost_answer_not_processing) - file: >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js assertion: >- it refuses both decisions before the last lookup (lost_answer_not_in_review) provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it refuses both decisions before the last lookup (lost_answer_not_in_review) - file: >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js assertion: >- it fails the intent with the person’s reason, frees its key and resolves the item failed provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it fails the intent with the person’s reason, frees its key and resolves the item failed binding_review: [] - id: ATS-ACC-TRX-007-08 title: Unqueryable old intent becomes abandoned level: api proves: - BR-CAP-ACC-TRX-007-09 preconditions: >- A processing intent is more than twenty-four hours old, is outside human review and uses a processor that supplies no lookup function. steps: - do: Sweep its outstanding work. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it is abandoned by the sweeper after 24 hours, with its event (FC-17) expected: Abandonment and its retained event are recorded. negative: false data_needs: A controlled twenty-four-hour clock advance. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it is abandoned by the sweeper after 24 hours, with its event (FC-17) - TST-ACC-TRX-082 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it is abandoned by the sweeper after 24 hours, with its event (FC-17) category: transition test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js assertion: 'it is abandoned by the sweeper after 24 hours, with its event (FC-17)' provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it is abandoned by the sweeper after 24 hours, with its event (FC-17) binding_review: [] - id: ATS-ACC-TRX-007-09 title: Bank clearing finishes pending receipts level: api proves: - BR-CAP-ACC-TRX-007-10 - BR-CAP-ACC-TRX-007-13 - INV-DOM-ACC-TRX-003-19 preconditions: Three gateway electronic checks await outcomes. steps: - do: >- Inspect, report clearing and return, deliver a clearing event and repeat settlement. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/integrations-electronic-check.integration.spec.js#it settles the one the authorization reads cleared: succeeded, its capture item eligible expected: >- Clearing releases reconciliation eligibility, return reverses the receipt, event settles once and repeated settlement fails. negative: false data_needs: Gateway clearing and return responses. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/payments/integrations-electronic-check.integration.spec.js#it records the payment pending_settlement on the electronic_check method: the account’s last four, no card brand - >- services-accounting:modules/transactions/tests/integration/services/payments/integrations-electronic-check.integration.spec.js#it settles the one the authorization reads cleared: succeeded, its capture item eligible - >- services-accounting:modules/transactions/tests/integration/services/payments/integrations-electronic-check.integration.spec.js#it returns the one the authorization reads failed, as an ACH return - >- services-accounting:modules/transactions/tests/integration/services/payments/integrations-electronic-check.integration.spec.js#it settles the third by the event the gateway sends, found by its subject - >- services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it refuses settling a payment not awaiting settlement (payment_not_pending_settlement) - >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it records the capture as one eligible settlement item keyed payment::capture, on Stripe’s timing (the account names no processor) - TST-ACC-TRX-075 - TST-ACC-TRX-080 - TST-ACC-TRX-082 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/integrations-electronic-check.integration.spec.js#it settles the one the authorization reads cleared: succeeded, its capture item eligible category: transition test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/payments/integrations-electronic-check.integration.spec.js assertion: >- it records the payment pending_settlement on the electronic_check method: the account’s last four, no card brand provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/integrations-electronic-check.integration.spec.js#it records the payment pending_settlement on the electronic_check method: the account’s last four, no card brand - file: >- services-accounting:modules/transactions/tests/integration/services/payments/integrations-electronic-check.integration.spec.js assertion: >- it settles the one the authorization reads cleared: succeeded, its capture item eligible provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/integrations-electronic-check.integration.spec.js#it settles the one the authorization reads cleared: succeeded, its capture item eligible - file: >- services-accounting:modules/transactions/tests/integration/services/payments/integrations-electronic-check.integration.spec.js assertion: 'it returns the one the authorization reads failed, as an ACH return' provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/integrations-electronic-check.integration.spec.js#it returns the one the authorization reads failed, as an ACH return - file: >- services-accounting:modules/transactions/tests/integration/services/payments/integrations-electronic-check.integration.spec.js assertion: >- it settles the third by the event the gateway sends, found by its subject provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/integrations-electronic-check.integration.spec.js#it settles the third by the event the gateway sends, found by its subject - file: >- services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js assertion: >- it refuses settling a payment not awaiting settlement (payment_not_pending_settlement) provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it refuses settling a payment not awaiting settlement (payment_not_pending_settlement) - file: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js assertion: >- it records the capture as one eligible settlement item keyed payment::capture, on Stripe’s timing (the account names no processor) provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it records the capture as one eligible settlement item keyed payment::capture, on Stripe’s timing (the account names no processor) binding_review: [] - id: ATS-ACC-TRX-007-10 title: Customer administration cannot mark system clearing level: api proves: - BR-CAP-ACC-TRX-007-11 preconditions: The caller administers the customer workspace. steps: - do: Invoke the manual settlement system operation. provenance: test source: >- services-accounting:modules/transactions/tests/e2e/payment-reversals.e2e.spec.js#it is refused the settled route as a console administrator: it is a system route (403) expected: Access is denied. negative: true data_needs: A customer administrator identity. bound_to: - >- services-accounting:modules/transactions/tests/e2e/payment-reversals.e2e.spec.js#it is refused the settled route as a console administrator: it is a system route (403) - TST-ACC-TRX-011 provenance: test source: >- services-accounting:modules/transactions/tests/e2e/payment-reversals.e2e.spec.js#it is refused the settled route as a console administrator: it is a system route (403) category: permission test_bindings: - file: >- services-accounting:modules/transactions/tests/e2e/payment-reversals.e2e.spec.js assertion: >- it is refused the settled route as a console administrator: it is a system route (403) provenance: test source: >- services-accounting:modules/transactions/tests/e2e/payment-reversals.e2e.spec.js#it is refused the settled route as a console administrator: it is a system route (403) binding_review: [] - id: ATS-ACC-TRX-007-11 title: Bank entry follows processor capability level: api proves: - BR-CAP-ACC-TRX-007-12 preconditions: Payrix installations differ in electronic-check support. steps: - do: Request hosted-entry information for both instrument choices. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/stripe/payment-client-side-info.integration.spec.js#it offers the card alone for mode both when the installation has electronic checks off: asked again once, no failure expected: >- Enabled installation offers card and bank; disabled installation offers card alone. negative: false data_needs: Gateway capability responses. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/stripe/payment-client-side-info.integration.spec.js#it offers the bank account beside the card for mode both when the installation takes electronic checks - >- services-accounting:modules/transactions/tests/integration/services/stripe/payment-client-side-info.integration.spec.js#it offers the card alone for mode both when the installation has electronic checks off: asked again once, no failure - >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0365.spec.ts#ACT-ACC-0365 - TST-ACC-TRX-127 - TST-ACC-TRX-271 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/stripe/payment-client-side-info.integration.spec.js#it offers the card alone for mode both when the installation has electronic checks off: asked again once, no failure category: rule test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/stripe/payment-client-side-info.integration.spec.js assertion: >- it offers the bank account beside the card for mode both when the installation takes electronic checks provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/stripe/payment-client-side-info.integration.spec.js#it offers the bank account beside the card for mode both when the installation takes electronic checks - file: >- services-accounting:modules/transactions/tests/integration/services/stripe/payment-client-side-info.integration.spec.js assertion: >- it offers the card alone for mode both when the installation has electronic checks off: asked again once, no failure provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/stripe/payment-client-side-info.integration.spec.js#it offers the card alone for mode both when the installation has electronic checks off: asked again once, no failure - file: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0365.spec.ts assertion: ACT-ACC-0365 provenance: test source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0365.spec.ts#ACT-ACC-0365 binding_review: - binding: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0365.spec.ts#ACT-ACC-0365 completeness: not-verified provenance: observed source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0365.spec.ts#ACT-ACC-0365 note: >- This citation remains component evidence. A browser request driven through an API helper does not establish direct database checks or every branch of the combined scenario. - id: ATS-ACC-TRX-007-12 title: Recovery feeds the same financial records as immediate capture category: interaction level: api proves: - BR-CAP-ACC-TRX-007-03 - BR-CAP-ACC-TRX-007-06 - BR-CAP-ACC-TRX-007-10 - BR-CAP-ACC-TRX-008-04 - BR-CAP-ACC-TRX-008-07 - BR-CAP-ACC-TRX-009-09 - BR-CAP-ACC-TRX-009-10 - BR-CAP-ACC-TRX-012-08 - BR-CAP-ACC-TRX-012-09 - BR-CAP-ACC-TRX-013-03 - BR-CAP-ACC-TRX-013-06 - BR-CAP-ACC-TRX-020-05 - BR-CAP-ACC-TRX-020-08 - BR-CAP-ACC-TRX-011-03 - BR-CAP-ACC-TRX-011-04 exercises: - CAP-ACC-TRX-007 - CAP-ACC-TRX-008 - CAP-ACC-TRX-009 - CAP-ACC-TRX-012 - CAP-ACC-TRX-013 - CAP-ACC-TRX-020 - CAP-ACC-TRX-011 preconditions: >- An isolated workspace has eligible customers, products, matching accounts, an open period and two open batches. Each branch owns separate financial records. steps: - do: >- Capture a card payment with a lost answer, recover it by lookup, allocate its remaining value and complete a second invoice through settlement. Request a return and deliver its confirmation; in a separate branch deliver a bank return. Include a settlement that reserves customer credit during processor uncertainty. provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it resolves the intent succeeded, naming the payment, claimed and resolved, with the batch chosen at initiation; 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; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it settles the one the bank cleared: succeeded, settled_at, its capture item eligible, the settle event; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-006-take-a-card-or-bank-payment-through-the-processor.md#WF-ACC-TRX-006; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-007-resolve-lost-processor-answers-and-clear-bank-debits.md#WF-ACC-TRX-007; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-008-settle-a-customer-s-invoices-with-credit-and-money.md#WF-ACC-TRX-008; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-013-apply-payment-events-from-the-integration-platform.md#WF-ACC-TRX-013; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-07; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-04 expected: >- Recovery creates one receipt; settlement retains its linked components; confirmed refund returns held value and bank return restores debt without duplicate event effects. negative: false data_needs: >- Separate command keys, two customers, invoice lines, receipts and credit; controlled processor outcomes and a fixed calendar where the branch requires them. bound_to: [] provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it resolves the intent succeeded, naming the payment, claimed and resolved, with the batch chosen at initiation; 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; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it settles the one the bank cleared: succeeded, settled_at, its capture item eligible, the settle event; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-006-take-a-card-or-bank-payment-through-the-processor.md#WF-ACC-TRX-006; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-007-resolve-lost-processor-answers-and-clear-bank-debits.md#WF-ACC-TRX-007; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-008-settle-a-customer-s-invoices-with-credit-and-money.md#WF-ACC-TRX-008; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-013-apply-payment-events-from-the-integration-platform.md#WF-ACC-TRX-013; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-07; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-04 test_bindings: [] binding_review: [] evidence: - >- services-accounting at f47cb263875bbc0c5640fba7dae6785ec32695f8: the test files named in bound_to. - >- react-console at baf6dae382d6f41dce976c7f848667ccc37e076f: the Playwright journeys ACT-ACC-0302, 0318, 0319, 0324, 0365. - >- rhythm-v2-docs:specs/accounting/transactions/design: related workflows, domain invariants and state transitions examined for the back-fill. coverage: rule: covered transition: 'gap: FND-ACC-TRX-072' validation: covered permission: covered edge: 'gap: FND-ACC-TRX-072' failure: covered boundary: covered concurrency: covered invariant: covered interaction: covered coverage_notes: edge: >- No dedicated edge scenario covers the applicable conditions; the finding identifies the remaining specification work. transition: >- Selected transition scenarios exist, but the listed state paths still need explicit guard, effect and actor mappings. interaction_coverage: - to: CAP-ACC-TRX-008 scenarios: - ATS-ACC-TRX-007-12 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it resolves the intent succeeded, naming the payment, claimed and resolved, with the batch chosen at initiation; 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; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it settles the one the bank cleared: succeeded, settled_at, its capture item eligible, the settle event; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-006-take-a-card-or-bank-payment-through-the-processor.md#WF-ACC-TRX-006; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-007-resolve-lost-processor-answers-and-clear-bank-debits.md#WF-ACC-TRX-007; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-008-settle-a-customer-s-invoices-with-credit-and-money.md#WF-ACC-TRX-008; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-013-apply-payment-events-from-the-integration-platform.md#WF-ACC-TRX-013; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-07; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-04 - to: CAP-ACC-TRX-009 scenarios: - ATS-ACC-TRX-007-12 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it resolves the intent succeeded, naming the payment, claimed and resolved, with the batch chosen at initiation; 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; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it settles the one the bank cleared: succeeded, settled_at, its capture item eligible, the settle event; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-006-take-a-card-or-bank-payment-through-the-processor.md#WF-ACC-TRX-006; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-007-resolve-lost-processor-answers-and-clear-bank-debits.md#WF-ACC-TRX-007; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-008-settle-a-customer-s-invoices-with-credit-and-money.md#WF-ACC-TRX-008; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-013-apply-payment-events-from-the-integration-platform.md#WF-ACC-TRX-013; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-07; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-04 - to: CAP-ACC-TRX-011 scenarios: - ATS-ACC-TRX-007-12 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it resolves the intent succeeded, naming the payment, claimed and resolved, with the batch chosen at initiation; 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; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it settles the one the bank cleared: succeeded, settled_at, its capture item eligible, the settle event; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-006-take-a-card-or-bank-payment-through-the-processor.md#WF-ACC-TRX-006; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-007-resolve-lost-processor-answers-and-clear-bank-debits.md#WF-ACC-TRX-007; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-008-settle-a-customer-s-invoices-with-credit-and-money.md#WF-ACC-TRX-008; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-013-apply-payment-events-from-the-integration-platform.md#WF-ACC-TRX-013; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-07; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-04 - to: CAP-ACC-TRX-012 scenarios: - ATS-ACC-TRX-007-12 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it resolves the intent succeeded, naming the payment, claimed and resolved, with the batch chosen at initiation; 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; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it settles the one the bank cleared: succeeded, settled_at, its capture item eligible, the settle event; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-006-take-a-card-or-bank-payment-through-the-processor.md#WF-ACC-TRX-006; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-007-resolve-lost-processor-answers-and-clear-bank-debits.md#WF-ACC-TRX-007; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-008-settle-a-customer-s-invoices-with-credit-and-money.md#WF-ACC-TRX-008; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-013-apply-payment-events-from-the-integration-platform.md#WF-ACC-TRX-013; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-07; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-04 - to: CAP-ACC-TRX-013 scenarios: - ATS-ACC-TRX-007-12 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it resolves the intent succeeded, naming the payment, claimed and resolved, with the batch chosen at initiation; 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; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it settles the one the bank cleared: succeeded, settled_at, its capture item eligible, the settle event; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-006-take-a-card-or-bank-payment-through-the-processor.md#WF-ACC-TRX-006; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-007-resolve-lost-processor-answers-and-clear-bank-debits.md#WF-ACC-TRX-007; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-008-settle-a-customer-s-invoices-with-credit-and-money.md#WF-ACC-TRX-008; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-013-apply-payment-events-from-the-integration-platform.md#WF-ACC-TRX-013; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-07; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-04 - to: CAP-ACC-TRX-020 scenarios: - ATS-ACC-TRX-007-12 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it resolves the intent succeeded, naming the payment, claimed and resolved, with the batch chosen at initiation; 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; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it settles the one the bank cleared: succeeded, settled_at, its capture item eligible, the settle event; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-006-take-a-card-or-bank-payment-through-the-processor.md#WF-ACC-TRX-006; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-007-resolve-lost-processor-answers-and-clear-bank-debits.md#WF-ACC-TRX-007; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-008-settle-a-customer-s-invoices-with-credit-and-money.md#WF-ACC-TRX-008; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-013-apply-payment-events-from-the-integration-platform.md#WF-ACC-TRX-013; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-07; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-04 transition_coverage: - state_model: STATE-ACC-TRX-005 transition: 1 gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/lost-answer-commands.ts; services-accounting:modules/transactions/services/payments/intent-sweeper.ts; services-accounting:modules/transactions/db/payment-intents.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it resolves the intent succeeded, naming the payment, claimed and resolved, with the batch chosen at initiation - state_model: STATE-ACC-TRX-005 transition: 2 gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/lost-answer-commands.ts; services-accounting:modules/transactions/services/payments/intent-sweeper.ts; services-accounting:modules/transactions/db/payment-intents.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it is capped at what the line owes then and the rest stays unapplied: the charged money is never refused - state_model: STATE-ACC-TRX-005 transition: 3 gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/lost-answer-commands.ts; services-accounting:modules/transactions/services/payments/intent-sweeper.ts; services-accounting:modules/transactions/db/payment-intents.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it frees the key: the same key sent again is tendered again, as a new intent (declined again here) - state_model: STATE-ACC-TRX-005 transition: 4 gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/lost-answer-commands.ts; services-accounting:modules/transactions/services/payments/intent-sweeper.ts; services-accounting:modules/transactions/db/payment-intents.table.ts; 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 - state_model: STATE-ACC-TRX-005 transition: 5 gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/lost-answer-commands.ts; services-accounting:modules/transactions/services/payments/intent-sweeper.ts; services-accounting:modules/transactions/db/payment-intents.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it hands the intent to a person at the last lookup: needs_review, the item published with its facts - state_model: STATE-ACC-TRX-005 transition: 6 gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/lost-answer-commands.ts; services-accounting:modules/transactions/services/payments/intent-sweeper.ts; services-accounting:modules/transactions/db/payment-intents.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it refuses both decisions before the last lookup (lost_answer_not_in_review) - state_model: STATE-ACC-TRX-005 transition: 7 gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/lost-answer-commands.ts; services-accounting:modules/transactions/services/payments/intent-sweeper.ts; services-accounting:modules/transactions/db/payment-intents.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it refuses both decisions before the last lookup (lost_answer_not_in_review) - state_model: STATE-ACC-TRX-005 transition: 8 gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/intent-sweeper.ts:sweepProcessingIntents - state_model: STATE-ACC-TRX-006 transition: 1 gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it refuses a date in no open period (period_not_open) - state_model: STATE-ACC-TRX-006 transition: 2 gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it settles the one the bank cleared: succeeded, settled_at, its capture item eligible, the settle event - state_model: STATE-ACC-TRX-006 transition: 3 gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it settles the one the bank cleared: succeeded, settled_at, its capture item eligible, the settle event - state_model: STATE-ACC-TRX-006 transition: 4 gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it settles the one the bank cleared: succeeded, settled_at, its capture item eligible, the settle event - state_model: STATE-ACC-TRX-006 transition: 5 gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it records it offline: executed, the payment partially_refunded with 1000 refunded (FC-11, FC-14) - state_model: STATE-ACC-TRX-006 transition: 6 gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it records it offline: executed, the payment partially_refunded with 1000 refunded (FC-11, FC-14) - state_model: STATE-ACC-TRX-006 transition: 7 gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it records it offline: executed, the payment partially_refunded with 1000 refunded (FC-11, FC-14) - state_model: STATE-ACC-TRX-006 transition: 8 gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it reverses the live allocation so the line owes again, and the payment item’s facts sum to zero (FC-16) - state_model: STATE-ACC-TRX-006 transition: 9 gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it refuses a kind the method does not allow (reversal_kind_mismatch): an ACH return of a check, a bounced check of a card - state_model: STATE-ACC-TRX-006 transition: 10 gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/dispute-inquiry-lost.integration.spec.js#it writes no payment reversal and leaves the payment succeeded, nothing reversed permission_coverage: - key: accounting.payments.create where_checked: api gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing permission scenarios are retained; assertion-level coverage of this grant at every declared surface remains unverified. evidence: - >- rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#CAP-ACC-TRX-007 - key: accounting.payments.read where_checked: api gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing permission scenarios are retained; assertion-level coverage of this grant at every declared surface remains unverified. evidence: - >- rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#CAP-ACC-TRX-007 - key: accounting.payments.update where_checked: api gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing permission scenarios are retained; assertion-level coverage of this grant at every declared surface remains unverified. evidence: - >- rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#CAP-ACC-TRX-007 - key: accounting.payments.settle where_checked: api gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing permission scenarios are retained; assertion-level coverage of this grant at every declared surface remains unverified. evidence: - >- rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#CAP-ACC-TRX-007 - key: accounting.payment-element.read where_checked: api gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing permission scenarios are retained; assertion-level coverage of this grant at every declared surface remains unverified. evidence: - >- rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#CAP-ACC-TRX-007 - key: accounting.payment-element.create where_checked: api gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing permission scenarios are retained; assertion-level coverage of this grant at every declared surface remains unverified. evidence: - >- rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#CAP-ACC-TRX-007 - key: accounting.stripe-settings.read where_checked: api gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing permission scenarios are retained; assertion-level coverage of this grant at every declared surface remains unverified. evidence: - >- rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#CAP-ACC-TRX-007 - key: accounting.stripe-settings.update where_checked: api gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 note: >- Existing permission scenarios are retained; assertion-level coverage of this grant at every declared surface remains unverified. evidence: - >- rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#CAP-ACC-TRX-007 rule_coverage: - rule: BR-CAP-ACC-TRX-007-01 scenarios: - ATS-ACC-TRX-007-01 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it refuses an inactive merchant account (merchant_account_inactive), charging nothing - rule: BR-CAP-ACC-TRX-007-02 scenarios: - ATS-ACC-TRX-007-02 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it refuses a planned allocation over the line’s balance (over_application), charging nothing - rule: BR-CAP-ACC-TRX-007-03 scenarios: - ATS-ACC-TRX-007-02 - ATS-ACC-TRX-007-12 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it resolves the intent succeeded, naming the payment, claimed and resolved, with the batch chosen at initiation - rule: BR-CAP-ACC-TRX-007-04 scenarios: - ATS-ACC-TRX-007-03 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it frees the key: the same key sent again is tendered again, as a new intent (declined again here) - rule: BR-CAP-ACC-TRX-007-05 scenarios: - ATS-ACC-TRX-007-04 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it is capped at what the line owes then and the rest stays unapplied: the charged money is never refused - rule: BR-CAP-ACC-TRX-007-06 scenarios: - ATS-ACC-TRX-007-05 - ATS-ACC-TRX-007-12 provenance: proposed source: >- 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 - rule: BR-CAP-ACC-TRX-007-07 scenarios: - ATS-ACC-TRX-007-06 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it hands the intent to a person at the last lookup: needs_review, the item published with its facts - rule: BR-CAP-ACC-TRX-007-08 scenarios: - ATS-ACC-TRX-007-07 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/lost-answers.integration.spec.js#it refuses both decisions before the last lookup (lost_answer_not_in_review) - rule: BR-CAP-ACC-TRX-007-09 scenarios: - ATS-ACC-TRX-007-08 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it is abandoned by the sweeper after 24 hours, with its event (FC-17) - rule: BR-CAP-ACC-TRX-007-10 scenarios: - ATS-ACC-TRX-007-09 - ATS-ACC-TRX-007-12 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it settles the one the bank cleared: succeeded, settled_at, its capture item eligible, the settle event - rule: BR-CAP-ACC-TRX-007-11 scenarios: - ATS-ACC-TRX-007-10 provenance: proposed source: >- services-accounting:modules/transactions/tests/e2e/payment-reversals.e2e.spec.js#it is refused the settled route as a console administrator: it is a system route (403) - rule: BR-CAP-ACC-TRX-007-12 scenarios: - ATS-ACC-TRX-007-11 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/stripe/payment-client-side-info.integration.spec.js#it offers the card alone for mode both when the installation has electronic checks off: asked again once, no failure - rule: BR-CAP-ACC-TRX-007-13 scenarios: - ATS-ACC-TRX-007-09 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it records the capture as one eligible settlement item keyed payment::capture, on Stripe’s timing (the account names no processor) executable_gaps: - scenario: ATS-ACC-TRX-007-12 gap: FND-ACC-TRX-072 provenance: unknown source: FND-ACC-TRX-072 evidence: - >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it resolves the intent succeeded, naming the payment, claimed and resolved, with the batch chosen at initiation; 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; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it settles the one the bank cleared: succeeded, settled_at, its capture item eligible, the settle event; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-006-take-a-card-or-bank-payment-through-the-processor.md#WF-ACC-TRX-006; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-007-resolve-lost-processor-answers-and-clear-bank-debits.md#WF-ACC-TRX-007; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-008-settle-a-customer-s-invoices-with-credit-and-money.md#WF-ACC-TRX-008; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-013-apply-payment-events-from-the-integration-platform.md#WF-ACC-TRX-013 invariant_coverage: - invariant: INV-DOM-ACC-TRX-003-06 scenarios: - ATS-ACC-TRX-007-02 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it resolves the intent succeeded, naming the payment, claimed and resolved, with the batch chosen at initiation note: >- The cited scenario and its constituent test assertions are the proof boundary. - invariant: INV-DOM-ACC-TRX-003-07 scenarios: - ATS-ACC-TRX-007-04 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it is capped at what the line owes then and the rest stays unapplied: the charged money is never refused note: >- The cited scenario and its constituent test assertions are the proof boundary. - invariant: INV-DOM-ACC-TRX-003-19 scenarios: - ATS-ACC-TRX-007-09 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/payments/tender.integration.spec.js#it records the capture as one eligible settlement item keyed payment::capture, on Stripe’s timing (the account names no processor) note: >- The cited scenario and its constituent test assertions are the proof boundary. --- # Collect processor payments and resolve uncertainty: Capability Test Specification ## Coverage The category map separates specified examples from recorded gaps. The table lists a scenario or finding for each rule requiring proof; a listed scenario may still be proposed. Executable bindings cover their cited assertions, while the transition, permission and invariant registers identify combinations that need further proof. | Required rule | Scenario or finding | |---|---| | `BR-CAP-ACC-TRX-007-01` | `ATS-ACC-TRX-007-01` | | `BR-CAP-ACC-TRX-007-02` | `ATS-ACC-TRX-007-02` | | `BR-CAP-ACC-TRX-007-03` | `ATS-ACC-TRX-007-02`, `ATS-ACC-TRX-007-12` | | `BR-CAP-ACC-TRX-007-04` | `ATS-ACC-TRX-007-03` | | `BR-CAP-ACC-TRX-007-05` | `ATS-ACC-TRX-007-04` | | `BR-CAP-ACC-TRX-007-06` | `ATS-ACC-TRX-007-05`, `ATS-ACC-TRX-007-12` | | `BR-CAP-ACC-TRX-007-07` | `ATS-ACC-TRX-007-06` | | `BR-CAP-ACC-TRX-007-08` | `ATS-ACC-TRX-007-07` | | `BR-CAP-ACC-TRX-007-09` | `ATS-ACC-TRX-007-08` | | `BR-CAP-ACC-TRX-007-10` | `ATS-ACC-TRX-007-09`, `ATS-ACC-TRX-007-12` | | `BR-CAP-ACC-TRX-007-11` | `ATS-ACC-TRX-007-10` | | `BR-CAP-ACC-TRX-007-12` | `ATS-ACC-TRX-007-11` | | `BR-CAP-ACC-TRX-007-13` | `ATS-ACC-TRX-007-09` | ## Interactions With Related Capabilities Capture a card payment with a lost answer, recover it by lookup, allocate its remaining value and complete a second invoice through settlement. Request a return and deliver its confirmation; in a separate branch deliver a bank return. Include a settlement that reserves customer credit during processor uncertainty. Recovery creates one receipt; settlement retains its linked components; confirmed refund returns held value and bank return restores debt without duplicate event effects. The complete chain remains proposed until one executable run proves its combined outcomes.