TapQR

Payment infrastructure for merchants who were never the customer

Self-initiated. Solo. Live web product at tapqr.live with a public frontend and backend repository. The NFC hardware, the soundbox and the AI layer described in section 10 are roadmap, not built. No merchant traction figures exist and none are claimed here.

---

01 · Context

India solved the consumer side of digital payments and then largely stopped.

UPI made paying trivial. A customer opens any one of a dozen apps, points a camera at a printed square, types an amount, and the money moves in about two seconds at no cost to either party. That is a genuinely world-class piece of public infrastructure, and it is now so normal that a vegetable seller with a laminated QR code taped to a crate is unremarkable.

TapQR started from a question about the other side of that transaction. The customer's experience is finished. The merchant's experience barely started.

I built it as my own project, alongside freelance and client work, with no team and no funding. That constraint shaped almost every decision in this case study, and it is worth stating at the top rather than discovering in the postmortem.

02 · Problem

A merchant using a printed UPI QR code has a payment rail and nothing else.

Concretely, the gaps I kept returning to:

The code is static. It is a printed URI. It cannot be rotated, expired, disabled, tied to a specific till, or reassigned when a shop changes hands. A physical sticker in a public place is a permanent, unrevocable credential.

Confirmation is fragmented. The merchant learns a payment succeeded from the customer's phone screen, or from an SMS, or from a separate app, or from a rented soundbox device from whichever provider sold them one. The transaction, the notification and the record live in three different places owned by three different companies.

There is no merchant-side history worth the name. A payments app shows a merchant a reverse-chronological list. That is a ledger, not information. It answers "did I get paid" and nothing else.

Nothing accumulates. Two years of transactions produce two years of rows. No pattern about hours, days, seasonality, repeat customers, basket size or cash-flow timing is ever surfaced, even though every one of those facts is latent in data the merchant already generated.

The sentence I wrote at the time still holds up: the QR code collects money, but it does not help the merchant understand or grow the business.

03 · Why the problem mattered

Three reasons, in descending order of how much I trust them.

The information asymmetry is structural, not incidental. Payment aggregators have every merchant's transaction data and build analytics products on top of it. The merchant who generated the data usually gets a settlement report. That gap is not a UX oversight, it is a consequence of who the paying customer is. Aggregators sell to enterprises and lenders. The single-outlet merchant is a volume input, not an account.

Merchant intelligence is the wedge for credit. A merchant with two years of structured, verified transaction history is a fundamentally different lending proposition than a merchant with a bank passbook. This is not a hypothesis I tested, and I want to be careful not to overclaim it, but it is the reason a merchant-data product is more interesting than a merchant-analytics feature.

Hardware is where trust lives. The soundbox category exists because merchants wanted an audible confirmation they could hear from across a shop without looking at a phone. That tells you something. The merchant's real requirement was never analytics. It was certainty, delivered without interrupting what their hands were doing.

04 · Research

I need to be direct about this section, because the earlier version of this case study on my portfolio was not.

I did not run a formal merchant study. There was no sampling frame, no instrument, no timing protocol, no consent process, no dataset. A previous write-up of this project claimed payment behaviour was reviewed across fifty-plus merchants with average scan times measured to the second. I cannot produce that study, so it does not belong in a case study.

What I actually had:

Observation as a participant in the market. I live in Delhi. I use UPI several times a day. I have watched hundreds of these transactions happen from the customer side, including the failure modes: the faded sticker, the merchant leaning over to check their own phone, the "sir, screenshot dikha do" when a network hiccup delays confirmation.

Product teardowns. I read the public documentation for what the rails actually permit: dynamic QR generation, UPI Lite for low-value offline-capable payments, and the NFC tap flows that the specification supports.

Competitive reading. The existing merchant tools cluster at two extremes. Either a free static QR with no software, or a full point-of-sale system with a monthly fee and a hardware footprint that assumes a counter, a power socket and a staffed till. The middle is thin.

Reasoning from the soundbox category's existence. The clearest signal available was commercial rather than qualitative. Merchants pay rent, monthly, for a single-purpose device whose only job is to say a number out loud. That is a revealed preference and it is stronger evidence than anything I could have got from asking.

That is what I had. It is enough to design a first version from. It is not enough to claim I validated the problem, and section 14 is about what that cost.

05 · Insights

Merchants will not open an app to confirm a payment. The interaction cost is wrong. Both hands are busy, the queue is moving, and a screen check takes attention the merchant does not have. Any design that routes confirmation through a screen the merchant must pick up has already failed.

Scanning is a customer-side cost that merchants pay for. Camera acquisition, focus, framing and a degraded print surface all add seconds. Seconds compound at a counter. NFC removes the acquisition step entirely: the customer touches a phone to a physical object and the payment flow opens. I want to be precise that I am claiming a mechanism here, not a measured figure. Public NFC and UPI documentation supports the mechanism. I never instrumented the difference and I am not going to pretend a number.

Confirmation is multi-sensory or it is not confirmation. Audio alone fails in a loud market. Visual alone fails when nobody is looking. The category standard, a light plus a spoken amount, is the right answer and it exists because someone learned this the hard way.

Static credentials in public places are a security problem nobody is treating as one. A printed QR code that cannot be rotated is a permanent bearer credential stuck to a wall. Sticker replacement fraud, where an attacker pastes their own code over the merchant's, is a real and reported attack class in exactly this market. Dynamic generation is not a convenience feature. It is the security model.

The reason to build software before hardware is not cost. It is that hardware without a system is another soundbox. If the platform exists first, a device becomes an interface to something. If the device comes first, the platform becomes an accessory.

06 · Product thinking

The insights converge on one reframe, and the reframe is the whole product.

TapQR is not a way to accept payments. It is a way for a merchant to own their own transaction data. Accepting payments is the acquisition surface, because it is the only thing a merchant is already looking for. The product is what accumulates behind it.

That reframe decided several things at once.

It made the sticker the atomic unit rather than the account. A merchant does not sign up for a platform, they buy a thing that does a job, and the platform arrives with it. This matters enormously for a product with no brand and no distribution: I am not asking for a behaviour change, I am selling an object that replaces an object they already have.

It made the dashboard the product surface rather than a settings page. If the value proposition is understanding, the dashboard is where the value is delivered.

It made hardware a later chapter rather than the opening move. The soundbox is the most obviously desirable thing in the entire concept and it is the thing I deliberately did not build first. Getting acrylic moulded with an embedded NFC tag that still reads reliably is a supply-chain problem, and a supply-chain problem for a solo builder with no funding is a project-ending problem, not a milestone.

And it set the positioning line, which has stayed unchanged since: Tap or Scan. One Smart Sticker. Infinite Intelligence. The first clause is the compatibility promise. The second is the form factor. The third is the direction. That third clause is intentionally aspirational and I have tried to be careful, in the product and here, not to let it read as a description of what ships today.

07 · Strategy

Dual rail from day one, and never frame NFC as the upgrade. Tap where the phone supports it, scan where it does not. A merchant cannot audit their customers' handset capabilities, so any product that makes them choose has handed them a problem. NFC is the fast path. QR is the guaranteed path. Both resolve to the same payment intent.

Software first, hardware second, intelligence third. Deliberate sequencing, stated as such in the original write-up. The web platform is the foundation; hardware plugs into an existing system; the AI layer needs a corpus that only exists after the first two have been running.

Sell an object, not a subscription. The public pricing reflects this: ₹199 once for the physical sticker, ₹99 a month for the intelligence tier. The hardware price is low enough to be an impulse decision and it is the trust purchase. The subscription is the business, and a merchant only sees the point of it after the data exists. Charging for analytics before there is anything to analyse would fail, which is why the split is the shape it is.

Choose boring, cheap, well-documented infrastructure. With no funding, every architectural decision was also a runway decision. This is covered in section 10, but the principle came first: nothing that requires a DevOps hire, nothing with a per-seat licence, nothing I could not redeploy from scratch in an afternoon.

Offline capability as a differentiator rather than a fallback. UPI Lite X exists precisely because connectivity in Indian retail is not a given. Marketing it as a feature rather than a degraded mode is the honest framing, and it happens to be the more compelling one.

08 · Information architecture

The system has two audiences that never meet, and it is really two products.

The customer path is not an app and must never become one. Tap or scan, arrive in a payment flow, done. There is no TapQR account, no login, no branding to absorb. The customer should ideally never learn the product's name. Every element added to this path is a tax on the merchant's throughput.

The merchant path is a dashboard, structured in four layers:

Identity          account, business profile, settlement destination
  Devices         the physical stickers: which, where, active or revoked
    Money         transactions, settlement state, payment links
      Meaning     patterns over time  ← the roadmap layer

The nesting is the argument. Devices sit above transactions because in this product a transaction is meaningless without knowing which physical object produced it. That is what makes multi-till and multi-outlet coherent later, and it is the structural difference between this and a payments app's flat feed.

The top three layers exist in the build described in section 12. The fourth is roadmap.

Device management earns its place as a first-class object. A sticker is a credential with a physical location. It gets damaged, moved, stolen, replaced, or covered by an attacker's sticker. Treating stickers as revocable, individually-identified objects is the direct architectural consequence of insight four in section 05.

09 · UX and design

Four TapQR interface screens exist in the public gallery and are the primary visual evidence for this section.

Hierarchy. The dashboard opens on a single number: money in, for the current period. Not a chart, not a feed, not a grid of cards. Everything else is one level down. A merchant checking their phone between customers has about two seconds of attention, and the design has to reward that first glance completely.

Interaction cost. The two operations a merchant repeats are "check today" and "generate a payment link". Both are reachable without navigation. Everything a merchant does once, like configuring a settlement account, is allowed to be several taps deep. Frequency, not importance, determines depth.

Cognitive load. The merchant is not a finance professional and is very often not working in English as a first language. So: no jargon where a plain word exists, no abbreviation without expansion, currency always with the symbol, dates always absolute rather than relative. "Settled" and "Pending" are the only two states shown, because introducing the real settlement state machine to the merchant would be technically honest and practically useless.

Visual system. Dark surface, high contrast, one accent colour used exclusively for money-related affirmatives. Numerals set in a tabular figure so columns align and a changing amount does not shift the layout. Restraint here is functional, not aesthetic: on a mid-range Android phone in daylight, contrast is a legibility feature.

Trust and perceived performance. Payment interfaces are read as reliable or unreliable within the first interaction, and perceived reliability is mostly about whether state is unambiguous. The rules I settled on: never animate a number into place, because motion on a currency value reads as instability. Never show a spinner where a skeleton will do. Never let a payment appear in the feed before it is confirmed, even optimistically. Optimistic UI is correct for a social feed and wrong for money. This is the same lesson the Hublix work produced from the opposite direction, and it is the subject of one of the articles in this archive.

Empty and error states. A new merchant's dashboard is empty by definition, so the empty state is the actual first impression of the product, not an edge case. It has to teach the next action rather than apologise. Error states name what to do, not what went wrong: "Payment not confirmed. Ask the customer to check their app" beats any status code.

The physical design is the real interface. An acrylic stand at a counter has to survive being knocked over, wiped down, and left in sun. It has to be identifiable at a glance so a repeat customer knows the ritual. It has to work at whatever height a counter happens to be. None of this is graphic design and all of it is product design, and it is the part of the concept I have the least evidence I can execute, because I have not sourced a manufacturer.

Accessibility. Contrast targets against WCAG 2.2 AA. Currency and status never encoded by colour alone. Touch targets sized for one-handed use on a phone held in a hand that is also holding change. The gap I will name: I have not tested any of this with a screen reader in Hindi, and I do not know how the dashboard performs there.

Tradeoffs I made and would defend. Dark theme costs some daylight legibility and buys a lot of perceived category-appropriateness, which for a payments product bought on trust is worth it. Two settlement states instead of five costs precision and buys comprehension. No merchant-side mobile app costs convenience and buys a smaller surface I can actually maintain alone.

10 · Technology

Stated stack, as itemised in the original build article, and consistent with what exists publicly.

Frontend. Next.js with TypeScript, Tailwind CSS, Framer Motion. Deployed on Vercel. The public repository tapqr-platform ("TapQR - Website") is TypeScript and was last updated 2 March 2026.

Backend. Fastify with JWT authentication. The public repository tapqr-backend ("TapQR - Backend") is JavaScript, same date.

Data. PostgreSQL on Neon. Deployed via Railway.

Design and tooling. Figma, Google Stitch, 21st.dev, and the Antigravity local IDE.

Live surface. tapqr.live serves the marketing site and exposes /register, /login and /dashboard.

The reasoning behind each choice, since a stack list is not an argument.

Fastify rather than Express or Nest. Payment endpoints are I/O bound and latency sensitive, and Fastify's schema-based validation gives request validation and serialisation from one declaration. For a solo build, a framework that makes the boring correct thing the default is worth more than a large ecosystem.

Postgres rather than a document store. Money is relational and needs transactional guarantees. A payment touches a merchant, a device, a transaction and a settlement record, and those need to move together or not at all. Neon's separation of storage and compute means the database scales to zero when nothing is happening, which for a pre-revenue product is the difference between a hosting bill and no hosting bill.

JWT with a hard boundary. Stateless auth keeps the API deployable anywhere. The honest caveat is that JWT revocation is a known weak point, and for a payments product session invalidation matters more than it does elsewhere. This is on my list and it is not solved.

Vercel plus Railway rather than one cloud. Split because the frontend wants edge delivery and the backend wants a persistent process near the database. Two providers is more operational surface than one, and I accepted that to avoid running container infrastructure myself.

The QR and NFC resolution path is the same in both cases by design. An NFC tag holds a URI. A dynamic QR encodes the same URI. The tag and the code are two physical encodings of one identifier that resolves server-side to a payment intent. This is what makes dual rail cheap instead of two implementations, and it is why "tap or scan" is one product rather than two.

What is not built. The soundbox and all custom hardware. The AI layer in full: cash-flow forecasting, fraud detection, behavioural analytics, recommendations. The mobile app. The admin platform. Offline transaction architecture. Every one of these is future tense in the original article and future tense here. The marketing site advertises AI fraud detection, offline UPI Lite X and merchant intelligence as product pillars, and I want to be explicit that those describe the product's direction rather than its current state. That gap between a landing page and a build is normal at this stage, and it is also exactly the kind of thing this case study exists to be honest about.

11 · Marketing and GTM

ICP. A single-outlet merchant in an Indian metro, already accepting UPI, transacting somewhere between a handful and a few hundred payments a day, with no point-of-sale system and no analytics, who has either rented a soundbox or considered it. Not the enterprise chain, which needs integrations I cannot build. Not the pure street vendor, for whom ₹199 is a real decision and the software half of the value is inaccessible.

Positioning. Against a free static sticker, TapQR costs money and must justify it with revocability, speed and understanding. Against a rented soundbox, it is cheaper and has software behind it. Against a full POS, it is a fraction of the cost and requires no counter, no power and no training. The middle of that triangle is real and mostly unoccupied.

Messaging. Tap or Scan. One Smart Sticker. Infinite Intelligence. Compatibility, form factor, direction. The product's marketed pillars are fraud detection, offline capability and merchant intelligence, which is a coherent set for the ICP: the fear, the constraint and the upside.

The hardware-first funnel. ₹199 once, then ₹99 a month. The object is the acquisition event and the subscription is the business. The sequencing is not a pricing trick, it follows from the product: intelligence requires accumulated data, so the subscription can only become worth paying for after the sticker has been working for a while. Get the object into the shop, let the data accumulate, and the second sale argues for itself.

Distribution, which is the unsolved problem. A single-outlet merchant in Delhi is not reachable through content marketing, Product Hunt or developer channels. They are reachable geographically, by someone physically present, or through an intermediary they already trust: their distributor, their accountant, their trade association, their neighbouring shop. That is a field sales problem or a partnership problem. I have not solved it and it is the single largest risk to the entire concept. Everything in this case study up to here is a build problem, and build problems are the ones I am good at, which is very likely why the distribution problem is the one still open.

What I have not done. No paid acquisition, no launch, no merchant pilot I can evidence, no distribution partnership, no measured funnel. There is a live site with pricing and signup routes. That is a shopfront, not a go-to-market.

12 · Execution

What exists:

• A live marketing site at tapqr.live with positioning, feature narrative and public pricing
• Account scaffolding: /register, /login, /dashboard
• A merchant onboarding flow
• A merchant dashboard covering revenue view and transaction history
• Transaction management
• Device management for physical stickers
• Dynamic QR generation
• Payment links
• Two public repositories, frontend and backend, both last updated 2 March 2026
• Four interface design screens, published

What exists as design only: the acrylic stand form factor, the soundbox concept.

What exists as writing only: the AI layer, the mobile app, the admin platform, offline transaction handling.

The first milestone was the web platform, and it was completed as scoped. That is the accurate summary.

13 · Results

No outcome metrics exist for TapQR. Nothing was instrumented, no merchant pilot ran, and no transaction volume, uptime, merchant count or conversion figure can be reported.

An earlier version of this case study on my portfolio stated fifty-plus pilot merchants in New Delhi, ₹2.5 million in test volume and 99.9% uptime. I cannot produce evidence for any of those numbers and they are not repeated here. My own build article, written in June 2026, says plainly that TapQR is still early in its journey and reports no metrics at all. That article is the accurate account. The removal of those figures from this case study is deliberate and it is the single most important edit in this document.

What can be verified: the product is live, the price is public, the code is public, the interface is designed and the architecture is real. For a solo, unfunded build that is a substantial artifact. It is not traction and it is not going to be described as traction.

14 · What went wrong

I built the dashboard before I had earned the right to. With no research instrument, I designed a merchant analytics surface out of my own model of what a merchant wants. My model may be right. I have no way to know, and the honest reading is that I chose the part of the problem I enjoyed. Building is more comfortable than standing in a shop asking a stranger to explain their day.

I published metrics I could not support. This is the failure that matters most and it is not a product failure, it is an integrity one. Numbers appeared in the portfolio write-up that do not exist in the build record. I do not think it happened maliciously; portfolio pages get written in a mode where specificity feels like professionalism, and a plausible number feels better than an empty section. It is still wrong, and the correction is public in section 13. It also had a practical cost: it made the whole project less credible to anyone who checked, which is the opposite of what a portfolio is for.

The marketing site describes a product further along than the build. AI fraud detection, offline UPI Lite X and merchant intelligence are presented as pillars. One of the three is partially real. "TapQR is Live 🚀" as a hero headline is defensible for a live web app and misleading about the ecosystem. I would now write the landing page to the build.

The hardware ambition consumed thinking and produced nothing. Sourcing a manufacturer who could embed an NFC tag in acrylic without degrading read reliability took weeks of iteration and did not conclude. The correct decision, which I reached late, was to postpone the physical object entirely. Getting there earlier would have bought me those weeks back. The lesson generalises: hardware distribution is significantly harder than software, and a solo builder should treat any atoms-based dependency as a project risk rather than a milestone.

Two clouds was premature. Splitting frontend and backend across Vercel and Railway is defensible at scale and was overhead at zero users. Two dashboards, two failure modes, two sets of environment variables, for a product with no traffic.

JWT revocation is unresolved. I shipped stateless auth because it was fast and I have not built proper session invalidation. On a payments product that is a real gap, not a nice-to-have, and I am naming it rather than leaving it to be discovered.

The positioning drifted across my own surfaces. At one point my portfolio homepage described TapQR as solving broken professional networking, which is a completely different product from merchant payments. That is what happens when a landing page gets rewritten separately from a product. It also demonstrates why a knowledge base like this one needs to exist.

15 · What I learned

Sequencing is a real strategy and it is mostly about what you refuse. Software before hardware before intelligence was the right call and it was right for a reason I only articulated later: each stage makes the next one cheaper, and skipping ahead makes the earlier stage a sunk cost. The soundbox after a platform is a peripheral. The soundbox before a platform is a competitor to companies with supply chains.

Constraints did produce focus, and the version of that lesson I believe now is narrower than the version I wrote at the time. No funding forced choices I would defend on the merits: Postgres over anything exotic, Fastify over a heavier framework, a scale-to-zero database. What constraints did not do was substitute for research. "I had no resources" explains a small stack. It does not explain designing a dashboard for a user I never spoke to. Those are different problems and I had been treating them as one.

A stack is a runway decision. Every dependency has an ongoing cost in money or attention, and at zero revenue attention is scarcer. The question I now ask about any addition is not whether it is better but whether I can afford to maintain it while unfunded.

Design is a competitive advantage in this category specifically. Merchant software in this segment is not designed at all. It is functional and it looks it. A merchant deciding whether to trust an unknown payments product with their money reads the interface as evidence about the company. That is not vanity, that is the actual signal available to them.

Distribution is the product for a physical-object business. I can build the software. I cannot yet get an object into ten thousand shops, and no amount of additional building changes that. Recognising which of your problems is not a building problem is uncomfortable and it is the most useful thing this project taught me.

Write the case study to the build. The build record and the portfolio should be the same document with different formatting. Where they diverge, the portfolio is wrong.

16 · What I would do differently

Spend the first two weeks in shops, not in an editor. Twenty conversations with merchants in Lajpat Nagar or Sadar Bazar, unstructured, recorded with permission, before a line of dashboard code. Not to validate the idea. To find out which of my four problem statements a merchant actually recognises, and in what words.

Instrument from the first commit. Not analytics for a growth dashboard. Event logging so that any future claim has a source. The reason I have no metrics is not that nothing happened, it is that I did not build the ability to know. That is a two-hour decision that would have changed section 13 entirely.

Ship the revocation story before the analytics story. Dynamic, individually-identified, revocable codes are the defensible technical claim and they address a real fraud vector in this market. Analytics is the aspiration. I led with the aspiration because it was more exciting to design. Leading with security would have been a sharper product and an easier sale.

Write the landing page from the build, and update it when the build moves. One rule: nothing on the marketing site that is not in the repository.

Treat distribution as a design problem from day one. Who physically hands a merchant this sticker? If the answer is nobody, the product does not exist regardless of how good the dashboard is. Candidate answers worth testing: an existing FMCG or telecom distributor who already visits these shops weekly, a merchant association, or an accountant channel. I have tested none of them, and I would now rather have one signed distribution conversation than another shipped feature.

Pick one cloud. Consolidate until there is a measured reason not to.

Decide what TapQR is, once, in writing, and make every surface obey it. The positioning drift in section 14 was avoidable with a single canonical document. This case study is now that document.

17 · Current status

Live web product. Prototype ecosystem. Actively developed. No traction claimed.

Component	Status
Marketing site with public pricing	Live
Merchant onboarding, dashboard, transactions, device management, QR generation, payment links	Built
Frontend and backend repositories	Public, last updated 2 March 2026
Interface design	4 screens published
NFC physical sticker	Designed, not manufactured
Soundbox hardware	Concept
AI layer: forecasting, fraud detection, behavioural analytics	Roadmap
Mobile app, admin platform, offline transactions	Roadmap
Merchant pilot	Not run
Distribution	Unsolved

---

Related reading in this archive

• Designing for latency and trust in real-time products: the optimistic-UI argument from section 09, worked out properly
• Product design under uncertainty: what to do when you have not done the research, and what it costs
• What seventeen products in five months actually taught me: where TapQR sits in the wider build record
• Hublix: the same latency-and-trust problem approached from IoT
• The build archive: the repository record that dates this work
• Architecture at the model boundary: what the roadmap AI layer would have to be built against

Sources

1. Dev Chopra, "Building TapQR: My Journey From Freelancing to Creating a Smart Payment Ecosystem", BuildWithDev, 6 June 2026. https://buildwithdev.xyz/research/building-tapqr-my-journey-from-freelancing-to-creating-a-smart-payment-ecosystem
2. TapQR product site, pricing and feature pillars. https://www.tapqr.live/
3. TheDevChopra/tapqr-platform and TheDevChopra/tapqr-backend, public repositories, last updated 2 March 2026. https://github.com/TheDevChopra
4. TapQR interface screens, 4 published. https://devchopra.life/gallery
5. National Payments Corporation of India, UPI product documentation and UPI Lite specifications. https://www.npci.org.in/what-we-do/upi/product-overview
6. Reserve Bank of India, guidance on offline retail digital payments. https://www.rbi.org.in
7. NFC Forum, NFC Data Exchange Format and Type 2 Tag specifications. https://nfc-forum.org/build/specifications
8. W3C, Web Authentication and payment request context for browser payment flows. https://www.w3.org/TR/payment-request/
9. Web Content Accessibility Guidelines 2.2, contrast and target size criteria. https://www.w3.org/TR/WCAG22/