Show Me the Money

Narrated

Your trip planner is genuinely good. People sign up, they generate AI-powered itineraries, they upload photos, everything runs smoothly in the background, and the state machine keeps everything orderly. You’ve shown it to friends. Some of them use it regularly. A few have told their friends.

And now someone asks the question you’ve been thinking about: “Can I pay for this? I’d love a premium version.”

So you think about it. Free users get 3 trips per month. Premium users pay ten dollars a month and get unlimited trips, longer itineraries, and AI photo captions. That sounds reasonable.

How hard can it be? You’ll add Stripe, put a “Subscribe” button on the page, and when someone pays, you flip a switch in the database from “free” to “premium.” Done.

Except it’s not done. Not even close. Because taking money online is one of the most deceptively complicated things in software.

Here’s why. When a user clicks “Subscribe” on your page, they don’t pay you directly. They enter their credit card on a payment provider’s page — Stripe or Paddle or whoever. That provider charges the card, takes a cut, and then has to tell your app that the payment went through. But what if your server is down for two seconds when the payment goes through? What if the user closes the tab after paying but before your app records it? What if their card gets declined next month? What if they dispute a charge? What if they cancel and want a refund?

Every one of these scenarios has to be handled. And the way they’re handled is with something called webhooks — messages that the payment provider sends to your app when things happen. “This person paid.” “This payment failed.” “This subscription was cancelled.” “This charge was disputed.”

Your app doesn’t decide whether a payment succeeded. The payment provider tells you. You listen and react. This is event-driven architecture, and it’s the backbone of every payment system on the internet.

Let’s set it up.