13.1 Introduction

Digital currency has revolutionised payment methods, with respect to methods such as Paytm wallet, BHIM UPI, net-banking and mobile banking. This has made us think about leveraging such existing trends but use it for the greater good of the common people who regularly use hard cash for the most mundane daily tasks, which includes commuting by bus. India has many people commuting by bus every single day, and only the conductor knows how hard it is to keep track of people, who has got the tickets, and how much change he owes the passengers. Regular passengers take a monthly pass, others keep digging in their pockets, bags, and wallets for change [1]. Enter OOPS (offline-offline payment system). Imagine an offline PayTm wallet but for bus commuting; that represents a version of our project. Here, the passenger, when signing up for the scheme, pays an appropriate amount (let’s say Rs.100) as deposit and puts up an additional amount for whatever the user needs for commuting, using the same logic as Paytm wallet, in the OOPS virtual wallet [2]. When riding the bus, the passenger opens our mobile app (“passenger-app”) and asks the bus conductor for a ticket from his/her starting point to the destination. The conductor uses our conductor-app on the device to make connection with the passenger with audioQR (near sound data transfer) technology, which is what Google Pay uses. The passenger transfers the money from the virtual wallet to the conductor’s account; if the transfer is successful, the conductor sends the ticket confirmation to the passenger along with an updated balance on the passenger’s wallet. The transaction details include: unique transaction id (number indicative of bus route, bus number, and bus conductor), unique passenger id, starting point, destination, the bus tariff, balance to be updated on the passenger wallet, and finally a time stamp of the transaction. Up to this point, the entire procedure is carried out offline. The process requires no internet connectivity, only the need for two android phones, one having the passenger-app and the other having the conductor-app [3]. Near Sound Data Transfer (NSDT) is a sound-based portable exchange innovation, created and protected by Tagattitude since 2005. NSDT utilizes the idea of one-time password (OTP), which is sent through the sound channel of a cell phone, to make an electronic mark to perform secure exchanges. This technology is compatible with all smartphones used in the world because it uses the device’s audio channel (speaker and microphone) for the transaction. The primary use of NSDT is for mobile banking transactions through the mobile platform Tagpay [4, 5]. It is a way of enabling authentication on websites by securely “opening doors”.

13.2 State of the Art

This is an offline payment app. The basic working of this system is that payment can be made offline, i.e., without internet connection. This is exhibited when the payments are queued, while not connected to the internet. Given below in Table 13.1 is a literature survey of the offline payment trend in India vs abroad.

TABLE 13.1
Offline Payment Trends in India

Bitcoin, which is an appropriated method of exchange wherein a bank plays no role, is an effective cryptocurrency. The preparation expenses to the banks are reduced, which is a helpful and favorable position. On the other hand, its exchanges are open, and sensitive exchanged information can be followed by other people. This is a significant disadvantage [6]. Likewise, the size of the e-coin steadily increases with every exchange and consequently limits the number of clients.

Some e-payment systems proposed have security imperfections: an assault on the detection of double spending, possible fashioning of the expiration date of a legitimate e-coin, and cheating on the exchange convention. In these systems, an intruder can pull back coins without inputting their real identity, and forge a legitimate coin utilizing the homomorphic property of modular operations [7, 8]. Thus, most of the recent schemes proposed contain some major flaws, resulting in security issues, and, hence, they are not deployable. None of them have been accepted globally (Table 13.1).

13.3 Problem Statement

With OOPS, we can make fast transactions because payments are made offline, and the details are later synced with our server online. We can help with live bus tracking, which is a superpower every Indian aspires to have. If the conductor has internet connectivity, we would be pushing bus ticket transactions to the cloud (“firebase” in our scenario); otherwise, transactions will queue the next time the conductor has internet access to post them as batches [9]. At the end of every bus ride or at the end of every day, the conductor has to upload the bus ticket transactions. This is essential and is a convention followed in the ordinary ticketing system as well. If the conductor has prolonged internet connectivity, as mentioned in the above scenario, we can also do bus live tracking, which usually every passenger in the world dreams of.

13.4 Proposed System

In our system, the user has to create an account with the help of the mobile number after he/she installs the application (“app”). The mobile number is verified with the help of an OTP. Next, the user has to lodge money into the OOPS virtual wallet, with the help of a debit/credit card. To purchase the ticket, the passenger has to select “buy ticket”, at which point audio signals are sent from the phone. The conductor has to receive the audio signal from the passenger’s phone. The details of the ticket received, namely the amount and ID, are visible on the conductor’s screen. The passenger can retry if the transaction fails for any reason [10].

The passenger, conductor, and the bus depot management interact with the system directly. All are given initial access to the internet, with the bus depot being an exception by having an internet connection at all times. The communication between the bus passenger and bus conductor is direct and both parties interact directly with the software through the developed interface. The bus service management accesses the entire system directly. Fig. 13.1 shows the appropriate Process Flow Diagram

13.4.1 System Architecture

We used multi-modular MVVM architecture for the Android app. There are a lot of other software architectures that exist, like MVC (Model View Controller), MVP (Model View Presenter), MVVM (Model View ViewModel), MVI (Model View Intent), VIPER, MOBIUS, and MVRx (Model View Reactive extensions), etc. But the most popular ones are MVP and MVVM. Since the start of Android phone development, there has been no specific architecture or guidelines given by anybody, so everyone could choose whatever system suited them. This resulted in inconsistencies among projects in various organizations, which put the burden on developers to learn many different architectures. But to maintain standards, people started using MVP architecture [11]. Soon, people realized that this architecture cannot scale so Google themselves released a guide to app architecture. This architecture was based on MVVM architecture, with the simple addition of a repository layer.

MVP uses a more generalized version of MVVM but, in Android, we have multiple sources of data, like local SQLite Database and remote REST API source. To manage this multiple data source, we have to use a layer called Repository. Repository depends both on local DataAccessObjects (DAOs) and remote WebServices to provide data to ViewModels, which Views observe. Fig. 13.2 shows the System Architecture.

In real life, the repository first returns a whole table as an observable variable, which will be empty at first. After this, the repository immediately makes a REST API call to fetch data and insert them into the database and now, since UI (View) is observing the database, it will now show the updated data. This is a simple example of reactive programming [12].

13.4.2 Internal Architecture

The modules defined are as follows:

• Models
• Local
• Remote
• Repository
• Common
• Feature-Authentication
• Feature-Passenger
• Feature-Conductor
• Core/App

After the passenger taps the “Buy Ticket” button, the app generates audio signals using the device’s speaker.. Fig. 13.3 shows the corresponding Internal Architecture

The app will support recharging the virtual wallet through a number of payment methods, such as credit or debit cards issued by almost all the banks in our country. Only a person with a verified mobile number is allowed to make transactions (payments/lodgments) though this app, for security reasons. In case of any money thefts, the owner of the mobile with that particular mobile number will be held responsible.

After the end of each working day, in the bus depot, the summary of the transactions is uploaded online, for calculating the profit, and for maintenance of the record. The server in the bus depot is connected with a cloud service for database management and processing needs. In this way, we have eliminated the need for a local database.

13.5 Results and Discussion

The application we designed was perfectly able to send and receive money from the passenger side and the conductor side, respectively. The audio signals worked correctly as expected and, even when on noisy public transport, like a local bus, the app was able to send and receive the audio signals with correct results.

The concept of the one-time password (OTP) ensures that only genuine customers can transact through this app, and no person is able to impersonate someone with his mobile number. Since the medium of communication is an audio channel, there is no need for special encryption/decryption mechanism for safety. The local transaction ensures that no hacker can intercept and/or steal any information from the system. The non-dependence on internet connectivity is a major plus point as it can be used in remote areas where network signals can be intermittent and/or very weak. Also, analysis of the trends in ticket purchase can be carried out on the data on the central database, which is updated at the depot every day after the working day has ended. Fig. 13.4 (a)-(c) show a working demonstration of the app.

13.6 Future Scope

Efforts are already being made to improve upon this initial model. With the use of Big Data technologies at the server end, it would become a lot faster and more secure to store the cumulative data. This will be helpful in finding variations and trends in the travel sector. More transport facilities could be deployed on busy routes, whereas, on routes where travel is less frequent, the frequency of the vehicles could be reduced. Machine learning is a domain in which we can focus our efforts for providing smart solutions, using facial recognition, combined with other biometrics for additional security.

There is always scope for improvement in any of the systems built. Even if the slightest of changes can enhance the system, the change should be considered; the security mechanism and the audio speed could be further improved, for example, if we use a different medium of communication. Security mechanisms, which are standard and widely accepted, can be used in the wireless communication, to achieve greater security. Newer security issues are arising each day, and maintenance of the security of the system is considered a challenging task these days.

13.7 Conclusion

In our paper, we have proposed a model for an offline payment system which is better than the payment apps which are on the market today, because our application does not depend solely upon internet connection. In a country like ours, where a majority of the population lives in remote areas, having an internet connection all the time is a very challenging task. So, our application can work well in those areas. Also, during natural calamities, when the communication systems are completely shut down, this application can turn out to be a life saver in terms of transport; it could also be adapted to allow the purchase of important items. Having a cloud service at the back end enables us to have data stored and retrieved faster, thus eliminating the need for having a local database and a server maintenance person at all times. Cloud storage also keeps the data more secure. Looking at the amount of data thefts and other security attacks, our system will be able to cater to the changing security needs as our means of data communication, namely audio waves, is very secure.

References

1. 1. Mrs. Dhanalakshmi Komirisetty, Mr. B. Sarath Simha . A Study on Paytm’s Growth in India as A Digital Payment Platform. International Journal of Research and Analytical Reviews (IJRAR) 5(4), December 2018.
2. 2. Abdullah Al Rahat, Kazi Md. Rokibul Alam, R. Tahsin, G.G. Md. Nawaz Ali . All Offline Electronic Payment System Based on an Untraceable Blind Signature Scheme. KSII Transactions on Internet and Information Systems 11(5): 2628–2645, January 2017.
3. 3. Karamjeet Kaur, Dr. Ashutosh Pathak . E-Payment System on E-Commerce in India. International Journal of Engineering Research and Applications 5(2): part 1, February 2015.
4. 4. P.S.V.S. Sridhar, T.V.S. Rohitkumar, G. Dharani, V.B.S. Akhila . Introducing Secured Offline Payments using FRoDO. International Journal of Innovative Technology and Exploring Engineering (IJITEE) 8(7s), May 2019.
5. 5. Bazeem Ismaeil Khan, Zubair Ahmed Shaikh . Secure Device for Offline Micro Payment. International Journal of Emerging Trends & Technology in Computer Science 24(4): 33–37, March 2017.
6. 6. T. Takahashi, Akira Otsuka . Secure Offline Payments in Bitcoin, Institute of Information Security, Yokohama, Japan. Available at https://fc19.ifca.ai/wtsc/SecureOfflinePayments.pdf.
7. 7. Siamak Solat . Security of Electronic Payment Systems: A Comprehensive Survey. Available at https://arxiv.org/ftp/arxiv/papers/1701/1701.04556.pdf.
8. 8. R. Bargavi, Dr. L. Jaba Sheela . Fraud Resilient Device Offline Micro-Payments using Bit-Exchange Algorithms. International Journal of Engineering and Computer Science 6(3): 20699–20704, March 2017.
9. 9. P. Shana Jebin . PayOff: An Approach for Offline microPayments. International Journal of Innovative Research in Computer and Communication Engineering 5(3), March 2017.
10. 10. Ki-Woong Park, Sung Hoon Baek . OPERA: A Complete Offline and Anonymous Digital Cash Transaction System with a One-Time Readable Memory. IEICE TRANSACTIONS on Information and Systems 100(10): 2348–2356, October 2017.
11. 11. Prasad A. Naik, Kay Peters . A Hierarchical Marketing Communications Model of Online and Offline Media Synergies. Journal of Interactive Marketing 23(2009): 288–299, November 2009.
12. 12. Dennis Abrazhevich . Electronic Payment Systems: A User-Centered Perspective and Interaction Design. Available at https://pure.tue.nl/ws/files/2396269/200411085.pdf.