Payments Without a Payments Project

The Stripe checkout page takes an afternoon. What takes the quarter is the webhook endpoint that has to survive the same event arriving three times, the dunning emails nobody has written yet, and the question of what your business is supposed to do differently the moment a card finally clears at 2am.

Authorizing a card is the smallest part of the job

Moving money has been a solved problem for years. You will spend that afternoon on the checkout surface, it will work, and you will feel good about the estimate you gave. Then the rest of it starts showing up in pieces.

A webhook endpoint that is publicly reachable, verifies signatures, and behaves correctly when a retry fires while your server is restarting. A card that declines on renewal, which means dunning, which means email, which means a template and a schedule and a decision about how many attempts you make before cutting off access. Refunds, including partial ones. Proration when somebody upgrades on the 14th. Receipts that match what the customer thinks they bought. A dispute flow you will not think about until the first dispute lands. Test keys and live keys, and the afternoon somebody ships the wrong one. Tax, if you sell anywhere that cares, and most places care.

Each piece is a day, maybe two. They arrive one at a time over months, and every one of them lands as an interruption to whatever you were actually building that week.

The expensive part is what the payment is supposed to change

Here is where I think founders misjudge the work. The project is not really about money movement. It is about the record the money is supposed to update.

A successful charge is a fact that has to change your business in six places at once. The deal moves to won. The contact stops being a prospect, which means your outbound has to stop writing to them, and that stopping is not automatic. Onboarding starts. Whoever answers the phone needs to know this person is paying before they call in. The quote you sent last week has to close out against the amount actually collected rather than the amount you hoped for. Then next month the card fails and every one of those changes has to run backward.

Stripe knows a payment happened. It has no idea about your pipeline stages, your quote, your task list, or which of your people owns the account. Translating money arrived into the business now behaves differently is where the quarter actually goes, and it is the part you cannot demo to anyone.

Somebody ends up doing reconciliation on Monday mornings

Watch what happens when that translation layer does not exist. Payments land in one system, customers live in another, and a human opens both and makes them agree. Export a CSV. Search names. Fix the three that do not match because the card was in a spouse's name, or the company paid under a different legal entity, or the email on the receipt belongs to their accountant. Mark the deals won by hand.

That human is the founder for the first year. After that it is an ops hire whose real job description is being the API between two products you already pay for.

It also gets worse as you succeed. More customers, more rows, more mismatches, and the hour it used to take on Monday becomes three.

The usual patch is an automation tool. A Zap fires on a payment event and writes a field somewhere. What you have built there is production software with no owner. Nobody tests it, nobody reads its logs, and the bill scales with your volume, because Zapier charges by task and payments generate tasks forever. It fails quietly. You find out from a customer who got a dunning email nine days after they paid you.

Generated checkout code is code you now own

The AI app builders made this specifically worse. Ask Lovable or Base44 or Bolt for a checkout page and you get one, plus a server route, and the whole thing has the finished appearance of something a person reviewed. What you actually have is source code sitting in your repository at the exact point in your product where mistakes cost real money and customers see them the same day. The keys. The webhook secret. Retry behavior, the refund path, the ledger you did not know you needed. Yours to operate, at whatever hour it breaks. Skipping the first draft of the payments project is not the same as avoiding it. You inherited the maintenance of something you never wrote.

Payments as a setting only works if the system already holds the customer

Which is the point. Payments are not a feature you bolt onto a product. They are a property of a system that already knows who the customer is.

Rocketship takes Stripe payments. That sentence only matters because of what sits next to it inside the same product: the CRM record, the pipeline stage, the quote you sent, the tasks, your custom fields, the app you published on your own domain. A payment is not an event arriving from outside that has to be matched against a stranger by fuzzy name search. It happened to a customer who was already in the room.

Connect the account. Send the quote. Money arrives against a record that already exists, so there is no second system to reconcile it with, and the Monday CSV ritual never gets invented, which means nobody ever gets hired to perform it.

Do the arithmetic before you open the ticket

Launch is $24.99 a month, and payments are the small part of what that buys. It also finds buyers, writes to them, reads and answers what comes back, and keeps your phone number answered around the clock. Frontier is $79 and books the meetings onto your calendar. Take the higher number and call it $948 a year.

Now price the other path honestly. The build. The review of the build. Somebody carrying a pager for it. The tax question you defer for two quarters. Month nine, when renewals start failing and it turns out nobody ever wrote the dunning logic. Whatever a quarter of your own attention is worth to you, the comparison is not close.

One good reason to build it yourself

If payments are the product, build them. Marketplaces splitting a payout three ways, anything metering usage by the second, lending, escrow. When the money flow is the thing customers are buying, that is real engineering and it deserves your strongest people and a long timeline.

Everyone else is building a commodity on a deadline while their competitors ship things customers actually asked for. Nobody has ever chosen a product because of its webhook handler. They chose it because it did something useful, and then they wanted to pay for it, and that part should be easy.