Rhythm 2.0 Specifications

Appearance

ATS-COM-ORD-007Collect payment without duplicate charges: Acceptance Test Set

Markdown

ATS-COM-ORD-007

Collect payment without duplicate charges: Acceptance Test Set

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-COM-ORD-007

KindAcceptance test setProduct areaCommerceModuleCustomer purchases, purchased benefits and vendor stockRevision1

Read atservices-commerce c8b66a98react-console baf6dae3

Test Scenarios

15 scenarios proving CAP-COM-ORD-007; 13 bound to an existing test.

01 Unresolved card retries resume the original attemptapitest
Proves
BR-CAP-COM-ORD-007-01
Preconditions
Accounting has not supplied a final answer for a card request.
Steps
Retry with another token and later resolve the original 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 paymentapinegativetest
Proves
BR-CAP-COM-ORD-007-02
Preconditions
One placed order is past its window and another is accepted.
Steps
Attempt the normal tender action for both.
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 paymentapitest
Proves
BR-CAP-COM-ORD-007-03
Preconditions
An order predates policy removal of a method and another policy lists no offline choice.
Steps
Try portal offline payment, a retained frozen method and staff cash.
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 tokenapitest
Proves
BR-CAP-COM-ORD-007-04
Preconditions
A card payment uses a token and merchant account.
Steps
Inspect the returned payment attempt.
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 orderapitest
Proves
BR-CAP-COM-ORD-007-05
Preconditions
An unpaid pay-now order has a usable window.
Steps
Submit a declining card and then an approving card.
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 attemptsapitest
Proves
BR-CAP-COM-ORD-007-06
Preconditions
A payment intent can be processing, completed or unresolved beyond fifteen minutes.
Steps
Run the tender reconciliation cases.
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 requirementapitest
Proves
BR-CAP-COM-ORD-007-07
Preconditions
A seventy-five-dollar sale has limited credit and two card legs.
Steps
Apply credit and the successive card payments.
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 methodsapitest
Proves
BR-CAP-COM-ORD-007-08
Preconditions
A single-payment policy governs a portal sale alongside staff offline cases.
Steps
Attempt a second member payment and record the supported staff methods.
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 referenceapitest
Proves
BR-CAP-COM-ORD-007-09
Preconditions
A placed order’s policy permits deferred payment.
Steps
Choose terms with the supplied purchase-order number.
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 chargingapinegativetest
Proves
BR-CAP-COM-ORD-007-10
Preconditions
A frozen account cannot settle the fixture currency and the policy limits card amounts.
Steps
Try that default, an eligible alternative and an out-of-range amount.
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 paymentapinegativetest
Proves
BR-CAP-COM-ORD-007-11
Preconditions
The placed order’s billing transport remains unavailable.
Steps
Attempt payment while billing retry also receives no answer.
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 orderunittest
Proves
BR-CAP-COM-ORD-007-13
Preconditions
Controlled adapters return decline, success, unpaid-close, check and terms cases.
Steps
Exercise submission and each supported recovery or method choice.
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 actionsunittest
Proves
BR-CAP-COM-ORD-007-14
Preconditions
Sample orders span unpaid pay-now, terms, paid and missing-permission cases.
Steps
Render their action cards.
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 declinebrowserproposed
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
Build the purchase, place it, decline the first card, pay with the replacement and inspect the order.
Expected
The intended browser proof shows one sale and successful charge with both attempts and invoice conversion; it remains unbound.
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 Accountingbrowserproposed
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
Place with a purchase-order reference, follow the Accounting payment link and return to detail.
Expected
The intended browser proof connects the audited terms sale to later paid money and eligible delivery; it remains unbound.
Data
A controlled workspace with the parties, commercial setup and application responses described above.
Source
FND-COM-ORD-032

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