PayPal Checkout Integrator

Add PayPal to a custom-built store without touching code. An AI agent writes the integration; nine real PayPal sandbox purchases, not the AI, decide if it works.

Comment

Inspiration

Many small online stores aren't built on Shopify or Wix. A freelancer, an agency, or an AI site builder made them, and the code sits in a GitHub repository the owner never opens. These stores almost always take cards through Stripe, and almost never offer PayPal, even though many shoppers look for the PayPal button at checkout.

Adding PayPal properly isn't a one-line change. It takes:

  • a server SDK and a browser client token
  • a database migration
  • signed webhooks handled exactly once
  • refunds
  • protection against a shopper editing the price in their browser

Then someone has to prove none of it broke card payments. AI coding tools can write this code, but a store owner can't tell whether AI-written payment code is correct. So we built the opposite of "trust the AI": the AI writes the code, and PayPal's own records decide whether it works.

This project is inspired by my experience doing shopping for my favourite scented candles from an artisinal candle maker . They did not have a pay with paypal which I use everyday then I did my research and realized that most stores lose their sales due to lack of shoppers' preferred payment method for example paypal.

What it does

PayPal Checkout Integrator is a GitHub App and dashboard for store owners who can't code.

  1. Connect your store with GitHub. Everything is in plain English, with a Developer view for technical users.
  2. Click "Add PayPal checkout." A Claude agent reads the store and writes a plan. Nothing happens until the owner clicks "Looks good, build it."
  3. The agent adds PayPal next to the card checkout: JS SDK v6 buttons, Pay Later messaging, Orders v2 create and capture, refunds, and verified webhooks.
  4. A robot shopper makes nine real PayPal sandbox purchases: one item; several items; a cancel halfway through; a declined payment; a duplicate webhook; a forged webhook; a price tampered with in the browser; a refund; and the original card checkout.
  5. The owner gets a pull request with a green "PayPal checkout" check and a public test report: the purchase video, PayPal's record of each order, and the Stripe and PayPal database rows side by side.
  6. Every later change is re-tested. In our demo, a later "simplification" let the browser send the total. The check went red, 7 of 9, because PayPal captured $0.01 for a $129 order.

How we built it

  • Agent: Claude (claude-opus-5-5) in a streaming tool-use loop with adaptive thinking and prompt caching. It saves a repo map and a file plan, then builds stage by stage, one commit per stage. Before using any PayPal SDK name, it checks the APIMatic Context Plugin (13 lookups in the hosted run).
  • Guards: once the code is written, nothing the AI says counts. The code has to install, type check, lint, and build. The TypeScript compiler confirms that every PayPal SDK method the code calls exists in the installed @paypal/paypal-server-sdk types. Only planned files may change, Stripe files must be untouched, and no secrets may appear in the diff.
  • Harness: Playwright drives the real PayPal sandbox popup, then each result is confirmed with GET /v2/checkout/orders/{id}.
  • Repair loop: when a check fails, the agent gets the exact evidence and may edit only the files involved, for up to 4 rounds.
  • Product: a Next.js app on Render (sign-in, dashboard, reports, GitHub and PayPal webhooks) and a pg-boss worker that runs the agent and browser, both on Postgres. Secrets are encrypted at rest with AES-256-GCM. A second Claude call rewrites results in plain English and is labeled as AI-written. It never decides pass or fail.

A purchase scenario passes only if PayPal says the order completed, the capture equals the cart total to the cent, and the store's database row matches the row from the same cart paid with Stripe (ignoring provider IDs):

$$ \text{status} = \texttt{COMPLETED} \;\wedge\; \text{captured} = \sum_{i} p_i \, q_i \;\wedge\; \text{row}{\text{PayPal}} \setminus \text{IDs} = \text{row}{\text{Stripe}} \setminus \text{IDs} $$

Challenges we ran into

  • Webhooks: PayPal's simulator events fail signature verification, and the store under test isn't publicly reachable. We built a relay that stores each real sandbox delivery byte for byte and replays it to the store under test. That lets us test duplicate and forged webhooks against genuine signatures.
  • The v6 client token: the sandbox rejects domains[]=localhost, so generated code only sends domains for real hosts.
  • Defining "it works" without trusting the AI: we used the store's existing Stripe behavior as the reference. The same cart paid both ways must produce matching rows.
  • Explaining payment changes to non-coders: early plans asked owners to pick between technical options. We rewrote them so the owner's only decision is yes or no.

What we learned

  • Sandbox APIs make good judges of AI-written payment code: PayPal's order and capture records don't hallucinate.
  • A documentation tool (APIMatic) plus a compiler check that every method exists eliminated invented SDK methods.
  • Non-technical users don't want options. They want a plan they can say yes to, and proof that it worked.

Result: 9 of 9 on a hosted run, from a Stripe-only store to a pull request with a green check in about 30 minutes, for $3.38 of model usage.

Built With

Share this project:

Updates

Submission history