GrowthReceipt

A marketing agent for indie founders that learns from verified PayPal purchases, not likes. Every approved post gets its own buy link, and the agent plans the next move from what people paid for.

Comment

Inspiration

I build small software products, and marketing them always ends the same way. I post on LinkedIn and X, I get likes and clicks, and I still cannot say which post made someone pay. Analytics tools stop at the click. Payment dashboards show the money but not the message that earned it. So the next post is a guess.

I wanted a marketing agent that is judged by the same thing the founder is judged by: real purchases. The server creates and captures each PayPal order, and PayPal confirms the payment with a webhook whose signature the server verifies. That is a much stronger signal than a like, and it was the missing input for an agent that plans marketing.

What it does

GrowthReceipt runs one loop: brief, draft, approve, buy, verify, learn.

  1. Brief. The founder describes the product, audience and channels, or pastes a link to the product page. The agent reads the public page and suggests the brief for the founder to edit.
  2. Draft. The campaign agent writes a week of posts for each channel. Progress streams to the screen as the agent reaches each real step. The run keeps going if the founder reloads or leaves the page, and a toast or an optional browser notification says when it is ready.
  3. Approve. Each post waits for the founder. Each post can be approved, edited, or sent back with a note. "Revise with agent" rewrites a post to match the note, and it returns to review.
  4. Buy. Every approved post gets its own public buy link. A customer who clicks it sees a simple checkout and pays through PayPal. Approved posts can be published to LinkedIn with one click, or posted automatically on their scheduled day once the founder connects LinkedIn and turns that on.
  5. Verify. The server captures the order at its own catalog price, and PayPal confirms the payment with a signed webhook. The purchase is attributed to the exact post that referred it. A Technical proof view lists the order, the capture, each webhook with its signature check, and the credit to the post. The founder can refund a purchase through PayPal from Results. A refund made there or in PayPal reaches GrowthReceipt through the verified PAYMENT.CAPTURE.REFUNDED webhook, and the refunded amount stops counting as revenue and as evidence for the agent.
  6. Learn. The founder asks for the next post. The agent reads the verified purchases, looks up each order it cites with the PayPal Orders API, and proposes one focused experiment, with its reason, its confidence and the evidence it used. "Why this recommendation" shows "Checked with PayPal" with each order and what PayPal returned. Code, not the model, ranks the paying posts and labels the evidence as early, a clear leader, a tie or mixed. A tie asks for a controlled comparison instead of a winner.
  7. Decide. The founder approves, edits or rejects the plan. On approval the agent drafts one new post built on the post that earned the money. It waits in review, gets its own buy link once approved, and the next purchases show whether it earns more.

The agent can also suggest that customers buy a different pack from the product's catalog, for example a larger pack once buyers keep coming back. The switch happens only if the founder approves it, and Results then splits revenue by offer.

A revenue dashboard built with AG Studio shows revenue by post, channel and week, with a PayPal receipts widget that lists each order with its capture and webhook proof. A dashboard assistant answers questions about the numbers. From a next move, "Show these posts in the dashboard" opens it filtered to the posts the agent cited. Before the first purchase the dashboard shows sample data, labelled as samples.

The demo promotes LaunchCheck, a launch page scanner I also built, with its three real scan packs (3 scans for $4, 10 for $9, 30 for $19). Every payment runs in the PayPal sandbox, so no real money moves.

Why it is different

Analytics and UTM links tell a founder which post drew a click. Payment dashboards and PayPal reports show what customers bought, but not which post led to the purchase. Social schedulers publish content but do not learn from purchases. GrowthReceipt connects those steps. Each approved post has its own buy link, each completed PayPal order is attributed to that post, and the agent uses the verified payment evidence to propose the next test. GrowthReceipt creates the checkout itself, so each purchase is credited from a PayPal order it made and a webhook PayPal signed, not matched up from reports afterwards.

Try it in about 60 seconds

  1. Open https://growthreceipt.addisstack.com and select Try the judge demo. No account is needed.
  2. The workspace opens on a sample LaunchCheck campaign. In Content, the Day 3 post on X is already approved.
  3. Select Make a test purchase. The post's buy link opens in a new tab, as a customer would see it.
  4. Pay with the PayPal sandbox buyer shown on the buy page: [email protected], password JudgeBuyer2026!. It is a sandbox account with play money.
  5. Return to the workspace. Today shows the verified payment and the post it is attributed to.
  6. Select Find next move. Read the recommendation and open Why this recommendation to see the evidence. Approve, edit or reject it.
  7. After Approve and draft post, the new post appears in Content for review.
  8. Open Results, then Technical proof, to see the order, capture and webhook IDs. A webhook usually arrives within a minute.

Reset demo at the top of the workspace restores the starting state. Each judge demo is private to its browser.

A guided tour opens on the first visit and walks these steps. Common questions (how a purchase is linked to a post, what if the agent is wrong, why PayPal, what data the agent sees, cost per run, refunds) are answered in the Help panel and in the judge FAQ.

How we built it

PayPal

  • Orders API v2. The FastAPI server creates and captures every order. The browser never sends a price. The server takes it from the campaign's current catalog offer.
  • Each order carries the post's attribution ID in custom_id and the offer in reference_id, so the capture is credited to the exact post whose buy link took the payment.
  • JavaScript SDK v6 on the public buy page, with an eligibility check and a one time payment session.
  • Webhooks. Each event's signature is checked with PayPal before it is stored as proof.
  • PayPal-Request-Id on order creation and capture, so a retried capture returns PayPal's first answer instead of counting twice.
  • Only a capture with status COMPLETED counts as verified revenue.
  • Orders API lookup as an agent tool. The next move agent calls get_paypal_order for the orders it cites. The tool only reads paid orders of the current campaign, at most 5 per run, and code compares status, capture ID, amount and currency with the stored receipt.

AI

  • OpenAI Agents API with streaming sessions. Six agent workflows: brief from a product page, campaign draft, post revision, next move with a PayPal tool, follow up post, and the dashboard assistant.
  • Every output is a typed schema, validated before the app uses it.
  • The next move agent receives normalized PayPal evidence only: purchases per post, revenue per offer, the evidence label and the offer catalog. It is told not to invent conversion rates, traffic or causality.
  • Safety lives in code. The app refuses a recommendation that does not ask for human approval, drops any offer switch outside the catalog, and checks the switch again at approval time.
  • The page reader fetches only https pages on public addresses, checks each redirect, caps size and time, and passes page text to the model as data.

App

  • FastAPI, Postgres on Supabase, Next.js 16 and React, hosted on Railway.
  • AG Studio 3.0 for the revenue dashboard, with a custom PayPal receipts widget, and AG Grid for the purchase evidence table.
  • Agent runs are stored as jobs with their progress steps and a heartbeat, so the page can reattach after a reload. A run that stops beating reads as interrupted instead of running forever.
  • Every founder action and agent run is a campaign event, which gives the activity log and the proof chain.
  • LinkedIn publishing through the LinkedIn API for personal profiles.
  • 126 API tests, including a full revenue loop test through the real routes with deterministic fakes. CI runs ruff, mypy, pytest, Biome and TypeScript checks before anything deploys.

Challenges we ran into

  • Attribution that holds up. A purchase had to be tied to one post without trusting the browser. The fix was one public buy link per approved post. The server looks up the post, the campaign and the offer from the link, so the price and the attribution both come from the server.
  • Small numbers. One purchase is not a winner. I moved the judgment out of the model: code ranks posts by verified revenue, uses the number of purchases to judge how much to trust the lead, and labels anything under 3 purchases as an early signal. The agent has to follow that label.
  • Keeping the agent honest about offers. Letting the agent change what customers buy is powerful and risky. It may only pick from the catalog, only with at least one purchase behind it, and only with the founder's approval.
  • Letting the agent read PayPal safely. The PayPal tool had to see real orders without reaching another founder's orders. It only accepts order IDs from the campaign's own paid receipts, and the result shown to the founder is what PayPal returned, recorded by code, not the agent's summary of it.
  • Agent runs that outlive the page. A campaign draft takes a while, and founders reload or switch tabs. The run now lives on the server as a job, and the page follows it again after a reload.
  • Real world edge cases. An audit pass found that a pending capture would have counted as revenue, and that a buyer could see an old price if the founder switched the offer mid checkout. Both are fixed and tested.

Accomplishments that we're proud of

  • The loop works end to end on the hosted demo, from a pasted product link to a PayPal purchase to an approved follow up post.
  • The proof chain. A judge can open Technical proof and match each order, capture and webhook ID to the post that earned it.
  • The agent changes its advice when the evidence changes. No purchases, an early signal, a leader, a tie, or a mixed result where one post earned more and another was bought more often each lead to a different kind of experiment.
  • Human approval is enforced by the server, not only by the interface.
  • Revenue counts only after PayPal sends a verified PAYMENT.CAPTURE.COMPLETED webhook. Each event ID is stored once, so a retried webhook never counts twice.
  • 126 API tests, plus a hosted Playwright suite that runs daily against the live site. A separate run makes a real PayPal sandbox purchase and refund.
  • A judge can go from the home page to a verified purchase and the agent's next move in about 60 seconds, with no sign up.

What we learned

  • Payment events are a better decision signal for a marketing agent than engagement, because they are verified, specific and hard to fake.
  • The agent works better when code decides the facts (ranking, evidence strength, the catalog) and the model decides the words and the experiment.
  • Showing the agent's real progress and its evidence builds more trust than a polished answer with no trail.

What's next for GrowthReceipt

  • PayPal Subscriptions, so the agent learns which message brings subscribers who stay, not only first purchases.
  • Founders connect their own PayPal account through partner onboarding, so buyers pay the founder directly. Their past PayPal transactions come in through the Transaction Search API as a baseline for which offers customers buy.
  • The offer catalog comes from the founder's own products, and an approved offer switch can run as a split test.
  • Publishing to X and LinkedIn Company Pages, with views and clicks shown next to verified purchases for each post.
  • More autonomy in steps. The agent proposes a new pack or price within limits the founder sets, then acts inside a budget with every action logged and reversible.
  • Specialist agents for writing, analysis and pricing under one planner, with agent runs moved from the API to a job queue served by a worker service.
  • Each past recommendation checked against the purchases that came after it, so founders can see how often the agent was right.

The full plan, with its diagram, is in the architecture doc.

Built With

  • ag-grid
  • ag-studio
  • fastapi
  • github-actions
  • linkedin-api
  • next.js
  • openai
  • openai-agents-api
  • paypal
  • paypal-javascript-sdk
  • paypal-orders-api
  • paypal-webhooks
  • playwright
  • postgresql
  • pydantic
  • python
  • railway
  • react
  • supabase
  • typescript
Share this project:

Updates

Submission history