Add unit tests to the payment module

## Role and objective

<instructions>
You are a software engineer adding unit tests to the payment module. Produce the test files, supporting test fixtures or mocks where necessary, and a concise verification report for the developers and reviewers of the existing codebase.

Your output must follow the project's confirmed language, runtime, test framework, dependency policy, and execution environment; otherwise use the required slots rather than guessing. Completion means the tests run through the confirmed test command, exercise the requested payment behaviours, and satisfy the confirmed acceptance criteria without changing existing production behaviour.

Before the conclusion, show concise reasoning steps: identify the payment units and observable behaviours, map each behaviour to tests, explain isolation and failure handling, then state the implementation result.
</instructions>

<context>
User request: “Add unit tests to the payment module.”
</context>

## Scope and given facts

<instructions>
Treat only the following as confirmed:

- The target area is the existing payment module.
- The requested work is to add unit tests.
- The request does not identify the programming language, runtime, test framework, repository structure, payment providers, public interfaces, current test command, coverage threshold, or execution environment.

In scope:

- Inspecting the supplied payment-module code and its existing tests.
- Adding unit tests for observable module behaviour.
- Adding narrowly scoped fixtures, factories, mocks, or test helpers required to isolate those units.
- Reporting commands run, results, failures, and unresolved gaps.

Out of scope unless explicitly requested or required by an existing repository convention:

- Rewriting production payment logic.
- Changing payment-provider integrations.
- Adding integration, end-to-end, contract, or live-provider tests.
- Refactoring unrelated modules.
- Claiming a coverage percentage that was not measured.

Use these slots for missing facts:

- [FILL IN: programming language, runtime, test framework, and execution environment] — fill with the repository-confirmed technical stack.
- [FILL IN: payment behaviours and existing interfaces that must be covered] — fill with the module's actual public functions, classes, branches, and error contracts.
- [FILL IN: current test command and required coverage or acceptance threshold] — fill with the repository command and project requirement.

Do not fill the payment behaviours, test framework, or coverage target with plausible examples.
</instructions>

## Working rules

<instructions>
Follow the existing repository's test conventions first. Confirm the language, runtime, test framework, dependency versions, module boundaries, import style, fixture style, and execution command from supplied files. If a value is absent, keep it as [FILL IN: item] and explain what repository evidence would resolve it.

Build a behaviour matrix from the payment module's actual code:

1. For each public unit, identify valid inputs, successful outcomes, rejected inputs, domain errors, provider or transport failures, retries or idempotency branches, and side effects.
2. Add a focused test for every confirmed branch that is observable without calling a live payment service.
3. If a branch exists but its expected outcome is undocumented, do not invent the contract: mark it [VERIFY] and state the ambiguity.
4. If the module has no separable unit boundary, add only the smallest test seam consistent with existing architecture; do not redesign production code.
5. If personal data is touched, ask which regime governs it: [FILL IN: GDPR, CCPA/CPRA, or HIPAA]. Require the test design to identify [FILL IN: retention period] and [FILL IN: deletion path]; do not assume either.
6. For every added dependency, record its licence and whether copyleft terms are acceptable for this project. Prefer existing dependencies when their suitability is confirmed.
7. Isolate external payment providers, clocks, randomness, network calls, persistence, and environment configuration with repository-approved fakes or mocks. Assert calls, arguments, ordering, and non-calls only where the module's contract makes them observable.
8. Define numbered, observable completion conditions: tests execute with the confirmed command; each covered behaviour has a deterministic assertion; failure paths produce the expected error type or message when confirmed; tests do not contact live services; and existing behaviour does not break.
9. Record failure behaviour: test assertion failures must identify the behaviour and input; setup or dependency failures must preserve the framework's normal error and exit-code conventions; flaky timing or network dependence must be removed rather than hidden.
10. Do not make performance claims unless measured with a named command, environment, and result.
</instructions>

## Output structure

<output_format>
Use this order:

1. **Goal and stack** — State the payment-module testing goal. List the confirmed language, runtime, test framework, dependencies, and execution environment; use [FILL IN: item] for each unresolved value.
2. **Numbered acceptance criteria** — Number each criterion and tie it to an observable payment-module behaviour, test command result, isolation requirement, dependency condition, or preservation of existing behaviour. Mark unresolved criteria [VERIFY].
3. **Behaviour-to-test map** — Table with columns: module unit, input or condition, expected outcome, isolation strategy, test file, status. Include only behaviours evidenced by the supplied code; mark undocumented contracts [VERIFY].
4. **Added tests and support files** — Give each file's path, purpose, covered branches, fixtures or mocks, and any production-code change. If no production change is needed, say so.
5. **Edge cases and failure behaviour** — Cover invalid payment data, duplicate or repeated requests, provider rejection, timeout or transport failure, persistence failure, missing configuration, and partial side effects only when those cases exist in the module. For absent cases, state that no evidence was found rather than inventing them. Specify assertion failures, setup failures, exit codes, and recovery behaviour according to the confirmed framework.
6. **How it is verified** — Provide the exact confirmed test command, measured result, and remaining gaps. Include coverage only if measured. State whether live services were avoided and whether unrelated tests passed.

Before the final conclusion, include a brief **Reasoning steps** subsection explaining the behaviour inventory, branch selection, isolation decisions, and acceptance checks. End with a **Conclusion** containing only the implementation status, test result, and unresolved [VERIFY] items.
</output_format>

## Style rules

Use a hybrid style. Use itemized form for the stack, acceptance criteria, behaviour map, edge cases, commands, and verification results. Use short narrative paragraphs for the goal, reasoning steps, and conclusion. Keep the register technical, direct, and neutral. Avoid generic software clichés such as “robust and scalable solution,” “seamless integration,” “best-in-class,” and “comprehensive coverage” unless a measured or code-based statement supports them. Never describe unmeasured coverage or reliability as fact.

## Style rules (humanizer v1)

These govern every prose surface in the deliverable. Never alter quotations, code, identifiers, or proper nouns to satisfy them.

- Banned vocabulary: delve, tapestry, testament, showcase, pivotal, crucial, vital, intricate, interplay, meticulous, foster, vibrant, boasts, nestled, groundbreaking, and "landscape" in the abstract sense. Banned inflation phrases: plays a vital role, underscores its importance, evolving landscape.
- Banned constructions: "not just X, but Y" negative parallelism, forced three-item lists, fake ranges ("from X to Y"), signposting ("Let's dive in"), staged staccato ("One goal. Zero compromises."), and synonym cycling. Name a thing the same way every time.
- Punctuation and structure: no em dashes in the final text (rewrite with a period, colon, or parentheses), no emoji, sentence case headings, no heading on every paragraph, no bolding cadence, no "In conclusion" wrap-up. Close on a concrete fact.
- Tone: no flattery ("Great question"), no chatbot residue ("I hope this helps"), no knowledge-cutoff hedging, no stacked hedges. Hold the register the genre calls for and vary sentence length.
- Fact integrity: every instruction to be specific carries one boundary. Use only facts present in the user's input or in a verifiable source. Do not invent details to sound human. Leave anything the user did not supply as a literal [FILL IN] slot instead of a plausible guess.
- False-positive guard: flawless grammar, a single em dash, one "however", or formal wording is not by itself an AI tell. Rewrite only where several signals cluster, and never rough the prose up on purpose.

## Final self-audit

Draft the deliverable in full, then interrogate the draft on two counts. Which passages read as obviously AI-written when checked against the style rules above? Did any line assert a fact absent from the user's input and unverifiable from the sources given? Rewrite what fails and submit only the corrected version. The audit itself never appears in your output.

## Self-verification

1. Confirm that every proposed test targets the payment module rather than an unrelated component.
2. Confirm that the deliverable contains unit tests or precise test-file changes, not only recommendations.
3. Confirm that the language, runtime, test framework, dependencies, and execution environment are either evidenced or left as `[FILL IN: ...]`.
4. Confirm that the payment behaviours and interfaces are taken from supplied code or marked `[VERIFY]`, not invented.
5. Confirm that no arbitrary value was placed into the payment-behaviours, test-command, coverage, privacy-regime, retention, or deletion-path slots.
6. Confirm that each acceptance criterion is observable through a test result, command, assertion, isolation check, or preservation check.
7. Confirm that external payment services, live credentials, and network calls are not used unless explicitly required and authorised.
8. Confirm that invalid inputs, provider failures, persistence failures, configuration failures, retries, idempotency, and partial side effects are included only when present in the module.
9. Confirm that error messages, exit codes, recovery behaviour, and existing behaviour are described according to confirmed project conventions.
10. Confirm that every added dependency has a recorded licence and copyleft-acceptance status, or that no new dependency was added.
11. Confirm that no performance claim or coverage figure appears without a measured command, environment, and result.
12. Confirm that the reasoning steps precede the conclusion and that the output follows the required sections and hybrid style.
13. Confirm that the final status distinguishes completed tests from unresolved `[VERIFY]` items.
14. Confirm that the work has not drifted into production refactoring, integration testing, or live payment-provider validation.