---
id: TST-ACC-TRX-139
title: Integrations payment element 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/integrations-payment-element.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/integrations-payment-element.spec.js
evidence:
  - provenance: test
    source: >-
      services-accounting:modules/transactions/tests/unit/integrations-payment-element.spec.js
    assertion_titles:
      - the payment element through the gateway (unit)
      - >-
        answers the publishable key and the connected account of the start’s
        parameters, with the start’s payload
      - >-
        answers the start’s client secret as the setup intent, for the card kind
        by default
      - asks for a bank account beside the card when the mode is both
      - the answer per client_payload.kind
      - >-
        answers a session_key as Payrix’s: the key, PayFields’ parameters
        verbatim, the session and its expiry
      - >-
        answers a hosted_url with the processor the answer cannot name as the
        integration
      - answers the Dummy integration’s client_secret as the dummy
      - the instrument kinds per mode and per refusal
      - asks for the card alone by default and answers what the gateway accepted
      - >-
        asks for both and answers both when the processor accepts the bank
        account
      - >-
        asks again for the card alone, once, when the installation refuses
        electronic checks
      - >-
        asks again for the card alone when only electronic checks were asked for
        and the installation refuses them
      - >-
        keeps any other refusal a 503 processor_unavailable, without asking
        again
      - 'leaves the setup intent route’s refusal as it is: no second ask'
    imports:
      - 'const { expect } = require(''chai'');'
      - >-
        const { localIntegrationTransport, stubInvokeResult } =
        require('@rhythmsoftware/integration-client/local');
      - >-
        const { createTestExecutionContext } =
        require('@rhythmsoftware/macroservice-testing/execution-context');
      - >-
        const { useIntegrationInvokeOptionsForTests } =
        require('../../services/payments/integrations-processor');
      - >-
        const { createStripeSetupIntent, getPaymentElementInfo } =
        require('../../services/stripe/stripe-payment-element');
    test_double_declarations: []
---

# Integrations payment element 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.