Telegram-Shop-Bots für deutsche KMU: die Anatomie eines Chat-Shops

Ein Telegram-Shop-Bot ist eine Verkaufsfläche mit zwei Seiten: Inline-Tastaturen im Chat und eine Mini-App-Ansicht, beides hängt an einem einzigen HTTP-Service. Katalog, Bezahlung und Bestellstatus leben dort, wo die Kundschaft ohnehin ist. Am Ende kommt alles ohne Store-Review und Install-Schritt aus, und der einfachste Zahlungsweg sogar ohne Kartenformular.

Für einen deutschen Betrieb rechnet sich das anders als bei einem Startup. Die Kundschaft kommt persönlich vorbei: Stammgäste, Leute aus dem Viertel, ein Umkreis von zwanzig Kilometern. Niemand installiert eine App, um 500 g Kaffee zu kaufen. Eine Chat-App, die ohnehin täglich offen ist, öffnen viele.

Woraus besteht ein Telegram-Shop-Bot?#

Drei Teile, und nur das Backend ist kompliziert:

Chat-Fläche. Reply-Keyboards navigieren durch den Katalog, Inline-Keyboards tragen die Produktaktionen. Jeder Tastendruck kommt als Callback-Update am Webhook an. callback_data ist auf 64 Bytes begrenzt. Im Payload liegt also eine ID wie add:42, nie das Produkt selbst.

Mini-App-Fläche. Eine Webseite (nur HTTPS), die in Telegram aufgeht, mit den Theme-Variablen des Chats gerendert und über signierte initData authentifiziert. Hier schlägt ein Warenkorb mit Mengen das Tastatur-Menü. Die Mini-Apps-Spezifikation definiert den ganzen Vertrag, und sie ist kurz.

Ein Backend. Ein Webhook-Endpunkt für Chat-Ereignisse, eine kleine HTTP-API für die Mini-App und eine Tabelle für Bestellungen. In meinem eigenen Build sind das grammY plus Hono plus SQLite: grob ein Dutzend Endpunkte, ein Deploy.

Wie funktioniert Bezahlen ohne Kartenformular?#

Zwei Wege, beide vom Bot aus gestartet:

Telegram Stars (Währung XTR). Der Bot schickt eine in Stars berechnete Rechnung, Telegram zieht ab, und der Bot bekommt successful_payment als Update. Rückerstattung ist ein API-Aufruf (refundStarPayment). Abos sind eingebaut: subscription_period: 2592000 (30 Tage) macht aus jeder Rechnung einen Monatsplan, der sich ohne Cron-Job verlängert.

Ein Payment-Provider. Stripe und andere integrieren sich über Telegram Payments: die Kundschaft zahlt in Euro per Karte, der Provider nimmt PCI ab, das Geld geht direkt aufs Konto. Physische Waren wollen meist diesen Weg.

Stars tauschen Bequemlichkeit gegen einen Umrechnungsabschlag: Auszahlung läuft über Fragment, zu einem Satz unter dem Nennwert. Also bewusst in Stars preisen. In meinem Referenz-Shop rechne ich mit 1 ⭐ = 2 Cent und runde zugunsten der Kundschaft.

Warum ist das nicht einfach ein schlechterer App-Store?#

Ehrlich verglichen: Ein App-Store gibt ein Listing, Updates durch Review und 15 bis 30 % Anteil auf digitale Güter. Ein Bot gibt ein Deploy, Deep Links, die ein bestimmtes Produkt öffnen (?startapp=hausmischung), Inline-Sharing von Produktkarten in jeden Gruppenchat und kein Review zwischen Releases.

Was der Store hat und der Bot nicht: einen Browser zur Entdeckung, ein bekanntes Zahlungsblatt und Unabhängigkeit von den Entscheidungen eines Plattform-Betreibers. Ein Shop-Bot passt, wenn Kundschaft über Mundpropaganda, lokale Suche oder die eigene Website kommt. Er passt nicht für Verbraucher-Akquise im großen Maßstab.

Ein lauffähiges Beispiel#

Ich habe einen als Referenz gebaut und betreibe ihn: @roestwerk_bot verkauft Kaffee mit Stars-Kasse, Karten-Kasse in Euro über gehostetes Stripe Checkout (Testbetrieb), Ein-Klick-Rückerstattung direkt an der Bestellnachricht, einem Monatsabo und einem live Bestellstatus, der die eigene Bestätigungsnachricht von „bezahlt“ über „wird geröstet“ bis „abholbereit“ umschreibt. Die interaktive Demo auf der Landing-Page zeigt denselben Ablauf, ohne Telegram zu öffnen.

Was ich in jeden Shop-Bot übernehmen würde: die State Machine, die eine Bestellung als bezahlt, dann geröstet, dann abholbereit behandelt; der Erstattungs-Knopf an der Bestellnachricht selbst; und das Abo, das Telegram verwaltet statt ein Scheduler.

Was in Produktion zuerst bricht#

1. Ungeprüfte Webhooks. Wer die URL findet, kann gefälschte Updates schicken. Beim Registrieren secret_token setzen (1 bis 256 Zeichen) und vor dem Parsen den X-Telegram-Bot-Api-Secret-Token-Header prüfen. Webhooks enden nur auf den Ports 443, 80, 88 und 8443.
2. Dem Client vertrauen. initDataUnsafe ist angreiferkontrolliert. Die initData-HMAC serverseitig validieren (das Secret ist HMAC-SHA256 des Bot-Tokens mit dem String „WebAppData“) und gleich auth_date prüfen.
3. Unbeantwortete Callbacks. Jede callback_query braucht einen answerCallbackQuery-Aufruf, sonst dreht sich beim Kunden der Ladespinner. Erst antworten, dann verarbeiten.
4. Duplikate. Telegram liefert Updates nach Timeouts erneut. Ein Bestell-Handler ohne Idempotenz verkauft denselben Kaffee zweimal. Speichere die Delivery-ID, persistiere vor dem Verarbeiten, und behandle Duplikate als Planungsrealität, nicht als Anomalie.

Für wen sich das lohnt#

Shops, deren Katalog in einen Chat passt: abholbasierte Lebensmittel und Kunsthandwerk, Termin-Gewerbe, Abo-Boxen. Der Chat-Thread ist das CRM nebenbei. Eine Telegram-User-ID ist ein stabiler Kundenschlüssel, die Bestellhistorie ist eine Query entfernt, und Benachrichtigungen fahren auf derselben Leitung, wenn der Shop Menschen woanders erreichen will. Das ganze System hat weniger Code als eine übliche E-Commerce-Plugin-Strecke, und jedes Teil davon ist absichtlich geschrieben.