---
id: TST-ACC-TRX-323
title: Accounting payrix card suite
kind: browser-lifecycle
product_area: accounting
module: transactions
revision: 1
status: draft
source_sha:
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
repository: react-console
files:
  - e2e/mock/accounting-payrix-card.mock.spec.ts
implements: []
implements_parts: []
environment: mock
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 5
isolation: A browser context and suite-controlled mocked responses.
provenance: test
source: 'react-console:e2e/mock/accounting-payrix-card.mock.spec.ts'
evidence:
  - provenance: test
    source: 'react-console:e2e/mock/accounting-payrix-card.mock.spec.ts'
    assertion_titles:
      - >-
        1. the pop-up names Payrix, the host draws its frame and the Card / Bank
        Account toggle
      - >-
        2. a card is tokenized by the host and the payment is recorded with the
        token
      - >-
        3. a decline at the charge shows the reason, and Try Again loads a fresh
        session
      - >-
        4. a failed tokenization says so inline, and the retry runs on the form
        as it was
      - >-
        5. an empty form cannot be paid: Pay shows the host's field error and
        the form stays open
      - >-
        6. a bank account is accepted: the toggle, the host's bank fields, then
        Bank account accepted
      - 7. a returned bank account says why and Try Again starts over
      - 8. with electronic checks off there is no Bank Account toggle
      - >-
        9. a Foundation invoice (a Stripe merchant account, answered by the
        Dummy in mock mode) draws the Test Provider
      - '10. screenshot: ${account.name} ${kind} ${scheme} ${device.name}'
    imports:
      - 'import { expect, test, type Locator, type Page } from "@playwright/test"'
      - 'import { mockUrl, routes } from "../support/routes"'
    test_double_declarations:
      - ' * MOCK: the Take Payment pop-up on a Payrix merchant account (ACCT-M2 WP-Y), against the in-memory Accounting service.'
      - ' * Scripted by the stand-in: card 4242… pays (t1_tok_mock_4242); 4000 0000 0000 0002 is declined at the charge; 4000 0000 0000 0069'
      - ' * fails tokenization ("Your card has expired."); bank 000123456789 clears (t1_tok_mock_6789); 000111111116 is returned.'
      - ' * `?echecks=0` makes the mock merchant account answer card only (no Bank Account toggle).'
      - ' * Seed: INV-1050 ($700, open, customer Harbor, Acme Association). The mock store lives in the page, so a reload resets it.'
      - 'import { mockUrl, routes } from "../support/routes"'
      - 'const IDENTITY = { mockIdentity: "customer" } as const'
      - >-
        /** One of the real Payrix frame's PayFields inputs; the host names its
        containers `pf-<id>-<field>`. The stand-in puts a plain input in the
        container (live PayFields puts an iframe there). */
      - '  await page.goto(mockUrl(routes.accounting.invoice("inv-1050"), { ...IDENTITY, ...query }))'
      - '  // The bank account token settled as an electronic check: the mock service refuses (`invalid.instrument_kind`) any other behaviour,'
      - >-
        test("9. a Foundation invoice (a Stripe merchant account, answered by
        the Dummy in mock mode) draws the Test Provider", async ({ page }) => {
      - '  await page.goto(mockUrl(routes.accounting.invoice("inv-1038"), IDENTITY))'
      - '          await page.goto(mockUrl(routes.accounting.invoice(account.invoice), IDENTITY))'
---

# Accounting payrix card suite

## Verification Boundary

The suite exercises console screens and their requests in a browser with controlled responses. 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

Controlled browser responses do not establish service authorization, database bounds, processor behavior or financial persistence. An unbound feature chain remains proposed, and this registration carries no execution result.

## Real Dependencies and Test Doubles

The real browser and console components run against suite-controlled data or responses. The evidence register identifies the mock setup; those returned values are assumptions of the screen test.

## Must Not Be Doubled

The screen components, their validation and their outgoing request construction are the verification boundary and must remain real. Service financial integrity needs an additional suite with real persistence.