A production payment platform, built with AI, stopped from launching by AI

Every enterprise is currently being told that AI writes code now. The demonstrations are real and the productivity claims are largely true for the first eighty percent of a system.

The question nobody demonstrates is the last twenty. Can an AI-built system take money? Can it be trusted with the path where a mistake means a customer is charged and receives nothing? That is where the argument actually sits, because a checkout is the least forgiving thing anyone builds. Everything else in a business degrades politely. A payment path either takes the money and records the order, or takes the money and loses it, and the second one you learn about from the customer.

The defects that matter there are not the ones a test suite finds. They live in the seams: a transient database error during a handoff between two services, a retry that fires twice, a queue that accepts a job and quietly drops it. These are exactly the failures that both human teams and AI-assisted teams miss, because everyone tests the path where things work.

So the real question for an AI-native build is not whether the AI can write the code. It is whether you have built an assurance process good enough to catch what the AI, and the humans reviewing it, would otherwise ship.

The organisation sells scheduled certification training and was running its commercial operation on a legacy administration system it did not control and could not extend.

It needed its own platform: a storefront and checkout that took real payments, a back office staff could genuinely run classes from, and the document trail that follows a sale, including certificates and invoices.

One constraint shaped the entire architecture. If the system of record goes down for twenty minutes, that must not stop anyone buying. Revenue availability and record-keeping availability are different requirements, and conflating them is how a back-office deployment takes the storefront down with it.

We froze the design before any build code was written, and kept it outside the repository. Architecture, data model, flows and wire contracts live in a separate design vault governed by a canonical field dictionary. Decisions are numbered. When a contract has to change, the vault changes first and the repository follows, never the reverse.

Seventy-eight numbered decisions came out of that discipline, forty-two locked at the design freeze and the rest recorded during build and launch. On an AI-native build this is not bureaucracy. It is the only thing standing between you and a codebase that drifts a little further from its own design with every generated file.

We split the money path from the record path. Checkout runs as its own service, a FastAPI application with a React front end, and it is the always-on component. It captures payment, then hands the order to the platform asynchronously. If the back office is briefly unavailable, browsing and paying continue and orders queue behind them. Buyers never log in at all, which removes an entire category of account and session risk from the storefront.

We consolidated to one trunk-based monorepo mid-build. The original plan called for four separate repositories. We dropped it once it was clear the shared payment, mail, document and domain-type libraries would end up copied between them. Duplicated shared libraries in an AI-assisted build diverge quickly, because each repository’s context contains a slightly different version of the same truth.

We instrumented the boundaries where money changes hands. Dollars are used at every staff-facing boundary rather than integer cents, because the failure mode there is a human misreading a figure and issuing the wrong refund. Processor fees are sourced differently for online and offline payments, since assuming one source for both silently corrupts reconciliation.

We ran a verification pass on the numbers rather than trusting them. The back-office dashboard went live only after all 121 of its computed figures were checked by hand against independently derived values. An AI-built reporting surface that is confidently wrong about revenue is worse than no reporting surface, and the only way to know is to compute the numbers a second way.

Then we pointed thirteen agents at it. Two days before launch we ran a multi-agent end-to-end campaign against the real stack, real Postgres and real Redis, rather than a mocked environment.

The campaign returned NO-GO.

It found that a transient database error during the handoff between checkout and the system of record could silently drop a paid order. The customer would have been charged. The order would not have existed. Nobody would have known until that customer made contact, and the ones who never make contact are the part that should worry you.

The fix was a retry with a dead-letter queue, so a paid order retries and, if it still cannot land, parks somewhere visible rather than vanishing. We re-verified on real infrastructure the same day and lost zero of fifteen orders.

That single defect is the entire justification for the campaign, and for running it against real infrastructure. A conventional pre-launch check would have exercised the happy path, found it green, and shipped. The 1,079 automated tests did not catch it either, because the failure required a transient fault at a specific moment in a distributed handoff, and that is not a scenario a unit test expresses.

It is also the honest answer to the question about AI-built systems. The AI built it, the AI found the defect the AI had built, and a person made the call to accept a NO-GO two days from launch.

The platform is in production and the health endpoint returns OK. Orders have been placed through the live checkout in a real browser and are on file.

Those orders ran on test-mode payment keys. No customer money has moved through the platform yet, because three owner-controlled gates remain deliberately closed. An earlier internal note claimed real customer orders were flowing through it, and that was corrected, because it was not true.

We would rather state that plainly than let the more impressive version stand. Anyone evaluating this work should know that the money path is built, tested and assured, and has not yet carried a live customer transaction.

The database also runs as a single managed instance. High availability was deliberately deferred rather than overlooked, with point-in-time recovery enabled and a restore drill completed and passed. That is a considered position for the current stage, not a permanent one.

Two things, and they matter more to an enterprise than the platform itself.

AI-native delivery needs assurance that scales with it. If AI multiplies how much code a team produces and the review process stays the same, the fraction of the system anyone has genuinely examined collapses. The answer is not to slow the generation down. It is to raise the assurance ceiling by the same factor, which in practice means using agent fleets adversarially, against real infrastructure, with the standing to fail a release.

Design authority has to live outside the code. A frozen design vault with numbered decisions and a canonical field dictionary is what stops an AI-assisted build from drifting away from its own architecture. Vault changes first, repository follows. Without that, every generation is locally sensible and the system as a whole slowly stops making sense.

For a client asking whether they can trust AI to build something that matters, this is the honest answer. Yes, provided you build the thing that catches it when it is wrong, and provided somebody is willing to act on the verdict.