Someone taps a button and money appears in your account. Between those two things sits more machinery than you'd expect, and a few surprises that are better discovered now than during launch week.
You don't touch card numbers
The first relief. You will never handle, store, or see a card number.
Payment companies like Stripe give you a checkout page, or components that live in your app but are technically theirs. The card details go from the customer straight to them. Your app only ever receives a message saying "this person paid, here's what for."
That's deliberate, and it's why storing card details yourself is somewhere between a legal minefield and a bad idea. Let people whose entire business is this handle it.
Web and app store are different worlds
This catches people out, and it's worth knowing before you choose where to sell.
If people pay on your website, you use something like Stripe or Paddle and pay roughly 3 percent plus a small fixed fee. You get the money in a few days.
If people pay inside an iPhone or Android app, you generally have to use Apple's or Google's payment system, and they take 15 to 30 percent. Not negotiable, and the rules about what you can even mention in the app are strict. Historically you couldn't so much as link to your own website's cheaper checkout, though that's been loosening in some places.
Thirty percent is a lot. It's worth deciding early whether the paying happens on the web or in the app, because it changes both your pricing and your build.
Subscriptions are a lot of small states
A one-off payment is simple. Someone pays, you give them the thing.
Subscriptions have a surprising number of situations, and each one that isn't handled shows up as a confused or angry customer.
The trial starts, and ends. It converts, or it doesn't. The renewal succeeds. The renewal fails because the card expired, which happens constantly and is the most common one people forget. Someone upgrades mid-month, or downgrades, and something has to happen about the difference. Someone cancels but has paid until the 20th, so they should keep access until then. Someone asks for a refund. Someone's payment fails three times and eventually you have to actually cut them off.
None of these are exotic. All of them turn up in the first month with real customers. Services like Stripe handle most of the mechanics, but your app still has to react correctly when it's told what happened.
The bug that gives everyone a free subscription
Worth naming because it's specific, common, and expensive.
While building, you need a way to test the paid experience without paying. So you write something temporary that says "this user has premium," planning to replace it later.
Then launch happens, and the temporary thing is still there, and every single user has premium. Nobody reports it, because who reports getting things for free.
The general shape of this problem: anything you stub out for testing needs to be impossible to forget. Make it fail loudly rather than fail open. A test mode that crashes when it reaches production is far kinder than one that quietly gives away your product.
Test it with real money
The most important sentence in this lesson.
Payment code that has never processed an actual transaction is not finished. Test modes are useful, and they don't prove the thing works, because the difference between sandbox and live is exactly where the surprises live.
Before launch, buy your own product. Real card, real money, small amount. Watch it arrive. Then cancel it and watch that work too. Then let a renewal happen if you can wait for it.
It feels silly to pay yourself a few dollars. It's the cheapest insurance available.
A quick story. My app had the whole purchase flow built. Subscription service wired in, tiers defined, the paywall screen designed and looking good.
It was never tested against a single real transaction. Not one.
Which meant the thing standing between the app and actual revenue was completely unverified, right up until the end. Everything else was polished, and the part that turns work into money had never been run once in anger.
It's an easy thing to defer because it's fiddly and unglamorous compared to building features. It's also the one part where a bug means you either lose money silently or give the product away, and you may not find out for weeks.
If you want help setting up payments
Point four is the one worth keeping. It's a specific, common, expensive mistake and it's easy to design out before you make it.
That's Chapter 3. You've got a reason for people to return, a first minute that works, a line between free and paid, a price, and a way to collect it. Chapter 4 is getting the thing out of your laptop and into the world.