Scan to Pay — scoping a camera-first payment flow

Context

A request for a "scan to pay" feature in the banking app. The phrase covers two genuinely different products, and the request did not specify which.

• Bill capture — point the camera at a paper bill, extract the biller code and reference number, pre-fill the payment.
• Live QR code scanning — point the camera at a merchant's QR code and complete a payment at the point of sale.

These share a camera and almost nothing else. Different payment rails, different failure modes, different error handling, different regulatory footprint, different partners.

The most useful work was scoping

Before any screens, I resolved which of the two was actually in scope and got that agreed. Ambiguity of this kind is cheap to resolve at the start and expensive at any later point — a flow designed for one and built for the other fails in ways that are not obvious until integration.

Camera-first design

The flow puts the camera first rather than presenting a menu that leads to a camera. Scanning is the task; anything preceding it is overhead on a job the customer is standing there trying to complete.

That decision moves the design difficulty into the states around the camera:

• Permission — what the customer sees before granting camera access, and the path back if they previously refused
• Guidance — how the viewfinder communicates what to aim at without a tutorial
• Failure — poor lighting, crumpled paper, unreadable or unsupported codes, partial capture
• Verification — what is shown after a successful read, before money moves

The customer is confirming a transaction based on something a machine read for them. The extracted values have to be checkable at a glance.