--- id: CAP-ACC-BKS-012 title: Configure the methods used to receive money feature: FEAT-ACC-BKS-04 product_area: accounting module: books revision: 1 status: draft product_intent: confirmed implementation_evidence: observed supersedes: - CAP-ACC-CFG-019 source_sha: services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f intent_sources: - >- services-accounting:docs/architecture/accounting-2.0/02-decisions.md#2.11 The payment methods, deferred payment and order collection decisions (Andrew, 2026-10-18 evening); decision D-01 - >- services-accounting:docs/architecture/accounting-2.0/02-decisions.md#2.11 The payment methods, deferred payment and order collection decisions (Andrew, 2026-10-18 evening); decision D-05 - >- services-accounting:docs/architecture/accounting-2.0/02-decisions.md#2.11 The payment methods, deferred payment and order collection decisions (Andrew, 2026-10-18 evening); decision D-08 purpose: >- Finance staff name payment methods and define how each is offered and recorded. outcomes: - Configured methods retain the payment behaviour transactions interpret. - Initial system methods remain present and active. - Offline receipt remains a staff-only channel. concepts: - CON-ACC-BKS-006 actors: - ACT-ACC-001 - ACT-ACC-002 - ACT-ACC-003 - ACT-ACC-005 surfaces: - console - api preconditions: [] postconditions: [] permissions: - key: accounting.payment-methods.read where_checked: api scope: tenant - key: accounting.payment-methods.create where_checked: api scope: tenant - key: accounting.payment-methods.update where_checked: api scope: tenant rules: - id: BR-CAP-ACC-BKS-012-01 proved_by: [ATS-ACC-BKS-012-01, ATS-ACC-BKS-012-10, TST-ACC-BKS-057, TST-ACC-BKS-093, TST-ACC-BKS-171] statement: >- A payment method chooses card, bank-debit or offline behaviour at creation and cannot later change that behaviour. kind: invariant enforced_at: - api - service - database must_prove: true provenance: test source: >- services-accounting:modules/books/tests/e2e/payment-methods.e2e.spec.js#answers 409 payment_method_behaviour_immutable to another behaviour origin: >- services-accounting:docs/architecture/accounting-2.0/02-decisions.md#2.11 The payment methods, deferred payment and order collection decisions (Andrew, 2026-10-18 evening); decision D-01 - id: BR-CAP-ACC-BKS-012-02 proved_by: [ATS-ACC-BKS-012-02, ATS-ACC-BKS-012-09, TST-ACC-BKS-093] statement: >- The five system methods—credit card, ACH, cash, paper check and wire—remain active and keep deposit handling, while permitted name, description, ordering, reference, availability and bounce choices may be changed. kind: policy enforced_at: - service - database must_prove: true provenance: test source: >- services-accounting:modules/books/tests/integration/services/persistence/payment-methods.integration.spec.js#refuses to be deactivated, 409 payment_method_system origin: >- services-accounting:docs/architecture/accounting-2.0/02-decisions.md#2.11 The payment methods, deferred payment and order collection decisions (Andrew, 2026-10-18 evening); decision D-01 - id: BR-CAP-ACC-BKS-012-03 proved_by: [ATS-ACC-BKS-012-03, ATS-ACC-BKS-012-07, TST-ACC-BKS-093] statement: >- Offline methods are console-only; every method has distinct nonempty channels, defaulting to console for offline, console and portal for bank debit, and all channels for card. kind: validation enforced_at: - api - service - database must_prove: true provenance: test source: >- services-accounting:modules/books/tests/integration/services/persistence/payment-methods.integration.spec.js#refuses an offline method offered in the portal, naming the rule origin: none - id: BR-CAP-ACC-BKS-012-04 proved_by: [ATS-ACC-BKS-012-04, TST-ACC-BKS-093, TST-ACC-BKS-174] statement: Only offline methods may allow bouncing or deposit into undeposited funds. kind: validation enforced_at: - service - database must_prove: true provenance: test source: >- services-accounting:modules/books/tests/integration/services/persistence/payment-methods.integration.spec.js#refuses a card method that may bounce origin: none - id: BR-CAP-ACC-BKS-012-05 proved_by: [ATS-ACC-BKS-012-04, TST-ACC-BKS-093, TST-ACC-BKS-174] statement: 'A prompted reference has a label, and an unprompted reference has none.' kind: validation enforced_at: - service - database must_prove: true provenance: test source: >- services-accounting:modules/books/tests/integration/services/persistence/payment-methods.integration.spec.js#refuses a prompted reference without its label origin: none - id: BR-CAP-ACC-BKS-012-06 proved_by: [] statement: >- Methods have no delete operation despite the published delete permission; non-system methods can instead be deactivated. kind: policy enforced_at: - api must_prove: false provenance: observed source: 'services-accounting:aws/accounting.service.ts:PaymentMethodsPermissions' origin: none - id: BR-CAP-ACC-BKS-012-07 proved_by: [ATS-ACC-BKS-012-05, TST-ACC-BKS-093] statement: >- Migration adds active cashier’s check, money order and offline card methods and inactive purchase-order and payroll-deduction methods, all outside the protected system set. kind: lifecycle enforced_at: - service must_prove: true provenance: test source: >- services-accounting:modules/books/tests/integration/services/persistence/payment-methods.integration.spec.js#writes cashier’s check, money order and offline card active, and the two legacy methods inactive, none a system method origin: none - id: BR-CAP-ACC-BKS-012-08 proved_by: [] statement: >- Method lists sort by configured order and name and filter by behaviour, channel, public-link availability or active state. kind: policy enforced_at: - api - service must_prove: false provenance: test source: >- services-accounting:modules/books/tests/integration/services/persistence/payment-methods.queries.integration.spec.js#orders by sort order, then name, then id, answering only the tenant’s methods origin: none scenarios: - id: SC-CAP-ACC-BKS-012-01 given: Staff need a check-number prompt on check payments. when: >- The administrator renames Paper Check and configures a required reference labelled Check #. then: The method remains offline and requests the reference when used. provenance: test source: >- services-accounting:modules/books/tests/e2e/payment-methods.e2e.spec.js#renames a system method - id: SC-CAP-ACC-BKS-012-02 given: The administrator has defined an offline Lockbox method. when: They try to make it available in the portal. then: The save is refused because offline receipt is console work. provenance: test source: >- services-accounting:modules/books/tests/e2e/payment-methods.e2e.spec.js#answers 400 to an offline method offered in the portal, naming the rule edge_cases: [] constraints: [] depends_on: [] related: - CAP-ACC-BKS-019 - CAP-ACC-BKS-003 journeys: [] open_questions: [] evidence: - 'Verified source file: services-accounting:aws/accounting.service.ts' - >- Verified source file: services-accounting:docs/architecture/accounting-2.0/02-decisions.md - >- Verified source file: services-accounting:modules/books/db/payment-methods.table.ts - >- Verified source file: services-accounting:modules/books/tests/e2e/payment-methods.e2e.spec.js - >- Verified source file: services-accounting:modules/books/tests/integration/services/persistence/payment-methods.integration.spec.js - >- Verified source file: services-accounting:modules/books/tests/integration/services/persistence/payment-methods.queries.integration.spec.js - >- Verified source file: services-accounting:modules/books/tests/unit/rules/payment-method-rules.spec.js controls: [TC-IAM-001, TC-IAM-002, TC-IAM-003, TC-IAM-004, TC-IAM-005, TC-AZ-001, TC-AZ-002, TC-AZ-003, TC-AZ-004, TC-AZ-005, TC-AZ-006, TC-TEN-001, TC-TEN-002, TC-TEN-003, TC-DAT-001, TC-DAT-004, TC-LOG-001, TC-LOG-002, TC-LOG-003, TC-LOG-004, TC-LOG-005, TC-PI-001, TC-PI-003, TC-PI-005] exercised_by: [FAS-ACC-BKS-04-01, FAS-ACC-BKS-04-02, FAS-ACC-BKS-04-03, FAS-ACC-BKS-04-04] suites: [TST-ACC-BKS-057, TST-ACC-BKS-093, TST-ACC-BKS-171, TST-ACC-BKS-174] --- # Configure the methods used to receive money ## Purpose Finance staff name payment methods and define how each is offered and recorded. ## How It Works The administrator reviews the methods available to the workspace. They adapt names and reference prompts to the finance team’s language. A newly added method chooses the payment behaviour that later workflows use. Availability determines where the method can be offered. Offline money remains work that staff record in the console. A change that conflicts with method behaviour is refused. System methods remain available, while other obsolete methods can be deactivated. ## Relationships Provisioning supplies system methods, and payment workflows interpret each method’s behaviour.