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.
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.
Coverage
Rulecovered
Transitiongap: FND-ACC-TRX-072
Validationcovered
Permissioncovered
Edgegap: FND-ACC-TRX-072
Failurecovered
Boundarycovered
Concurrencycovered
Invariantcovered
Interactioncovered
Test Scenarios
12 scenarios proving CAP-ACC-TRX-007; 11 bound to an existing test.
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"
}
]
[
{
"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.
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.
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.
Data
A processor callback that introduces competing payment.
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.
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.
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.
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)"
}
]
[
{
"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.
[
{
"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)"
}
]
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"
}
]
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.
Data
Separate command keys, two customers, invoice lines, receipts and credit; controlled processor outcomes and a fixed calendar where the branch requires them.