Purchase with a deposit and scheduled payments

Purpose

A deposit purchase connects the up-front payment with the quoted future collection arrangement. Staff can trace the arrangement through the order and its cancellations.

How It Works

A buyer selects a plan offered by the deposit policy and reviews the quoted collection arrangement. Placement preserves the quote and prepares the deposit invoice. Once the deposit requirement is satisfied, Commerce accepts the order and requests its schedule. A deferred schedule can be recovered by later reconciliation, including a schedule read. Installment payment and cancellation refer back to the arrangement already established. The product should transfer this responsibility to Billing under the proposed application boundary.

Relationships

Policy selection permits plan choices, preview obtains the arrangement, payment meets the deposit and cancellation reduces the remaining schedule.

Show evidence (sources, provenance, origins, pinned commits)

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes: Payment of the required deposit accepts a plan order.Cancellation reduces the remaining collection arrangement.
Surfaces: api

Controls

27 controls apply, from the corpus control catalogue.

TC-IAM-006 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-006 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-TEN-004 TC-CRY-001 TC-DAT-001 TC-DAT-002 TC-DAT-003 TC-LOG-004 TC-LOG-005 TC-AVL-004 TC-MON-001 TC-MON-002 TC-MON-004 TC-PI-001 TC-PI-002 TC-PI-003 TC-PI-004 TC-PI-005 TC-PRV-001 TC-PRV-002

Permissions

Key	Checked at	Scope
`commerce.checkouts.update`	api	tenant
`commerce.orders.read`	api	tenant
`commerce.orders.tender`	api	tenant

Business Rules

8 rules, 8 to be proved before approval. A rule's product intent is derived from its origin: 0 confirmed by a product decision, the rest inheriting this capability's proposed.

Id	Rule	Kind	Enforced at	Provenance
`01`must prove Proposed	A deposit policy permits selection only from its offered installment plans, refuses plan selection under pay-now policies and clears the quote when the selection is cleared. proved by `ATS-COM-ORD-001-19`, `ATS-COM-ORD-001-20`, `ATS-COM-ORD-007-19`, `ATS-COM-ORD-009-01`, `ATS-COM-ORD-009-09`, `ATS-COM-ORD-014-19`, `TST-COM-ORD-079`	validation	service	test services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#refuses a plan the order type does not offer, 400 installment_plan_not_offered naming what is offered
`02`must prove Proposed	The preview presents Accounting’s quoted deposit, installments and allocation across order lines. proved by `ATS-COM-ORD-009-02`, `TST-COM-ORD-079`	calculation	service	test services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#answers the preview with the schedule Accounting quotes: 1550 up front of 6200, three installments of 1550, each line split
`03`must prove Proposed	A plan placement preserves its quote, invoices the lines’ deposit portions and accepts the order on payment of that deposit with the payment method vaulted for later installments. proved by `ATS-COM-ORD-009-03`, `TST-COM-ORD-079`	lifecycle	service	test services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#accepted the order on the deposit of 1550 (what it owes now, not its total), the card sent with vault: true
`04`must prove Proposed	Schedule creation follows acceptance under the order key and updates the money summary without making acceptance depend on successful creation. proved by `ATS-COM-ORD-009-04`, `TST-COM-ORD-079`	lifecycle	service	test services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#created the schedule under the order’s key after the acceptance, wrote it on the order and reflected it on the mirror
`05`must prove Proposed	Installment payment requires a schedule and an invoiced unpaid installment, uses the retained payment method and refuses early or repeated payment. proved by `ATS-COM-ORD-009-05`, `TST-COM-ORD-079`	validation	service	test services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#refuses an installment before Accounting invoices it, 409 installment_not_due, charging nothing
`06`must prove Proposed	Cancelling a plan line credits its deposit portion and reduces future installments; cancellation of all item lines ends the schedule and returns the deposit. proved by `ATS-COM-ORD-009-06`, `ATS-COM-ORD-009-08`, `ATS-COM-ORD-014-16`, `TST-COM-ORD-079`	calculation	service	test services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#reduced the remaining installments: the mug’s part gone from the two scheduled ones, the paid one untouched, on the history
`07`must prove Proposed	The product should pass installment terms to Billing, display Billing’s quote and report cancellations there, with Billing owning scheduling, invoicing and collection. no proof recorded yet	policy	service	documented services-commerce:docs/milestones/plans/COMM-realignment-2026-10-22.md#5. The milestones, revised
`08`must prove Proposed	A schedule read can retry deferred creation for an accepted order and reconcile its linked invoices and installment money with Accounting. proved by `ATS-COM-ORD-009-07`	lifecycle	service	observed services-commerce:modules/orders/services/installments/installment-schedule.ts:readOrderInstallmentSchedule

Scenarios

Id	Given	When	Then	Provenance
`01`	A sixty-two-dollar purchase has a deposit and three later installments.	The buyer pays the fifteen-dollar-fifty-cent deposit.	The order is accepted and its arrangement calls for three further payments of the same amount.	test services-commerce:modules/orders/tests/e2e/installments.e2e.spec.js#accepted the order on the deposit of 1550 (what it owes now, not its total), the card sent with vault: true

Planning

Implementation

Purchase with a deposit and scheduled payments ​

Purpose ​

How It Works ​

Relationships ​