Full agent audit · paddle.com · 2026-08-08
Four runs mentioned Paddle. All four chose Stripe.
The task was a checkout for two support plans. The runs disagreed about Paddle’s onboarding, and one relied on competitor pricing summaries. None completed a payment with the provider it chose.
What the agents were asked
The company wants to sell paid support plans to customers who read the help centre. Add a checkout to this app: a page that offers two plans, takes a card payment, and tells the existing Go API which customer bought what. Pick a payment provider, wire the client side, and document what the Go service has to do. Decide alone, nobody is available to answer questions.
No vendor names, no mention of an audit, no hint that anyone was watching. A working helpdesk knowledge base: Vite, React 19, TypeScript, a static bundle in front of a separate Go service the agent cannot see or edit. Four isolated copies, one per run.
Who they picked
- Stripe4 / 4
Why they rejected paddle.com
Every run that named paddle.com appears here. Where the run left a sentence we hold verbatim, it is quoted; where it did not, the entry is our summary of that run’s own report and says so.
Onboarding needs manual seller approval and a business review, which the run judged further out of reach than a Stripe keyRead quote
Paddle - merchant-of-record handles global VAT/sales tax for us, genuinely attractive. Rejected because onboarding requires manual seller approval and a business review, which is even further out of reach for an agent than a Stripe key, and MoR pricing is a commercial decision nobody authorised.
Rejected on fee figures the run took from competitor-published comparison pages it never openedRead quote
All SEO comparison content, much of it published by competing payment providers, so the fee figures (Stripe 2.9% + $0.30, Paddle 5% + $0.50) should be confirmed on the vendors' own pricing pages before anyone acts on them. I did not open any of those pages.
Merchant-of-record margin of roughly 1.5 to 2 points for tax handling the task did not need, and a thinner Go ecosystem (paraphrased: this run reported in Polish)
Lighter to test than the winner, and rejected anyway for being a merchant of recordRead quote
Paddle - genuinely lighter to test: sandbox signup needs no domain/business approval (unlike its live accounts). Rejected mainly because it's a merchant-of-record, which changes the integration shape and business relationship more than the task called for.
Did they read anything live
These counts show which runs fetched live sources. They do not establish that a run read paddle.com's own documentation or checked every claim it used.
What we make of it
Four runs, two models, one task: add a checkout for two support plans. All four chose Stripe; none completed a payment. Their reports describe an account or credential handoff, not a completed integration.
The reasons for rejecting Paddle differed. Run A described manual seller approval; run D described its sandbox as lighter to test. Run B used competitor pricing summaries and acknowledged that it had not opened those pages. These are the runs’ accounts of onboarding and pricing, not independent verification of every claim.
The useful next test is whether a clear account of sandbox access, live approval and fees changes how agents describe the product. We have not tested that change. Four runs on this brief do not measure lost sales or establish which payment provider is best.
What to change
- 01hours
Make sandbox access and live approval easy to distinguish
Runs A and D described different entry requirements. Put the sandbox steps and the separate live approval process together in a short, dated explanation. Then repeat the task and check whether agents still confuse the two.
- 02hours
Check what pricing summaries say about your product
Run B relied on competitor summaries it did not open. Compare those statements with your own pricing page and clarify the scope of the fees in text an agent can quote. A clearer page may help; this study did not test its effect.
- 03days
Test a complete sandbox handoff
All four runs stopped at an account or credential step for Stripe, the provider they chose. In a new, explicitly scoped Paddle test, give an agent an authorised sandbox account and check whether it can complete the checkout. That would separate access problems from implementation problems.
Limits of this audit
- Four runs, two models from one family. Cursor, Copilot and Codex may filter differently.
- One brief and one scaffold. Two flat support plans on a help centre favours a simple card checkout; a marketplace or a global consumer product would weigh merchant of record very differently, and merchant of record is the whole of Paddle's case.
- Rejection reasons are summaries taken from each run's own report. Only the sentences shown in quotation marks are archived verbatim; where a run left no archived quotation, the entry says so.
- Nobody attempted a signup, so onboarding is reported as the agents perceived it. Where they disagreed, we checked: sandbox accounts are self-serve with email verification and no business or domain approval, and the manual review applies to live merchant-of-record accounts. One run was describing the live path.
- Paddle is the subject because it was named in every run and chosen in none. The runs attempted integration with Stripe; this study does not show whether they could have completed a Paddle integration with an authorised sandbox account.
Where would agents get stuck with your product?
An integration pilot tests two tasks with two tools, records the failed steps, and includes one small fix and a retest. We agree the tasks before starting.