Q&A from July 29, 2025 webinar
1) Is there a way to tell a Payment QR code from a URL QR Code
Yes, and the differences are important, especially from a security standpoint.
A typical URL QR Code simply encodes a static web address (e.g. https://example.com) and is designed to be scanned by a mobile phone camera. These are often used for marketing, menus, or links to checkout pages. However, they’re also easily spoofed, since a fraudster can substitute a QR Code that redirects the user to a malicious or counterfeit site.
In contrast, the X9 Payment QR Code contains structured EMV-formatted data, not just a URL. It includes fields like merchant name, city, amount and currency and is meant to be scanned by a trusted payment app or wallet, not a browser. If scanned from a mobile app, this ensures the code can’t be tampered with or redirected without detection.
That said, a Payment QR Code may contain a URL — but it's not a redirect link. It's a reference to a secure, hosted payment payload, which the app retrieves and validates using cryptographic methods. This adds flexibility while maintaining end-to-end integrity and trust.
2) Can the payment QR code be stored in a database?
Yes. Both the data in the Payment QR Code string (the EMV-formatted data encoded in the QR image) and the associated Payload data it points to can be stored in a database. This is useful for tracking payment status or managing expiration logic.
3) Would QR codes be a potential solution to solve for directory (alias based payments)? Scan my qr code and make a payment to me... or for a specific funding (such as taking up a collection for a baby shower)
Yes, QR Codes are well-suited for these kinds of use cases. The X9 QR Code could be presented in a mobile app (by a payee) that someone else (the payer) can scan and pay. The payee’s account in the QR code could be their real account number or an alias.
For the baby shower use case, a dynamic QR code could be generated for each contributor so that it’s easier to keep track of who paid and when which helps avoid confusion or duplicate payments.
4) What are we talking about QR Code? The QR Code is just a channel to transport data. Several kinds of protocols/data can be transported by QR code. You cannot initiate the execution of a payment with QR Code indeed
That’s absolutely correct. A QR Code by itself doesn’t initiate a payment. It simply encodes data. In the case of the X9 standard, the QR Code transports structured EMV data that includes a reference to a hosted payload which contains the payment request details.
What makes this powerful is what happens after the QR Code is scanned:
- A payment app or digital wallet parses the QR Code data;
- It retrieves the associated payload (e.g. amount, payee info, digital signature);
- Then it uses that information to initiate a credit push payment (e.g. via FedNow, RTP, ACH, or push-to-card).
So you're right, the QR Code is just the starting point. The real value lies in how the ecosystem uses it to securely initiate payments with standardized data
5) Do you think really the QR Code is the adapted channel to do payment at POI? The user experience is less than with NFC channel for example for cards.
It’s true that in environments where NFC is already widespread and supported by both consumers and merchants, it can offer a very fast and seamless experience. But QR Codes solve some different, and very practical, problems.
- They work without merchant hardware. With QR Codes, merchants don’t need contactless terminals — just a screen or printed code. This dramatically lowers the barrier to accepting digital payments, especially for SMBs and billers.
- They’re payment network-agnostic. QR Codes can support instant payments like FedNow or RTP, or ACH credit push, not just card rails, creating opportunities to speed up settlement.
- They support richer data. A QR Code can embed or point to structured data like invoice numbers, line items, or tips, enabling more flexible payment flows than a card tap.
So while QR Codes may not replace NFC for every use case, they’re a powerful tool for enabling digital payments at the POI, especially where cost, infrastructure, or payment method diversity are key factors.
6) I don't see any "networks" involved in the debit transaction. Would any fees involved be up to the bank? If service was provided.
Great observation. Unlike card transactions, which flow through card networks, the payment flows supported by the QR Code standard are based on credit-push models over networks like FedNow, RTP, ACH credit push, or push-to-card rails.
In these models:
- The payer initiates the payment via their bank or wallet;
- The payment is sent directly to the payee’s financial account;
- Banks and service providers may still charge fees for services like transaction processing, hosting payloads, or providing fraud controls.
So yes, any fees are determined by the financial institutions involved, based on the services they offer.
7) How do you see the potential in Europe, especially given the consolidation in the wallets space (Wero, EuroPa)? Does the technology work in SEPA instant rails?
Technically, yes, the QR Code standard is rail-agnostic and fully capable of supporting payments over SEPA Instant. The payload can carry the necessary payment instruction details, and the payer’s app or wallet can initiate a SEPA Instant credit transfer once the QR Code is scanned.
The bigger question is about ecosystem alignment. With initiatives like Wero and European Payments Initiative (EPI) aiming to consolidate wallets and payment experiences across Europe, there’s real momentum, but also a need for alignment on formats, branding, and QR Code parsing logic.
That said, QR Codes are already well understood across Europe (e.g. in Switzerland, the Netherlands, and Nordic countries), and with the right coordination, the same technology stack could absolutely be used to support interoperable instant payments across the EU.
8) Seems like a killer app for consumer adoption of FedNow and/or Stablecoins as a payment option.
Absolutely. FedNow and stablecoins both offer faster, cheaper payment rails, but what’s been missing is a unified, user-friendly front end that lets consumers and businesses actually use those rails at checkout, for bill pay, or peer-to-peer. QR Codes provide that - a familiar and simple way to trigger a structured payment over any supported rail.
9) Does this eliminate the need for a directory model?
A directory is still helpful, but payment QR Codes don’t rely on the existence of a directory to work.
Scanning a QR code could trigger a payment to an alias rather than an account number. In that case, the QR Code becomes a delivery channel, and the directory still plays a role in resolving the final destination.
10) What is the expected role of instant payment rails like Fed/TCH in this payment flow?
FedNow and RTP serve as the settlement layer - they move the money after a payment is initiated. The QR Code itself doesn’t move funds; it simply carries the data needed to trigger a payment.
Once the QR Code is scanned, the payer’s app reads the payload and uses that information to initiate a payment over an instant rail like FedNow or RTP. Those networks then handle real-time clearing and settlement between financial institutions.
11) Why do we need to reinvent an EMV pull transaction for cards with QR Code?
To support direct bank payments, not just card transactions
12) In the artifacts provided by the working team, are there best practices or suggestions on how to identify QR codes that are perhaps compromised or someone taking a short cut?
Yes. The QR Code includes a CRC checksum to detect basic corruption or tampering at the EMV level, plus a digital signature to verify authenticity. The payer’s app can also validate the linked payload to ensure it came from a trusted source.
While the standard doesn’t prescribe fraud rules, it enables PSPs to add checks like timestamp validation, QR Code reuse prevention, and anomaly detection.
13) Is there an ISO message to request generation of a QR Code? For example, to be used by a PSP client to request a QR Code from that PSP (as a service provided by the PSP).
Not today. And, the X9 standard doesn’t define how a merchant requests a QR Code from their PSP. This is typically handled via proprietary APIs or service agreements between the merchant/client and PSP.
14) Don't we have confusion between QR Code and the data content? Why do we need a status of the QR Code and for what?
That’s a great point, and yes, it’s important to distinguish between the QR Code itself and the payment request it represents.
There’s the encoded EMV-formatted QR Code string. When scanned, it points to a hosted payload which contains the full details of the payment request - things like amount, merchant, payment reference, and more.
The QR Code status doesn’t refer to the QR Code string or image itself — it refers to the lifecycle of the payment request tied to that QR Code. There are 4 possible statuses for QR Codes in the X9 standard.
- Active - QR Code is available for payment
- Initiated - Payment has been triggered; QR Code is now locked
- Paid - Payment has been successfully completed.
- Cancelled - The QR Code was cancelled by the payee or payee’s PSP
Tracking QR Code status helps:
- Prevent duplicate payments,
- Support reconciliation and error handling,
- And ensure a clean, consistent user experience.
The QR Code status is dynamic, and tied to the backend logic managing the payment lifecycle.
15) Could the digital signatures use existing private/pubilc keys like Apple - like Apple's Passkeys.
No, not for this use case. The X9 QR Code standard relies on digital certificates issued by the X9 Financial PKI.
Apple’s Passkeys (and similar platform-specific keys) are designed for device-level authentication within a closed ecosystem. They’re not intended to be portable, verifiable, or anchored to a financial institution’s identity across a multi-party network.
In contrast, in this X9 standard, signatures are meant to support interoperable, cryptographically verifiable trust between payers, payees, and their PSPs, which requires an industry-backed, standards-compliant PKI.
16) Today an ISO20022 message camt.054 for payment notification has no signature data in it!
That’s correct. The ISO camt.054 message wasn’t designed with built-in cryptographic signatures. It’s typically used for reporting (e.g. a credit posted to an account), and assumes that trust is managed within a closed banking environment.
In contrast, the payment notification in this X9 standard is used for real-time confirmation between two PSPs in a more open and dynamic flow where the payee’s PSP needs a way to verify that the notification is authentic, untampered, and traceable to a known source.
That’s why this standard introduces an HTTP message signature for the payment notification, using digital signatures and key material bound to the PSP’s identity. It’s a secure way to ensure integrity and non-repudiation across PSPs, which ISO camt.054 alone doesn’t provide.
17) What is the adoption rate of the banks for QR code-initiated payments? (using X9 standards)?
The X9 QR Code standard is still in the finalization phase, so formal adoption by banks is just beginning. That said, there is strong interest and early engagement from financial institutions, payment service providers, and networks looking to support QR Code-initiated payments.
18) It seems that this is primarily for instant payments which seems great, but I thought I heard that it could be used for ACH network and push-to-card as well?
Yes, while the standard is optimized for instant payments like FedNow and RTP, it’s rail-agnostic. It can also support ACH credit push and push-to-card payments, depending on what the payer’s PSP supports.
19) I frequently use a QR code on a restaurant bill to pay for a meal. Is that different in some way? Is the x9 standard new/different/better in some way?
Yes, most QR Codes used in restaurants today are proprietary, meaning they’re built by a single provider (like Toast, Square, or PayPal). They only work within that app ecosystem and often point to a URL for card-based payments.
The X9 payment QR Code standard is different - it’s designed to be interoperable and rail-agnostic, meaning any participating bank, wallet, or app can scan and process the payment - over FedNow, RTP, ACH credit push, or push-to-card - not just card rails.
So while today’s QR code payment experiences are convenient, they’re typically closed-loop and limited to specific providers. The X9 standard enables a broader, open ecosystem where QR Codes can trigger secure, real-time payments across banks and payment types.
20) In nexo standards, we are working hard to manage the acceptance of instant credit transfer seamlessly to take into account all the use cases we can find.
That’s great to hear. Nexo and X9 are aligned in many ways. Both aim to support seamless, secure acceptance of credit transfers at the point of interaction, especially as instant payments grow globally.
The X9 standard is focused specifically on the U.S. ecosystem, and is designed to:
- Support multiple rails (FedNow, RTP, ACH credit push, push-to-card),
- Embed rich structured data using an EMV-compliant QR Code format,
- And enable secure, interoperable payments initiated via scan.
We see efforts like nexo and X9 as complementary, working toward the same goal: making real-time account-based payments as seamless and trusted as card payments across borders and use cases.
21) Do you think that the big interchange fees for the issuers on card payments impact (negatively) the banks adoption of real-time payments?
In some cases, yes. For banks that earn significant interchange revenue from card payments, there can be hesitation to fully embrace real-time payments, especially if the alternative doesn’t offer a clear revenue stream.
But it's not the whole story. Many banks are now seeing real-time payments as a strategic opportunity:
- To reduce acceptance costs for merchants
- To offer new revenue-generating services (e.g. instant bill pay, account-based checkout);
- And to defend deposit relationships by being at the center of fast, digital money movement.
So while interchange economics may slow adoption for some, new business models will likely emerge around QR code - initiated instant payments that make it very attractive for the broader payments ecosystem.
22) Do you think it will take the adoption to 3rd party service providers prior to this technology taking off?
Third-party service providers will definitely help accelerate adoption, especially by making it easier for merchants, billers, and platforms to integrate QR code-initiated payments without building everything from scratch.
In reality, it will take both, banks laying the foundation, and third-party providers helping scale and simplify it for the broader market.
23) On the question of "economics" of a QR code. What are the true costs of generating a QR code? I would be surprised if it is anything but de minimus. I'm asking this at a very basic level separate from any sort of an acquiring relationship.
To generate QR Codes securely, dynamically, and at scale, especially with payload signing, hosting, lifecycle management, and compliance with the X9 standard, you need enterprise-grade software and infrastructure.
That’s where real cost and value come in, and where providers may charge for QR Code generation as part of a broader payment or orchestration service.
24) How do you anticipate consumer behavioral adoption?
When QR Codes are embedded into everyday experiences with clear value, consumers will adapt quickly.
Ultimately, consumer adoption will grow as banks and wallets make “scan to pay” easy and rewarding, and as more merchants accept QR Code based payments as a mainstream option - just like in Brazil, India, or China.
25) What is the typical (high level) scope of build required by the PSPs?
At a high level, PSPs need to build three core components:
- QR Code Generation – Accept input (e.g. amount, reference), generate a signed payload, and return the QR Code string.
- Payload Hosting – Host the payload at a secure endpoint, manage its status (active, initiated, paid, cancelled), and enforce expiration logic.
- Notification Handling – Receive and verify signed payment notifications from the payer’s PSP, and update status.
Optional features may include merchant APIs, fraud checks, and dashboard tools — but the core is secure generation, hosting, and confirmation.