39. Payments in — Travel

Mankind invented wheel in 3500 B.C. and since then that wheel is revolving… today we have various modes to travel and when they say ‘world has become smaller’ then it is true… once as a family, we travelled from Walldorf, Germany to Venice, Italy in cab, bus, train, flight and boat in a single day… and in a single day. Thanks to multiple travel modes and online bookings…

There are various types of travel merchants:

• Operators: Companies that run the vehicle and it can be bus (e.g. VRL) or Flight (e.g. SpiceJet)
• OTAs (Online Travel Agents/Aggregators): Companies that sell tickets of these operators (e.g. Abhibus — where I can buy tickets of one of the many bus operators or MakeMyTrip — where I can book flight ticket of any airline )

Travel merchants sell tickets through various channels

• Website / App: Where users can visit and buy tickets
• Agents: Who buys ticket inventory from operators or OTAs and sell to customers (individuals or companies)

And not to forget the platform companies who provide software (kind of ERP/booking engine) for the operators. E.g. Bitla Soft

Let’s talk about payments:

Payment requirements are almost same as that of eCommerce sectors… so refer the earlier chapter for details… Here is brief snapshot

• Use Cases: Purchase of tickets
• Channels: Website, mobile Apps, mSite
• Payment modes: CC, DC, NB, UPI, Wallets, pay later products etc.
• Seamless payment flows (checkout experience)
• Performance: maximum uptime and scalability
• Success rate: Critical
• Refund management: Especially when ticket sizes are larger
• Charges: Typically same as eCommerce rates (with exceptions) and get flat rate on Net-banking for B2B transactions i.e. when agents or companies buy tickets/inventory
• Settlement: Earlier settlement will come handy in case OTA or Agent has to pay to the operator to buy the inventory

Other requirements:

Illustration — Random Bus

What is the unique thing about travel merchants…. ?

Here is the bus that is scheduled to go to Mumbai from Bangalore on 23rd Jan and bus has 20 seats.

To maximise the sales of seats, the seats are distributed and sold by various entities such as the bus operator (on its website/app), OTAs and agents of operator & OTAs.

Here are the things that need to be considered

(i) seat inventory is limited (as there are only 20 seats)

(ii) Inventory has expiry date (bus is leaving on 23rd Jan)

(iii) Can’t sell same seat to two customers (The fight it may trigger in bus over the seat will be entertaining to some level but let’s not do it)

These requirements create additional problems/requirements w.r.t. payments

a. Pending transaction:

Let’s say you are booking the yellow seat (above illustration). If transaction is successful then merchant issues the ticket and if transaction fails then seat is released back to inventory… but what will merchant do if the transaction goes into ‘pending’ state?

Transaction can’t be in limbo for long… so merchant has to take action… one of the ways is wait for 15–20mins and try to fetch latest transaction state (if transaction is successful then issue the ticket) but if transaction is still in pending state then release the inventory and mark the transaction for auto-refund (if transaction becomes successful eventually)

Note: This method is useful for any merchant which have to take action in finite period (e.g. food delivery — need to place order with restaurant and gaming merchants — need to add the funds to user can participate in game without before start of the game)

b. Reducing refunds due to multi-system interaction:

Let’s say the booking system needs to interact with operator (E.g. IRCTC) to issue the ticket and operator’s system failed to respond back then what will merchant do? Merchant either wait indefinitely or initiate refund for the customer so customer can book another ticket. But as you know, refunds are cumbersome and expensive.

In such cases, Pre-Authorisation can be useful feature where amount is blocked temporarily and debited or voided depending on the status from operator. With this feature, merchant can avoid all refund related hassles, save on TDR and give better user experience. This is not flawless solution as solution works only on selected instruments (Credit & debit cards of Visa and MasterCard) and all issuers do not respond correctly all the time.

Illustration: Pre-Auth scenarios

Illustration:

Let’s say user wants to book two tickets for Rs.1000 and PG charge is 1.80%. So below are the use cases — Full debit, void and partial debit (this case may not be useful for travel but quite handy for food delivery or grocery merchants who fail to fulfil entire order)

Operators are selling tickets on OTA and after exhausting its channels, OTAs are selling tickets on eCommerce sites (and soon eCommerce companies will start selling ‘tooth brush’ on travel portals… never know)… not sure what to call these models but for now these things look like ‘Russian Nesting Dolls’

Travel is one of the fastest growing segment as people are travelling for leisure, emergency, business and what not… and still most the transactions are not done online so there is huge scope for these companies and for online payments.