Zahlungen auf der Website 2026: Checkout, Zahlungslink und eine Danke-Seite, die nicht lügt

Die Suche, die schon Leute herbringt, ist „Telegram-Bot-Zahlung“. Die nächste ist leiser und größer: sie wollen Geld auf einer Seite kassieren, die ihnen gehört. Kartennummer im Direct, Screenshot einer Überweisung, Thread „ich habe gezahlt, bitte prüfen“ — das ist kein Acquiring. Das ist unbezahlter Betrieb. Ein Site-Checkout ist dieselbe Aufgabe wie ein Zahlungs-Bot, in einer URL, die Google indexiert und die ein Fremder ohne Messenger öffnet.

Ich habe schon geschrieben, wie Rechnungen und Webhooks in Telegram laufen. Hier der Website-Zwilling: Hosted Checkout, Zahlungslink, Apple Pay auf einer Landingpage, Kassenbon nach paid. Dasselbe Backend. Andere Tür.

1. Drei Zahlungsformen auf der Site (eine wählen, dann wachsen)

Tag eins braucht keinen Warenkorb. Einen Pfad, der eine pending-Bestellung anlegt, eine echte Acquiring-Seite öffnet und erst zurückkommt, wenn der Webhook paid sagt.

• Zahlungslink / Rechnungsbutton: ein SKU, ein Preis, „Bezahlen“ öffnet Monobank oder LiqPay. Für Nachhilfe, Anzahlung, eine Beratungsstunde. Die Seite ist das Angebot; der Link die Kasse.
• Landing + Checkout: ein Kurs, ein Leistungspaket, eine Warteliste die zur Abbuchung wird. Name, E-Mail, Betrag, dann Hosted Pay. Noch kein Katalog. Das meinen die meisten mit „Zahlung auf der Website“.
• Shop-Checkout: Katalog, Varianten, Warenkorb, Versand, dann zahlen. Nur wenn SKUs und Versand schon da sind. Damit anfangen ist, wie eine Vier-Produkt-Marke zwei Monate vor der ersten bezahlten Bestellung verbrennt.

2. Kein Logo wählen. Wählen, wer das Wallet schon hat

Ein zweiter Button, den niemand nutzt, ist keine „mehr Conversion“. Es ist ein Support-Ticket. Welches Acquiring - Mono, LiqPay, Stripe - habe ich im Telegram-Zahlungsleitfaden schon verglichen. Auf der Website zählt nur: der Fremde aus Ads oder Maps zahlt mit dem, was schon im Handy liegt. Eine Methode zu diesem Wallet. Apple Pay und Google Pay sitzen darauf; deshalb endet die Anzahlung in der Bahn, statt an der Kartennummer zu sterben.

3. Was auf der Website bricht, das ein Bot nie sieht

Die Pipeline Rechnung-Webhook-Erfüllung ist dieselbe wie im Bot-Artikel. Ich klebe sie hier nicht nochmal. Eine öffentliche URL bringt drei Brüche, die ein Chat nicht hat.

• /success ist Danke, nicht paid. Ich habe Shops gesehen, die paid setzten, weil der Browser nach Zurück dort landete, oder weil die Bank-App auf einen toten Tab zurückkam. Zeigen Sie „wir bestätigen die Zahlung“. Der Webhook kippt den Status.
• Das Merchant-Secret bleibt auf dem Server. Eine Next.js-Seite, die die Rechnung im Browser anlegt, leakt den Key ins Client-Bundle. Das ist ein Website-Bug. Ein Bot schickt dem Kunden diese Datei nicht.
• Rückkehr aus der Bank-App kann den Tab töten. Der Käufer denkt, er hat gezahlt; Ihr UI ist weg. Mail oder SMS mit derselben Bestell-ID und eine Danke-Seite, die den Status vom Server liest, sind die Rettung. Telegram hat den Thread schon. Eine Site nicht.

4. Ein Kassenbon ist kein PDF, das Sie von Hand tippen

Wenn Sie ukrainische FOP sind und Ware oder viele Leistungen verkaufen, reicht der Bank-Webhook nicht. Nach paid ruft der Server Checkbox oder Vchasno.Kasa, der Käufer bekommt das fiskalische PDF auf der Danke-Seite oder per Mail. Ein Mensch, der nach jedem Stripe-Ping das РРО tippt, so verschwinden Abende.

5. Warum der Checkout am Handy stirbt

Der meiste Traffic zu „Zahlung auf der Website“ zahlt auf einem Fünf-Zoll-Screen. Die Brüche, die ich repariere, sind nicht exotisch.

• Langsames Landing: erscheint der Bezahlen-Button nach drei Sekunden Layout Shift, ist ein Teil der kaufbereiten weg. Core Web Vitals sind ein Checkout-Feature.
• Ein Formular, das ein volles Konto verlangt, bevor der Betrag klar ist. Name und Telefon (oder E-Mail) reichen für den Beleg. Ein Account ist ein späteres Produkt.
• Kein Apple Pay / Google Pay auf iOS und Android. Karte in Safari in der Bahn tippen - so leckt die Anzahlung.
• Nachnahme als Standard. Fühlt sich nett an. Bringt die unbezahlte Arbeit zurück, der Sie entkommen wollten: bestätigen, erinnern, No-Show.

6. Website und Telegram: ein Hauptbuch, zwei Türen

Der populäre Artikel in diesem Blog ist ein Telegram-Zahlungs-Bot. Der Kanal bleibt das richtige Postfach in der Ukraine. Eine schlechte Homepage. Ein Fremder aus Google Ads oder Maps startet keinen Bot, um den Preis zu lernen. Er öffnet eine Seite. Wer Ihnen schon in Telegram schreibt, soll in Telegram zahlen. Wer den Namen noch nicht kennt, auf der Site. Beide treffen dieselbe Pipeline: pending → Rechnung → Webhook → Fiskal → Erfüllung.

Fazit: stellen Sie die Kasse auf eine URL, die Ihnen gehört

Wenn Geld noch als Kartennummer im Chat läuft, ist das Upgrade kein Plugin. Eine pending-Bestellung, Mono oder LiqPay oder Stripe, Apple Pay am Handy, ein Webhook der fiskalisiert, eine Danke-Seite die nicht lügt. Ich baue das als Senior Web Engineer auf Next.js - dieselbe Pipeline kann eine Telegram-Rechnung für die öffnen, die schon im Messenger leben. Schreiben Sie über das Formular, was Sie verkaufen und wo der Käufer sitzt (Ukraine oder Ausland). Wir schneiden den kleinsten Checkout, der diesen Monat eine echte Zahlung annimmt.