Getting paid is a system, not an afterthought

Most business owners treat payments as the last checkbox on launch day — sign up for something, paste in a button, hope money arrives. That is how you end up with three-day payout delays during your best week of sales, a disputed charge that freezes your account, and a tax season built on spreadsheet guesswork. A payments system is the machinery between your customer clicking "buy" and money landing in your bank account, and it deserves to be designed before you sell anything.

Think of the pipeline in four stages: capture, authorization, settlement, and payout. Capture is the moment you collect payment details. Authorization is the card network asking the customer's bank, "does this person have the funds, and is this legitimate?" Settlement is the actual movement of money between banks — it happens in batches, not instantly. Payout is the processor moving your accumulated balance to your bank account on its own schedule. A failure at any stage looks different: a failed capture is an abandoned checkout, a failed authorization is a declined card, a failed settlement is a missing deposit, a failed payout is a cash-flow crisis.

Your job in this course is to build that pipeline end to end and understand every failure mode inside it. You will choose a processor deliberately instead of defaulting to whatever your friend uses, set it up with the right account type and verification from day one, configure test and live environments properly, wire up the events that tell your business "payment succeeded" (webhooks), and learn how to handle the unhappy paths — declines, refunds, disputes — without panicking. By the end you will have a working Stripe test integration you built yourself, which means when you flip to live mode you are changing a setting, not discovering your setup for the first time with real money on the line.

The cost of skipping this is real. A single disputed charge with no documentation strategy costs you the sale, the merchandise or service already delivered, and a $15 dispute fee. A payout stuck in a verification review costs you the payroll or ad spend it was supposed to cover. Build the system first; the sales are easier after.

How money actually moves: cards, ACH, and digital wallets

Three rails carry almost all online payments, and they move money in fundamentally different ways. Understanding the differences tells you when to offer each one, what each costs, and where each breaks.

Cards (Visa, Mastercard, Amex, Discover) run on the card networks. When a customer pays, their bank (the issuer) authorizes the charge against the card, the network settles the funds between banks in a batch process, and your processor eventually pays you out. Authorizations are near-instant; settlement typically lands in your processor balance in one to two business days. Fees are the highest of the three rails — around 2.9% plus 30¢ per transaction in the US — because the issuer bank takes a cut (the interchange fee) and the network takes a cut (the assessment). Failure modes: declines (insufficient funds, fraud flags, expired cards), chargebacks (the customer disputes through their bank, which can claw the money back weeks later), and card-updater problems when stored cards expire silently.

ACH moves money directly between US bank accounts through the Automated Clearing House network — no card network in the middle. It is dramatically cheaper (Stripe charges 0.8% capped at $5), but slow: debits take three to five business days to clear, and a payment can be reversed by the account holder for up to 60 days. ACH works for large invoices, retainers, and subscriptions where the fee savings beat the delay — a $2,000 invoice costs about $1.66 in card fees per hundred versus a $5 cap on ACH. Never use it for anything where you deliver value instantly before the debit clears.

Digital wallets (Apple Pay, Google Pay, Link) are not separate rails — they are a layer on top of cards and bank accounts. The customer authenticates with their phone's biometrics and the wallet passes a one-time token to the processor instead of raw card numbers. Checkout conversion jumps because the customer never types a 16-digit number; fraud drops because tokens are useless if stolen. Cost is the same as a card payment underneath. Offer wallets at every checkout and invoice by default — there is no downside.

The practical rule: cards for anything consumer-facing and instant, ACH for big-ticket B2B invoices, wallets everywhere as the fast lane on top.

What you will build in this course

By the final module you will have a complete, working payments setup in Stripe's test mode — the same dashboard, API, and webhook plumbing that real businesses use, running against simulated money so you can break things safely. Here is the build order, which matches the modules:

Module 1: You pick your processor using real fee math on your own numbers, not vibes. You will complete account setup with the right business details the first time (entity type, tax ID, beneficial owners, bank account), because re-verification later freezes payouts. You will understand payout schedules and reserves so cash flow never surprises you.

Module 2: You go deep on Stripe: the dashboard's four neighborhoods (Payments, Customers, Billing, Developers), API keys and where each one lives, test mode versus live mode, and creating products and prices with real code — curl and Node.js, run against your own account. You will set up a webhook endpoint with signature verification, the single most skipped step in DIY payment integrations, and test it locally with the Stripe CLI.

What you will NOT do in this course: flip the switch to live mode and accept real money. That step requires your completed business verification, your real bank account, and decisions about pricing and refund policy that are business calls, not technical ones. Everything here is designed so the live switch is a small, boring change: new API keys, same code. If any step feels mysterious, stop and re-read — "I sort of get webhooks" is exactly the state that causes silent order-fulfillment failures later.

A note on scope: Stripe is the reference implementation because it has the best docs, the cleanest test mode, and the widest feature set. The concepts — authorization versus capture, settlement, webhooks, disputes — transfer to every processor. Learn the machinery once, on Stripe; you will recognize it everywhere else.