Inspiration

The inspiration for this project is from a problem I experienced on my own college campus. My college provides free Wi-Fi, but when hundreds of students connect to it, the network can become painfully slow. Something as simple as paying for lunch at the canteen using UPI can turn into a frustrating experience. Payments get stuck, connections time out, and sometimes I have to walk around campus searching for a better signal or simply give up on the transaction. It made me wonder: Why should a payment depend entirely on an internet connection, especially when the need to pay doesn't disappear just because the network does? That question led me to explore offline payments and the technologies shaping their future, including UPI Lite X, UPI123PAY, and India's Digital Rupee. India has become a global leader in real-time digital payments, and I believe making digital payments more resilient to connectivity failures is an important next step. The opportunity goes far beyond a college canteen. During floods, natural disasters, network outages, or in areas with unreliable connectivity, access to digital payments can become critical. I didn't want to simply build another payment application. I wanted to explore a different approach: what if users could make payments without an active internet connection while keeping funds accounted for within the banking system? That idea became the foundation of my offline payment system. For me, this project is an opportunity to move beyond using existing fintech solutions and start experimenting with what the next generation of digital payments could look like.

What it does

Paron is designed to enable digital payments even when an internet connection is unavailable. Before going offline, a user receives a cryptographically signed spending token linked to funds reserved in the system's ledger. The token specifies the authorized spending limit and expiry, allowing the user to make payments within predefined boundaries. When the payer and merchant are offline, the planned Bluetooth-based payment flow allows the payer's device to transmit the transaction details and token to the merchant's device. The merchant can verify the payment authorization locally, without needing to contact the backend for every transaction. Once connectivity is restored, pending transactions are synchronized with the backend. The system checks transaction validity, detects duplicate submissions, and evaluates suspicious activity before settlement. Its ledger service manages fund reservations and settlement, while asynchronous processing helps handle batches of transactions reliably. AI-powered fraud detection is an extension of the project: it is intended to assess transaction risk during synchronization, when connectivity returns, alongside existing rule-based checks. The goal is to make digital payments more resilient to weak networks and outages without treating an offline transaction as automatically settled or removing the need for fraud controls.

How I built it

I built Paron as a native Android wallet backed by a set of Spring Boot services. Before going offline, a customer can fund their demo wallet through PayPal Sandbox and reserve a capped amount for offline use. The app signs a payment receipt on the device and transfers it to a nearby merchant using a QR code or Bluetooth. When connectivity returns, the backend checks the receipt and token, applies deterministic fraud rules and a scikit-learn risk model, and reconciles accepted payments with the ledger. The risk model is served through FastAPI and was trained on synthetic payment scenarios. PayPal credentials remain on the backend; the project uses Sandbox funds and does not move real money.

Challenges I ran into

Double spending is difficult to prevent when devices are offline. Without a connection to a shared ledger, a merchant cannot get immediate central authorization or know whether the same token was presented elsewhere. Paron limits exposure with a prepaid spending cap, signed receipts, replay checks, and reconciliation after reconnect. The backend can flag conflicting claims, but I do not claim that offline double spending is impossible. I also had to coordinate several services across funding, token issuance, balances, fraud review, and synchronization. PayPal Sandbox approval and capture, service connectivity, and keeping app state consistent when a request times out all required careful handling.

Accomplishments that I'm proud of

I turned a frustrating experience—being unable to pay at a college canteen when the internet dropped—into a working prototype that explores a practical alternative. I’m proud of the native Android payment flow, signed QR handoff, PayPal Sandbox funding integration, and backend reconciliation path. I also built a risk-scoring service that provides a score and human-readable reasons, while keeping final settlement decisions subject to backend rules.

What I learned

Offline payments require clear limits. Cryptography can help prove who created a receipt and whether it was changed, but it cannot give an offline merchant the same immediate certainty as an online authorization. A bounded allowance and a reliable reconciliation process are essential. I also learned to treat model output as one signal rather than as proof of fraud. My model uses synthetic scenarios, so it demonstrates the risk-scoring pipeline; it still needs evaluation against appropriate real-world data before it could support production decisions.

What's next for Paron

I plan to explore NFC and additional offline handoff methods, improve the merchant receiving experience, and make synchronization and recovery more reliable across devices. I also want to strengthen device key protection and evaluate the risk model against responsibly sourced real-world outcomes before making claims about its effectiveness. If you'd like me to combine this project story with your hackathon contribution timeline into a single submission draft, let me know, and I can put them together.

Share this project:

Updates

Submission history