On this page · 10 sections
- Decision 1: distribution, and the free tier that closed
- Decision 2: NDC and offers-and-orders, without the hype
- Decision 3: refunds are a product requirement, not a support process
- Decision 4: recurring payments after 21 April 2026
- Decision 5: maps and routing costs, and the India threshold
- What eCorpIT builds for travel products
- India-specific considerations
- FAQ
- How eCorpIT can help
- References
Summary. The default starting point for a travel app prototype no longer exists. Amadeus decommissioned its self-service developer portal on 17 July 2026 and disabled the API keys on that date, so a 2026 build begins with a commercial distribution agreement rather than a free tier. Three other things moved with it. The RBI E-mandate Framework 2026, dated 21 April 2026, repealed eight earlier circulars and caps unauthenticated recurring charges at ₹15,000 per transaction. DGCA requires a portal-booked refund to complete within 21 working days, with the onus on the airline. And 51 of the 64 new PCI DSS v4.x requirements became mandatory on 31 March 2025. Distribution, refunds and payments now decide more of a travel app's cost than the interface does.
Most travel app briefs that reach us describe screens. Search, results, seat map, payment, itinerary. The screens are the cheap part. What determines whether the product is viable is which distribution channel you can actually get access to, what your refund obligations cost to service, and how many payment failure modes your checkout has to survive. This page covers those five decisions, then how we build.
Decision 1: distribution, and the free tier that closed
Almost every travel app tutorial written before mid-2026 starts with the Amadeus Self-Service APIs, because they had a free test quota and self-serve signup. That route is closed. PhocusWire reported that Amadeus paused registration for new users and fully decommissioned the portal for existing users on 17 July 2026, from which date API keys were disabled and the portal became inaccessible. An Amadeus spokesperson said: "We are decommissioning only the self-service section of the Amadeus for Developers portal." The enterprise side continues.
The practical consequence is that content access is now a contracting exercise before it is an engineering one. Travelport's API and SDK terms of use are explicit that they "form part of and are incorporated by reference into the Developer Contract", that "the charges for the Service, if any, are specified in the Developer Contract", that invoices fall due within 30 days with interest accruing at 1 percent per month, and that "all Charges are non-refundable". No public rate card exists on any major GDS site. Any figure you have seen quoted for GDS setup or annual cost came from a third-party estimate, not the vendor.
Two clauses in those terms shape architecture directly. Travelport requires developers to comply with "then-current Payment Card Industry Data Security Standards" and to provide proof of compliance on request, which pulls PCI scope into the integration itself. It also forbids using the service to perform queries and then complete bookings through a third party's system, which rules out the cheapest multi-source design: shop on one provider, book on another.
Budget the contracting timeline explicitly. A four-month build against a distribution agreement that takes five months to sign is a project that ships late for reasons no engineer can fix.
Decision 2: NDC and offers-and-orders, without the hype
The standards picture is genuinely important and routinely overstated.
IATA's NDC fact sheet, dated June 2026, describes NDC as "a data communication standard via an API that enables sellers to interact with airlines to shop, order, pay, and service products & services using Offer and Order standards". The schema line has moved on: the fact sheet notes that "the new generation of schemas introduced with NDC 24.1 and beyond offers incremental but significant advancements" over the 21.3 generation. Airline capability is tracked through the Airline Retailing Maturity index and its public ARM registry, which is the right place to check what a specific carrier actually supports before you promise a feature.
Willie Walsh, Director General of IATA, described the destination at the 80th IATA AGM on 3 June 2024: "Modern Airline Retailing will serve air travelers better, by replacing complex legacy processes of tickets, PNRs, and EMDs with a system of 'offers and orders' that will parallel what most other retailers use."
The date attached to that in trade coverage deserves care. IATA's own industry vision for offers and orders says the Distribution Advisory Council "is considering an aspirational goal of 100% Offers and Orders by 2030, with the possible sunset of legacy standards", and the footnote on the same page adds that this "does not imply that the industry will be 100% Offers and Orders by 2030". The NDC fact sheet is blunter still: "it remains each airline's responsibility to individually assess the opportunity for NDC adoption and to decide their best timelines. IATA will not prescribe a specific course of action."
Design accordingly. Build an internal offer and order model, because that is where the standard is going and ONE Order merges the ticket, EMD and PNR into a single record. But do not build a product that assumes every carrier will be there on a fixed date, because no such deadline has been published.
| Integration route | What it gets you | The constraint to plan for |
|---|---|---|
| GDS via Developer Contract | Broad multi-carrier content, settlement | Contract-only pricing, 30-day invoice terms, PCI proof on request |
| Direct airline NDC API | Richer offers, ancillaries, servicing | One integration per carrier; capability varies by ARM level |
| Aggregator or consolidator | Fastest route to inventory | Margin sits with the aggregator; less control over servicing |
| Hotel and car supplier APIs | Cross-sell revenue | Separate contracts, separate cancellation rules |
| Amadeus Self-Service | Was the free prototyping route | Decommissioned 17 July 2026 |
| Bed bank or channel manager | Property inventory without direct deals | Rate parity and allocation rules bind the UI |
Decision 3: refunds are a product requirement, not a support process
Indian regulation writes part of your cancellation flow for you.
DGCA's Civil Aviation Requirement, Section 3, Series M, Part II, Refund of Airline Tickets to Passengers, sets three timelines. Credit card refunds go back to the cardholder's account within seven days. Cash purchases are refunded immediately at the office of purchase. And where the ticket was bought "through travel agent/portal, onus of refund shall lie with the airlines as agents are their appointed representatives", with the airline required to ensure "the refund process is completed within 21 working days".
Four more clauses in that requirement are product decisions, not policy footnotes. Statutory taxes and user development, airport development and passenger service fees are refundable on cancellation, non-utilisation or no-show, including on promotional fares where the basic fare is non-refundable. A 48-hour look-in option lets a passenger cancel or amend without additional charges, subject to the stated departure windows. Holding money in a credit shell "shall be the prerogative of the passenger and not a default practice of the airline", so a checkout that defaults to wallet credit is non-compliant. And "the airlines shall not levy any additional charge to process the refund", which removes a revenue line some product plans assume.
Separately, Series M, Part IV, revision 4, dated 25 January 2023 and effective 15 February 2023, sets denied boarding, cancellation and delay compensation, with amounts of ₹5,000, ₹7,500 and ₹10,000 by block time. Build the entitlement calculation into the booking record rather than leaving it to a support agent with a spreadsheet.
Decision 4: recurring payments after 21 April 2026
If your product sells a subscription, a travel pass, or an instalment plan, the rules changed this year.
The RBI consolidated everything into the Digital Payments E-mandate Framework, 2026, dated 21 April 2026, which repealed eight earlier circulars including the foundational August 2019 instrument. Any integration guide still citing those circular numbers is describing repealed law.
The operative numbers: recurring transactions may be authorised without additional factor authentication up to ₹15,000 per transaction, and above that AFA applies. The higher ₹1,00,000 threshold is reserved for insurance premiums, mutual fund subscriptions and credit card bills, and travel is not in that list. The issuer must send a pre-transaction notification "at least 24 hours prior" to the debit. The first transaction under an e-mandate always requires AFA validation. No charge may be levied on the customer for the facility. The acquirer must ensure compliance by the merchants it onboards, which means your payment partner will push those obligations into your contract.
Two details matter for a travel product specifically. The framework covers recurring transactions "domestic or cross-border", so an international booking flow is in scope. And this edition allows existing e-mandates to be mapped to reissued cards, which removes a churn source that used to break annual passes silently. We set out the implementation sequence in our RBI e-mandate directions 2026 recurring payments engineering checklist.
On card security, 51 of the 64 new requirements in PCI DSS v4.x became effective on 31 March 2025, per the PCI Security Standards Council. Two land on small travel merchants who previously had a light path: requirement 11.3.2 now expects merchants completing Self-Assessment Questionnaire A to run quarterly scans by an Approved Scanning Vendor, and requirement 12.5.2 adds an annual scope confirmation. Version 3.2.1 was retired on 31 March 2024, so v4.0 and v4.0.1 are the only active versions.
Decision 5: maps and routing costs, and the India threshold
Travel apps are map-heavy, and the unit economics differ by market in a way that catches growth models out.
Google publishes a separate India rate card alongside the global one, both updated 11 August 2026, and both quote prices in USD rather than rupees. On the India card, Compute Routes Essentials carries a 70,000-event monthly free cap and then costs $1.50 per 1,000 events. The global card gives 10,000 free events and starts at $5.00 per 1,000. Navigation Request is $8.00 per 1,000 in India against $25.00 globally, on a 7,000-event free cap rather than 1,000.
The trap is the convergence point. The India card is a two-tier structure whose rates equal the global card's 1,000,001 to 5,000,000 tier and its 5,000,000-plus tier. Below one million monthly events India is roughly three times cheaper. From 1,000,001 events the two cards are identical, and the India card simply stops at ten million events, above which Google directs you to sales. A model that extrapolates the cheap India rate to scale will understate map cost by a factor of three at exactly the point the product succeeds. The same arithmetic applies to any location-heavy build, which is why we cover it on our taxi app development company and on demand app development company pages.
What eCorpIT builds for travel products
eCorpIT is eCorp Information Technologies Private Limited, founded in 2021, with its engineering office at Sector 83, Gurugram. We hold CMMI Level 5, ISO 27001:2022 and MSME certification, and we are partners of AWS, Microsoft, Google, Shopify and Kaspersky.
For travel and hospitality the work falls into four shapes. A booking front end over supplier content, with search, fare rules, ancillaries and seat selection. A mid-office layer holding the offer and order model, so supplier changes do not reach the app. A payments and refunds engine that implements the DGCA timelines and RBI mandate rules as code rather than as runbook steps. And an operations console for the team who handle schedule changes, because that is where the support cost actually lives.
Delivery runs in five steps. Scoping produces a written specification and an architecture decision record covering which supplier route you can realistically contract. A design and integration spike resolves the highest-risk supplier dependency before any timeline is committed. Sprint delivery runs with a senior-led team and your product owner in the review. A hardening phase covers performance under fare-search load, security review and card-data scope reduction. Handover comes with runbooks, or a managed arrangement if you would rather keep us on.
The stack is picked against the problem: React and Next.js or Astro on the web, React Native or Flutter for mobile, Node.js or Java for the booking services, PostgreSQL with Redis for fare caching, and AWS or Google Cloud with Terraform underneath. Offline-first behaviour on the mobile client matters more in travel than in most categories, because travellers open the itinerary screen in airports and on aircraft where connectivity is poor, so the itinerary, boarding pass and support contact path are built to work from local storage.
On engagement, we quote against a written scope rather than publishing a rate card, and for products with real supplier unknowns a dedicated team usually costs less over twelve months than three consecutive fixed-scope phases. Related pages: our travel and hospitality app development service, Flutter app development company for the cross-platform route, and the wider mobile app development company in India view.
Where personal data is in scope we build to Digital Personal Data Protection Act requirements; we do not claim certification under a framework we do not hold.
India-specific considerations
An India-facing travel product carries three obligations a generic build does not. The DGCA refund timelines apply to the portal even though the onus sits with the airline, which means your reconciliation has to prove what you passed on and when. The RBI e-mandate ceiling of ₹15,000 sits below the price of a single international ticket, so any instalment or pass product needs an authentication step designed into the flow rather than bolted on. And map costs are cheaper only up to the one-million-event threshold, which a domestic travel app can cross in a single festival season.
The honest engineering judgement is that the interface is rarely what sinks a travel product. Supplier access and refund servicing are.
FAQ
How eCorpIT can help
We start a travel engagement with the supplier question, because the answer changes the architecture and the timeline more than any other input. That scoping produces a written specification, an architecture decision record, and a realistic view of how long your distribution contract will take to sign. From there we build the booking front end, the offer and order layer, and the refunds engine that implements the DGCA and RBI rules in code. Tell us which suppliers you already have access to and when the product has to be live: /contact-us/.
References
- API and SDK policies and terms of use — Travelport.
- Google Maps Platform pricing, India — Google, updated 11 August 2026.
- Google Maps Platform pricing, global — Google, updated 11 August 2026.
- CAR Section 3, Series M, Part IV, Rev. 4: denied boarding, cancellation and delay — DGCA, effective 15 February 2023.
- Digital Payments E-mandate Framework, 2026 — Reserve Bank of India, 21 April 2026.
- Now is the time for organizations to adopt the future-dated requirements of PCI DSS v4.x — PCI Security Standards Council.
Last updated: 16 August 2026.
