---
id: TST-COM-ORD-093
title: Installments and deposits
kind: integration
product_area: commerce
module: orders
revision: 1
status: draft
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
repository: services-commerce
files:
  - modules/orders/tests/integration/services/installments/installments.integration.spec.js
implements: []
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/integration/services/installments/installments.integration.spec.js
    test_cases:
      - >-
        writes the schedule id once with order.installment_schedule_created, and writes nothing for the same
        id again
      - 'refuses another schedule for the order, 409, and a schedule on an order with no plan, 409'
      - >-
        records an installment attempt on an accepted order, and refuses a card attempt there and an
        installment one on a placed order
      - creates nothing while the order is placed (the schedule follows the deposit)
      - >-
        creates the schedule under the order’s key once accepted: the order’s lines at their totals, the order
        number, the id written, the mirror reflecting it
      - answers exists on a repeat without asking Accounting again
      - wrote order.installment_schedule_created with the key
      - >-
        records a lost answer as order.installment_schedule_deferred, leaving the order without a schedule,
        and creates it on the next try
      - >-
        takes the schedule Accounting names when it holds one already (installment_schedule_exists under
        another key)
      - >-
        links the invoiced installment’s invoice once, purpose installment, keyed by the installment, no line
        id moved
      - >-
        writes the schedule’s reflection on the mirror: the invoiced installment, what remains, the next due
        date
      - 'reduces the scheduled installments to the remaining unit’s financed part, under the cancellation’s key'
      - cancels the schedule once every item line is cancelled
      - 'tells the story on the history: reduced, then cancelled, each naming the cancellation and the outcome'
      - 'answers not applicable for an order with no schedule, asking nothing'
scenario_coverage: []
dependency_evidence:
  provenance: test
  source: 'services-commerce:modules/orders/tests/integration/services/installments/installments.integration.spec.js'
  declared_by_test: >-
    PostgreSQL (the stand-in view), the persistence services, the installment workflows, the execution
    contexts under `rhythm_commerce_app`. Doubled: Accounting (the fixture, in process), the clock (fixed).
---

# Installments and deposits

## Verification Boundary

The suite exercises persistence or workflow operations against the local integration database.

## 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.