PAYMENTS / LESSON 01

How Online Payments Work.

What happens when someone pays online, why you never handle card numbers yourself, and how to choose a payment tool

Written by Andrew Lee JenkinsPublished Oct 5, 202610 min readFree lesson

Taking money online looks like one lil button. Behind that button are banks, card networks, fraud checks and a LOT of rules. In this lesson we'll walk through what actually happens when someone pays, why apps hand that whole job off to a payment provider, and the two very different tools this module covers.

What Happens When Someone Pays

Here's a simplified card payment, from the click all the way to money landing in your account.

Step 1. The Customer Enters Their Card

They type their card details on a checkout page, or they tap something like Apple Pay or Google Pay.

Step 2. The Payment Provider Takes Over

The card details go to the payment provider. Your app never gets them. The provider passes the payment request along through the card network, like Visa or Mastercard.

Step 3. The Customer's Bank Decides

The bank that issued the card checks the account and either approves or declines the payment.

Step 4. Your App Hears the Result

The provider tells your app whether the payment worked, usually with a webhook.

Step 5. The Money Arrives Later

Approved payments get collected and paid out to your bank account on a schedule, minus the provider's fees (yeah, they take their cut).

Example

  Customer --- card details ---> Payment provider ---> Card network ---> Customer's bank
                                       |                                     |
                                       |<------------ approved or declined --+
                                       |
  Your app <--- webhook: "payment succeeded" ---+
     |
  Give the customer what they bought

Why You Never Touch Card Numbers

Handling raw card numbers comes with strict security rules, known as PCI compliance. Meeting those rules yourself is a big job, and it never really ends.

Payment providers carry that weight for you. The card number goes straight from the customer's browser to the provider's secure systems. Your app only ever sees a reference to the payment and never the card itself.

What Else a Payment Provider Handles

Card processing is only the start. A good provider also deals with all of this.

Fraud. Spotting stolen cards and sketchy payments.
Refunds. Sending money back to the customer.
Disputes. When a customer asks their bank to reverse a charge, also called a chargeback.
Subscriptions. Charging the same customer every month, and retrying when a card fails.
Payment methods. Wallets, buy now pay later, and local options in other countries.
Receipts and invoices. Proof of what was paid.

Never Trust the Thank You Page

So a customer lands on your "thank you" page. Did they pay? Maybe... and maybe not. They could've closed the tab halfway through, or just typed the URL in directly.

The signal you can actually trust is the webhook. The provider sends your server a signed message saying the payment succeeded, and THAT'S when you give access, ship the order or send the receipt. You'll see webhooks in action in the Stripe chapter, and they get a full lesson of their own later on in the API Fundamentals module.

Two Kinds of Payment Tools

This module covers two tools that live in very different places.

	Payments API	Selling Platform
What it is	Building blocks you wire into your own app	A place to sell, with payments built in
Who builds the checkout and product pages	You, using the provider's tools	The platform does it for you
Who tracks who paid for what	Your app and database	The platform keeps memberships and access
Best when	You want full control inside your own product	You sell digital products, memberships or access and want to move fast

Stripe is a payments API. Whop is a platform for selling digital products, memberships and access, with payments built in.

If you know me at all, you know I'm the own-your-tools guy. Three years of an all-in-one SaaS can run you $30,000+ handed to a company that can change the rules any Monday. Even so, I'm not telling you to build card processing from scratch (please don't).

What to Look For

When you're comparing payment tools, ask yourself these questions.

What are you selling? Physical goods, software subscriptions, courses, community access?
Do you want your own checkout or a ready-made one? More control means more work.
Which payment methods do your customers use? Cards, wallets, local methods.
How do you find out a payment worked? Look for clear webhook docs.
Is there a test mode or sandbox? You should be able to make fake payments while you build.
What are the fees? Most providers take a fee on each transaction instead of charging a flat monthly price.

The Tools in This Module

Tool	Kind	Chapter Covers
Stripe	Payments API	How a payment flows, checkout, webhooks and testing
Whop	Selling platform	What it is, setting up a product and checkout, and the developer side

TL;DR

A payment travels from the customer, through the provider and card network, to the customer's bank and back
Payment providers handle card security so your app never touches card numbers
They also handle fraud, refunds, disputes, subscriptions and payment methods
Trust the webhook, never the thank you page
Stripe is a payments API you build with, and Whop is a selling platform with payments built in
Check fees on the provider's own pricing page

What's Next?

The Stripe chapter is up first. You'll see why payments get complicated and how a Stripe payment flows from start to finish...

Loading the lesson…

Loading activities…