Rhythm 2.0 Specifications

Appearance

ATS-COM-ORD-007Collect payment without duplicate charges: Capability Test Specification

Markdown

ATS-COM-ORD-007

Collect payment without duplicate charges: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-COM-ORD-007

Design

Executed by
TST-COM-ORD-017, TST-COM-ORD-018, TST-COM-ORD-075, TST-COM-ORD-095, TST-COM-ORD-103, TST-COM-ORD-143, TST-COM-ORD-145

KindAcceptance test setProduct areaCommerceModuleCustomer purchases, purchased benefits and vendor stockRevision2

Read atservices-commerce c8b66a98macroservice-libraries 54536a44react-console baf6dae3

Collect payment without duplicate charges: Capability Test Specification ​

Coverage ​

RuleScenario or finding
BR-CAP-COM-ORD-007-01ATS-COM-ORD-007-01, ATS-COM-ORD-007-16, ATS-COM-ORD-007-19
BR-CAP-COM-ORD-007-02ATS-COM-ORD-007-02
BR-CAP-COM-ORD-007-03ATS-COM-ORD-007-03
BR-CAP-COM-ORD-007-04ATS-COM-ORD-007-04
BR-CAP-COM-ORD-007-05ATS-COM-ORD-007-05
BR-CAP-COM-ORD-007-06ATS-COM-ORD-007-06
BR-CAP-COM-ORD-007-07ATS-COM-ORD-007-07, ATS-COM-ORD-007-17, ATS-COM-ORD-007-18
BR-CAP-COM-ORD-007-08ATS-COM-ORD-007-08
BR-CAP-COM-ORD-007-09ATS-COM-ORD-007-09
BR-CAP-COM-ORD-007-10ATS-COM-ORD-007-10
BR-CAP-COM-ORD-007-11ATS-COM-ORD-007-11
BR-CAP-COM-ORD-007-12no scenario: FND-COM-ORD-064
BR-CAP-COM-ORD-007-13ATS-COM-ORD-007-12
BR-CAP-COM-ORD-007-14ATS-COM-ORD-007-13

A partially paid void returns only captured money. A placed sale has a captured card leg and an applied credit leg. Void it and replay the money adjustment.

Applied payments update the order’s balance. A billed sale receives less credit than requested. Read its money, pay the remainder and read again.

Crossing workflow examples also cover preparation, commitment and recovery at their service handoffs. Their structured bindings distinguish specified outcomes from executable evidence.

Coverage

  • Rule covered
  • Transition gap: FND-COM-ORD-064
  • Validation covered
  • Permission gap: FND-COM-ORD-064
  • Edge gap: FND-COM-ORD-064
  • Failure covered
  • Boundary covered
  • Concurrency covered
  • Invariant gap: FND-COM-ORD-064
  • Interaction covered

Test Scenarios

19 scenarios proving CAP-COM-ORD-007; 14 bound to an existing test.

01 Unresolved card retries resume the original attemptinvariantapitest
Proves
BR-CAP-COM-ORD-007-01
Preconditions
Accounting has not supplied a final answer for a card request.
Steps
[ { "do": "Retry with another token and later resolve the original intent.", "provenance": "test", "source": "services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#answers uncertain, the order tender_uncertain, the attempt uncertain naming Accounting’s intent" } ]
Expected
The retry resumes the original attempt, one payment is retained and resolution accepts the order.
Data
Use the controlled records and transports established by the cited tests.
Bound to
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#answers uncertain, the order tender_uncertain, the attempt uncertain naming Accounting’s intent
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#resumes the same attempt on a retry, whatever card the retry names, and moves nothing while the intent is processing
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#accepts the order once Accounting holds the payment, with one charge and the payment on the attempt
Source
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#answers uncertain, the order tender_uncertain, the attempt uncertain naming Accounting’s intent
02 Expired and accepted orders reject normal paymentboundaryapinegativetest
Proves
BR-CAP-COM-ORD-007-02
Preconditions
One placed order is past its window and another is accepted.
Steps
[ { "do": "Attempt the normal tender action for both.", "provenance": "test", "source": "services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses a tender after the window 409 tender_window_expired and gives the sentence plain in the details, without the error class prefix (COMM-M2 R2-5)" } ]
Expected
The responses identify tender_window_expired and order_not_tenderable.
Data
Use the controlled records and transports established by the cited tests.
Bound to
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses a tender after the window 409 tender_window_expired and gives the sentence plain in the details, without the error class prefix (COMM-M2 R2-5)
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses a second tender of the accepted order, 409 order_not_tenderable
Source
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses a tender after the window 409 tender_window_expired and gives the sentence plain in the details, without the error class prefix (COMM-M2 R2-5)
03 Frozen method choices distinguish staff offline paymentpermissionapitest
Proves
BR-CAP-COM-ORD-007-03
Preconditions
An order predates policy removal of a method and another policy lists no offline choice.
Steps
[ { "do": "Try portal offline payment, a retained frozen method and staff cash.", "provenance": "test", "source": "services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses an offline tender by a member, 403 tender_kind_staff_only, and a kind the profile does not allow, 409, read from the ORDER’s snapshot: the order placed before the change still allows it (22 §9)" } ]
Expected
Portal offline payment is refused, the earlier frozen choice remains usable and staff cash succeeds.
Data
Use the controlled records and transports established by the cited tests.
Bound to
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses an offline tender by a member, 403 tender_kind_staff_only, and a kind the profile does not allow, 409, read from the ORDER’s snapshot: the order placed before the change still allows it (22 §9)
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#lets staff record cash for the rest although the policy lists no offline method, accepting the order
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#still refuses a member an offline tender under that policy, 409 tender_kind_not_allowed
services-commerce:modules/orders/tests/unit/tender/tender-kinds-of-profile.spec.js#admits terms only for a profile offering a collection option, and nothing for one offering nothing
Source
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses an offline tender by a member, 403 tender_kind_staff_only, and a kind the profile does not allow, 409, read from the ORDER’s snapshot: the order placed before the change still allows it (22 §9)
04 Attempt output masks its payment tokeninvariantapitest
Proves
BR-CAP-COM-ORD-007-04
Preconditions
A card payment uses a token and merchant account.
Steps
[ { "do": "Inspect the returned payment attempt.", "provenance": "test", "source": "services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#never stores the card: the attempt keeps a reference of the merchant account and the token’s last four only" } ]
Expected
The instrument reference contains the account and token suffix but excludes the complete token.
Data
Use the controlled records and transports established by the cited tests.
Bound to
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#never stores the card: the attempt keeps a reference of the merchant account and the token’s last four only
Source
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#never stores the card: the attempt keeps a reference of the merchant account and the token’s last four only
05 A decline permits a later attempt on the same ordertransitionapitest
Proves
BR-CAP-COM-ORD-007-05
Preconditions
An unpaid pay-now order has a usable window.
Steps
[ { "do": "Submit a declining card and then an approving card.", "provenance": "test", "source": "services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#answers 200 declined with the processor’s code, the order still placed with its pro forma, the attempt declined" } ]
Expected
The decline preserves the sale; the next attempt accepts it under the next sequence and key.
Data
Use the controlled records and transports established by the cited tests.
Bound to
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#answers 200 declined with the processor’s code, the order still placed with its pro forma, the attempt declined
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#accepts the order on the next attempt, under the next sequence and key
Source
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#answers 200 declined with the processor’s code, the order still placed with its pro forma, the attempt declined
06 Financial sweeps reconcile uncertain attemptstransitionapitest
Proves
BR-CAP-COM-ORD-007-06
Preconditions
A payment intent can be processing, completed or unresolved beyond fifteen minutes.
Steps
[ { "do": "Run the tender reconciliation cases.", "provenance": "test", "source": "services-commerce:modules/orders/tests/integration/services/orders/financial-sweeps.integration.spec.js#moves nothing while Accounting’s intent is still processing, and escalates nothing before fifteen minutes" } ]
Expected
Processing retains uncertainty, completed payment accepts once and persistent uncertainty raises an exception.
Data
Use the controlled records and transports established by the cited tests.
Bound to
services-commerce:modules/orders/tests/integration/services/orders/financial-sweeps.integration.spec.js#moves nothing while Accounting’s intent is still processing, and escalates nothing before fifteen minutes
services-commerce:modules/orders/tests/integration/services/orders/financial-sweeps.integration.spec.js#resumes the attempt once Accounting’s sweeper has finished the intent: the payment on the attempt, the order accepted, one charge
services-commerce:modules/orders/tests/integration/services/orders/financial-sweeps.integration.spec.js#raises tender_uncertain on an attempt still uncertain past fifteen minutes
Source
services-commerce:modules/orders/tests/integration/services/orders/financial-sweeps.integration.spec.js#moves nothing while Accounting’s intent is still processing, and escalates nothing before fifteen minutes
07 Only applied amounts satisfy the payment requirementruleapitest
Proves
BR-CAP-COM-ORD-007-07
Preconditions
A seventy-five-dollar sale has limited credit and two card legs.
Steps
[ { "do": "Apply credit and the successive card payments.", "provenance": "test", "source": "services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#accepts the order on the leg that completes the total (08 row 14), the first leg captured" } ]
Expected
Only fifteen dollars of credit counts, and acceptance waits until the remaining successful legs cover the amount.
Data
Use the controlled records and transports established by the cited tests.
Bound to
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#accepts the order on the leg that completes the total (08 row 14), the first leg captured
services-commerce:modules/orders/tests/unit/tender/tender-rules.spec.js#leaves a credit leg that applied less than it asked at what it applied, so the order still owes the rest
services-commerce:modules/orders/tests/unit/tender/tender-rules.spec.js#declines a credit leg whose settlement applied nothing
services-commerce:modules/orders/tests/unit/tender/tender-rules.spec.js#is the total less the legs that succeeded, ignoring the declined and uncertain ones
Source
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#accepts the order on the leg that completes the total (08 row 14), the first leg captured
08 Single-payment limits permit staff recovery methodspermissionapitest
Proves
BR-CAP-COM-ORD-007-08
Preconditions
A single-payment policy governs a portal sale alongside staff offline cases.
Steps
[ { "do": "Attempt a second member payment and record the supported staff methods.", "provenance": "test", "source": "services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses a member a second payment, 409 split_tender_not_allowed naming the policy" } ]
Expected
The member receives split_tender_not_allowed while staff recording succeeds.
Data
Use the controlled records and transports established by the cited tests.
Bound to
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses a member a second payment, 409 split_tender_not_allowed naming the policy
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#lets staff record a money order and a cashier’s check as split payments, each under its Accounting method
Source
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses a member a second payment, 409 split_tender_not_allowed naming the policy
09 Terms conversion retains a purchase-order referencetransitionapitest
Proves
BR-CAP-COM-ORD-007-09
Preconditions
A placed order’s policy permits deferred payment.
Steps
[ { "do": "Choose terms with the supplied purchase-order number.", "provenance": "test", "source": "services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#pay later converts the pro forma to a real invoice and accepts the order on terms" } ]
Expected
The invoice becomes real and the order accepts without a payment charge.
Data
Use the controlled records and transports established by the cited tests.
Bound to
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#pay later converts the pro forma to a real invoice and accepts the order on terms
Source
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#pay later converts the pro forma to a real invoice and accepts the order on terms
10 Merchant account and amount checks precede chargingvalidationapinegativetest
Proves
BR-CAP-COM-ORD-007-10
Preconditions
A frozen account cannot settle the fixture currency and the policy limits card amounts.
Steps
[ { "do": "Try that default, an eligible alternative and an out-of-range amount.", "provenance": "test", "source": "services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#asks Accounting whether the merchant account may settle the tender: the order’s frozen default refused when ineligible, 409 merchant_account_not_eligible, a request naming an eligible account accepted" } ]
Expected
The first fails eligibility, the alternative succeeds and the range check refuses the last request.
Data
Use the controlled records and transports established by the cited tests.
Bound to
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#asks Accounting whether the merchant account may settle the tender: the order’s frozen default refused when ineligible, 409 merchant_account_not_eligible, a request naming an eligible account accepted
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses a card outside the profile’s acceptance range on an order placed under it, 409 tender_kind_not_allowed naming the range, from the order’s snapshot
Source
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#asks Accounting whether the merchant account may settle the tender: the order’s frozen default refused when ineligible, 409 merchant_account_not_eligible, a request naming an eligible account accepted
11 Unanswered invoice creation prevents paymentfailureapinegativetest
Proves
BR-CAP-COM-ORD-007-11
Preconditions
The placed order’s billing transport remains unavailable.
Steps
[ { "do": "Attempt payment while billing retry also receives no answer.", "provenance": "test", "source": "services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses the tender 409 order_not_billed when billing it now gets no answer either, charging nothing" } ]
Expected
The result is order_not_billed and Accounting receives no charge.
Data
Use the controlled records and transports established by the cited tests.
Bound to
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses the tender 409 order_not_billed when billing it now gets no answer either, charging nothing
Source
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses the tender 409 order_not_billed when billing it now gets no answer either, charging nothing
12 Composer recovery retains the created orderinteractionunittest
Proves
BR-CAP-COM-ORD-007-13
Preconditions
Controlled adapters return decline, success, unpaid-close, check and terms cases.
Steps
[ { "do": "Exercise submission and each supported recovery or method choice.", "provenance": "test", "source": "react-console:components/order-composer/__tests__/live-composer.test.tsx#places the order, then takes a card: declined first, approved on the same order" } ]
Expected
The same order remains visible with the appropriate payment result, check reference or terms reference.
Data
Use the controlled records and transports established by the cited tests.
Bound to
react-console:components/order-composer/__tests__/live-composer.test.tsx#places the order, then takes a card: declined first, approved on the same order
react-console:components/order-composer/__tests__/live-composer.test.tsx#keeps the placed order, awaiting payment, when the card pop-up is closed unpaid
react-console:components/order-composer/__tests__/live-composer.test.tsx#records a check against the placed order with its number
react-console:components/order-composer/__tests__/live-composer.test.tsx#bills on terms with the purchase order number, and takes no money
react-console:components/order-composer/__tests__/live-composer.test.tsx#offers the payment methods the checkout policy allows, and no others
Source
react-console:components/order-composer/__tests__/live-composer.test.tsx#places the order, then takes a card: declined first, approved on the same order
13 Order detail renders appropriate financial actionspermissionunittest
Proves
BR-CAP-COM-ORD-007-14
Preconditions
Sample orders span unpaid pay-now, terms, paid and missing-permission cases.
Steps
[ { "do": "Render their action cards.", "provenance": "test", "source": "react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows Take Payment and Void Order on an unpaid pay-now order inside its window" } ]
Expected
The cards show pay-now actions or the Accounting terms link as appropriate and hide unauthorized actions.
Data
Use the controlled records and transports established by the cited tests.
Bound to
react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows Take Payment and Void Order on an unpaid pay-now order inside its window
react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows Receive Payment as a link to Accounting's Settle Invoices with the invoice selected, and no Take Payment
react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows none of them to someone without the permissions
Source
react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows Take Payment and Void Order on an unpaid pay-now order inside its window
14 Staff phone sale survives an initial declineinteractionbrowserproposed
Proves
AS-JNY-COM-ORD-001-01 AS-JNY-COM-ORD-001-02 AS-JNY-COM-ORD-001-03
Preconditions
A live workspace has a customer address, product, promotion and development processor cards.
Steps
[ { "do": "Build the purchase, place it, decline the first card, pay with the replacement and inspect the order.", "provenance": "proposed", "source": "FND-COM-ORD-032" } ]
Expected
The browser retains one order through the decline and later successful charge, with both attempts and invoice conversion visible.
Data
A controlled workspace with the parties, commercial setup and application responses described above.
Source
FND-COM-ORD-032
15 Organization terms sale can be paid through Accountinginteractionbrowserproposed
Proves
AS-JNY-COM-ORD-002-01 AS-JNY-COM-ORD-002-02 AS-JNY-COM-ORD-002-03
Preconditions
A contact without a purchasing role acts for an organization under a terms-capable policy.
Steps
[ { "do": "Place with a purchase-order reference, follow the Accounting payment link and return to detail.", "provenance": "proposed", "source": "FND-COM-ORD-032" } ]
Expected
The browser links the terms sale to its later Accounting payment and eligible delivery.
Data
A controlled workspace with the parties, commercial setup and application responses described above.
Source
FND-COM-ORD-032
16 Two same-key payment writers retain one attemptconcurrencyapitest
Proves
BR-CAP-COM-ORD-007-01 INV-DOM-COM-ORD-002-07
Preconditions
Two database connections record payment with one key on a placed order.
Steps
[ { "do": "Hold the first transaction until the second waits, then commit.", "provenance": "test", "source": "services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#resumes the same attempt on a retry, whatever card the retry names, and moves nothing while the intent is processing" } ]
Expected
The second receives the first attempt and one payment-attempt record remains.
Data
Use an isolated workspace with the records and responses named in the preconditions.
Bound to
services-commerce:modules/orders/tests/integration/services/persistence/orders.integration.spec.js#answers the second the same tender, created: false, once the first committed
Source
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#resumes the same attempt on a retry, whatever card the retry names, and moves nothing while the intent is processing
17 A partially paid void returns only captured moneyinteractionapiproposed
Proves
BR-CAP-COM-ORD-007-07 BR-CAP-COM-ORD-008-06
Preconditions
A placed sale has a captured card leg and an applied credit leg.
Steps
[ { "do": "Void it and replay the money adjustment.", "provenance": "proposed", "source": [ "services-commerce:modules/orders/tests/unit/tender/tender-rules.spec.js#leaves a credit leg that applied less than it asked at what it applied, so the order still owes the rest", "services-commerce:modules/orders/tests/unit/orders/void-refund.spec.js#refunds the paid part of a part-paid order before the memo of its line is cut" ] } ]
Expected
The card refund precedes invoice credit, the credit follows its own treatment and replay sends no extra refund.
Data
Use an isolated workspace with the records and responses named in the preconditions.
Source
services-commerce:modules/orders/tests/unit/tender/tender-rules.spec.js#leaves a credit leg that applied less than it asked at what it applied, so the order still owes the rest,services-commerce:modules/orders/tests/unit/orders/void-refund.spec.js#refunds the paid part of a part-paid order before the memo of its line is cut
18 Applied payments update the order’s balanceinteractionapiproposed
Proves
BR-CAP-COM-ORD-007-07 BR-CAP-COM-ORD-010-06
Preconditions
A billed sale receives less credit than requested.
Steps
[ { "do": "Read its money, pay the remainder and read again.", "provenance": "proposed", "source": [ "services-commerce:modules/orders/tests/unit/tender/tender-rules.spec.js#leaves a credit leg that applied less than it asked at what it applied, so the order still owes the rest", "services-commerce:modules/orders/tests/integration/services/mirror/refresh-money-mirror.integration.spec.js#raises accepted_without_invoice_line on the billed line the view lacks, one open row counting both findings, and still writes the mirror it could derive" ] } ]
Expected
The first read retains the unpaid remainder and the second shows acceptance with that remainder covered.
Data
Use an isolated workspace with the records and responses named in the preconditions.
Source
services-commerce:modules/orders/tests/unit/tender/tender-rules.spec.js#leaves a credit leg that applied less than it asked at what it applied, so the order still owes the rest,services-commerce:modules/orders/tests/integration/services/mirror/refresh-money-mirror.integration.spec.js#raises accepted_without_invoice_line on the billed line the view lacks, one open row counting both findings, and still writes the mirror it could derive
19 Uncertain deposit payment resumes the original attemptinteractionapiproposed
Proves
BR-CAP-COM-ORD-007-01 BR-CAP-COM-ORD-006-01 BR-CAP-COM-ORD-009-01
Preconditions
A billed deposit sale loses its card response.
Steps
[ { "do": "Retry with another token, run recovery and read the schedule after success.", "provenance": "proposed", "source": [ "services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses a second tender of the accepted order, 409 order_not_tenderable", "services-commerce:modules/orders/services/tender/tender-refusals.ts", "services-commerce:modules/orders/services/persistence/orders.ts:recordTender", "services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#answers uncertain, the order tender_uncertain, the attempt uncertain naming Accounting’s intent", "services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#tells the story on the history: placed, billed, the tender recorded, submitted and resolved, the transition to accepted", "services-commerce:modules/orders/services/orders/financial-sweeps.ts:sweepFinancials" ] } ]
Expected
One attempt resolves and acceptance initiates one schedule under the sale key.
Data
Use an isolated workspace with the records and responses named in the preconditions.
Source
services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#refuses a second tender of the accepted order, 409 order_not_tenderable,services-commerce:modules/orders/services/tender/tender-refusals.ts,services-commerce:modules/orders/services/persistence/orders.ts:recordTender,services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#answers uncertain, the order tender_uncertain, the attempt uncertain naming Accounting’s intent,services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#tells the story on the history: placed, billed, the tender recorded, submitted and resolved, the transition to accepted,services-commerce:modules/orders/services/orders/financial-sweeps.ts:sweepFinancials

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.

Rhythm Software