Paying with Bangla QR on a Single Phone | Discussion Paper

Summary

Bangla QR is now mandatory and interoperable. It was built for one situation: a customer points a phone camera at a code displayed somewhere else. When a customer shops on a phone, the code appears on the same phone that holds the payer app. The camera cannot scan its own screen, and the payment stalls.

This paper proposes one small addition to the standard: a payment link that carries the existing Bangla QR string. A tap on the link opens a payer app, which reads the string with the parser it already has. India's UPI solved the same problem the same way. We also propose minimum safety rules for the link and a conformance test run by the Implementation Unit.

Plain terms

URI scheme: The first word of a link, before the colon. In banglaqr://pay the scheme is banglaqr. An app tells the phone which schemes it can open.
Deep link: A link that opens a specific screen inside an app, not just the app.
Chooser: The list a phone shows when more than one app can open a link. The customer picks one.
CRC: A short check code at the end of the Bangla QR string. If any character changes, the code no longer matches, and the app rejects the string.

1. The problem

Many Bangladeshi internet users own a single device, a smartphone. On that device, a merchant website or app can display a Bangla QR, and the payer's bank or MFS app is installed on the same phone. The customer has no way to feed one to the other:

The camera cannot scan the screen that is running the scanner.
A screenshot can sometimes be imported from the gallery, but that depends on each app offering the feature, and customers are not told to look for it.
The only remaining route is a second device, which this customer does not have.

A camera needs a code on another surface. One phone cannot give it one.

The result is a payment method that works at a shop counter and fails where digital commerce is growing: mobile web and in-app checkout. The same gap is likely to appear in person-to-person payments, which Bangladesh Bank has planned to introduce through Bangla QR.

This paper does not quote a figure for single-device users or abandoned checkouts. Bangladesh Bank and the scheme operators hold the transaction data that would size the problem, and we ask them to measure it.

2. Where Bangla QR stands today

Bangladesh Bank circular PSD-1 No. 01 of 1 April 2026 requires banks, MFS providers, PSPs and PSOs to replace proprietary merchant QR codes with Bangla QR by 30 June 2026, with penalties up to Tk 30 lakh. One regulator already reaches every payer and acquirer.
Banks and MFS apps have been directed to keep Bangla QR visible on their app homepages. Payer apps are therefore expected to read Bangla QR already, so a link only needs to hand them a string.
The specification is based on the EMV Merchant-Presented QR Code Specification. The payload is a standard machine-readable string with a checksum, merchant name, amount and reference fields.
The Cashless Bangladesh Unit was renamed the Bangla QR Implementation Unit, and instant settlement and zero interchange have been set by directive. A body exists to issue and maintain operating rules.
Person-to-person Bangla QR was planned from 1 November 2026, which widens the gap.

We searched published circulars and press coverage for any link, URI scheme or same-device provision in the standard and found none. We have not seen the full technical specification, so this is an absence of evidence, not proof. The Implementation Unit will know whether such a provision exists.

3. A precedent

India's UPI faced the same constraint. Its merchants present a link of the form upi://pay?pa=...&am=... in addition to a QR. When a customer taps it on an Android phone, the operating system lists every installed app that registered for the upi scheme. The customer picks an app, the app opens on its confirmation screen, and the customer approves. No camera is involved and no app is favoured. The mechanism is ordinary mobile-operating-system behaviour. It needs the scheme agreed once, and each app to register for it.

4. The proposal

4.1 A payment link that wraps the existing string

banglaqr://pay?v=1&d=<percent-encoded EMV QR string>

v is the link version.
d is the complete Bangla QR string, including its checksum, unchanged.
Static and dynamic codes are both supported. A dynamic code carries the amount and an order reference.

Four parts. The payload is the string a camera scan would have read.

4.2 An HTTPS equivalent

A custom scheme works well on Android, where the system offers a chooser. iOS has no chooser for custom schemes, and when more than one app claims a scheme the app that opens is not reliable. For iOS and for browsers that block custom schemes, define an HTTPS form of the same link on a domain designated by the Implementation Unit, which each payer app can verify. On desktop the existing QR remains the path.

4.3 What a payer app does with the link

Receive the link and extract d.
Pass it into the same reader used for camera scans and verify the checksum.
Show the confirmation screen with the merchant name and amount decoded from the string.
Require the customer's normal authentication before any money moves.

The flow, step by step

The same sequence, as it runs on one phone from the merchant checkout to the order match.

The flow on one phone, from the merchant checkout to the order match.

The same eight steps as text:

Merchant page. Mobile checkout shows the link
Tap Pay with Bangla QR. No camera needed
Phone lists payer apps. Apps that registered the scheme
Customer picks an app. Bank or MFS app opens
Confirm screen. Merchant and amount from the string
Customer authenticates. PIN, biometric or OTP
Payment. Same controls as a camera scan
Merchant notified. Order reference matches the order

What the payer app decides

The app applies the checks it already applies to a camera scan. Three failures end in an error screen. Extra parameters are not a failure: they are ignored.

Three things end in an error screen. Everything else follows the normal scan path.

What each phone does with the link

A chooser is the system list that asks which app should handle a link.

Who does what

Each party does a small, separate piece.

Implementer's checklist

Short, testable items for each party. Each one can be checked yes or no.

Bangladesh Bank and the Implementation Unit

The specification names the scheme and the version, for example banglaqr and v=1.
The specification names the HTTPS domain and the body that runs it.
The five test cases below are published, with the expected result for each.
A date is set by which every bank and MFS app must accept the link.
A list of apps that pass the conformance test is public and kept current.

Payer app developers

The app registers the scheme with the phone, and also the HTTPS link for iOS.
The link hands d to the same parser the camera scan uses, with no second parser.
The CRC is checked before anything is shown.
Merchant name and amount on screen come from d, never from other text in the link.
Parameters other than v and d are ignored.
No payment starts before the customer authenticates.
All five test cases below pass.

Merchants and gateways

The link and the QR are built from one Bangla QR string, so they cannot disagree.
d is percent-encoded, which means special characters are written as % codes.
A dynamic code carries the order reference, and the payment notification returns it.
Mobile checkout shows the link first, then the share sheet, then Save QR.
Desktop checkout shows the QR.
A customer who leaves checkout and comes back is matched to their order by the reference.

Test cases

Five links every payer app should pass before release. The expected result is the same for every app.

Test cases and the expected payer app behaviour
Case	Input	Expected behaviour
Valid link	A correct link with a good CRC.	Confirm screen shows the merchant name and amount from d. No payment until the customer authenticates.
Bad CRC	A link whose last four characters of d are wrong.	Rejected. Error screen. No merchant or amount shown as payable.
Tampered amount	The amount inside d is changed and the CRC is left as it was.	The CRC no longer matches. Rejected with an error screen.
Extra parameter	A valid link with &am=1 added to the end.	The extra parameter is ignored. The confirm screen shows the amount from d only.
Not a Bangla QR payload	d holds a web address or another kind of QR text.	Rejected as not Bangla QR. Error screen. Nothing is opened or paid.

5. Safety rules

Never pay automatically. A link only opens a confirmation screen.
Show what was decoded. Merchant name and amount come from the string, not from text in the link.
Verify the checksum and reject any string that fails it or has contradictory fields.
Ignore any parameter other than v and d.
Apply every control a camera scan applies, including cash-out and merchant-category checks.

Because the rules match a camera scan, the link adds a new way to deliver the string and no new way to move money.

6. Fallbacks while adoption is incomplete

Until every app supports the link, merchants and gateways can offer a chain on mobile: try the link, then the system share sheet, then a Save QR button with instructions to use the app's gallery import. This reduces failures but cannot remove them, because it depends on features each app may or may not have. It is a bridge, not a solution.

7. What we ask of Bangladesh Bank

Adopt a standard payment link for Bangla QR, in this form or an improved one, published as part of the specification.
Require every bank and MFS app to accept it, together with gallery import and pasted payloads, by a set date, as was done for homepage visibility.
Make the safety rules in section 5 mandatory for any app that accepts the link.
Confirm the payment-reference path: dynamic codes carry an order reference in the standard bill-number or reference field, and the payment notification returns it, so a customer who leaves checkout and comes back is matched to their order.
Run a conformance test and sandbox through the Implementation Unit, and publish the list of apps that pass.
Measure the problem: the share of Bangla QR attempts on mobile checkouts that are abandoned before completion.

8. Open questions for the regulator

Does the current technical specification already define a link or same-device provision that we have not seen?
Should the HTTPS form live on a domain run by Bangladesh Bank, the scheme operator, or a neutral body?
What lead time should apps be given before the link becomes mandatory?
Should offline operation, which Bangladesh Bank is reportedly working on, be considered in the same revision?

9. Our offer

KaritKarma will prepare a reference implementation: a link builder, a test page that exercises each fallback, and a short payer-side guide for parsing the link. We will publish it openly for any bank, MFS or gateway, and contribute it to a pilot with the apps and the Implementation Unit the regulator chooses.

Sources

Dates and directives are as reported in the sources above and should be confirmed against the primary circulars.