When AI Writes Code That Moves Money: Tests, Environment Separation and Human Approval Before Production

Code written with AI that touches charges, refunds or transfers needs five controls that have nothing to do with security: real environment separation, a test suite covering the money path, idempotency on every financial action, daily reconciliation against the provider, and a recorded human approval before it ships.

Why is financial correctness a different problem from security?

Because it breaks even when nobody is attacking. A double charge, a currency that switched, a rounding rule that always falls one way, a refund recorded twice: these are business-logic bugs occurring in entirely legitimate traffic. A good security review will not catch any of them, which is why the two reviews complement rather than replace each other. The other side, the one that does ask who got in, is covered in security risks in AI-generated code.

There is also a behavioural difference in the generated code. Code produced quickly gravitates to the successful path: a payment that clears, one customer, a stable network. The real money path is made mostly of the other cases, and those are precisely what does not get written unless it is asked for explicitly.

Environment separation: what test mode has to mean in practice

• Production keys exist neither on the development machine nor in any file tracked in git.
• The environment is selected from one environment variable, not a flag in code somebody can forget.
• The test database is entirely separate, including its backups and its queues.
• Real email sending and real charging are blocked in the test environment, not merely unused.
• Copying production data into test passes through a masking step for customer detail.
• The startup log states plainly which environment it is running in, on the first line.

The simple rule: if a scenario exists in which a local run can charge a real card, separation does not exist. General background on the split is in staging versus production environments.

What does a money-path test suite have to cover?

The important test here is not "the payment succeeded" but "what happened when it did not". The case table below is the minimum, and every row in it represents a bug that has already happened to somebody.

The middle three rows are the ones fast-written code almost always misses, because each of them requires thinking about what happens between the request and the response.

Idempotency and the double charge

Idempotency means a request sent twice produces one result. In payment terms: the customer is charged once even if the network swallowed the response and the system tried again.

1. Generate a unique key for the financial action before the first call, not during the retry.
2. Store the key on the order record, so it survives a server restart.
3. Send that same key on every retry of that exact same action.
4. Never reuse a key for a different action, however similar it looks.
5. Treat an "already processed" response as success rather than as an error.
6. Cover this path with an automated test that simulates a lost response.

Payment providers document the mechanism explicitly, and it is still absent from quickly generated code, because the successful flow never needs it. That is the definition of a control: something redundant right up to the moment it is the only thing preventing damage.

Daily reconciliation: the control that catches what stayed quiet

Reconciliation is a daily comparison across three sources: what your system recorded, what the provider reports, and what the bookkeeping holds. A gap counts as a finding even when no log contains an error.

• Count transactions, not only totals. Two errors can cancel out into a correct sum.
• Match on transaction id, never on amount plus date.
• Separate a timing gap, such as a business-day offset, from a real one.
• Run the comparison every day, including days on which nothing happened.
• Alert on a gap rather than producing a report somebody is meant to open.
• Store the reconciliation result, so it can be revisited six months later.

A transaction that failed quietly produces no error and no alert. It produces only a gap, which makes reconciliation the only control that will find it. The comparison methods themselves are the same ones described in card transaction reconciliation.

Human approval and the audit trail

• Any change touching amounts, currency or rounding gets read by a person, even when the tests pass.
• The release is staged, for example a small share of traffic, before it is opened fully.
• Every financial action stores a request id, the provider's transaction id and the accounting record id.
• The log states who approved, which version, and when it went live.
• A written rollback procedure exists, including what to do about charges already made.

The third item is the one that decides matters when an accountant asks a question. Those three ids are what turns "what happened in this transaction" into a single query instead of an investigation, and that holds whether the code was written by a person or by a model.

Sources

• Stripe API - idempotent requests
• Stripe documentation - testing