Pay $49. See what it changes. Undo it.
Real PayPal sandbox calls, start to finish.
Be the customer
Write as a customer. Claude drafts a real PayPal invoice for you.
- 1Ask to book
- 2Approve the invoice
- 3Pay it on PayPal
- 4See what it changed
- 5Undo
Claude says no
The owner asks to raise the ad with the most leads.
Claude gives money back
Same $49 charged twice. Only what the buyer wrote differs.
The ad's creator gets paid
$5 per PayPal-confirmed paid order, not per lead.
A real shop's October
A Vietnamese gift shop the author runs ads for. Paid by bank transfer.
How this is estimated
From the shop's own October: each ad group's money kept after refunds scales with its new share of the same 260M VND spend, to a power of 0.3 or 0.5 (returns flatten as an ad gets more spend, the usual assumption in marketing-mix models). If returns did not flatten at all, the same split would keep 48% more, an upper bound. One month, three ad groups, spend moved beyond what October tested, and no test: this is what the shop's own numbers imply, not a measured lift. Code: whatIf in src/merchantCase.js, checked by test/merchantCase.test.js.
How the shop counted, and limits
October 2026: 260M VND (about $10,000) on three ad groups, 12,100 chats, 705 orders paid and kept after refunds. Ranked by cost per chat, the ad report's view: A, B, C. Ranked by money kept per ad dollar: B, C, A.
Customers paid by bank transfer (VietQR); an order counts as paid only after the shop's accountant matched the money received to the order code. Meta records which ad started each chat; staff write that ad group's code into the order book, then match it against payments and refunds. That matching is done by hand today; it is the step Paid Signal does from PayPal's records. The figures are reported by the author from the order book and the ad account; the shop confirms them and published its book (1,214 invoices, 735 payments, 30 refunds, anonymised customer ids, in docs/proof); the ad account's own exports are no longer accessible. "Money" is revenue after refunds, before product, delivery and fees.
Paid Signal's split rule (the same code as the demo: paid orders kept per dollar of spend) would suggest A 53.8% → 17.3%, B 28.8% → 46.3%, C 17.3% → 36.4%. An illustration, not a measured lift; a person decides, and Paid Signal does not change a live Meta budget. The shop's payments did not go through Paid Signal or PayPal: the shop is why it exists, not a result of it. Numbers: merchant-case-2026-10.json.
Method and limits
735 bank transfers and the 30 refunds from its refund book, fed to the same ledger code the demo uses. A: 145 orders, 254M VND · B: 390 orders, 741M VND · C: 170 orders, 322M VND. This checks the arithmetic, the refunds and the order matching, not judgement or ad causality. Without order codes the time rule (same payer, same ad, close together) holds 2 of 7 with the 10-minute checkout window and 7 of 7 with the 60-minute window bank transfers get, a window set after reading this book. Every customer in this book ordered once, so false alarms cannot be measured on it. Run your own book in the browser: /audit.
More: the PayPal record, one lead's whole invoice loop, a synthetic week
The PayPal record behind Claude's answer
One lead, chat to paid invoice
A labelled synthetic week: raise and cut together
Its payments are made up, not PayPal captures: it shows a raise and a cut at once, which the live ledger cannot.