JalNetra: Warn, Then Relieve

Ladning Page of JalNetra
Live Evacuation and Flood Trajectory Path
Live Parameters of the affected region
Detailed Events
NDRF Report generated for the affected area
Relief case generated by AI for the affected region
Dashboard to Track Payments
PayPal Payment Gateway for Donations

Inspiration

On 26 August 2026 a glacier collapsed above Langtang in Nepal. The flood raced 226 km to the Indian border, and the first alarm on the gauge network came 2 hours 43 minutes after the collapse. By then the gauges near the source had already gone dark while still reading normal.

We built JalNetra ("the eye on the water") to close that gap. But a warning only solves half the problem. Once people are out of the water's way, someone has to pay for boats, shelter, food and medical teams, and that step is usually slow, manual and hard to audit. So we built both halves in one flow: detect, warn, then fund the relief with PayPal.

What it does

1. Detect. JalNetra watches 681 river points across India. It combines GloFAS river discharge and rain forecasts, Sentinel-1 radar flood maps, and a Copernicus terrain model. A small fitted logistic model scores flood probability for every 200 m cell, and only cells connected to the river count. The result is a flood trajectory polygon and an evacuation zone polygon, with the estimated people and phones inside. It predicts which of 291 villages along the Gandak the water reaches, and when (now, +3, +6, +12 and +24 hours).

2. Warn, with a human in the loop. Nothing is automatic. An operator reviews the map and approves the alert. The village head (Sarpanch) gets a two-way voice call and a Telegram message and answers escalate or false alarm. Only after "escalate" are citizens called, in Hindi and English, with a safe place named in the call. An NDRF advisory PDF (affected area, shelters, route, rescue estimate) goes to the national response team.

3. Fund the relief with PayPal (Flood-to-Relief).

AI plan. When risk is critical (or a demo is run), an AI model (Groq, gpt-oss-120b) drafts a relief assessment. The backend validates it against budget caps before creating a Relief Case with priced packages.
Human approval. Packages are quantity × unit cost. An operator must approve them, and editing a package sends it back to pending.
PayPal Checkout. An approved package becomes a transaction with a fixed amount and currency snapshot. The server creates the PayPal order and opens PayPal's approval page. After the buyer approves, the server captures the order.
Verified, not assumed. A transaction is marked completed only when the PayPal order ID, capture ID, amount and currency all match. A browser redirect alone never counts as payment.
Signed webhooks. Every webhook is checked through PayPal's verify-webhook-signature API. Events are deduplicated, matched to stored transactions, and rejected on amount or currency mismatch.
Refunds. Partial and full refunds work. Pending refunds reserve balance so over-refunds are impossible, and the transaction becomes refunded only when confirmed refunds equal the captured amount.
Payouts. Optional outbound payments to suppliers and beneficiaries through the PayPal Payouts API. They are capped, idempotent, and off by default. A payout counts as successful only after a verified PayPal item status.
Audit trail. Every package, payment, refund and payout action is written to a per-case audit log.

How we built it

Frontend: React 19, TypeScript and Vite. The same flood-model file (core.ts) runs in the browser and the backend.
Backend: One API handler runs on AWS Lambda and locally. The local backend runs the escalation service, the PayPal and Relief Case routes, and a Postgres ledger.
Data pipeline: Python scripts build flood masks and terrain layers from Sentinel-1, Sentinel-2, the Copernicus DEM, JRC water and ESA WorldCover.
PayPal: Orders v2 (create and capture), Refunds, Payouts and Webhooks, all against the PayPal Sandbox API. The Client ID and Secret stay server-side and are never exposed to the browser.
Voice and messaging: OmniDimension voice agents, Telegram bots, and a browser-built NDRF PDF report.

Challenges

Never trusting the happy path. A PayPal redirect isn't a payment. We had to design for cancelled checkouts, capture failures, duplicate and out-of-order webhooks (a refund arriving before its capture), and amount or currency mismatches.
Money safety around AI. AI output is treated as untrusted input. It is validated and capped, and a human approves before any payment, and payouts are opt-in.
Telephony limits. The voice provider allowed one concurrent call and has no keypad input, so answers are spoken and the citizen call retries while the Sarpanch call ends.
Rate limits. The free weather API has a daily quota, so we added a cached proxy and a bundled replay of the September 2026 flood as a fallback.
Honest modelling. With three radar flood maps from a single event, we report real numbers instead of inflating them.

What we learned

Payment correctness is about what you refuse to assume: batch accepted isn't paid, approved isn't captured, and a webhook isn't real until its signature is verified. We also learned how much an early warning is worth once the response (money, shelter, rescue) is wired to it.

Accomplishments and honest limits

Caught 56% and 66% of villages that radar later saw flooded, with false alarms (AUC 0.72 to 0.75, where 0.5 is a coin flip). This is an early-warning screen, not a guarantee, and a person always decides.
Predicts whether water reaches a place, not how deep. Cells are about 200 m, so it works at village scale.
All PayPal activity is Sandbox only, with no real money. Payouts need PayPal to enable the Payouts permission for the app. Without it, the AI assessment and case and package creation still work.

What's next

Validate the model across seasons and rivers, send one cell broadcast to the evacuation zone instead of per-phone calls, and move the relief flow from the local backend to the cloud with real operator authentication.

JalNetra: जल (water) + नेत्र (eye).