Betaal-QR-codes uitgelegd: PIX, PromptPay en UPI voor bureaus

Een klant geeft je een stapel materialen voor een nieuwe marktlancering: een tafelstandaard voor een restaurantketen die uitbreidt naar Brazilië, een poster voor een pop-up in Singapore, een flyer voor een beursstand in Bangkok. Ergens op elk item staat een QR-code die niet van jou is. Het is een betaalcode, gedrukt door de bank of het kassasysteem van de klant, en de klant wil twee dingen weten: kun je hem trackbaar maken zoals de marketingcodes die je voor hen bouwt, en is het veilig om hem naast je campagnecode op dezelfde pagina te zetten.

Beide vragen komen vaker voor dan de QR-code-industrie zelf toegeeft, omdat de meeste gidsen over QR-betalingen geschreven zijn voor developers die één betaalrail integreren, niet voor bureaus die zes verschillende nationale schema's op het eerste gezicht moeten herkennen en in gewone taal moeten uitleggen waarom ze niet werken zoals een marketing-QR-code. Dit is die gids: wat een betaal-QR-code precies bevat, de standaard die de meeste ervan delen, hoe PromptPay, PIX, UPI, PayNow en DuitNow van elkaar verschillen en van Zelle, en het eerlijke, technische antwoord op "kunnen we dit tracken."

Wat een betaal-QR-code eigenlijk is

Een marketing-QR-code, het type dat ScanKit genereert, codeert een korte URL. De camera van de telefoon leest de URL, opent een browser, en een redirect-server bepaalt waar de scan naartoe gaat, met optioneel het loggen van de scan onderweg. De code is een verwijzing. Al het interessante gebeurt op de server, na de scan.

Een betaal-QR-code is fundamenteel anders, niet alleen qua inhoud. Hij verwijst nergens naartoe. Hij bevat de transactiegegevens zelf, of genoeg daarvan om er een te starten: een identificatie van de begunstigde, een valuta, soms een bedrag, soms een vervaldatum. Wanneer een bankapp hem scant, is er geen redirect en geen server-lookup op het moment van scannen; de app parseert de payload direct en toont de betaalgegevens die hij zojuist uit de code heeft gelezen.

Dat onderscheid is belangrijk, want het is de reden dat een betaal-QR-code niet zomaar in een trackinglink gewikkeld kan worden zoals dat kan bij een website-URL. Er is niets om naartoe te redirecten. De code moet exact zo bij de betaalapp aankomen als de bank of schema-operator hem gegenereerd heeft, anders kan de app hem niet parseren.

De twee codes zien er op de pagina identiek uit, maar splitsen zich op het moment dat ze gescand worden.

1. De code wordt gescand. Op dit punt zijn een marketing-QR-code en een betaal-QR-code met het blote oog niet van elkaar te onderscheiden.
2. De payload van een marketing-QR-code is een URL, die wordt opgezocht op een redirect-server op het moment dat hij gescand wordt.
3. De payload van een betaal-QR-code is de transactiegegevens zelf, rechtstreeks gelezen door de bankapp, zonder dat daar een server aan te pas komt.
4. De marketingscan wordt gelogd en de telefoon komt uit op een getrackte bestemmingspagina.
5. De betaalscan toont een bevestiging zodra de overboeking is afgerond, zonder dat er ergens een scanrecord wordt aangemaakt.

Betaal-QR-codes splitsen zich ook op in twee gebruiksrichtingen, en de terminologie is de moeite waard om te kennen omdat klanten hem zullen gebruiken. Bij merchant-presented mode toont de handelaar een gedrukte of op een scherm getoonde code en scant de telefoon van de klant die, wat de modus is die vrijwel al het bureauwerk raakt: tafelstandaards, kassastickers, factuurcodes. Bij consumer-presented mode opent de klant zijn bankapp, genereert zelf een code op zijn eigen scherm, en scant de handelaar die met een kassascanner, de omgekeerde flow die gebruikt wordt bij sommige kassa's in de winkel en bij OV-poortjes. Bureaus hoeven zich alleen zorgen te maken over de eerste.

De standaard waarop de meeste nationale schema's zijn gebouwd

De meeste nationale "scan om te betalen"-codes die een bureau tegenkomt, PIX in Brazilië, PromptPay in Thailand, PayNow in Singapore, DuitNow in Maleisië, BharatQR in India, zijn gebouwd op dezelfde basis: de Merchant-Presented Mode-specificatie van EMVCo, voor het eerst gepubliceerd in 2017 door het consortium van kaartnetwerken dat ook de chipkaartstandaarden beheert. Elk land voegt vervolgens zijn eigen binnenlandse betaalgegevens toe in een gereserveerd veld binnen die basisstructuur, wat verklaart waarom de codes er van land tot land vergelijkbaar uitzien en zich vergelijkbaar gedragen, ook al zijn de onderliggende bankrails volledig gescheiden.

Structureel is een EMV-betaal-QR-code opgebouwd uit getagde datablokken, elk met een tweecijferige ID, een lengte en een waarde. Een bureau hoeft de ruwe payload niet te kunnen lezen, maar weten hoe de vorm eruitziet helpt wanneer het financiële team van een klant vraagt waarom hun code "niet werkt" met een generieke QR-generator: de payload bevat een point-of-initiation-vlag die de code als statisch of dynamisch markeert, een blok met merchant-accountinformatie in het bereik dat gereserveerd is voor binnenlandse schemagegevens (hier registreren PIX, PromptPay en de andere elk hun eigen identificatieformaat), een valutacode, een landcode en een controlesom. Verander een van die gegevens met een generieke tool die gebouwd is voor marketingcodes en de controlesom klopt niet meer, en de bankapp weigert de code gewoon in plaats van stilletjes verkeerd te betalen, wat op zijn minst het veilige faalmechanisme is.

Statische versus dynamische betaal-QR-codes

Hetzelfde onderscheid tussen statisch en dynamisch dat belangrijk is voor marketing-QR-codes duikt ook op bij betaal-QR-codes, maar de inzet is anders.

Een statische betaal-QR-code codeert alleen de accountidentificatie van de begunstigde, verder niets. Hij wordt één keer gedrukt, oneindig hergebruikt, op een kassasticker of een tafelstandaard, en de klant typt het bedrag zelf in zijn bankapp na het scannen. Hij is goedkoop om te produceren en verloopt nooit, wat precies de reden is dat de meeste kleine handelaren deze versie gebruiken, en precies de reden dat fraudeurs deze versie als doelwit kiezen: een statische code bevat geen bedrag, geen vervaldatum en geen transactiereferentie, dus een frauduleuze code die ervoor in de plaats gezet wordt, is functioneel niet te onderscheiden van de echte tot het geld niet aankomt waar het zou moeten.

Een dynamische betaal-QR-code wordt per transactie gegenereerd, met het bedrag, een transactiereferentie en een korte vervaltijd erin verwerkt, en daarna weggegooid na gebruik, qua opzet vergelijkbaar met een dynamische marketing-QR-code maar gegenereerd door een kassasysteem in plaats van een marketingplatform. Hij sluit het fraudevenster dat een statische code openlaat, maar moet voor elke verkoop opnieuw gegenereerd worden, wat verklaart waarom hij vooral voorkomt bij bemande kassa's met een kassasysteem erachter, en niet op een onbemande tafelstandaard.

Geen van beide versies is "trackbaar" in de zin die een bureau bedoelt bij een marketingcampagne. Er is geen scanlog, geen tijdstempel, geen locatiegegevens, omdat er op het moment van scannen geen server bij betrokken is om iets daarvan vast te leggen. Welke rapportage een klant ook krijgt over een betaal-QR-code, die komt uit de settlementgegevens van hun betaalverwerker, niet uit de code zelf.

Een overzicht per land

De onderstaande schema's regelen allemaal binnenlandse instant-betalingen, en een bureau dat in meerdere markten werkt, komt de meeste ervan vroeg of laat tegen.

PIX (Brazilië). Het instant-betaalschema van Brazilië, beheerd door de Banco Central do Brasil, vereist sinds oktober 2020 dat de QR-payload, bekend als BR Code, de EMV Merchant-Presented Mode-structuur volgt. Een statische PIX-code bevat alleen de sleutel van de begunstigde (een telefoonnummer, e-mailadres, belastingnummer of willekeurig token); een dynamische voegt het bedrag, een transactie-ID en een vervaldatum toe, en kan de betaalbevestiging automatisch terugsturen naar het eigen reconciliatiesysteem van de handelaar.

UPI en BharatQR (India). India gebruikt twee verschillende QR-formaten naast elkaar, en ze door elkaar halen is een veelgemaakte fout in QR-content die gericht is op bureaus. Een UPI-QR-code codeert een upi://pay-deeplink, een URI-intent in plaats van een EMV-payload, en opent alleen in UPI-compatibele apps zoals Google Pay, PhonePe of Paytm. BharatQR is het echte EMV-gebaseerde formaat, gezamenlijk ontwikkeld door de National Payments Corporation van India met Visa, Mastercard en Amex, en is interoperabel over zowel kaart- als UPI-rails in één code. UPI-QR domineert qua volume, ruwweg tien codes ingezet voor elke ene BharatQR-code begin 2025, ondanks dat BharatQR de universeel interoperabelere van de twee is.

PromptPay (Thailand). De nationale instant-betaalrail van Thailand, beheerd door de Bank of Thailand, gebruikt een EMV-gebaseerde merchant-presented code voor retail- en kassabetalingen, en was een van de eerste nationale schema's die zich koppelden aan een buurland: PromptPay en het Singaporese PayNow ondersteunen sinds april 2021 realtime grensoverschrijdende overboekingen tussen de twee systemen.

PayNow / SGQR (Singapore). De Singaporese SGQR wordt door de toezichthouders expliciet gedocumenteerd als gebouwd op de EMVCo Merchant-Presented Mode-specificatie, en functioneert als een overkoepelend label: één SGQR-sticker kan meerdere onderliggende betaalschema's (PayNow, plus diverse kaart- en e-walletrails) samenbrengen achter één code, zodat de app van de klant automatisch de juiste rail kiest in plaats van dat de handelaar vijf aparte codes moet tonen.

DuitNow (Maleisië). Beheerd door PayNet, het nationale betaalnetwerk onder toezicht van Bank Negara Malaysia, lanceerde DuitNow QR in december 2018 en volgt dezelfde EMV merchant-presented structuur, met de land- en valutacodes van Maleisië en een DuitNow-specifieke accountidentificatie in het binnenlandse datablok.

Zelle (VS). Zelle is het nuttige contrastgeval, omdat het op het eerste gezicht lijkt op de schema's hierboven maar in de praktijk niets op ze lijkt. Het is niet EMV-gebaseerd, niet zelfstandig scanbaar met een generieke QR-lezer, en opent alleen vanuit een Zelle-geactiveerde bankapp. Het identificeert een specifieke persoon-op-persoon-ontvanger in plaats van een betaalpunt van een handelaar, is alleen beschikbaar in de VS, en niet beschikbaar bij elke deelnemende bank. Als een klant vraagt of hun Amerikaanse betaal-QR-code "dezelfde standaard" is als PIX of PromptPay, is het eerlijke antwoord nee: Zelle valt in een compleet andere categorie, een propriëtair peer-to-peer-intentschema in plaats van een nationale merchant-presented rail.

Het patroon om te onthouden: nationale instant-betaal-QR-codes (PIX, PromptPay, PayNow, DuitNow, BharatQR) zijn merchant-presented, EMV-gebaseerd en landspecifiek maar structureel gestandaardiseerd. Aan een bankapp gebonden persoon-op-persoon-codes (Zelle, en in de praktijk ook UPI-QR zelf) zijn propriëtaire intentschema's, niet zelfstandig interoperabel, en moeten niet met dezelfde taal aan een klant beschreven worden.

Kun je een betaal-QR-code trackbaar maken?

Nee, en het is de moeite waard om uit te leggen waarom in plaats van gewoon nee te zeggen, want de technische reden is wat een klant ervan weerhoudt om het bij de volgende campagne opnieuw te vragen. De payload van een betaal-QR-code is de transactie: de accountidentificatie, de valuta, soms het bedrag, zijn gegevens die de betaalapp direct leest en waarop hij direct handelt. De payload van een marketing-QR-code is een URL, en het tracken gebeurt op de server waar de URL naar verwijst, volledig los van wat de telefoon toont. Er is geen equivalente stap in een betaalflow om een redirect aan vast te maken. Voeg er toch een toe, en de bankapp faalt óf op de validatie van de controlesom en weigert de code, óf, bij een UPI-achtige URI-intent, komt gewoon niet overeen met het verwachte schemaprefix en opent helemaal niet.

Dit is dezelfde structurele kloof die uitgebreider besproken wordt voor de Europese SEPA-gebaseerde GiroCode, en het antwoord is algemeen geldig: geen enkele bestaande standaard, waar dan ook, combineert een betaalpayload met scantracking op campagneniveau in één code. Wat een bureau in plaats daarvan kan aanbieden, is de eerlijke workaround: een marketing-QR-code, normaal getrackt, die leidt naar een pagina waar de daadwerkelijke betaal-QR-code van de klant getoond wordt, of de twee codes als duidelijk gescheiden elementen op hetzelfde stuk geplaatst, één om te browsen, één om te betalen. Een QR-code voor een restaurantmenu naast de betaalcode van een kassa is de alledaagse versie van precies deze combinatie, en het werkt juist omdat de twee codes nooit tot één code samengevoegd worden.

Het fraudegevaar dat bureaus vóór het drukken moeten aankaarten

Een statische betaal-QR-code heeft geen server die hem controleert op het moment van scannen, wat betekent dat er geen manier is om een geknoeide code na het drukken te detecteren of te blokkeren. Dat gat wordt actief uitgebuit. Amerikaanse autoriteiten hebben sinds januari 2022 herhaaldelijk openbare waarschuwingen afgegeven over criminelen die frauduleuze QR-stickers over legitieme stickers plakken op parkeermeters, restauranttafels en openbare bewegwijzering, waarbij betalingen (of inloggegevens) omgeleid worden naar rekeningen die zij beheren. In het Verenigd Koninkrijk steeg de gerapporteerde QR-codefraude over vijf jaar met ongeveer een factor veertien, en een gedocumenteerd geval in Redondo Beach, Californië, telde ongeveer 150 parkeermeters voorzien van nagemaakte QR-overlays, direct naast de legitieme betaalstickers geplaatst.

De praktische implicatie voor een bureau is dat dit geen probleem is dat een QR-platform na het drukken kan oplossen, want de kwetsbaarheid zit in de fysieke druk, niet in de logica van de code. Het sluit aan bij de bredere richtlijnen over QR-codebeveiliging voor bureaus: schrijf fraudebestendig drukwerk voor bij alles waar een betaalcode op staat (reliëfdruk of verhoogde druk, of laminaat dat zichtbaar scheurt als een sticker eraf wordt getrokken), laat betaalcodes ter plaatse controleren in plaats van te vertrouwen op een eenmalige installatie zonder verdere controle, en waar de betaalprovider van de klant dynamische, per-transactie codes aanbiedt in plaats van statische, raad de dynamische versie aan voor alles wat onbemand is.

Veelgestelde vragen

Wat is het verschil tussen een PromptPay-QR-code en een marketing-QR-code?

Een PromptPay-code codeert de betaalgegevens rechtstreeks, volgens het EMV-gebaseerde merchant-presented formaat van Thailand. Een marketing-QR-code codeert een URL die via een trackingserver redirect, zonder betaalinformatie in de code zelf.

Kan ik een PIX-, UPI- of PromptPay-QR-code trackbaar maken zoals een ScanKit-code?

Nee. De code bevat al de gegevens over de begunstigde en de transactie die de bankapp nodig heeft; hem in een redirect wikkelen verbreekt de controlesom of het verwachte formaat van de app, waardoor de code niet meer opent.

Is een statische of dynamische betaal-QR-code veiliger?

Dynamische codes zijn veiliger. Ze zijn eenmalig te gebruiken, aan een vast bedrag gekoppeld en kortstondig geldig, wat het venster sluit dat een statische, herbruikbare code openlaat voor een verwisselde of nagemaakte sticker.

Hoe werkt een PIX-QR-code in Brazilië?

PIX gebruikt BR Code, het EMV-gebaseerde merchant-presented formaat van Brazilië. Een statische PIX-code bevat alleen de sleutel van de begunstigde en vereist dat het bedrag handmatig wordt ingevoerd; een dynamische voegt het bedrag, een transactie-ID en een vervaldatum toe.

Wat is het verschil tussen UPI-QR en BharatQR in India?

UPI-QR codeert een app-specifieke upi://pay-link en opent alleen in UPI-apps. BharatQR is het echte EMV-gebaseerde formaat, interoperabel over kaart- en UPI-rails in één code. UPI-QR is veruit gangbaarder, met ongeveer een factor tien begin 2025, ondanks dat BharatQR de interoperabelere standaard is.

Is de QR-code van Zelle hetzelfde als die van PayNow of PIX?

Nee. Zelle is niet EMV-gebaseerd en opent alleen in een Zelle-geactiveerde bankapp; het identificeert een specifieke persoon in plaats van een handelaar. PIX, PromptPay, PayNow en DuitNow zijn nationale, EMV-gebaseerde merchant-rails; Zelle is een alleen-in-de-VS beschikbaar, aan een bankapp gebonden peer-to-peer-schema.

Wat betekent "merchant-presented" versus "consumer-presented" bij een QR-code?

Merchant-presented betekent dat de handelaar de code toont en de klant scant, de modus die gebruikt wordt bij vrijwel al het bureau- en retailwerk. Consumer-presented is het omgekeerde: de klant genereert een code op zijn eigen telefoon en de handelaar scant die.

Hoe kan ik zien of er met een betaal-QR-code geknoeid is?

Let op een sticker die iets boven het oppervlak eronder uitsteekt, afwijkende drukkwaliteit, of een code die ergens geplaatst is waar de handelaar er normaal geen zou neerzetten. Omdat statische codes geen server hebben die ze controleert, is fysieke inspectie de enige verdediging in real time.

Kan één QR-code zowel betaling als marketingtracking afhandelen?

Op dit moment niet. Geen enkele veelgebruikte standaard combineert een betaalpayload met scantracking op campagneniveau in één code. De praktische oplossing is twee duidelijk gescheiden codes, één getrackte marketingcode, één betaalcode, in plaats van te proberen ze samen te voegen.

Welke valuta- en landcodes staan er in een EMV-betaal-QR-code?

Valuta wordt gecodeerd met de numerieke ISO 4217-standaard (bijvoorbeeld de Braziliaanse real als 986, de Maleisische ringgit als 458), en land gebruikt de tweeletterige ISO 3166-1-code (BR, MY, SG, TH, IN).

Zijn QR-codebetalingen interoperabel over landsgrenzen heen?

Grotendeels niet, al bestaan er koppelingen: het Singaporese PayNow en het Thaise PromptPay ondersteunen sinds april 2021 realtime grensoverschrijdende overboekingen. De meeste nationale schema's blijven verder puur binnenlands, dus een code die gegenereerd is voor de rail van het ene land wordt niet herkend door de bankapps van een ander land.

De korte versie

Een betaal-QR-code bevat de transactie zelf; een marketing-QR-code bevat een link naar een transactie. Dat is de hele reden waarom ze niet samengevoegd kunnen worden, wat een klant ook vraagt. De meeste nationale schema's die een bureau in het buitenland tegenkomt, PIX, PromptPay, PayNow, DuitNow, BharatQR, delen dezelfde EMVCo merchant-presented structuur met landspecifieke gegevens erin, terwijl Zelle en het eigen, aan een app gebonden formaat van UPI ernaast staan als propriëtaire, alleen-in-de-bankapp-schema's. Wanneer een statische betaalcode ergens in de openbare ruimte hangt, behandel hem dan zoals je elk onbemand bord zou behandelen: schrijf fraudebestendig drukwerk voor, controleer hem ter plaatse, en houd hem visueel en functioneel gescheiden van de getrackte marketingcode die de daadwerkelijke campagnerapportage doet.