How to add a buy button to a website and test it before launch
A buy button is just a link to a checkout page your payment provider hosts. Create a payment link for the product, put it behind a clearly worded button next to the price, and then buy the thing yourself on a phone. The button is the easy part; most problems show up in the test purchase.
Link or embed: the first decision
Providers offer two ways to put checkout on a page. A payment link is a URL. Any button, text link or QR code can open it, and it works on every website builder, in emails and in social bios. An embedded button is a snippet of code the provider gives you. Stripe's embeddable buy button, for instance, is a <script> tag plus a <stripe-buy-button> element, and Stripe's docs list the Content Security Policy it needs: scripts and frames from js.stripe.com.
- Payment link
- Works anywhere a link works. No code, nothing loads on your page, and changes made at the provider apply without touching the site. The buyer leaves your page for the checkout.
- Embedded button
- Can show a styled card or open checkout over your page. Needs the provider's script to run on your site and a policy that allows it. Breaks if the script is blocked or the key is revoked.
For a small site, a link is usually the better trade. It's the same checkout either way; the embed only changes how the button is drawn and how the checkout opens.
Add the button, step by step
- Create the product and the link at your provider. In Stripe, that's a payment link with a product and price; PayPal calls the same thing Payment Links. Set the quantity rules, whether to collect an address, and what the buyer sees after paying.
- Copy the link and open it in a private window. Check the product name, price, currency and image are right before it goes anywhere near your site.
- Place the button beside the price and the essential facts. The buyer should see what they get, the price and the terms at the moment they decide, not three screens earlier.
- Word it as the action. "Buy the guide" or "Book and pay" beats a bare "Submit" or "Click here". If checkout opens in a new tab, say so or make it obvious from the context.
- Repeat the same link wherever the product appears. A second button at the end of a long page is fine; a second, different link for the same product is how prices drift apart.
- Run a test purchase, then a real one, as described below.
Test the full purchase before launch
Stripe and most other providers have a test mode where cards don't move money. Test links and live links are different URLs, so the test proves the flow, not the button you'll ship. Do both.
- In test mode: complete a purchase with the provider's test card, check the confirmation page or redirect, and look for the receipt email.
- With the live link on the published page: buy it once yourself with a real card, on a phone, over mobile data. Then refund it from the provider's dashboard. Stripe's after-payment docs cover the confirmation message, redirects, receipts and refunds.
- Check what happens next: did the notification reach you, did the buyer get what they paid for, and does the order show in your provider's dashboard?
- Try the unhappy path: cancel half-way through checkout and see where the buyer lands. A dead end here loses people who meant to come back.
Buy buttons on an Anticode site
Anticode sites use the payment link route. Under Connectors, add a Payment link from Stripe Payment Links, PayPal, Gumroad, Lemon Squeezy, Shopify or Whop. The site's pricing buttons and store Buy links then open your checkout in a new tab, and card details only go to your provider. Asking for payments in the brief, or later in a sentence, brings the buttons into the build.
Two consequences are worth knowing. Published pages run no scripts and allow no frames, so an embedded widget such as Stripe's buy button can't load there; the link does the same job. And the payment link belongs to the account, not to one site, so every buy button in the account opens the same checkout. For several products, link to a product list at your provider. The wider choice between links and on-site checkout is in how to accept payments on a website.
Mistakes that stop sales
- A test-mode link on the live site. Nothing is charged and nobody notices until a customer asks why the order never arrived.
- A button that looks disabled. Low-contrast grey buttons read as unavailable. Use the site's action colour and enough contrast.
- Prices that differ between page and checkout. Update both, or show the price only at checkout.
- No terms near the button. Link refunds and delivery times next to it; see the refund policy guide.
Limits
A payment link is one product, or one fixed set of items, per checkout. There's no cart where visitors combine products on an Anticode design-engine store, and Anticode doesn't track stock, shipping or tax. On-site pay pages through Stripe Connect are in Anticode's code but switched off, so don't plan around them. Plan details are on /pricing.
Questions people ask
Do I need a developer to add a buy button?
Not for a payment link: you paste a URL into a button. Embedded buttons need the provider's code on the page, which some site builders allow and others, including Anticode, don't.
Should the checkout open in a new tab?
Either works. A new tab keeps your page open if the buyer backs out. Say what will happen so people aren't surprised by the switch.
Can one button sell different sizes or options?
Some providers let a single link offer options or adjustable quantities. Otherwise you'd need a link per option. On Anticode there's one payment link per account, so point it at a product page or list at your provider that offers every option.