Trip ledger OS for Indian travel apps to unify card, UPI, rewards, and refunds around one traveler and one booking.

1. Travel transaction volume is rising fast enough that manual reconciliation breaks before the product team can keep adding categories.
2. Usage at 15–20 card transactions per month means the app now behaves like a daily wallet, so errors in rewards and refunds become recurring trust failures.
3. Once booking, card, RuPay, Visa, and UPI flows sit in one app, the hard problem shifts from distribution to cross-rail operations.
4. A large growth round at a $500M+ valuation suggests more players will copy the model, creating repeat demand for shared infrastructure rather than bespoke internal tooling.

Catalyst. Scapia's combination of rapid booking growth, high monthly card usage, and in-app convergence of credit-card and UPI rails makes cross-rail reconciliation newly urgent for any Indian travel-fintech platform trying to scale without margin leakage and support chaos.

Build a B2B infrastructure layer for Indian travel-fintech platforms that creates a single trip ledger across booking, payment, reward, and refund events. The product ingests OTA booking records, card authorizations and settlements, UPI pay-ins, reversals, and loyalty events, then resolves them to one traveler and one trip so finance, product, and support teams see the same truth. It would automate reward posting rules for different payment rails, flag broken or delayed refunds, and surface margin leakage when an itinerary touches multiple merchants or cancellation paths. Customer-facing teams could use the same ledger to explain exactly what happened on a disputed reward or refund instead of stitching data from multiple vendors. The first deployment is an overlay on top of the existing issuer, PSP, booking, and loyalty stack rather than a core replacement.

What's different. PSPs, booking engines, and loyalty platforms each own one subsystem, but none are designed around the trip as the financial object that ties bookings, payments, refunds, and rewards together. This company starts with a very specific operational wedge: making the traveler wallet accurate across card and UPI flows while finance teams keep margin and liability visibility. Over time, defensibility comes from rail-specific reconciliation logic, merchant and itinerary mappings, and a proprietary dataset on how travel-fintech transactions behave across booking categories and post-booking changes.

Jobs to be done

flowchart LR
  Buyer[VP Payments at travel app] --> Pain[Card, UPI, rewards, and refunds break across one trip]
  Pain --> Product[Trip-linked commerce ledger]
  Product --> Outcome[Accurate traveler wallet, faster refunds, better margin control]

Executive takeaways

• The wedge is credible because Indian travel apps are turning into everyday payment products, so the operational pain is no longer just booking reconciliation but cross-rail wallet accuracy across card, UPI, rewards, and refunds.
• The best early customers are not generic merchants; they are scaled OTAs and travel-fintechs whose mix of bookings, partner issuers, and reward promises creates expensive exceptions that generic payment layers do not resolve.
• Competitive intensity is moderate-to-high in adjacent layers, but most incumbents stop at routing, issuance, or after-the-fact close rather than owning trip-linked state.
• Regulatory design matters: the safest architecture is a software control plane that avoids becoming a regulated fund handler while still ingesting PA, issuer, and booking data.

Market definition

Workflow and ledger software for Indian travel platforms that need to reconcile one trip across booking events, card and UPI payments, rewards accrual, reversals, and refunds.

Customer and buyer

Primary users are payments, finance, and support operations teams at large OTAs and travel-fintechs; the economic buyer is typically the payments, product, or business-unit leader who owns refund SLAs, issuer relationships, and loyalty accuracy.

Buying triggers

• Launching or scaling a dual-network or UPI-linked credit-card program makes one customer journey span issuer files, card rails, UPI, and app-side reward logic. [1][4][5][13][15]
• Expanding from flights into hotels, buses, or broader travel categories increases the number of merchants, post-booking states, and refund edge cases finance teams must reconcile. [1][29][30][33]
• A spike in delayed refunds, chargebacks, or support exceptions forces operators to replace spreadsheet-heavy workflows with system-level controls. [17][18][19][23]

Willingness to pay

Budget exists when the platform already operates at large booking scale, pays multiple vendors across payments and card programs, and can justify software on avoided support cost, leakage reduction, and better refund/reward accuracy rather than on checkout conversion alone. [21][22][23][25][29][30][33]

Category dynamics

Growth signal 10.6% CAGR

Validation signals

• Tech Funding News reports that Scapia cards are used 15-20 times per month per user, which supports the thesis that travel cards are becoming everyday wallets.
• Federal Bank and BOBCARD both market the Scapia card around zero-forex, UPI/card rewards, instant redemption, and airport privileges, confirming the product bundles daily payments with travel benefits.
• ixigo reports 122.95 million annual passenger segments, 83.56 million MAUs, and a 3 hour 17 minute average refund time, showing that refund operations are product-critical at real scale.
• MakeMyTrip reported $9.8 billion of gross bookings in FY25 while air, hotel, and bus volumes all grew, which implies there are buyers large enough for dedicated exception and ledger tooling.
• EaseMyTrip served about 26 million customers and 2.63 million hotel partners, signaling another large Indian travel operator with multi-party settlement complexity.

Regulatory & technical constraints

• If the product begins pooling or moving customer funds directly, it risks entering India's payment-aggregator authorization perimeter; the cleaner design is a software layer over licensed partners.
• Merchants and payment aggregators cannot keep raw card-on-file data; tokenized flows and limited stored card metadata are mandatory.
• Large credit-card issuers must give eligible customers network choice at issuance or renewal, which affects how co-branded travel card programs are structured.
• Refund and disbursement orchestration needs network-specific status, reversal, and message logic, especially once card and UPI-linked behaviors sit in the same customer journey.

The market is crowded in adjacent layers—payment routing, card issuing, and back-office reconciliation—but still thin in software that treats the trip as the financial object and keeps the traveler-facing wallet in sync with the back office.

Why incumbents do not win by default

• Payment orchestration platforms. They improve acceptance, routing, and reconciliation at the payment layer, but they do not natively join itinerary, reward, refund, and support state into one traveler ledger.
• Card issuing and processor stacks. They abstract card rails and tokenization, but they stop at the card account and do not solve OTA booking-system joins or loyalty liability attribution.
• Finance close and reconciliation suites. They automate high-volume matching after the fact, but they are not designed to power customer-visible wallet accuracy or trip-time exception handling.
• Internal engineering teams at large OTAs. They can build bespoke ledgers, but the growing scale of bookings, refunds, and payment variants raises maintenance cost and slows launches across new rails and categories.

Trip Ledger OS should launch as a read-only, trip-linked control plane for Indian travel-fintechs and large OTAs that now span bookings, co-branded cards, UPI payments, rewards, and refunds in one customer journey. The first customer is a Series B+ travel platform with 200,000+ monthly active bookers, a live card program, and a near-term push into hotels or everyday spend, because that combination creates visible refund and reward errors before the company can justify rebuilding its entire stack. The immediate pain is not checkout conversion; it is broken wallet accuracy, slow refund resolution, and margin leakage caused by stitching issuer files, PSP events, OTA booking records, and loyalty logic by hand. The MVP should therefore stay outside regulated funds handling and focus on ingesting booking, card, UPI, refund, and reward events into one trip object, then surfacing exceptions for finance, product, and support teams. Go-to-market should pair founder-led sales with issuer and PSP influence partners, selling into a launch or expansion trigger rather than broad transformation budgets. Pricing should combine paid implementation with annual platform and event-based fees so the first deal is justified by avoided support labor, lower leakage, and better traveler-wallet accuracy. The researched market supports a narrow but real beachhead, with an estimated $27.0M TAM, $7.2M SAM, and $1.4M year-3 SOM for the India-first wedge. The main investor concern is that the market is concentrated and buyers may prefer internal builds or horizontal vendors unless the company proves that a read-only overlay can join data quickly and convert pilots into production.

Problem

• Indian travel apps that combine booking, card, UPI, rewards, and refunds still reconcile the trip lifecycle across issuer files, PSP dashboards, OTA records, and spreadsheets.
• When hotels, ancillaries, and everyday card or UPI spend grow, broken reward accrual, delayed reversals, and refund mismatches become recurring trust failures for travelers and recurring cost centers for finance and support.
• Horizontal payment tools, card stacks, and finance-close suites each solve one subsystem, but none keeps the traveler-visible wallet and the back-office ledger synchronized around one trip.

Solution

• Create a trip-linked ledger that maps each booking event, card authorization, UPI payment, refund, reversal, and reward posting to one traveler and one itinerary.
• Start as a read-only overlay on top of the issuer, PSP, OTA, and loyalty stack, with exception queues, audit trails, and workflow views for payments, finance, and support teams.
• Expand after initial proof into automated settlement, partner-liability reporting, and cross-merchant margin analytics once customers trust the trip object and event mappings.

Why we win

• The product is designed around the trip as the financial object, which is the core join that payment orchestrators, issuers, and finance-close tools do not natively own.
• The beachhead buyer already feels measurable pain during card or UPI launches, hotel-category expansion, and refund backlogs, so value can be proven through one operational workflow instead of a platform rewrite.
• Each deployment compounds rail-specific mappings, exception history, and reward or refund edge cases that are hard for internal teams or horizontal vendors to assemble across customers.

Milestones

flowchart LR
  Wedge[Trip-ledger wedge] --> MVP[Read-only ledger MVP]
  MVP --> Proof[Refund and reward proof]
  Proof --> Expansion[Settlement and benchmarking expansion]

Founding team

Experiment roadmap

Risk assessment

What must be true

• At least 5 of the first 10 target accounts will share enough data to build a joined trip ledger without a multi-quarter custom integration project.
• Refund, reversal, or reward exceptions are severe enough at scaled travel-fintech accounts to support a $250k-plus annual software budget after pilot proof.
• A read-only overlay catches at least 70% of material wallet-accuracy exceptions before customer escalation in early pilots.
• At least half of paid pilots convert to production because the product improves refund SLA, support effort, or leakage visibility in measurable terms.
• Horizontal payment orchestration, issuer stacks, and internal ledgers still leave enough unsolved trip-native workflow pain to preserve win rates above 25% in the beachhead.

Open diligence questions

• Which exact exception classes cause the most support cost and margin leakage today: missing rewards, delayed refunds, failed reversals, or merchant-settlement mismatches?
• What minimum data set will issuer, PSP, OTA, and loyalty partners provide to a third-party ledger vendor in the first deployment?
• Who owns budget when the pain spans payments, finance, product, and support rather than one function?
• How often do scaled OTAs decide to extend an internal ledger instead of buying a shared control plane?
• Can the company stay outside regulated funds handling while still delivering enough workflow value to justify enterprise pricing?

Model sanity

• Revenue engine. Base-case revenue is driven by active logos rising from 2.0 at Y1 end to 5.02 at Y3 end while blended annual revenue per logo moves toward $336K.
• Must go right. The company must keep data-join deployments under 90 days so the month-15, month-18, and month-22 conversions happen before the narrow 12-logo SAM gets saturated.
• Model breaks if. The downside case shows that a one-logo miss in Y2 plus higher churn nearly exhausts cash, leaving only about $43K at the trough.
• Next-round proof. A credible next financing requires 4-6 production logos, repeatable connector reuse, and at least two workflow expansions that show the read-only wedge can broaden.

Scenarios

Sensitivity

flowchart LR
  TargetAccounts --> PaidPilots
  PaidPilots --> ProductionLogos
  ProductionLogos --> PlatformAndUsageRevenue
  PlatformAndUsageRevenue --> GrossProfit
  GrossProfit --> Cash

Flags: Base case still depends on winning roughly 5 paying logos from a research-defined near-term SAM of about 12 accounts, so a few competitive losses matter a lot. · Revenue per FTE remains below mature software benchmarks because early deployments still require solutions work and connector upkeep. · The model only reaches the BP target gross margin in Y3; if connectors stay bespoke or buyers demand more implementation support, payback and runway will worsen.

• Platform bundling. Large OTAs, issuers, or PSPs may try to assemble similar reconciliation workflows internally once the pain becomes visible. Mitigation: Win on faster deployment, trip-native data modeling, and cross-vendor visibility that would take months of coordination for an internal team to reproduce.
• Category concentration. If only a handful of Indian travel-fintech platforms reach enough scale, the initial customer base could be narrower than it appears. Mitigation: Start in travel-first apps, then expand the same ledger into airline ancillaries, loyalty partners, and broader destination-commerce platforms that share the same cross-rail problem.
• Regulatory and rail complexity. Changes in card-network, RuPay, or UPI rules could break integrations or make some flows harder to automate. Mitigation: Position as an orchestration and reconciliation layer, keep policy rules configurable by rail, and build close partnerships with issuers and PSPs that absorb scheme changes early.