--- id: TST-COM-ORD-079 title: Installments and deposits kind: api-lifecycle product_area: commerce module: orders revision: 1 status: draft source_sha: services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b repository: services-commerce files: - modules/orders/tests/e2e/installments.e2e.spec.js implements: - ATS-COM-ORD-009-01 - ATS-COM-ORD-009-02 - ATS-COM-ORD-009-03 - ATS-COM-ORD-009-04 - ATS-COM-ORD-009-05 - ATS-COM-ORD-009-06 environment: local implementation_state: implemented latest_result: not-run latest_run_at: null latest_run_ref: null conformance: not-verified estimated_minutes: 2 isolation: The suite creates its own test workspace records and removes them using the fixture cleanup. evidence: - provenance: test source: 'services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js' test_cases: - >- answers the preview with the schedule Accounting quotes: 1550 up front of 6200, three installments of 1550, each line split - 'refuses a plan the order type does not offer, 400 installment_plan_not_offered naming what is offered' - >- refuses a plan under a pay-now ordering profile, 400 ordering_profile_not_deposit, whatever plans it lists - 'clears the choice with null: the preview quotes nothing' - >- froze the plan and the quoted schedule on the order, and billed the DEPOSIT pro forma: each line at its up-front part - >- accepted the order on the deposit of 1550 (what it owes now, not its total), the card sent with vault: true - >- created the schedule under the order’s key after the acceptance, wrote it on the order and reflected it on the mirror - 'answers the schedule route: the plan, the frozen quote, the schedule as Accounting holds it, scheduled' - 'refuses an installment before Accounting invoices it, 409 installment_not_due, charging nothing' - 'answers succeeded: an installment attempt of 1550 with Accounting’s payment, the order still accepted' - >- sent POST /payments with the schedule and the installment and NO method, allocated to the installment invoice, then told Accounting paid - >- linked the installment invoice to the order and moved the mirror in step: invoiced and paid 3100, the installment paid, 3100 remaining - >- refuses paying it again, 409 installment_already_paid, and an installment that is not on the schedule, 400 installment_not_found - 'credits the mug’s up-front part alone (the memo 300, the refund 300), never its financed part' - >- reduced the remaining installments: the mug’s part gone from the two scheduled ones, the paid one untouched, on the history - 'cancels the schedule whole once every item line is cancelled, the T-shirt’s deposit refunded' - 'refuses an installment of the cancelled order, 409 order_not_tenderable' - >- refuses an installment tender on an order with no schedule (a pay-now order), 409 no_installment_schedule, and answers its schedule route no_plan - 'refuses an installment tender without the installment_id, 400 naming it' - >- refuses another member’s order and a reader without the tender key, and answers the schedule route to a reader of the orders scenario_coverage: - scenario: ATS-COM-ORD-009-01 test_cases: - 'refuses a plan the order type does not offer, 400 installment_plan_not_offered naming what is offered' - >- refuses a plan under a pay-now ordering profile, 400 ordering_profile_not_deposit, whatever plans it lists - 'clears the choice with null: the preview quotes nothing' scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-009-02 test_cases: - >- answers the preview with the schedule Accounting quotes: 1550 up front of 6200, three installments of 1550, each line split scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-009-03 test_cases: - >- froze the plan and the quoted schedule on the order, and billed the DEPOSIT pro forma: each line at its up-front part - >- accepted the order on the deposit of 1550 (what it owes now, not its total), the card sent with vault: true scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-009-04 test_cases: - >- created the schedule under the order’s key after the acceptance, wrote it on the order and reflected it on the mirror - 'answers the schedule route: the plan, the frozen quote, the schedule as Accounting holds it, scheduled' scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-009-05 test_cases: - 'refuses an installment before Accounting invoices it, 409 installment_not_due, charging nothing' - 'answers succeeded: an installment attempt of 1550 with Accounting’s payment, the order still accepted' - >- refuses paying it again, 409 installment_already_paid, and an installment that is not on the schedule, 400 installment_not_found - >- refuses an installment tender on an order with no schedule (a pay-now order), 409 no_installment_schedule, and answers its schedule route no_plan scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. - scenario: ATS-COM-ORD-009-06 test_cases: - 'credits the mug’s up-front part alone (the memo 300, the refund 300), never its financed part' - >- reduced the remaining installments: the mug’s part gone from the two scheduled ones, the paid one untouched, on the history - 'cancels the schedule whole once every item line is cancelled, the T-shirt’s deposit refunded' scope: >- The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified conformance claim. dependency_evidence: provenance: test source: 'services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js' declared_by_test: >- the composed handler, the routes, the placement, the billing, tender and installment workflows, the cancellation workflow, the stub participant, the persistence services, PostgreSQL (the stand-in view). Doubled: the signing key pair, the other services' tables (local stand-ins), Accounting (the fixture, with the contracts package's schema and the contract's recorded reading), the facts port and the adjustment commands (the fixtures the running macroservice carries). --- # Installments and deposits ## Verification Boundary The suite drives the composed local API dispatcher and its registered routes. ## What This Suite Proves The registered cases check installments and deposits with their fixture records and assertions. Scenario bindings name only the examples those cases exercise. ## What It Does Not Prove A registered file supplies no run result or verified conformance by itself. Local fixtures do not establish deployed cross-service behavior or complete browser journeys. ## Real Dependencies and Test Doubles PostgreSQL and the exercised Commerce persistence or workflow code are real. Remote service records, clocks and transports follow the suite’s fixtures. ## Must Not Be Doubled The database constraints, role restrictions, locks and transactions exercised by this suite must use PostgreSQL.