A2A Purchase Pipeline

The purchase infrastructure Whop is building for the fall launch — the checkout flow, quantities, tags, workflow IDs, the metadata every payment carries, and how ClarityPay comes through. Every workflow, page, and link below is clickable.

Prepared by Parisa (Whop) · 1 Sep 2026 · the Copy button grabs this whole document as Markdown for pasting into an AI model or doc

1The flow, start to finish

2The checkout pages — live URLs & editors

Installments are Whop-native split-pay: the saved card is charged monthly and billing stops automatically after the final cycle. More than 10 seats goes through a sales rep's custom invoice, not the checkout.

3Quantities

• The seat count is chosen with a stepper at checkout and travels as metadata.quantity — a string, "0"–"10", on the Whop payment.
• No attendee names or emails are collected at checkout — by design (31 Aug call). The purchaser adds their team's names and emails afterward in TubConnect; nothing about the roster lives in the checkout.
• The buyer's own primary seat is not in quantity: a founder purchase with quantity: "3" is four people — one primary + three team seats.
• metadata.company is captured whenever seats are in the cart — the key that ties a later seats-only purchase back to the same account.

4The metadata contract

Every field rides payment.metadata on the Whop record and arrives in the webhook payload verbatim.

Tiers TO CONFIRM — Scott + team
A tier is what the buyer now holds; an offer is the path they took to hold it (bootcamp precedent: eb-ga/ga are offers, ga is the tier). Three tiers, proposed 2 Sep:

• Team members are never a tier. They hold no payment; a seat-holder activates in TubConnect, which is what fires W3. The seat count lives on the founder's payment as quantity.
• Payment path is not a tier. 10-pay and ClarityPay buyers hold the same thing as a pay-in-full buyer; the path is schedule + a2afall26_plan-{schedule}.
• Open question for Scott: should a seats-only top-up be its own tier (a2a-seats, as built) or land as a2a-primary with a quantity? Built as its own tier so Supabase can tell a founder purchase from a top-up without reading amounts. Scott adds the three codes to sales.offer_tiers once confirmed.

5ClarityPay — exactly how it comes through

Verified against Whop's codebase, 1 Sep:

• An approved application puts the payment at status: "pending", which fires the payment.pending webhook event. It sits there for up to 24 hours.
• When ClarityPay funds it, the payment flips to status: "paid" and payment.succeeded fires — same payment id, ~a day later. TUB is paid the full $9,970 up front at funding.
• Pending + metadata.schedule: "claritypay" is the successful-onboarding signal. Nothing else in this system produces a pending status — declines stay at status: open + substatus: failed (Whop declines never reach a terminal status), and an abandoned cart never creates a payment at all.
• Wired in the worker: pending + ClarityPay runs the full fulfilment (contact, tags, workflows) at approval; when funding later fires payment.succeeded for the same payment, fulfilment is deliberately skipped — the buyer is never onboarded twice — and only the status update is forwarded so the Supabase row flips to succeeded. Any other payment.pending (bank rails etc.) stays acknowledged-and-ignored.

6GHL — tags & workflows

Tag convention a2afall26_{action}-{detail}, applied additively by the worker; GHL never derives them. Location: REIO | The Uncommon Business (TL6J90dhkW0GGz8sogzu).

Workflows — Abs's fall builds (31 Aug, currently drafts) in the fall workflow folder. Contacts enter by API call, never tag trigger, so no NOT-filters are needed anywhere.

7n8n → Supabase

Decided architecture (31 Aug call): the worker feeds GHL for tagging and workflows, and n8n → Supabase powers the live dashboard and TubConnect access. What n8n receives is the Whop webhook payload — payment id, status, amounts, buyer, and the full §4 metadata — so Supabase rows carry quantity, company, schedule, and ghl_contact_id with no lookups.

De-duplication lives in Supabase and GHL (per the 31 Aug spec): the same email must not re-trigger onboarding — installment cycles 2–N and later seat top-ups are new payments from an already-onboarded buyer. Uniqueness on the Whop payment id (processor, processor_ref) keeps a replayed webhook from double-inserting.

8Infrastructure links

Questions → Parisa (Whop). The repo copy of this doc updates with the code that implements it.