EPC-QR-code: de SEPA-betaal-QR-standaard uitgelegd

Een EPC-QR-code bevat geen link. Hij bevat een SEPA-overschrijving, uitgeschreven als een kort blok platte tekst, en een bankapp die het formaat herkent, leest hem en vult het overschrijvingsformulier in. Er wordt geen server benaderd, er wordt niets opgezocht, en niets van de scan bereikt jou.

Dat ene feit bepaalt alles verder over hoe deze codes worden gebruikt. Je kunt er geen inkorten, je kunt er geen ompointen, en je kunt de scans niet tellen, omdat er nergens in de flow een verzoek plaatsvindt. De standaard erachter is EPC069-12 van de European Payments Council, de codes worden in Duitstalige markten meestal GiroCodes genoemd, en het loont om het formaat precies te begrijpen voordat je er duizenden van op facturen print. Voor het algemene geval van wat een code kan bevatten, behandelt wat een QR-code is de payloadvraag.

Wat de payload precies bevat

De payload is een reeks regels, in een vaste volgorde, elk een apart element. Een parser leest regel 1, verwacht BCD, leest regel 4, verwacht SCT, en geeft het op als een van beide ontbreekt.

Twee regels doen mensen struikelen. De structured reference en de unstructured text sluiten elkaar uit: vul de ene in en laat de andere leeg. En het bedrag is optioneel, wat de juiste keuze is voor een donatiecode waar de betaler zelf beslist, en de verkeerde keuze voor een factuur waar je een exact bedrag vooraf ingevuld wilt hebben.

Het hele blok is begrensd tot 331 bytes. De EPC069-12-richtlijnen leggen ook het foutcorrectieniveau vast op M en begrenzen het symbool tot versie 13, dus de code die je print heeft een bekend plafond op het aantal modules. Bouw je dit in code in plaats van te klikken in een generator, dan laat de Segno library-documentatie de veldvolgorde en de encoderingsregels zien in een vorm die je kunt testen.

Waarom je hem niet kunt inkorten of bijhouden

Een bijgehouden QR-code werkt door een URL te coderen die jij bezit. De scan opent die URL, jouw redirect antwoordt, je telt het verzoek, en de bezoeker komt terecht waar de link op dat moment naartoe wijst. Dynamische versus statische QR-codes behandelt het mechanisme in detail.

Niets daarvan is hier van toepassing. De bankapp is geen browser. Hij parset tekst, matcht het formaat, en opent een betaalformulier lokaal op het toestel. Er is geen HTTP-verzoek om te onderscheppen, dus:

• Er bestaat nergens een scantelling. Niet in jouw tool, niet bij de bank.
• Niets kan worden ompointed. Een verkeerd IBAN betekent een herdruk.
• De payload in een korte link verpakken breekt hem volledig, omdat de parser https ziet waar hij BCD verwacht.

Ik heb een team een week zien besteden aan het proberen krijgen van attributie op een betaalcode, voordat iemand de spec las. Het eerlijke antwoord is dat de betaalkant en de meetkant twee verschillende codes zijn, en als de lay-out ruimte heeft voor maar een van de twee, wint de betaalcode.

Wat je wel kunt meten, is alles eromheen. Bevat een mailing een factuur met een betaalcode, zet dan een aparte bijgehouden korte link op de brief voor het klantenportaal, de voorwaarden, of de supportpagina, en lees de betrokkenheid daaruit af. Elido's QR-codefuncties behandelen de bijhoudbare helft van het blad, en de betaalcode blijft precies zoals de standaard vereist.

Waar het werkt en waar niet

Ondersteuning zit in de afzonderlijke bankapps, wat verklaart waarom de dekking ongelijkmatig is op een manier die landenlijsten te rooskleurig voorstellen. Oostenrijkse en Duitse apps lezen deze codes al jaren, Finse en Nederlandse apps zijn over het algemeen betrouwbaar, Belgische ondersteuning is goed. Test daarbuiten eerst voordat je een oplage laat drukken.

Twee buren worden er vaak mee verward. De Swiss QR-bill is een andere specificatie met een eigen lay-out en een Zwitsers kruis in het midden van het symbool; het is geen EPC-code en apps in de eurozone lezen hem niet als betaling. En een betaallink van een kaartverwerker is dit helemaal niet: dat is een gewone URL in een QR, met een hosted checkout aan het einde, en die gedraagt zich als elke andere weblink, inclusief de tracking die daarbij hoort.

Voor de bredere vraag wat een gereguleerd betaal- of kredietbedrijf aan klanten mag voorleggen, behandelt URL-verkorters voor fintech de onderdelen waar een link bij betrokken is.

Er een maken zonder spijt

Zes controles, in de volgorde waarin ze je geld besparen.

1. Valideer het IBAN voor de generatie, niet na het printen. Een checksumtest kost niets en een herdruk kost een hele oplage.
2. Beslis bewust over de bedragvraag. Vast voor facturen, leeg voor donatieposters waar elk bedrag mogelijk moet zijn.
3. Geef de voorkeur aan de structured reference boven vrije tekst. Ze is korter, ze reconcilieert automatisch in je boekhouding, en ze houdt de payload klein.
4. Test in minstens drie bankapps, op beide telefoonplatforms. Parsers verschillen in hoe strikt ze de optionele velden behandelen.
5. Bepaal de afmeting van de gedrukte code op basis van de afstand waarop hij gescand zal worden, net als bij elke andere code. Hoe groot een QR-code moet zijn heeft de rekensom.
6. Houd hem mat. Glanslak over een betaalcode op een factuur onder kantoorverlichting is een supportticket dat op je ligt te wachten.

Het stickerprobleem

Er is één echte fraudevector, en die is fysiek in plaats van digitaal. Een statische betaalcode gedrukt op een factuur, een parkeermeter, een bord op een marktkraam of een liefdadigheidsposter kan worden overplakt met een sticker met een ander IBAN. Niets in de code verzet zich daartegen, want de payload is het papier.

De tegenmaatregelen zijn even fysiek. Print de code binnen de factuurlay-out, waar een label opvallend zou zijn, in plaats van op een plakstrook. Toon de naam van de begunstigde en de laatste cijfers van het IBAN in tekst naast de code, zodat een betaler kan vergelijken. En vertel mensen in de betalingsbevestigingsinstructies dat ze de naam moeten lezen die hun bankapp toont voordat ze bevestigen, want dat scherm is de enige plek waar de omwisseling zichtbaar wordt. Zijn QR-codes veilig, en wat is quishing eigenlijk behandelt het bredere aanvalspatroon, waarvan het grootste deel wel geldt voor de linkcodes die je elders op dezelfde pagina print.

Het geruststellende deel: een betaling heeft nog altijd een mens nodig om deze te bevestigen in een geauthenticeerde bankapp. De code vult een formulier alvast in, hij verplaatst nooit geld.

Lees de cornerstone-serie

Dit artikel valt onder de features-cluster. Voor de printworkflow rond elke code die je genereert, is een QR-code-campagne vanaf nul de cornerstone, en de QR-codegids in de docs behandelt het genereren van de bijhoudbare variant via de API.

Gerelateerd op de blog

• Dynamische versus statische QR-codes, en wanneer welke geschikt is
• Wat een QR-code is en wat hij kan bevatten
• QR-codes en de GDPR: wat een scan verzamelt
• URL-verkorters voor fintech-teams
• Hoe groot moet een QR-code zijn?