Inspiration
The worst payment bug is the one that only happens on a bad network. A customer clicks Pay. The charge goes through, but the response gets lost on the way back. The page shows an error, so they click again. Now they have paid twice, and nobody on the team has ever seen it happen.
More and more checkout code is written by AI assistants. That code looks right and passes the happy path. It is almost never tested against a lost response, a retry or a late webhook. I wanted a place where you can make those failures happen on demand and see what your code really does with someone's money.
What it does
The demo follows a small bookshop, Bramble Books.
- Fracture Lab runs the shop's checkout and drops the capture response at the worst moment. The customer retries, and two $12 charges go through.
- Eight money rules are checked against what the payment provider actually recorded. The "one order, one capture" rule fails, and the lab shows exactly where.
- An AI model investigates with a read only experiment and names the cause: the retry did not reuse the same request identity.
- AI writes a repair grounded in the real PayPal API contract from the APIMatic SDK, so it uses the right calls and the right headers instead of guessing.
- The repair is verified in an isolated sandbox. A tempting fake fix that just hides the error is rejected.
- The same failure is replayed against the fixed code. One charge. All eight rules pass.
- The duplicate charge is refunded.
- The whole loop is available from the command line and over MCP, so a coding agent can test its own payment code before a human ever reviews it.
How we built it
- A TypeScript monorepo with a Next.js app on Vercel, Postgres for runs and evidence, and Vercel Workflow for long running jobs.
- A shared PayPal core library built on the PayPal server SDK generated by APIMatic. It handles request identity, reconciliation and webhook verification, and it powers our other hackathon projects too.
- A fault injection runner with 13 runnable scenarios, including lost responses, retries, partial failures and replayed events.
- An invariant engine with eight money properties.
- OpenAI and Gemini models for diagnosis and repair, with policy checks and isolated verification before any fix is accepted.
- A CLI and an MCP server with 33 tools for developers and coding agents.
- A contract sheet that ties each PayPal call in the app to the SDK contract and to a passing test.
How AI uses PayPal
AI does two jobs here. It diagnoses money bugs by reading provider state, and it writes fixes that follow the PayPal contract exactly as APIMatic describes it. It is never trusted on its word. Every fix has to pass the same fault that broke the original code.
Tools used and how
- PayPal: Orders, captures, refunds, Webhooks, Agent Toolkit (sandbox)
- APIMatic: generated PayPal SDK and API context as the source of truth for contracts, diagnosis and repair
- OpenAI and Google Gemini: diagnosis, repair generation, independent checks
- Vercel, Vercel Workflow and Postgres: hosting, durable jobs, evidence storage
- MCP and CLI: developer and agent access
Challenges we ran into
Proving a fix is harder than writing one. An AI can make a failing test pass by deleting the check, catching the error or mocking the provider. We had to build a verifier that looks at what changed, not just whether the test is green, and that reruns the original fault in isolation.
Keeping evidence current was the other lesson. A proof that was true yesterday is not proof today, so the build now refuses to ship if the contract proof is stale.
Accomplishments that we're proud of
- A real double charge reproduced in the PayPal sandbox, then fixed, replayed and refunded.
- A recorded loop where a coding agent writes a checkout, fails the lab, looks up the contract, fixes its own code and passes.
- 644 passing tests and a contract sheet where every row is backed by a current proof.
What we learned
AI written payment code needs a referee. Giving the model the real API contract, and then testing its work under failure, is what turns a plausible answer into a correct one.
What's next
More failure scenarios against the live sandbox, support for more languages and frameworks, and a one command check that any team can add to CI.
Notes for judges
The interactive tour runs against a local model of the payment provider so it is instant and free to run, and it is labeled that way. The recorded PayPal sandbox double charge is shown alongside it as the real provider evidence.
Built With
- apimatic
- openai
- paypal
- typescript
