Q&A from July 29, 2025 webinar
X9 recently hosted a webinar highlighting the QR Code payments standard being developed by the X9A4 workgroup. The session featured a live demo showing how an invoice could be paid instantly through FedNow by simply scanning a QR code in the Star One mobile app.
The discussion sparked many great questions. We’ve compiled answers to all of them—explore the full Q&A below.
Want to see another live demo in action? Watch here as Matera demonstrates a QR payment sent over the FedNow network alongside Star One Credit Union and Payfinia.
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 encodes a static web address meant to be opened in a browser. These are easy to spoof, since a fraudster can replace the code with one that redirects to a malicious site.
By contrast, an X9 Payment QR Code contains structured, EMV-formatted payment data designed to be scanned by a trusted banking app or wallet — not a browser. While it may include a URL reference, the app retrieves and validates the payment data securely, preserving integrity and preventing tampering.
2) I frequently use a QR code on a restaurant bill to pay for a meal. Is that different 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.
3) 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.
4) 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.
5) Would any fees involved be up to the bank?
Yes, based on the services they offer. 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.
6) 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.
7) 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.
8) Why do we need a status of the QR Code and for what?
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.
9) Could the digital signatures use existing private/pubilc keys like Apple - specifically 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.
10) Could this be used for ACH and push-to-card as well?
Yes, while the standard is optimized for instant payments and digital currencies it’s rail-agnostic. It can also support ACH credit push and push-to-card payments, depending on what the payer’s PSP supports.
11) 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.
12) What are the true costs of generating a QR code?
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.
13) 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.
14) 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.
15) 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.
16) 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.
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, digital assets, 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.