Inspiration
I boarded in a hurry, left my cards behind, and trusted my phone to pay by UPI, which pays for almost everything on the ground. In the air there is no network, so UPI failed. A simple meal, and no way to pay.
That moment is the problem: where connectivity ends, payments end. On flights, trains, ships and in remote areas, sellers lose sales and passengers lose choice. Airlines can take cards onboard today, but usually on one rail, often the costliest, and busy crew have to handle the cards, which is where mistakes happen.
So we built AirPay. Take the order offline. After landing, the passenger pays through a single-use link on the cheapest suitable PayPal rail, and the airline can share the saving. No card handling for crew. A safe fallback if they do not pay. Every step audited.
What it does
- Cabin crew record orders offline on a device, within limits set for each payer type. No card is touched.
- After landing, orders sync once. Each order is pre-screened, then an AI agent proposes the cheapest eligible PayPal rail for the buyer. A rule guard accepts or overrides the AI using a cost table and a cap on irreversible rails.
- The passenger pays through a single-use PayPal link or QR. The QR is burned only when a verified payment event arrives, never by a scan.
- Funding is recorded per order: payer balance first, then bank, then card for the shortfall only. The merchant fee and the funding cost are shown separately.
- If the passenger does not pay, a confirmed backup-card consent is charged first. Indian UPI-debit passengers with no card go to a lender-backed pay-later step. International payers without consent become an airline loss, shown openly.
- Every decision goes into a hash-chained audit log, and one click verifies the chain.
How we built it
Node.js and SQLite. PayPal REST: Orders v2 for checkout and capture, Invoicing v2 for the payment link and QR, and webhook signature verification. Tested live in the PayPal sandbox: an invoice was created, a sandbox buyer paid on PayPal's own page (bank and Visa card), and the app confirmed the payment from PayPal's invoice status. Gemini proposes the rail and narrates audits, but deterministic rules always decide. The model never sees names or contacts, and never sets amounts or states. 35 automated tests cover limits, the state machine, token burn, the rail guard, consent, fallbacks, funding and the audit chain.
Challenges we ran into
Keeping the AI from ever moving money: the guard design. Modelling fallbacks honestly, so unpaid orders end as a clear airline loss and not a hidden one. Separating the merchant fee from the funding cost so we do not overclaim savings.
Accomplishments that we're proud of
A complete offline-to-settled flow with a tamper-evident audit trail, and a clear rule: the AI proposes, the rules decide.
What is real and what is simulated
Real: the offline queue, limits, state machine, single-use token, rail guard, audit chain, PayPal sandbox invoice creation, payment by a sandbox buyer, and status confirmation. Simulated: the UPI-style bank leg (PayPal's sandbox has no UPI), the lender, the savings account, payer balances for the funding order, and the SHIELD stub rules. Fee and funding-cost tables are illustrative, not PayPal's rates.
What we learned
Payment fees depend on the rail, and the funding source mainly changes cost upstream. Being honest about that made the design stronger.
What's next
A Razor pay UPI rail for Indian passengers alongside the PayPal rails, so the router can pick the lowest-cost suitable rail for every passenger. A first version is built in simulated mode, and Razorpay test-mode integration is next. UPI processed a record 25.47 billion transactions in October 2026 (NPCI), and PayPal does not support domestic payments inside India today. A tie-up with Razorpay or another approved Indian platform could let PayPal's network reach that market, online and in no-network settings like flights, trains and ships. After that: more places than aircraft, real lender and bank partners, and PayPal agent tools for checkout by conversation. We are also working on a route for payers with a basic phone or no internet at all: the order arrives by SMS, the payer's reply carries a one-time code, and payment completes on the UPI network's own channel (*99#), with a pre-payment audit before any money moves. It is tested in mock mode only. Indian provisional patent applications nos. 202641135327 and 202641135824 are filed.
Open source under AGPL-3.0. Patent pending: Indian provisional application no. 202641135327, filed 12 November 2026.
