Zahlungs-QR-Codes erklärt: PIX, PromptPay, UPI und Co. für Agenturen

Ein Kunde gibt Ihnen einen Stapel Materialien für einen neuen Markteintritt: einen Tischaufsteller für eine Restaurantkette, die nach Brasilien expandiert, ein Plakat für einen Pop-up-Store in Singapur, einen Flyer für einen Messestand in Bangkok. Irgendwo auf jedem dieser Materialien sitzt ein QR-Code, der nicht von Ihnen stammt. Es handelt sich um einen Zahlungscode, gedruckt von der Bank oder dem Kassensystem-Anbieter des Kunden, und der Kunde möchte zwei Dinge wissen: Lässt er sich wie die Marketing-Codes, die Sie für ihn bauen, trackbar machen, und ist es sicher, ihn auf derselben Seite neben Ihrem Kampagnencode zu platzieren?

Beide Fragen kommen häufiger vor, als die QR-Code-Branche in ihren eigenen Inhalten zugibt, denn die meisten Leitfäden zu QR-Zahlungen richten sich an Entwickler, die ein einzelnes Zahlungssystem integrieren, nicht an Agenturen, die sechs verschiedene nationale Systeme auf einen Blick erkennen und in einfachen Worten erklären müssen, warum sie nicht wie ein Marketing-QR-Code funktionieren. Genau das ist dieser Leitfaden: was ein Zahlungs-QR-Code tatsächlich enthält, der Standard, den die meisten von ihnen teilen, wie sich PromptPay, PIX, UPI, PayNow und DuitNow voneinander und von Zelle unterscheiden, sowie die ehrliche, technische Antwort auf die Frage "Können wir das tracken?"

Was ein Zahlungs-QR-Code tatsächlich ist

Ein Marketing-QR-Code, wie ihn ScanKit generiert, kodiert eine kurze URL. Die Kamera des Telefons liest die URL, öffnet einen Browser, und ein Weiterleitungsserver entscheidet, wohin der Scan geschickt wird, wobei er den Scan optional unterwegs protokolliert. Der Code ist ein Verweis. Alles Interessante passiert nach dem Scan auf dem Server.

Ein Zahlungs-QR-Code unterscheidet sich grundsätzlich, nicht nur inhaltlich. Er verweist auf nichts. Er trägt die Transaktionsdaten selbst, oder zumindest genug davon, um eine Transaktion zu starten: eine Zahlungsempfänger-Kennung, eine Währung, manchmal einen Betrag, manchmal ein Ablaufdatum. Wenn eine Banking-App ihn scannt, gibt es zum Zeitpunkt des Scans weder eine Weiterleitung noch eine Serverabfrage; die App liest die Nutzdaten direkt aus und zeigt die Zahlungsdetails an, die sie gerade aus dem Code ausgelesen hat.

Dieser Unterschied ist entscheidend, denn er ist der Grund, warum sich ein Zahlungs-QR-Code nicht einfach in einen Tracking-Link verpacken lässt, wie es bei einer Website-URL möglich ist. Es gibt nichts, wohin weitergeleitet werden könnte. Der Code muss die zahlende App exakt so erreichen, wie ihn die Bank oder der Systembetreiber generiert hat, sonst kann die App ihn nicht auslesen.

Die beiden Codes sehen auf dem Papier identisch aus, gehen aber in dem Moment, in dem sie gescannt werden, getrennte Wege.

1. Der Code wird gescannt. Ein Marketing-QR-Code und ein Zahlungs-QR-Code sind an diesem Punkt mit bloßem Auge nicht zu unterscheiden.
2. Die Nutzdaten eines Marketing-QR-Codes sind eine URL, die in dem Moment, in dem er gescannt wird, auf einem Weiterleitungsserver abgefragt wird.
3. Die Nutzdaten eines Zahlungs-QR-Codes sind die Transaktionsdaten selbst, direkt von der Banking-App gelesen, ganz ohne einen beteiligten Server.
4. Der Marketing-Scan wird protokolliert, und das Telefon landet auf einer getrackten Zielseite.
5. Der Zahlungs-Scan zeigt eine Bestätigung, sobald die Überweisung abgewickelt ist, ohne dass irgendwo ein Scan-Datensatz entsteht.

Zahlungs-QR-Codes unterteilen sich außerdem in zwei Nutzungsrichtungen, und die Begriffe lohnt es sich zu kennen, denn Kunden werden sie verwenden. Im Merchant-Presented-Modus zeigt der Händler einen gedruckten oder auf dem Bildschirm angezeigten Code an, und das Telefon des Kunden scannt ihn; das ist der Modus, mit dem nahezu die gesamte Agenturarbeit zu tun hat: Tischaufsteller, Kassenaufkleber, Rechnungscodes. Im Consumer-Presented-Modus öffnet der Kunde seine Banking-App, generiert einen Code auf seinem eigenen Bildschirm, und der Händler scannt ihn mit einem Kassenscanner, der umgekehrte Ablauf, der an manchen Einzelhandelskassen und Verkehrsdrehkreuzen genutzt wird. Agenturen müssen sich nur um den ersten kümmern.

Der Standard, auf dem die meisten nationalen Systeme aufbauen

Die meisten nationalen "Scan-to-Pay"-Codes, denen eine Agentur begegnet, PIX in Brasilien, PromptPay in Thailand, PayNow in Singapur, DuitNow in Malaysia, BharatQR in Indien, bauen auf derselben Grundlage auf: der Merchant-Presented-Mode-Spezifikation von EMVCo, die 2017 erstmals von dem Kartennetzwerk-Konsortium veröffentlicht wurde, das auch die Chipkarten-Standards verwaltet. Jedes Land fügt dann seine eigenen inländischen Zahlungsdaten in einen dafür reservierten Bereich dieser Grundstruktur ein, weshalb die Codes von Land zu Land ähnlich aussehen und sich ähnlich verhalten, obwohl die zugrunde liegenden Bank-Systeme völlig getrennt sind.

Strukturell besteht ein EMV-Zahlungs-QR-Code aus getaggten Datenblöcken, jeweils mit einer zweistelligen ID, einer Länge und einem Wert. Eine Agentur muss die Rohdaten nicht auslesen können, aber die grobe Struktur zu kennen hilft, wenn das Finanzteam eines Kunden fragt, warum sein Code mit einem generischen QR-Generator "nicht funktioniert": Die Nutzdaten enthalten ein Point-of-Initiation-Flag, das den Code als statisch oder dynamisch kennzeichnet, einen Block mit Händlerkontoinformationen in dem Bereich, der für inländische Systemdaten reserviert ist (hier registrieren PIX, PromptPay und die anderen jeweils ihr eigenes Kennungsformat), einen Währungscode, einen Ländercode und eine Prüfsumme. Ändert man diese Daten mit einem generischen Tool, das für Marketing-Codes gebaut wurde, bricht die Prüfsumme, und die Banking-App weist den Code rundweg zurück, statt stillschweigend falsch zu bezahlen, was zumindest der sichere Fehlerfall ist.

Statische vs. dynamische Zahlungs-QR-Codes

Derselbe Unterschied zwischen statisch und dynamisch, der bei Marketing-QR-Codes eine Rolle spielt, taucht auch bei Zahlungs-QR-Codes auf, allerdings mit anderem Risiko.

Ein statischer Zahlungs-QR-Code kodiert nur die Kontokennung des Zahlungsempfängers, sonst nichts. Er wird einmal gedruckt, unbegrenzt oft wiederverwendet, auf einem Kassenaufkleber oder Tischaufsteller, und der Kunde gibt den Betrag nach dem Scannen selbst in seiner Banking-App ein. Er ist günstig in der Herstellung und läuft nie ab, weshalb genau das die Version ist, die die meisten kleinen Händler nutzen, und genau deshalb auch die Version, auf die es Betrüger abgesehen haben: Ein statischer Code trägt weder Betrag noch Ablaufdatum noch Transaktionsreferenz, sodass ein an seiner Stelle untergeschobener betrügerischer Code funktional nicht vom echten zu unterscheiden ist, bis das Geld nicht dort ankommt, wo es sollte.

Ein dynamischer Zahlungs-QR-Code wird pro Transaktion generiert, mit fest eingebettetem Betrag, Transaktionsreferenz und kurzem Ablaufdatum, und nach Gebrauch verworfen, ähnlich im Prinzip wie ein dynamischer Marketing-QR-Code, nur generiert von einem Kassensystem statt von einer Marketing-Plattform. Er schließt das Betrugsfenster, das ein statischer Code offenlässt, muss aber für jeden Verkauf neu erzeugt werden, weshalb er an besetzten Kassen mit einem dahinterliegenden Kassensystem auftaucht und nicht auf einem unbeaufsichtigten Tischaufsteller.

Keine der beiden Versionen ist "trackbar" in dem Sinne, den eine Agentur für eine Marketingkampagne meint. Es gibt kein Scan-Protokoll, keinen Zeitstempel, keine Standortdaten, weil zum Zeitpunkt des Scans kein Server beteiligt ist, der irgendetwas davon aufzeichnen könnte. Welches Reporting ein Kunde zu einem Zahlungs-QR-Code auch bekommt, es stammt aus den Abrechnungsdaten seines Zahlungsdienstleisters, nicht aus dem Code selbst.

Eine Länderübersicht

Die folgenden Systeme wickeln allesamt inländische Echtzeitzahlungen ab, und eine Agentur, die marktübergreifend arbeitet, wird früher oder später auf die meisten von ihnen stoßen.

PIX (Brasilien). Brasiliens Echtzeitzahlungssystem, betrieben von der Banco Central do Brasil, schreibt seit Oktober 2020 vor, dass die QR-Nutzdaten, bekannt als BR Code, der EMV-Merchant-Presented-Mode-Struktur folgen. Ein statischer PIX-Code trägt nur den Schlüssel des Zahlungsempfängers (eine Telefonnummer, E-Mail-Adresse, Steuer-ID oder ein zufälliges Token); ein dynamischer fügt Betrag, Transaktions-ID und Ablaufdatum hinzu und kann die Zahlungsbestätigung automatisch in das eigene Abgleichssystem des Händlers zurückspielen.

UPI und BharatQR (Indien). Indien betreibt zwei unterschiedliche QR-Formate parallel, und sie zu vermischen ist ein häufiger Fehler in QR-Inhalten, die sich an Agenturen richten. Ein UPI-QR-Code kodiert einen upi://pay-Deep-Link, einen URI-Intent statt einer EMV-Nutzlast, und öffnet sich nur innerhalb UPI-kompatibler Apps wie Google Pay, PhonePe oder Paytm. BharatQR ist das eigentliche EMV-basierte Format, gemeinsam von Indiens National Payments Corporation mit Visa, Mastercard und Amex entwickelt, und in einem einzigen Code sowohl über Karten- als auch über UPI-Systeme interoperabel. UPI QR dominiert nach Volumen, mit Stand Anfang 2025 etwa zehn Codes pro einem BharatQR-Code, obwohl BharatQR von beiden das universell interoperablere ist.

PromptPay (Thailand). Thailands nationales Echtzeitzahlungssystem, betrieben von der Bank of Thailand, verwendet für den Einzelhandel und Kassenzahlungen einen EMV-basierten Merchant-Presented-Code und war eines der ersten nationalen Systeme, das sich mit einem Nachbarland verband: PromptPay und Singapurs PayNow unterstützen seit April 2021 Echtzeit-Überweisungen über Ländergrenzen hinweg zwischen den beiden Systemen.

PayNow / SGQR (Singapur). Singapurs SGQR wird von seinen Regulierungsbehörden ausdrücklich als auf der EMVCo-Merchant-Presented-Mode-Spezifikation aufgebaut dokumentiert und fungiert als vereinheitlichendes Label: Ein einziger SGQR-Aufkleber kann mehrere zugrunde liegende Zahlungssysteme (PayNow sowie diverse Karten- und E-Wallet-Systeme) hinter einem Code bündeln, sodass die App des Kunden automatisch das richtige System auswählt, statt dass der Händler fünf separate Codes anzeigen müsste.

DuitNow (Malaysia). Betrieben von PayNet, dem nationalen Zahlungsnetzwerk unter Aufsicht der Bank Negara Malaysia, startete DuitNow QR im Dezember 2018 und folgt derselben EMV-Merchant-Presented-Struktur, mit Malaysias Länder- und Währungscodes sowie einer DuitNow-spezifischen Kontokennung im inländischen Datenblock.

Zelle (USA). Zelle ist der nützliche Gegenfall, denn auf den ersten Blick sieht es ähnlich aus, funktioniert aber ganz anders als die oben genannten Systeme. Es ist nicht EMV-basiert, nicht eigenständig mit einem generischen QR-Reader scanbar und öffnet sich nur innerhalb einer Zelle-fähigen Banking-App. Es identifiziert einen bestimmten Person-zu-Person-Empfänger statt eines Händler-Zahlungsziels, ist auf die USA beschränkt und nicht bei jeder teilnehmenden Bank verfügbar. Fragt ein Kunde, ob sein US-Zahlungs-QR-Code "demselben Standard" wie PIX oder PromptPay folgt, lautet die ehrliche Antwort: nein. Zelle gehört in eine ganz andere Kategorie, ein proprietäres Peer-to-Peer-Intent-System statt eines nationalen Merchant-Presented-Systems.

Das Muster, das man sich merken sollte: Nationale Echtzeitzahlungs-QR-Codes (PIX, PromptPay, PayNow, DuitNow, BharatQR) sind Merchant-Presented, EMV-basiert und länderspezifisch, aber strukturell standardisiert. An Banking-Apps gebundene Person-zu-Person-Codes (Zelle sowie funktional der eigentliche UPI-QR) sind proprietäre Intent-Systeme, nicht eigenständig interoperabel, und sollten einem Kunden gegenüber nicht mit denselben Worten beschrieben werden.

Lässt sich ein Zahlungs-QR-Code trackbar machen?

Nein, und es lohnt sich, das zu erklären, statt es nur zu behaupten, denn der technische Grund ist es, der einen Kunden davon abhält, bei der nächsten Kampagne erneut zu fragen. Die Nutzdaten eines Zahlungs-QR-Codes sind die Transaktion: Die Kontokennung, die Währung, manchmal der Betrag, das sind Daten, die die zahlende App direkt ausliest und danach handelt. Die Nutzdaten eines Marketing-QR-Codes sind eine URL, und das Tracking passiert auf dem Server, auf den die URL verweist, völlig getrennt von dem, was das Telefon anzeigt. Es gibt in einem Zahlungsablauf keinen vergleichbaren Schritt, an den sich eine Weiterleitung anhängen ließe. Fügt man eine ein, scheitert entweder die Prüfsummenvalidierung der Banking-App und der Code wird abgelehnt, oder, im Fall eines UPI-artigen URI-Intents, passt einfach das erwartete Schema-Präfix nicht mehr, und der Code öffnet sich überhaupt nicht.

Das ist dieselbe strukturelle Lücke, die für Europas SEPA-basierten GiroCode ausführlicher behandelt wird, und die Antwort lässt sich verallgemeinern: Kein aktueller Standard, egal wo, verbindet Zahlungsnutzdaten mit Scan-Tracking auf Kampagnenebene in einem Code. Was eine Agentur stattdessen anbieten kann, ist die ehrliche Notlösung: ein wie gewohnt getrackter Marketing-QR-Code, der zu einer Seite führt, auf der der tatsächliche Zahlungs-QR-Code des Kunden angezeigt wird, oder die beiden Codes als klar getrennte Elemente auf demselben Material platziert, einer zum Stöbern, einer zum Bezahlen. Ein QR-Code für Restaurant-Speisekarten neben dem Zahlungscode an der Kasse ist die alltägliche Version genau dieser Kombination, und sie funktioniert gerade deshalb, weil die beiden Codes nie zu einem verschmolzen werden.

Das Betrugsrisiko, auf das Agenturen vor dem Druck hinweisen müssen

Bei einem statischen Zahlungs-QR-Code prüft zum Zeitpunkt des Scans kein Server, was bedeutet, dass ein manipulierter Code nach dem Druck nicht erkannt oder blockiert werden kann. Diese Lücke wird aktiv ausgenutzt. US-Behörden haben seit Januar 2022 wiederholt öffentlich vor Kriminellen gewarnt, die betrügerische QR-Aufkleber über echte auf Parkuhren, Restauranttischen und öffentlichen Beschilderungen kleben und damit Zahlungen (oder Zugangsdaten) auf Konten umleiten, die sie kontrollieren. In Großbritannien stieg die gemeldete QR-Code-Betrugsrate über fünf Jahre um etwa das Vierzehnfache, und ein dokumentierter Fall in Redondo Beach, Kalifornien, ergab, dass rund 150 Parkuhren mit gefälschten QR-Overlays versehen waren, die direkt neben den echten Zahlungsaufklebern angebracht wurden.

Die praktische Konsequenz für eine Agentur ist, dass dies kein Problem ist, das eine QR-Plattform nach dem Druck beheben kann, denn die Schwachstelle steckt im physischen Druck, nicht in der Logik des Codes. Das reiht sich ein in die umfassendere Anleitung zur QR-Code-Sicherheit für Agenturen: fälschungssichere Drucktechnik für alles vorschreiben, was einen Zahlungscode trägt (erhabener oder geprägter Druck, oder eine Laminierung, die sichtbar reißt, wenn ein Aufkleber abgezogen wird), Zahlungscodes vor Ort kontrollieren lassen statt sich auf eine einmalige Installation zu verlassen, und wo der Zahlungsdienstleister des Kunden dynamische Codes pro Transaktion statt statischer anbietet, für alles Unbeaufsichtigte die dynamische Version empfehlen.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem PromptPay-QR-Code und einem Marketing-QR-Code?

Ein PromptPay-Code kodiert die Zahlungsdaten direkt, gemäß Thailands EMV-basiertem Merchant-Presented-Format. Ein Marketing-QR-Code kodiert eine URL, die über einen Tracking-Server weiterleitet, ohne dass sich Zahlungsinformationen im Code selbst befinden.

Kann ich einen PIX-, UPI- oder PromptPay-QR-Code wie einen ScanKit-Code trackbar machen?

Nein. Der Code trägt bereits die Zahlungsempfänger- und Transaktionsdaten, die die Banking-App benötigt; verpackt man ihn in eine Weiterleitung, bricht die Prüfsumme oder das von der App erwartete Format, sodass sich der Code nicht mehr öffnen lässt.

Ist ein statischer oder ein dynamischer Zahlungs-QR-Code sicherer?

Dynamische Codes sind sicherer. Sie sind nur einmal gültig, an einen Betrag gebunden und kurzlebig, was das Zeitfenster schließt, das ein statischer, wiederverwendbarer Code für einen ausgetauschten oder gefälschten Aufkleber offenlässt.

Wie funktioniert ein PIX-QR-Code in Brasilien?

PIX verwendet den BR Code, Brasiliens EMV-basiertes Merchant-Presented-Format. Ein statischer PIX-Code trägt nur den Schlüssel des Zahlungsempfängers, der Betrag muss manuell eingegeben werden; ein dynamischer fügt Betrag, Transaktions-ID und Ablaufdatum hinzu.

Was ist der Unterschied zwischen UPI QR und BharatQR in Indien?

UPI QR kodiert einen appspezifischen upi://pay-Link und öffnet sich nur innerhalb von UPI-Apps. BharatQR ist das eigentliche EMV-basierte Format, in einem Code sowohl über Karten- als auch über UPI-Systeme interoperabel. UPI QR ist mit Stand Anfang 2025 mit etwa zehn zu eins deutlich verbreiteter, obwohl BharatQR der interoperablere Standard ist.

Ist der QR-Code von Zelle dasselbe wie PayNow oder PIX?

Nein. Zelle ist nicht EMV-basiert und öffnet sich nur innerhalb einer Zelle-fähigen Banking-App; es identifiziert eine bestimmte Person, keinen Händler. PIX, PromptPay, PayNow und DuitNow sind nationale, EMV-basierte Händlersysteme; Zelle ist ein auf die USA beschränktes, an Banking-Apps gebundenes Peer-to-Peer-System.

Was bedeutet "Merchant-Presented" im Vergleich zu "Consumer-Presented" bei einem QR-Code?

Merchant-Presented bedeutet, dass der Händler den Code anzeigt und der Kunde ihn scannt, der Modus, der bei nahezu der gesamten Agentur- und Einzelhandelsarbeit zum Einsatz kommt. Consumer-Presented ist umgekehrt: Der Kunde generiert einen Code auf seinem eigenen Telefon, und der Händler scannt ihn.

Wie erkenne ich, ob ein Zahlungs-QR-Code manipuliert wurde?

Achten Sie auf einen Aufkleber, der leicht über die darunterliegende Fläche hinausragt, auf abweichende Druckqualität oder auf einen Code, der an einer Stelle sitzt, an der ihn der Händler normalerweise nicht platzieren würde. Da statische Codes von keinem Server geprüft werden, ist die physische Inspektion die einzige Echtzeit-Verteidigung.

Kann ein einzelner QR-Code sowohl Zahlung als auch Marketing-Tracking abdecken?

Derzeit nicht. Kein weit verbreiteter Standard verbindet Zahlungsnutzdaten mit Scan-Tracking auf Kampagnenebene in einem Code. Die praktische Lösung sind zwei klar getrennt platzierte Codes, ein getrackter Marketing-Code und ein Zahlungscode, statt zu versuchen, sie zu verschmelzen.

Welche Währungs- und Ländercodes erscheinen in einem EMV-Zahlungs-QR-Code?

Die Währung wird nach dem numerischen ISO-4217-Standard kodiert (zum Beispiel der brasilianische Real als 986, der malaysische Ringgit als 458), und das Land verwendet den zweistelligen ISO-3166-1-Code (BR, MY, SG, TH, IN).

Sind QR-Code-Zahlungen grenzüberschreitend interoperabel?

Größtenteils nicht, auch wenn es Verbindungen gibt: Singapurs PayNow und Thailands PromptPay unterstützen seit April 2021 Echtzeit-Überweisungen über Ländergrenzen hinweg. Ansonsten bleiben die meisten nationalen Systeme rein inländisch, sodass ein Code, der für das System eines Landes generiert wurde, von den Banking-Apps eines anderen Landes nicht erkannt wird.

Kurz gesagt

Ein Zahlungs-QR-Code trägt die Transaktion selbst; ein Marketing-QR-Code trägt einen Link dazu. Das ist der ganze Grund, warum sie sich nicht verschmelzen lassen, egal was ein Kunde fragt. Die meisten nationalen Systeme, denen eine Agentur im Ausland begegnet, PIX, PromptPay, PayNow, DuitNow, BharatQR, teilen sich dieselbe EMVCo-Merchant-Presented-Struktur mit länderspezifischen Daten darin, während Zelle und das eigene, appgebundene Format von UPI abseits stehen, als proprietäre, nur-app-basierte Systeme. Wenn ein statischer Zahlungscode irgendwo öffentlich angebracht wird, behandeln Sie ihn wie jedes unbeaufsichtigte Schild: fälschungssichere Drucktechnik vorschreiben, vor Ort kontrollieren, und ihn visuell wie funktional getrennt halten vom getrackten Marketing-Code, der das eigentliche Kampagnen-Reporting übernimmt.