Ever stood at a checkout counter opening 3 different UPI apps just to see which one has a grocery cashback today? Yeah, me too.
So, I built ORBIT UPI 🪐
It’s a lightning-fast, zero-backend UPI payment router designed to eliminate friction and maximize your rewards.
What it does today:
📱 Scan & Select: Scan any UPI QR code right from your browser and jump instantly into your app of choice.
🔒 100% Local & Private: No backend. No servers. No tracking. Every transaction log is stored entirely on your local device browser.
The Future Vision (Smart Routing):
🧠 Cashback Optimization: ORBIT will read the Merchant Category (MCC) and auto-suggest the app with the best active cashback.
⚡ Downtime Bypassing: If a bank network is down, ORBIT will hide the failing apps and route you to the most stable one.
But I’ve hit a massive technical roadblock, and I need the fintech ecosystem's help.
While ORBIT’s deep-linking works perfectly with apps like CRED, I am being completely blocked by the heuristic engines of other major players.
🛑 The Issue: When ORBIT passes a standard, strictly formatted P2P intent, apps are throwing "Security Risk" errors simply because the intent originates from a web browser.
🚧 The Barrier: I understand the need to prevent phishing, but the only official "fix" right now is to register as a corporate merchant and integrate a heavy Payment Aggregator SDK just to generate a signed intent.
Question for the engineering/product teams at Phonepe, Gpay, CRED, PAYtm:
How can independent developers build legitimate, secure web-to-app routing utilities without being forced into an enterprise merchant flow?
Is there a modern standard or an intent structure for local-only tools to trigger user-initiated payments without hitting security blockades?
Would love any technical suggestions, intent string workarounds, or feedback from the community!
#UPI #FINTECH