Website Payments in 2026: Checkout, Payment Link, and a Thank-You Page That Does Not Lie

The search that already brings people here is “Telegram bot payment”. The next one is quieter and larger: they want to take money on a page they own. A card number in Direct, a screenshot of a bank transfer, a “I paid, check please” thread - that is not acquiring. It is unpaid ops. A site checkout is the same job as a payment bot, in a URL Google can rank and a stranger can open without installing a messenger.

I already wrote how invoices and webhooks work inside Telegram. This piece is the website twin: hosted checkout, payment link, Apple Pay on a landing page, fiscal receipt after paid. Same backend. Different door.

1. Three payment shapes on a site (pick one, then grow)

You do not need a cart on day one. You need a path that creates a pending order, opens a real acquiring page, and comes back only after the webhook says paid.

• Payment link / invoice button: one SKU, one price, a “Pay” that opens Monobank or LiqPay. Right for a tutor, a deposit, a consulting hour. The page is the offer; the link is the till.
• Landing + checkout: a course, a service package, a waitlist that turns into a charge. Name, email, amount, then hosted pay. No catalog yet. This is what most “I need payments on the site” actually means.
• Shop checkout: catalog, variants, cart, delivery, then pay. Only if you already have SKUs and shipping. Building this first is how a four-product brand spends two months before the first paid order.

2. Do not pick a logo. Pick who already has the wallet

A second button nobody uses is not “more conversion”. It is a support ticket. Which acquiring to wire - Mono, LiqPay, Stripe - I already compared in the Telegram payment guide. On a website the only extra decision is: the stranger from Ads or Maps pays with what they already have in the phone. One method that matches that wallet. Apple Pay and Google Pay ride on top of it; they are why a deposit finishes on a tram instead of dying at the card number.

3. What breaks on a website that a bot never sees

The invoice-webhook-fulfill pipeline is the same as in the bot article. I will not paste it again. A public URL adds three failure modes a chat does not have.

• /success is a thank-you page, not paid. I have watched shops mark the order paid because the browser landed there after the back button, or because the bank app returned to a dead tab. Show “we are confirming payment”. The webhook flips the status.
• The merchant secret must stay on the server. A Next.js page that creates the invoice in the browser leaks the key into the client bundle. That is a website bug. A bot never ships that file to the customer.
• Returning from the bank app can kill the tab. The buyer thinks they paid; your UI is gone. Email or SMS with the same order id, and a thank-you that reads status from the server, are the recovery. Telegram already has the chat thread. A site does not.

4. A fiscal receipt is not a PDF you type by hand

If you are a Ukrainian ФОП selling goods or many services, the bank webhook is not enough. After paid, the server calls Checkbox or Вчасно.Каса and the buyer gets the fiscal PDF on the thank-you page or in email. A human punching РРО after every Stripe ping is how evenings disappear.

5. Why the checkout dies on a phone

Most of the traffic that searches “оплата на сайті” will pay on a five-inch screen. The failures I fix are not exotic.

• A slow landing: if the pay button appears after three seconds of layout shift, a share of ready buyers is gone. Core Web Vitals are a checkout feature.
• A form that asks for a full account before the amount is clear. Name and phone (or email) are enough to send a receipt. An account is a later product.
• No Apple Pay / Google Pay on iOS and Android. Typing a card in Safari on a tram is how deposits leak.
• COD as the default. It feels kind. It reintroduces the unpaid work you were escaping: confirm, remind, no-show.

6. Website and Telegram: one ledger, two doors

The popular article on this blog is a Telegram payment bot. That channel is still the right inbox in Ukraine. It is a bad homepage. A stranger from Google Ads or Maps will not start a bot to learn your price. They will open a page. The people who already write to you in Telegram should pay in Telegram. The people who do not know your name yet should pay on the site. Both hit the same pending → invoice → webhook → fiscal → fulfill pipeline.

Conclusion: put the till on a URL you own

If money still moves as a card number in chat, the upgrade is not a plugin. It is a pending order, Mono or LiqPay or Stripe, Apple Pay on mobile, a webhook that fiscalizes, a thank-you that does not lie. I build that as a senior web engineer on Next.js - and the same pipeline can open a Telegram invoice for the clients who already live in the messenger. Write via the form with what you sell and where the buyer sits (Ukraine or abroad). We will cut the smallest checkout that can take a real payment this month.