Ausgangssituation: Kassenschlange, gedruckter QR-Code, wechselnde Zahlwege
Der Gastronom hat an jedem Tisch einen gedruckten QR-Code. Gäste sollen schnell per Smartphone bezahlen — die Zahlungsoptionen ändern sich aber regelmäßig (neue PSP, Aktionscodes, Trinkgeld-Regeln). Ein statischer QR-Code, der direkt zur Zahlungsseite eines Providers führt, ist starr und unflexibel. Ideal ist ein dynamischer QR-Workflow, der beim Scan eine Zahlung auslöst, das POS informiert und die Bestellung automatisch als bezahlt markiert.
Warum dynamische QR-Codes mit Webhooks und API hier sinnvoll sind
Dynamische QR-Codes trennen das gedruckte Medium vom Ziel: Der gedruckte Code bleibt, das Ziel (Zahlungsseite, Checkout-Flow, Fallback) lässt sich jederzeit ändern. Kombiniert mit Webhooks und API-Aufrufen ermöglicht das automatisierte Abläufe: Scan → Webhook/API → Erstellung/Bestätigung einer Bestellung → Weiterleitung zur Zahlungsseite oder direkter Zahlungsversuch. Zentral verwaltet in einem System wie Linkentra lässt sich das Target schnell anpassen, Medien/Branding pflegen und Scan-Statistiken einsehen.
3 praktikable Ablaufvarianten
Variante A — Orchestrator-Redirect (empfohlen für flexible Zahlungsintegration)
Architektur: QR → Linkentra (Short/Target) → Ihr Orchestrator (öffentliche Endpoint) → POS/PSP → Redirect zur Zahlungsseite.
- Beim Scan leitet Linkentra zu Ihrem Orchestrator weiter (oder sendet eine Webhook-Notifikation an ihn).
- Der Orchestrator erstellt in Ihrem POS eine Bestellposition via API, erzeugt ein Zahlungsobjekt beim PSP und gibt eine Zahlungs-URL zurück.
- Der Orchestrator leitet den Kunden zur Zahlungsseite weiter; nach Zahlungseingang informiert der PSP Ihren POS per Callback und Ihr System markiert die Bestellung als bezahlt.
Variante B — Linkentra-Webhooks als Trigger (minimaler Eingriff)
Architektur: QR (Linkentra) → direkte Redirect zu statischer Zahlungsseite; Linkentra sendet zeitgleich Webhook an POS/Orchestrator.
- Linkentra verwaltet den QR und leitet zur Zahlungsseite (z. B. PSP-Checkout) weiter.
- Gleichzeitig wird ein Webhook an Ihre Backend-URL gesendet, das die Bestellung im POS anlegt und auf Zahlung wartet.
- Nach erfolgreicher Zahlung gleicht Ihr System ab und vervollständigt die Bestellung.
Variante C — Scan → Direktzahlung (höchste Automatisierung, PSP-abhängig)
Architektur: QR → Orchestrator → API-Aufruf an PSP für Sofortzahlung (z. B. QR-basiertes Wallet) → Bestellabschluss.
Diese Variante setzt voraus, dass Ihr PSP eine API für unmittelliche Zahlungen (ohne Zwischenseite) anbietet. Vorteil: Kunde muss weniger klicken; Nachteil: stärkere Anforderungen an Sicherheit, Rückerstattungsprozesse und Integrationsaufwand.
Konkrete Webhook-Beispiel-Payloads
Diese Payloads sind Beispiele, die Ihrem POS/Orchestrator helfen, Bestellungen zu erzeugen und Zahlungen zu verknüpfen.
Scan-Event (gesendet beim Scan):
{
"event": "scan",
"qr_id": "qr_12345",
"scan_id": "scan_67890",
"timestamp": "2026-10-28T12:34:56Z",
"client_ip": "203.0.113.42",
"user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 15_0 like Mac OS X)",
"location": {"lat": 48.137154, "lng": 11.576124},
"metadata": {"table": "T12", "staff_id": "u42"}
}
Order-Created-Callback (Ihr System an Linkentra/Logik):
{
"event": "order_created",
"order_id": "ord_20261028_0001",
"qr_id": "qr_12345",
"amount": 18.90,
"currency": "EUR",
"payment_url": "https://pay.provider/checkout/abcde",
"expires_at": "2026-10-28T12:50:00Z"
}
Im einfachen Szenario leitet Linkentra nach dem Scan direkt zur payment_url weiter oder Ihr Orchestrator macht das. In komplexeren Setups verwendet Ihr Backend die scan-Payload, um Bestellung und Zahlung parallel zu initialisieren.
Sicherheits-Hardening — Basisregeln für Webhooks & API
- TLS erzwingen: Alle Endpunkte müssen HTTPS mit aktuellen TLS-Versionen nutzen.
- Authentifizierung: Verwenden Sie einen shared secret für Webhooks und prüfen Sie Signaturen (z. B. HMAC-SHA256 über Payload mit einem X-Signature-Header).
- IP-Filterung & Rate-Limiting: Whitelisten Sie bekannte Sender-IP-Bereiche und limitieren Sie eingehende Requests, um Missbrauch zu verhindern.
- Replay-Schutz: Akzeptieren Sie Webhook-Events nur mit eindeutigen IDs und verwerfen Sie doppelte oder zu alte Timestamps.
- Minimalrechte Prinzip: API-Keys und Service-Accounts nur mit unbedingt notwendigen Rechten ausstatten.
- Audit-Logs und Verschlüsselung: Sensible Daten verschlüsselt speichern; Zugriffe und Änderungen lückenlos protokollieren.
Beispiel: Verifizierung einer HMAC-Signatur (konzeptionell)
signature = header['X-Signature'] computed = HMAC_SHA256(shared_secret, request.body) if not constant_time_compare(signature, computed): reject 401
Monitoring & Betrieb: So bleibt das System verlässlich
- Health-Checks: Endpunkte für Liveness/Readiness bereitstellen und von einem Load-Balancer prüfen lassen.
- Webhook-Retries: Implementieren Sie eine Retry-Policy mit Backoff und Dead-Letter-Queue für nicht verarbeitbare Events.
- Dashboards & Alerts: Metriken wie Webhook-Latenz, Fehlerquote, Erfolgsrate der Zahlungs-Redirects und Scan-Volumen in Dashboards (z. B. Grafana) visualisieren; Alerts per Slack/Email/SMS einrichten.
- Test-Umgebung: Staging-QR-Codes und eine Test-Webhook-URL verwenden, um Integrationen ohne Live-Betrieb zu prüfen.
- Rate- & Spike-Protection: Schutzmechanismen gegen saisonale Lastspitzen (Events, Mittagessen) vorsehen.
Praxis-Checkliste für Deployment (kurz)
- QR-Design & Branding in Linkentra anlegen (SVG/PNG-Export für Druck).
- Orchestrator-Endpoint bereitstellen (TLS, Auth, Logging).
- POS-API-Integration: Endpunkte für Order-Create, Order-Update, Payment-Confirm definieren.
- Webhook-Handling implementieren: Signaturprüfung, Idempotenz, DLQ.
- Monitoring aufsetzen: Health-Checks, Dashboards, Alerts.
- Staging testen: komplette Zahlungs-Loop durchspielen, Fehlerfälle simulieren.
Kurzes Praxisbeispiel
Ein Café nutzt Linkentra, um QR-Codes an den Tischen zu verwalten. Beim Scan leitet Linkentra entweder direkt an die PSP-Checkout-Seite weiter (Variante B) oder zu einem Orchestrator, der Bestellung und Zahlung koordiniert (Variante A). Die POS-Kasse erhält per Webhook sofort eine Order-ID mit Tisch- und Scan-Metadaten; nach Zahlungseingang markiert die Kasse die Bestellung automatisch als bezahlt, Ausgabe von Rechnung und Bon geschieht ohne manuelles Zutun. Betreiber profitieren von zentraler Steuerung der QR-Targets, Anpassbarkeit von Zahlungszielen und Scan-Statistiken für Analysen.
Fazit & Handlungsempfehlung
Mit dynamischen QR-Codes, Webhooks und API-Workflows lassen sich Zahlungen am POS deutlich beschleunigen und administrative Schritte automatisieren. Entscheidend sind eine klare Orchestrator-Architektur, saubere Sicherheitsmaßnahmen und ein robustes Monitoring. Linkentra kann die zentrale Verwaltung der QR-Codes übernehmen — sowohl in Cloud- als auch in Self‑Hosted-Setups — und so Änderungen an Ziel-URLs, Branding und Fallbacks ohne Druckneuausgabe ermöglichen.
Jetzt starten: Linkentra entdecken und prüfen, welche Variante (Orchestrator-Redirect vs. Webhook-Trigger) am besten zu Ihrer Kassen- und Zahlungsarchitektur passt. Linkentra entdecken
Nächster Schritt
Linkentra selbst ausprobieren
Dynamische QR-Codes mit Kontrolle über Hosting und Daten: Inhalte nachträglich ändern, Branding anpassen, Medien zentral verwalten und Scans auswerten – wahlweise auf eigener Infrastruktur (Self‑Hosted) oder sofort in der Linkentra Cloud. Editionsabhängige Funktionen für Teams, API und White‑Label.