QR-first acceptance
Dynamic QRs, static QRs, EMVCo standard, PIX native, UPI via licensed partners, and pay-link QRs — all issued through one API and reconciled into one ledger alongside card, ACH and wallet receipts.
Key benefits
Four properties that show up the moment QR stops being a bolt-on and becomes part of the merchant's unified acceptance stack.
Dynamic QR (amount and reference baked in), static QR (reusable — tips, donations, table counter), and hosted pay-link QR. The merchant issues them through the same /v1/qrs endpoint and reads the same webhook stream on completion.
EMVCo Merchant-Presented QR standard, PIX QR (Brazil), UPI QR (India, via licensed partner gateways), plus proprietary pay-link QRs. The buyer's banking or wallet app already knows how to scan them.
A QR-paid receipt lands in the same ledger as an online authorisation or a POS terminal capture. Refunds, disputes and recurring renewals reference the same vault token.
Show the QR on a terminal screen, a laptop, a printed table tent, a poster — or share it as an image in a chat message. Detection and capture logic don't care where the QR was rendered.
How the qr code for payment link flow runs
What actually happens between the merchant calling the QR endpoint and the buyer's payment closing out in the merchant's ledger.
The merchant calls POST /v1/qrs with amount (dynamic) or leaves it null (static), currency, expiry and reference. The response returns a rendered PNG / SVG plus the raw payload string.
Display on-screen, print on a receipt or poster, or share as an image. Static QRs can be reused indefinitely; dynamic QRs expire on the configured window.
The buyer's banking app, wallet or dedicated payment app scans the QR. For EMVCo QRs the buyer's app handles the message-format negotiation; for pay-link QRs it opens the hosted pay-link surface.
The chosen rail carries the authorisation (card via connected acquirer, PIX via partner, UPI via partner gateway). The vault token issued on success carries into the merchant's ledger for later refund or recurring.
The webhook fires with QR ID, buyer's rail, amount and vault token reference. The merchant's ops surface reflects the paid state in real time.
Main use cases
Six recurring merchant shapes for QR — retail counter, restaurant tableside, donations, events, invoicing and PIX / UPI-native buyer segments.
Static counter QR replaces a card terminal for lower-ticket sales; buyer scans, pays via their banking app, receipt clears in real time. Reserved for markets where QR-native payment is dominant.
Dynamic QR per table with the bill amount baked in. Multiple diners can split by paying against sibling QRs; the merchant sees each payment as a separate receipt tagged to the same table.
Static QR on a poster, table tent or receipt drives donations or tips. Amount is left to the buyer's app or defaulted via the QR payload.
Vendor stalls display printed dynamic QRs per SKU or a static QR that opens a hosted amount-entry page. No terminal hardware to ship.
Invoices carry a hosted pay-link QR alongside the URL — buyers on mobile can pay by scanning the QR from the printed PDF rather than typing the URL.
Brazil (PIX) and India (UPI, via licensed partner gateways) accept QR-native buyer flows as first-class rails on the platform.
Platform features
Twelve capabilities the platform ships once and reuses across every QR flow — QR issuance, scheme compliance, receipt handling and reconciliation.
One endpoint issues both; static QRs are reusable, dynamic QRs carry per-transaction amount and reference.
The industry-standard merchant-presented QR format decoded by every major banking / wallet app.
Native PIX QR issuance with copy-paste-key fallback; receipts settle to the merchant's Brazilian settlement account.
UPI QR issuance for Indian buyers via licensed partner gateways; the merchant doesn't need a direct RBI PA licence.
Any topropay hosted pay link can render as a QR — scan to open the branded checkout on the buyer's device.
Rendered image assets plus the raw QR payload string for embedding in receipts, posters or apps.
Optional brand-safe logo overlay and colour tint on the QR, within EMVCo error-correction tolerances.
Dynamic QRs expire on the configured window; single-use QRs invalidate after the first successful authorisation.
QR-created, QR-viewed (where the buyer app pings back), QR-paid and QR-expired events with replay-safe IDs.
Successful QR payments issue a vault token identical to those from other channels; usable for refunds and recurring.
QR-paid receipts feed the same dispute queue as card, ACH and online; evidence packs support QR-specific metadata.
QR receipts normalised into the same ledger as card, ACH and wallet; tagged by rail, QR type and QR ID.
Trust & compliance
One audited orchestration environment plus rail-specific compliance from partner gateways where PIX and UPI QRs are delivered.
Ready to add QR to your stack
A 30-minute review covers the QR shapes relevant to your buyer geographies (EMVCo, PIX, UPI, pay-link), the flows most likely to shift volume onto QR, and a sandbox to test against before any commercial commitment.
Frequently asked
Definitions, single-use vs reusable mechanics, refund flows, security, and the practicalities of running QR alongside card, ACH and online receipts.
The qr code payment system on topropay delivers dynamic and static QR issuance, EMVCo Merchant-Presented QR compliance, PIX-native and UPI-native QR (via licensed partner gateways) and hosted-pay-link QR. Every QR-driven authorisation feeds into the same vault, reconciliation feed and dispute queue as card, ACH and online receipts.
A qr payment system moves the acceptance surface from the merchant's device to the buyer's device. The buyer scans, their banking or wallet app negotiates the message flow with the rail, and the merchant receives a signed webhook on success. There's no physical card presentment and no merchant-side terminal cryptogram — the security model lives inside the buyer's app.
qr code for payment link on topropay wraps any hosted pay link as a QR. The merchant issues a pay link with amount, currency and optional reference; the platform renders the QR pointing to the same URL. Buyers scan with any QR-capable camera app, land on the branded pay page, and complete the transaction on the buyer's device.
A qr code payment link can be either. Single-use QRs invalidate after the first successful authorisation, which is the safe default for per-transaction billing. Reusable QRs stay live until the merchant explicitly expires them — useful for donations, tip jars, table counters and static-poster campaigns.
A qr code payment solution for multi-store retail typically pairs static counter QRs (one per till) with dynamic per-transaction QRs on the terminal screen for higher-ticket sales. Reconciliation feeds tag each receipt with store ID, till ID and QR ID; head office reads one ledger across the estate.
The qr code mobile payment system works with any wallet or banking app that scans EMVCo Merchant-Presented QRs, plus PIX-capable apps in Brazil and UPI-capable apps in India (via partner gateways). Pay-link QRs work with any QR-capable camera app — the URL opens the buyer's default browser, which then renders the hosted pay page.
QR payloads for EMVCo QRs carry rail-specific integrity fields defined by the scheme. Hosted-pay-link QRs point to HTTPS URLs whose Referer and origin the platform validates on load. Amount tampering isn't possible on dynamic QRs — the amount lives inside the signed payload and is validated on the rail side.
Refunds run against the vault token the QR authorisation produced. For card-backed QR authorisations the refund reverses through the connected acquirer that carried the original; for PIX or UPI-backed authorisations the refund runs through the partner rail's own reversal flow. In both cases the merchant triggers it from the same dashboard as any other refund.
Yes. Dynamic QRs bake the exact amount, currency and reference into the payload. Multi-currency merchants issue QRs in the buyer's expected currency; conversion (if applicable) is handled on the rail or the buyer's app side, not on the merchant's.
Where the QR flow supports scan-time telemetry (some rails and hosted pay-link QRs), the merchant sees a QR-viewed webhook. Abandoned scans surface separately from failed authorisations, so ops can distinguish 'buyer walked away' from 'authorisation declined'.
EMVCo QRs support four error-correction levels. The platform defaults to level M (~15% correction), which is safe for both screen and clean print. Level H (~30% correction) is available for logo overlays or noisy print environments; the trade-off is a physically larger QR at the same data payload.
Yes. PIX and UPI QRs (the latter delivered via licensed partner gateways) surface in the same dashboard as card-backed QRs. Reconciliation tags each row with the rail that cleared the payment; the merchant reads one ledger across every QR channel.
QR-payment integration on topropay is typically 1–2 weeks — most of the work is on the merchant's UI to render the returned QR image and consume the webhook. The QR issuance endpoint is a normal REST call; the platform-side plumbing (routing, vault, reconciliation) already runs behind the merchant's existing integration.
Both buyers open the same hosted pay page and each completes their own transaction. The platform issues separate authorisations and separate vault tokens; the merchant's ops see two receipts, both tagged with the same static QR ID.
QR-payment is dominant in Brazil (PIX), India (UPI), China (Alipay / WeChat Pay via partner), and increasingly in the EU as EMVCo QR gains regulator support. In the US and UK, QR remains a niche channel — most volume runs through card or wallet — but the same platform supports it where merchants want to offer it.
Related