YouPI PG: a self-hosted UPI payment gateway, explicitly experimental

The idea, and the pitch

YouPI PG is a payment gateway you run yourself for UPI and cash on delivery payments in India, and its two selling points are in the badges and the comparison table. The first is that the fee is zero, where the table contrasts the two to three percent plus eighteen percent GST of the established aggregators with a stated zero. The second is settlement, where the aggregators are listed at two to three business days and YouPI PG is listed as instant peer to peer to the bank. The mechanism behind both is that there is no aggregator in the middle, so the money moves from the customer's UPI app to the merchant's own account and the software only orchestrates the flow around it. The project also advertises white labelling as a hundred percent, dynamic QR payments, a universal JavaScript checkout, WhatsApp one-time password authentication before checkout, and automated payment verification. It was originally created by a different author and is now maintained by someone else, and the repository version is 1.0.0.

The research notice, which is the most important paragraph

The README opens with a long notice, and it is unusual enough to quote in substance. The project calls itself an independent, experimental research and learning project, published primarily so that other developers can study, test, review and contribute to it, and says explicitly that it is not certified, bank approved, network approved, audited or production ready. It defines the appropriate scope as local development, test environments, demos, learning and carefully controlled experiments, and states that it is not for critical, high value, high volume, time sensitive or business critical transactions, and that it should not be the sole source of truth for confirming a payment. It sets a conservative project guideline of no more than twenty payment attempts per day per receiving account for experiments, and is careful to add that this is a guideline of the project and not a claim about a universal limit. It states there is no affiliation with the network, the regulator, any bank or any UPI application, that using the software does not authorise anybody to operate a regulated service, and that it comes with no warranty of accuracy, availability, security or compliance.

How the checkout is put in front of a customer

The integration is designed to be nearly free of effort for the merchant, and the demo descriptions in the README are the clearest account of it. On the desktop, a single script brings up a modal that auto-binds to elements marked with a data attribute, so a merchant adds the attribute to a button and gets a checkout. On mobile, the same flow becomes a bottom drawer, with one-tap deep links into the payment applications, and the demo names four of them. Inside the flow, a pre-checkout one-time password is sent through WhatsApp and the customer types a six digit code, which the README presents as a real-time verification step before the payment is offered. The QR code that appears is a vector image generated on the fly with two timers running, which is the part that lets a screen be reused for a later payment once the first one times out, and a counter desk mode offers cash and card as a fallback when there is no phone in the customer's hand.

How the system decides a payment arrived

This is the part a reader should look at hardest, because it is where the risk lives. The mechanism is observation rather than instruction. The project watches bank SMS alerts, watches Gmail, and ships a native Android observer application, and the status is then reflected in near real time by polling. In other words, nothing tells the bank to pay; the software infers that money has moved because a message arrived that says so. The README is candid about the consequences, stating that browser callbacks, screenshots, message parsing and the software's own status are not by themselves conclusive proof of settlement, and that the merchant must reconcile against the bank's official records and handle duplicates, delayed alerts, refunds, disputes and failed payments safely. That is the correct warning, and it also means the confirmation path is only as good as the alert parsing and the bank, which is a different kind of dependency from the one a real gateway offers.

The stack and the shape of the repository

The implementation is a modern Node stack, and the manifest describes a TypeScript project built with project references, with npm workspaces covering the shared packages and the applications. The build script compiles with the TypeScript compiler, the database is SQLite running in native write-ahead logging mode, and the test suite is on vitest with a badge claiming thirty-one of thirty-one tests passing. The applications include a payment API, and the scripts directory holds the database initialisation, the start process and a package synchronisation step, with an environment example file at the root for the configuration. The repository also carries an OpenAPI description, an architecture document, an agent instruction file, a documentation folder and a data directory, which together suggest a project that has been designed rather than accumulated.

The limits, stated plainly

Several limits are written into the project itself. The twenty transaction guideline caps the real use of the system to a scale where it cannot be a business, and that is deliberate, so a merchant cannot quietly grow into it. The confirmation mechanism depends on message formats that banks and applications can change without notice, and a bank that rewords an alert breaks the detection. The fee comparison is fair about the aggregator fee and silent about the costs this project moves onto you, namely running and securing the servers, reconciling every payment, handling disputes, and the compliance work the project explicitly says it does not do for you. And the maintenance history is thin, a version 1.0.0 with no tagged releases in the repository, one creator and one maintainer, which for a component that sits in a payment path is a fact to weigh rather than a footnote.

The alternative, and the real comparison

For a merchant taking real money, the alternatives are an established aggregator, where a two to three percent fee buys compliance, reconciliation, dispute handling, fraud screening and a support organisation, or the payment network's own merchant arrangements with the bank, which avoid the aggregator fee while keeping the bank in the loop for compliance. YouPI PG's difference in approach is that the software is only the orchestration and the detection, and the compliance, the settlement guarantees and the accounting are all the merchant's problem. That is a reasonable trade for a learning project and an unreasonable one for a shop, and the project says as much in terms that are unusually direct. The genuine value of the repository, then, is as a readable reference implementation of a checkout with a one-script integration, a pre-checkout identity check and a bank-alert driven confirmation, in a language and stack a web developer already knows.

Editorial conclusion

YouPI PG fits a developer who wants to understand how a payment checkout and a payment confirmation flow work together, a merchant evaluating what a self-hosted, fee-free settlement would take, and a team building a demo that must not touch a real payment. It does not fit a business taking money from customers, because the project itself says so in terms, and because the confirmation mechanism is an inference from an alert rather than an instruction to a bank. Before evaluating it at all, read the research notice in the README, confirm with your bank and with the payment network what you are permitted to do, and treat every settlement as unverified until you have reconciled it against the bank's own records.

Frequently asked questions

Official sources

1. Issues
2. README
3. youpi-pg/YouPI-PG on GitHub