Taking payments

A customer asked if they can pay online. Now what?

Getting paid online is easier than it looks, and riskier than it looks if you wire it up the wrong way. Here is how to pick the right setup and make it safe.

Oct 28, 20266 min readBy the AftUp team

You are wrapping up a job, or answering a message from a regular, and they ask the question you knew was coming. “Can I just pay you online?” You say yes, of course. Then you sit down that night and realize you have no idea what “online” means for your site.

You built the site yourself. Maybe in Bolt or Lovable, maybe in Squarespace or Framer. It looks good. It has a contact form. But there is no button that takes money, and every guide you find either assumes you are a developer or tries to sell you a full ecommerce platform you do not need.

Let’s sort it out.

What’s actually going on

Taking a payment online has three jobs. Someone has to collect the card safely. Someone has to tell your business the payment worked. And the customer needs a receipt. The question is not really “which tool” but “who does each of those jobs.”

The good news is that services like Stripe can do almost all of it for you. You have three common options, from simplest to most involved.

A Payment Link is a hosted payment page you create in Stripe for a specific product or amount. You get a URL. You put it behind a “Pay now” button, in an email, or in a text message. The customer pays on Stripe’s page, not yours.

This is the right fit for a fixed-price service, a deposit, a class, a consultation or a simple product. No code. No card data on your site.

Checkout

Stripe Checkout is the same idea, a payment page Stripe hosts, but your site creates the session on the fly. That lets you pass in which items the customer picked, quantities, customer email and where to send them afterward.

Checkout needs a small piece of server-side code, usually a serverless function on hosts like Netlify or Vercel, or a backend function in tools like Supabase. AI builders will often generate this for you when you ask for “Stripe checkout.”

A full cart

If you sell many products with variants, inventory, shipping rules and discount codes, you probably want an actual store: Shopify, Squarespace Commerce, Wix Stores or similar. They handle the cart, tax settings and order management. Building all of that yourself inside a custom app is possible, but it is a lot of surface area to keep correct.

If you can describe what you sell in one sentence, start with a Payment Link. Move up only when you outgrow it.

The parts that trip people up

Test mode versus live mode. Stripe keeps two separate worlds. Test mode uses fake card numbers and fake money. Live mode is real. Each has its own keys, products and payment links. A very common surprise is a site that launches still pointing at test mode, so customers “pay” and nothing arrives.

Secret keys. Stripe gives you a publishable key and a secret key. The publishable key is designed to be public. The secret key is not. It can create charges, issue refunds and read your customer data. It should only live on a server or in environment variables for a serverless function, never in code that runs in the browser. AI builders sometimes put it in the wrong place when you ask them to “make it work quickly.”

Prices set on the server. If your site sends the price from the browser to the payment step, someone can change that number before it goes. The safe pattern is that the browser says which product, and your server looks up the price, ideally using the price IDs you created in Stripe. Payment Links handle this for you automatically.

Webhooks. When a payment completes, Stripe can send a message to a URL on your site. That message is a webhook. It is the reliable signal that money moved. Your “thank you” page is not reliable on its own, because a customer can close the tab, lose signal or land there without paying. If you need to do something after payment, like mark an order paid, send a download or unlock an account, do it from the webhook. Your webhook code should also verify Stripe’s signature so it knows the message really came from Stripe.

Receipts. Stripe can email receipts automatically. You usually need to turn this on and add your business details and branding in your Stripe settings. Without it, customers pay and hear nothing, and that is when refund requests and chargebacks start.

What to do right now

You can get a lot of this done in an afternoon.

  • Write down what you are selling. One price or many? One-time or recurring? Fixed or variable? This decides Payment Link, Checkout or cart.
  • If it is simple, make a Payment Link. Create the product in Stripe, generate the link, and add it to a clear button on your site. Test it in test mode first.
  • Turn on email receipts in your Stripe account and add your business name, support email and logo.
  • Search your project for the word “secret” or for keys that start with sk_. If you find one in frontend code or in a public repository, revoke it in Stripe, create a new one, and move it to your host’s environment variables.
  • Check where prices come from. If your site sends a dollar amount to the payment step, ask your builder to change it so the server uses Stripe price IDs instead.
  • Run a test purchase in test mode, then switch to live keys and live links and make one small real purchase. Refund it. Confirm the receipt arrived and the payment shows up in Stripe.
  • Write a one-line refund policy and put it near the pay button. Customers feel safer when they know what happens if something goes wrong.

When to hand it off

Payment Links you can absolutely handle yourself. Where people get stuck is the step after that: Checkout sessions, webhooks, signature checks, subscription logic, and making sure live mode is truly live. It is also the place where a quiet mistake costs real money or leaks a key.

That is the kind of work we do every week. On a care plan, we review how your site takes payments, move any secret keys to where they belong, set up or fix webhooks, confirm receipts go out, and run a real test transaction after changes. We work inside the tool you already used, so there is no rebuild. You can see the details on our payments page, and if you run a shop, the online stores page covers what changes when you have a catalog.

The Growth plan includes up to two hours of fixes each month, which covers most payment setups and tune-ups. You can compare plans on the pricing page. And if payments are only one piece, the post-launch checklist covers the rest.

Before you send that first customer a link, it is worth knowing what else might be off. Send us your URL for a free site check and we will tell you, in plain English, within 48 hours.

FAQ

Common questions

What is the simplest safe way to take payments on a site I built myself?

For most small businesses, a Stripe Payment Link or Stripe Checkout. Stripe hosts the payment page, handles the card details and sends receipts, so your site never touches card numbers.

Is it okay to put my Stripe secret key in my site's code?

No. The secret key belongs only on a server or in a serverless function's environment variables. Anything in frontend code can be seen by anyone who opens your site, so a leaked secret key should be revoked and replaced right away.

Why do I need webhooks if Stripe already shows a success page?

A success page only means the browser got redirected. A webhook is Stripe telling your system directly that a payment actually completed, which is what you should rely on before fulfilling an order or unlocking access.

How do I know my payments are live and not in test mode?

Stripe keeps test and live mode separate, with different keys, products and payment links. Check that your site uses live keys and live links, then make one small real purchase and refund it.

Stop babysitting your website.

Get a free site check and see exactly what needs fixing.

Free. No card. Report in 48 hours.