The first time you try to take money on your own website, you meet a vocabulary nobody warned you about. Webhooks. Idempotency keys. Test mode, live mode. You wanted a button that says Pay. You got homework.
Almost all of it is plumbing, and plumbing is somebody else's job. One idea in there is worth ten minutes of a business owner's attention, though, because it decides who owns your money and your customers. It's called a connected account. Understand that one and you can ignore the rest with a clear conscience.
What's happening back there
A payment processor sits between your customer's card and your bank. Someone types a card number into a checkout page, the page hands that number to the processor instead of to you, the processor asks the card network and the customer's bank whether it's good, and money reaches your account later with a cut taken out. How big a cut, and how much later, depends on the processor and where you are. Check their current pricing and payout terms yourself. Those numbers move, and anything quoted in an article ages badly.
The detail that matters is what never happens. The raw card number should never sit on your server. Never land in your database, never arrive in your inbox. That's what keeps a small business out of the deep end of card industry compliance. If any setup ever asks you to store card numbers yourself, close the tab.
Connected account, in plain English
When software lets you sell something, the money can flow two ways.
First way: the software company collects the payment. Their merchant account. Their name on your customer's bank statement. Their decision about when you get paid. You're a supplier waiting on a settlement.
Second way: you have your own Stripe account, opened in your business name with your bank details, and you give the software permission to create charges on it. That's a connected account. The customer pays you. The software presses the button.
Think of a market. In one version, the operator takes all the cash at the gate and settles with stallholders on Friday. In the other, customers hand money straight to you and you pay rent for the pitch. Same market. Very different place to be standing if the operator has a bad month.
What changes when the account is yours:
- Payouts follow your processor's schedule, not some vendor's cash flow
- Refunds and disputes get handled in your own dashboard, by you, today
- Your business name shows on the customer's statement, so fewer people call their bank shouting fraud
- Payment history, saved cards and subscriptions live in your account, so leaving the software doesn't mean leaving the customers
- Nobody sits on your revenue while they decide whether to release it
So ask one question before you buy any tool that handles checkout. Whose account does the money go through? Short question, short answer. A vendor who talks around it has already told you the answer.
What you should never have to configure
Back to the plumbing. Webhooks are the classic trap. Your customer pays on the processor's side of the wall, which means your app has no idea it happened until a message comes back saying so. That message is the webhook. Nobody wires it up, and you get a very specific kind of broken: the money arrives, the app never records the order. Customer stares at a spinner. You stare at a payout with no name attached to it. Then you spend Sunday matching bank lines to emails.
The rest is the same flavor. Test credentials and real ones, and remembering to swap them before launch. A cancel page, so someone who backs out doesn't hit an error. Coping with the same event arriving twice. Saving the customer's payment ID against their account, so a repeat buyer isn't treated as a stranger with a new card. HTTPS on every page in the flow. None of it is a business decision. It's identical wiring for a dog groomer and a design studio, and you should not be the one holding the soldering iron.
What is actually your job
Some of it can't be handed off, and shouldn't be.
Your processor will want to know who you are before it sends you money. Business details, bank details, proof you're a real human being. What gets asked for varies by country and gets updated, so read the requirements on the day rather than trusting a blog post. Anti money laundering rules drive that step. No tool skips it for you, and none should. Block out twenty minutes and have your paperwork on the desk.
Then the decisions. What you charge. Whether it's a one-off, a deposit, or a monthly subscription. Whether the deposit is refundable, and until when. What the line on the customer's statement should say so they recognize it three weeks later. Whether a no-show gets charged. Those are the questions worth your attention. They're also the ones that get rushed, because everyone burns their energy on webhooks first.
The payment link trap
Plenty of owners get to a working payment in an afternoon. Generate a payment link, paste it on a page, done. Fine, right up until you want the payment attached to something. A booking. A customer record. A login that gives them what they bought. A screen showing who's paid and who hasn't. That's when the afternoon fix turns into a rebuild, usually while orders are already coming in.
How Rocketship handles it
Describe your business in plain English and Rocketship builds the app around it. Customer database, logins, admin dashboard, and checkout running through your own Stripe account, live on your domain in minutes. You connect Stripe once, by signing in and approving it. Checkout session, webhook, order record, customer ID: all wired before you ever see the app. Money goes to your bank. Your name on the statement. There's a free tier, and paid plans start at twelve dollars a month.
Because the app sits in the same system as your phone line, a paid booking is just another event. The receptionist answering your number at 11pm knows the slot is gone. Sophie can email that customer in the morning without being told to.