---
id: TST-ACC-TRX-147
title: Payment method rules suite
kind: unit
product_area: accounting
module: transactions
revision: 1
status: draft
source_sha:
  services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8
repository: services-accounting
files:
  - modules/transactions/tests/unit/rules/payment-method-rules.spec.js
implements: []
implements_parts: []
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 1
isolation: In-memory fixtures and test-controlled collaborators.
provenance: test
source: >-
  services-accounting:modules/transactions/tests/unit/rules/payment-method-rules.spec.js
evidence:
  - provenance: test
    source: >-
      services-accounting:modules/transactions/tests/unit/rules/payment-method-rules.spec.js
    assertion_titles:
      - a payment’s method (unit)
      - paymentMethodIdOf
      - reads the payment_method_id
      - >-
        maps each retired value of the method alias to the system method it
        became
      - reads any other alias as a method id
      - accepts the id and an alias naming the same method
      - >-
        refuses the id and an alias naming two methods, 400
        payment_method_mismatch
      - refuses a request naming no method
      - behaviourOfAlias
      - 'knows the behaviour of each retired value, and none of a configured id'
      - paymentChannelOf
      - >-
        takes the request’s channel, else the portal for a portal payment, else
        the console
      - requireUsablePaymentMethod
      - answers a method active and offered in the channel
      - 'refuses a method the tenant does not have, 404 payment_method_not_found'
      - 'refuses an inactive method, 409 payment_method_inactive'
      - >-
        refuses a method the channel does not offer, 409
        payment_method_unavailable
      - >-
        refuses only existence in requireExistingPaymentMethod, so the receive
        can choose its path before the command
      - missingReferenceRefusal
      - >-
        refuses a required reference absent from a request naming the method by
        id, 400 payment_reference_required
      - accepts the reference given
      - keeps the earlier contract for a request on the method alias
      - asks nothing of an import
      - asks nothing of a method that prompts for no reference
      - what reads a payment’s behaviour (unit)
      - 'goes through the processor for card and bank_debit, never for offline'
      - >-
        keys the settlement item by reconciliation’s kind: card, or
        electronic_check for a bank debit
      - >-
        gives a refund the retired value of the payment’s method: the processor
        behaviours’ own, an offline system method’s, else other
      - >-
        names the batch rules’ payment type of a provisioned or migrated method
        by its id, any other by its behaviour
      - names a refund’s retired method value as before
      - admits every processor reversal but a bounced check for processor money
      - admits a bounced check only for an offline method that may bounce
    imports:
      - 'const { expect } = require(''chai'');'
      - '} = require(''../../../services/payments/payment-method-rules'');'
      - >-
        const { batchPaymentTypeOf } =
        require('../../../services/batches-for-documents');
    test_double_declarations: []
---

# Payment method rules suite

## Verification Boundary

The suite exercises financial calculations and input contracts in an isolated test process. Registration records the existing executable file; it does not report a run or establish product approval.

## What This Suite Proves

The executable assertions exercise this module, but no capability or feature scenario binding is established for this file. Its individual assertion titles remain in the evidence register for subsequent mapping.

## What It Does Not Prove

Pure calculations and doubled collaborators do not establish database persistence, route authorization or deployed behavior. An unbound feature chain remains proposed, and this registration carries no execution result.

## Real Dependencies and Test Doubles

The imported calculation or contract runs with the fixtures and collaborators declared by the test. The evidence register retains those declarations so the boundaries can be inspected.

## Must Not Be Doubled

The calculation or contract being asserted must remain real; replacing it with a predetermined result removes this suite’s evidence.