7 min readFeatures

EPC QR Code: The SEPA Payment QR Standard Explained

An EPC QR code encodes a SEPA credit transfer, not a URL, so a banking app can prefill the form. What the payload holds, and why you cannot track it.

Marius Voß
DevRel · edge infra

An EPC QR code doesn't contain a link. It's a SEPA credit transfer, written out as a short block of plain text, and a banking app that recognises the format reads it and fills in the transfer form. No server is contacted, nothing is looked up, and nothing about the scan reaches you.

That single fact decides everything else about how these codes are used. You can't shorten one, you can't repoint one, and you can't count the scans, because there is no request anywhere in the flow. The standard behind it is the European Payments Council's EPC069-12, the codes are usually called GiroCodes in German-speaking markets, and the format is worth understanding precisely before you print thousands of them on invoices. For the general case of what a code can carry, what a QR code is covers the payload question.

What the Payload Actually Contains

The payload is a sequence of lines, in a fixed order, each one a separate element. A parser reads line 1, expects BCD, reads line 4, expects SCT, and gives up if either is missing.

LineContentLimit
Service tagBCDfixed, 3 characters
Version001 or 002002 makes the BIC optional
Character set1 for UTF-8, up to 8one digit
IdentificationSCTfixed, 3 characters
BICbeneficiary bank identifier11 characters, often omitted
Beneficiary namethe account holder70 characters
IBANbeneficiary account34 characters
AmountEUR followed by the value0.01 to 999999999.99, in EUR
Purpose codeISO purpose, rarely used4 characters
Structured refcreditor reference, or35 characters
Unstructured textfree-text remittance instead140 characters
Beneficiary to originatornote shown to the payer70 characters

Two rules trip people up. The structured reference and the unstructured text are mutually exclusive: fill one, leave the other empty. And the amount is optional, which is the correct choice for a donation code where the payer decides, and the wrong choice for an invoice where you want an exact figure prefilled.

The whole block is capped at 331 bytes, and the elements are separated by a line feed or CRLF, with no separator after the last one. The 331 bytes count UTF-8 bytes, so accented names use more than their character count. Name, IBAN, BIC and the structured reference are marked fixed, meaning the payer's app should not let them be edited. The EPC069-12 guidelines, version 3.1 issued 19 March 2024 (accessed 2026-10-25; the field table above is checked against it) also pin the error correction level at M and cap the symbol at version 13 (69 modules per side). The document's own sample payload is 96 bytes and produces a version 6 code of 41 modules. If you build this in code, the Segno library documentation (accessed 2026-10-25) shows the field order, and its helper fixes the error level at M and the version at 13 or lower, matching the spec.

The four blocks of an EPC QR payload, from the fixed service tag through beneficiary details and amount to the remittance reference

Why You Cannot Shorten or Track It

A tracked QR code works by encoding a URL you own. The scan opens that URL, your redirect answers, you count the request, and the visitor lands wherever you currently point the link. Dynamic versus static QR codes covers the mechanism in full.

None of that applies here, and there's no workaround.

The banking app isn't a browser. It parses text, matches the format, and opens a payment form locally on the device. There's no HTTP request to intercept, so:

  • No scan count exists, anywhere. Not in your tool, not in the bank's.
  • Nothing can be repointed. A wrong IBAN means a reprint.
  • Wrap the payload in a short link and it breaks, because the parser sees https where it expects BCD.

The payment side and the measurement side are two different codes. If the layout has room for only one, the payment code wins. I'd put the payment code first and the tracked link second, every time.

What you can measure is everything around it. If a mailing carries an invoice with a payment code, put a separate tracked short link on the letter for the customer portal, the terms, or the support page, and read the engagement from that. Elido's QR code features cover the trackable half of the sheet, and the payment code stays exactly as the standard requires.

Where It Works and Where It Does Not

Support lives in individual banking apps, which is why country lists oversell it. The EPC document is explicitly informative, and implementing it is optional for banks. Test before you commit to a print run.

Two neighbours get confused with it. The Swiss QR-bill is a different specification with a Swiss cross in the middle, and euro-area apps won't read it as a payment. A card processor's payment link is just a URL in a QR with a hosted checkout at the end, and it tracks like any web link.

For the wider question of what a regulated payments or lending business can put in front of customers, URL shorteners for fintech covers the parts where a link is involved.

A payment QR code decoded offline into a transfer form compared with a link QR code that reaches a redirect and produces analytics

Can You Make One With Elido?

Not as a dedicated feature.

Checked in the code on 2026-10-25: the free QR generator tool has six content types (URL, text, Wi-Fi, vCard, email, SMS), and none is an EPC or payment type. The dashboard QR designer takes a single-line content field, so it can't hold a multi-line payload at all.

The workaround is the free tool's Text type, which has a multi-line box and passes your text through unchanged. Paste the twelve lines, keep error correction on M (the tool's default), and download the PNG or SVG. Two cautions. There's no validation, so a wrong IBAN or an extra trailing line break produces a code that looks fine and fails in the bank app. And it's a static code with no tracking, which is exactly what a payment code should be. A real EPC type with IBAN checking is on our backlog.

Producing One Without Regret

Six checks, in the order they save you money.

  1. Validate the IBAN before generation, not after printing. A checksum test costs nothing and a reprint costs a run.
  2. Decide the amount question deliberately. Fixed for invoices, empty for donation posters where any figure should be possible.
  3. Prefer the structured reference over free text. It is shorter, it reconciles automatically in your accounting, and it keeps the payload small.
  4. Test in at least three banking apps, on both phone platforms. Parsers differ in how strictly they treat the optional fields.
  5. Size the printed code for the distance it will be scanned from, exactly as with any other code. How big a QR code should be has the arithmetic.
  6. Keep it matte. Gloss varnish under office lighting causes glare and failed scans.

The Sticker Problem

There is one real fraud vector, and it is physical rather than digital. A static payment code printed on an invoice, a parking meter, a market stall sign or a charity poster can be covered with a sticker carrying a different IBAN. Nothing in the code can resist that, because the payload is the paper, and it doesn't check anything.

The mitigations are equally physical. Print the code inside the invoice layout where a label would be obvious, rather than on an adhesive patch. Show the beneficiary name and the last digits of the IBAN in text next to the code, so a payer can compare. And in the payment confirmation instructions, tell people to read the name their banking app displays before they confirm, because that screen is the only place the swap becomes visible. Are QR codes safe, and what quishing actually is covers the broader attack pattern, most of which does apply to the link codes you print elsewhere on the same page.

The reassuring part is that a payment still needs a human to confirm it in an authenticated banking app. The code prefills a form, it never moves money. For how a bank should govern the other codes it prints around a payment code, see the fintech and banking section of the URL shorteners for fintech guide linked below.

For the printed workflow around any code, see a QR code campaign from scratch. The QR code guide in the docs covers the trackable kind.

Frequently asked questions

What is an EPC QR code?

A QR code that encodes the details of a SEPA credit transfer as plain text, so a banking app can read it and prefill the transfer form. It was standardised by the European Payments Council in the EPC069-12 guidelines and is also known as a GiroCode. The payload is a fixed sequence of lines starting with the service tag BCD, and it contains no web address at all.

Which countries support GiroCode payments?

Support sits in the banking app, not the country. The EPC says the scheme is optional for banks, and Wikipedia lists Austria, Belgium, Finland, Germany, the Netherlands, Luxembourg, Estonia, Latvia, Lithuania and Italy as places where the codes are commonly used (accessed 2026-10-25). We have not tested individual apps, so test yours. Outside the euro area the code is meaningless. Switzerland uses its own QR-bill standard, which looks similar and is not compatible.

Can an EPC QR code be dynamic or trackable?

No. The payment details are inside the printed pattern, and the phone decodes them offline without contacting any server, so there is nothing to redirect and nothing to count. If you need to change the amount or the reference, you generate a new code. Anything sold to you as a dynamic payment QR is a link to a payment page, which is a different product.

What happens if I put a short link in an EPC QR code?

The banking app fails to parse it and either shows an error or falls back to treating the code as an ordinary URL. The parser expects the first line to be BCD and the fourth to be SCT; a URL matches neither. Payment QR codes and link QR codes are two separate codes that happen to share a symbol shape.

How big can the payload be?

331 bytes, which caps the QR at version 13 with error correction level M under the EPC guidelines. In practice the remittance text is what fills it, so a long free-text reference is the field that pushes a code over the limit. Keep the reference structured and short and the code stays sparse enough to scan from a printed invoice.

Are payment QR codes safe on printed invoices?

The code itself carries no executable content, and the payer confirms the transfer in their banking app, which shows the beneficiary name and IBAN before anything moves. The real risk is physical: a sticker placed over the printed code redirecting the payment to another account. Print the code inside the invoice layout, not on a label, and tell payers to check the name on the confirmation screen.

Try Elido

Paste a URL, get a working short link

No signup. Link lives for 30 days. Sign up to keep it forever.

Free account required. The free plan includes 25 links in total. Already have an account? Log in

Try Elido

EU-hosted URL shortener with custom domains, deep analytics, and an open API. Free tier - no credit card.

Tags
epc qr code
girocode
sepa payment qr code
qr code payment
static qr code
invoice qr code

Continue reading