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.

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.