You have a pathway, an exchange, a model, an offer, and a price hypothesis. All of it is theory until money can move cleanly — and the buyer, the access, and the records all agree about what happened. This lesson designs that moment.

The vocabulary

• Checkout — the buyer-facing page or link where they confirm what they buy and pay. Hosted by a provider; you never see card numbers.
• Payment processor — the regulated service that moves money (card networks, bank rails) and handles compliance. Examples: Stripe, Paddle, Gumroad. You choose one; you do not become one.
• Invoice — a request to pay, typically for services, with amount, due date, and payment instructions. A receipt proves payment already happened; an invoice asks for it.
• One-time payment — a single charge for a bounded outcome (a brief, a package, a workshop seat).
• Subscription — repeating charges for continuing value, with a defined renewal rhythm and a cancellation path (deepened in Class 81).
• Trial — limited-time or limited-scope access before payment. Free, paid, or freemium — each is a different promise (Class 81).
• Renewal — the moment a subscription continues (and the receipt the customer should receive).
• Refund / cancellation process — the stated path for undoing or ending the exchange, including timelines and what access remains.
• Receipt — the provider-issued proof of charge. Always send one; it prevents half your support mail.
• Payout — money moving from the provider to your bank account, minus fees, on the provider's schedule — not the moment the customer pays.

Learn these once and every provider's dashboard becomes readable: they all implement the same nouns with different button labels.

The durable system

Whatever provider you use, the flow is the same six steps. Design all six before integrating any:

offer page → checkout / invoice → confirmation → access / delivery → support + cancellation path → records / reconciliation

1. Offer page states the promise (80.4) with price, rhythm, and exit path. No surprises at checkout. 2. Checkout / invoice collects payment securely. One-time service? A fixed invoice or payment link suffices — no subscription engine needed. 3. Confirmation tells the buyer what happened: receipt, what they now have, when it arrives or renews, how to get help. Send it immediately. 4. Access / delivery grants exactly what was sold: workspace seat, report download, fitting appointment, workshop invite. Access should derive from payment status, not from memory. 5. Support + cancellation path answers "it failed" and "I want out" before they are asked. Who responds, within how long, at which address. 6. Records / reconciliation logs every charge, refund, and payout so month-end is arithmetic, not archaeology.

A common beginner inversion is building step 2 first (a beautiful billing integration) with steps 1, 4, and 5 as afterthoughts. Reverse it: write steps 1, 4, and 5 in plain language, then wire step 2 to serve them.

Who handles what: provider mechanics vs. builder decisions

The division of labor is clean:

• The provider handles mechanics: card collection and storage, charge attempts and retries, tax-calculation helpers, receipts, payout timing, PCI-compliant surfaces.
• You own the decisions: the offer and its boundaries, the access rule (who gets what, when), the support owner and response time, the customer experience around failure and cancellation.

Concretely: Stripe can retry a failed card and email a receipt. Only you can decide whether a lapsed subscriber keeps read access to old briefs, who answers a "my team cannot log in" message on a Sunday, and what your refund window is. Write those decisions in the flow document below — an implementation agent can wire webhooks, but it cannot invent your policy.

Two safety rules connect to Part XI (security) and Part VII (infrastructure):

1. Never store card details yourself — in a database, a spreadsheet, or an email thread. Use the provider's secure checkout and billing surfaces exclusively. 2. Treat access and payment status as controlled product state. "Does this account currently have workspace access?" must be answered by one authoritative check (provider subscription status mirrored in your system), not by scattered flags. Lesson 81.4 builds the retention side of this state.

Three worked flows (illustrative hypotheticals, not provider quotes)

• Research-service package ($495 fixed): invoice → client pays by due date → confirmation email with delivery date and revision terms → brief delivered + walkthrough booked → one revision window, then case closed → invoice marked paid, receipt filed. Failure path: overdue invoice triggers one reminder, then the slot releases. Support: named owner, 48-hour reply.
• Desk workspace ($39/seat/month): checkout link → provider confirms subscription → account gains workspace seats automatically → monthly renewal with receipt → cancellation link in every receipt; read access to past briefs for 30 days. Failure path: failed renewal triggers provider retry plus your plain-language notice ("update your card to keep Monday briefs"). Support: help address plus a status page.
• Local / classroom equivalents: tailor's wedding package takes a 50% deposit invoice at booking and the balance on pickup, with the fitting dates in the confirmation. A ByeBuy weekend workshop sells fixed seats through a payment link; confirmation carries the prep checklist and the refund date (full refund until seven days before, transfer after).

Each flow fits on half a page — and each names the failure path, which is where trust is actually built.

DO: write your PAYMENT-FLOW.md

Exercise. Create PAYMENT-FLOW.md:

# PAYMENT-FLOW
Payer: [who pays + method, e.g. team lead, card via provider link]
Trigger: [what starts payment — booking, checkout click, invoice due date]
Confirm: [receipt + message buyer receives + what access/delivery follows + timing]
Failure path: [declined card / overdue invoice / expired trial → retry, notice wording, who follows up]
Support: [owner, channel, response time; cancellation + refund terms with dates]
Records: [where charges/receipts/payouts are logged; monthly reconciliation step]

Finish line: a payment-to-delivery workflow detailed enough to hand to an implementation agent — no missing owner, no "we'll figure out refunds later."

Verify: walk the flow with a test dollar (or the provider's test mode): pay, confirm the receipt reads correctly, check that access appears and disappears on schedule, and trigger one failure. If any step requires you to remember something manually, write the checklist or automate the check before launch.

Common failure mode: no written failure or cancellation path. The first declined card or "please refund me" then becomes a improvisational crisis — in front of the exact customer whose trust you most need. Write the sentences while calm.

Check your understanding

1. What does the provider handle, and what must the builder decide no provider can decide? 2. Why must access derive from payment status as controlled state rather than manual flags? 3. What six steps belong in every payment flow, and which one do beginners most often skip?

Next: Class 81

Class 80 gave you the full decision stack: pathway, exchange, family, first test, offer, price, payment. Class 81 deepens the product pathway — subscriptions that earn renewal through recurring value, honest trial design, pricing units, and churn as product feedback. Bring your VALUE-EXCHANGE.md, OFFER-CARD.md, and PAYMENT-FLOW.md: the subscription work starts from them, not from a billing dashboard.