Cutover

Migrate legacy PayPal code, and prove it still pays.

Comment

Inspiration

I have managed bank and e-wallet integration projects, and one lesson never changes: cutover day is the scariest day. Changing the payment code behind a live checkout is easy to start and terrifying to finish, because if it breaks, nobody can pay and you only find out afterwards. Many shops still run PayPal code written years ago (the classic NVP API, checkout.js v4, IPN), while PayPal keeps moving developers to Orders v2, its server SDKs, JS SDK v6 and webhooks. AI can do the rewriting. But nobody should have to trust an AI with checkout, so Cutover does not ask for trust. It produces evidence.

What it does

Cutover is an AI migration agent for developers. You point it at a legacy PayPal shop and it:

  1. Discovers every PayPal touchpoint with a plain code scan (43 in the sample shop) and every security risk (9), and says how sure each mapping is. Anything it cannot map goes to a human. It never guesses.
  2. Rewrites the whole shop with Gemini into a separate folder: Orders v2, the PayPal PHP Server SDK, JS SDK v6 and a verified webhook handler. Nothing is applied automatically. Every change is a diff a person approves.
  3. Checks and repairs. Automatic checks catch the AI's mistakes and send them back for repair for up to three rounds: syntax, leftover legacy code, invented SDK methods, contract and smoke tests, and a real Chrome clicking the PayPal button.
  4. Proves it in the PayPal sandbox. The same 7 scenarios (single item, multi-item, buyer cancels, refund, refund twice, replayed confirmation, empty cart) run in a real browser against the old and the new shop. After every payment, PayPal itself is asked what happened. Result (recorded run): 7 of 7 identical, and the touchpoint count goes from 43 to 0.

The demo site runs both shops live. Pay once in each and the page compares the two payments, confirmed by PayPal, and shows which generation of code made each one.

How I built it

  • PayPal: Orders v2, the PayPal PHP Server SDK (generated by APIMatic), JS SDK v6, webhooks (signature verified through PayPal's verify endpoint), and the classic NVP API for the "before" shop.
  • AI: Gemini (gemini-2.5-flash, with gemini-3.1-flash-lite as fallback) does the rewrite and the repairs. It is grounded on PayPal's old-to-new mapping and on SDK facts verified in the sandbox. Gemini never decides what is correct: the checks and the sandbox do.
  • Proof harness: Playwright driving real Chrome, with PayPal queried after each payment, then a diff of the two runs.
  • Demo site: a small Node server runs both PHP shops side by side and the report page, with AG Grid for the findings table. Hosted on Render.
  • Built with Claude Code as my development assistant. Everything was started and built during the submission period.

Challenges I ran into

The AI got things wrong, and that is the point of the project. Real mistakes from real runs, each caught by a check:

  • It invented a PayPal SDK method that does not exist (caught by an SDK guard that looks every controller up in the installed package).
  • It broke the checkout button by awaiting the order before opening PayPal, so the browser blocked the window (caught by a real-browser smoke test).
  • It sent zero-quantity items PayPal rejects, and crashed the whole shop when an optional webhook setting was missing.
  • A cheaper fallback model dropped the cart UI (caught by a UI parity check).
  • It read the wrong field in the webhook event. Offline checks cannot see real events; only a real sandbox webhook after deploy exposed it. The fact is now in the grounding and a check guards it. A second live sandbox payment found another one: the demo server's proxy lowercased PayPal's signature headers, so the handler rejected every real webhook until the header lookup was made case-insensitive (a human fix).
  • A trap only differential testing finds: the classic API is idempotent (replaying a confirmation returns the same transaction), but Orders v2 refuses a second capture. A naive migration silently changes that behaviour. Cutover's replay scenario catches it.

Accomplishments that I'm proud of

  • A migration that is proven, not promised: 7 of 7 scenarios identical, verified by PayPal itself.
  • Honesty built in: the page lists what was left for a human and where the evidence stops.
  • A live demo where anyone can pay in both shops and watch PayPal confirm each payment.

What I learned

Trust in AI-written payment code comes from the checks around the model, not from the model. Checks must run against real systems: the sandbox and a real webhook found bugs that no offline test could.

What's next

More legacy stacks (other languages and PayPal APIs such as DoDirectPayment and billing agreements, which are flagged for a human today), a GitHub bot that opens a pull request with the diff and the proof attached, and a hosted version for teams.

Sandbox only, fake money. Not affiliated with or endorsed by PayPal. Voice-over in the demo video generated with elevenlabs.io.

Built With

Share this project:

Updates

Submission history