Ηλεκτρονικές και κινητές πληρωμές με χρήση σάρωσης QR Code
Electronic and mobile payments using QR Code scan
QR Code Services App is an Android application that undertakes to execute on-line direct transactions. The application consists of two parts. One part concerns the android application that is installed on the user's device and the second part of the software embody the side of the bank. The latter, developed with Java and Spring boot framework. The bank, as usual, after the necessary checks, responds with messages, which include information about a successful or a failed transaction as the content. In the case of a failed transaction, the response contains error codes and logs that describe the reason of the failure. At the successful responses, there are no error codes but there are code indications of a successful transaction containing more transaction-related information such as the payment code or ID. On the other hand, the first part of the app (Android app) is a native application, and its purpose is to simplify the purchase process of a product compared to the existing traditional processes and payment methods we already know.The user of the application simply scans a QR Code on a product, whether or not it has a physical nature, for example, such a product may be a bottled water (physical material) or the purchase of a product on the Internet (the air ticket market - intangible material) and the application decodes the QR Code, extracts the information of interest, for example, information about the trader, such as Walmart and the product, for example the name of the product and its price. It then processes these data and a combination of pre-agreed information is displayed on the mobile user screen. The user, has always under his control the continuation of the upcoming market or its cancellation. If selected to proceed, the user is taken to the next screen and has to choose one of the debit/credit cards for example (VISA, MASTER CARD, DISCOVER) or an IBAN account, depending on which cards and accounts he has previously registered. It should be emphasized that the application, for simplicity reasons of presentation, considers that the user has previously stated a series of his own debit / credit cards and account (s). In the present embodiment, this information is declared in an xml file, but in a commercial version of the application, the application should allow the user to add, remove, or modify these elements through separate and dedicated screens. After selecting the card or account from which the money will be deducted, the user is also prompted to enter the pin. The pin is a four-digit numeric data and subjects to various checks. Only numeric digits are allowed and the pin’s length, has a restriction of four digits, otherwise the application posts relative error messages in red shades and focuses in the pin field until the user gives the correct combination. Although the implemented application is a demo version and not a market one, it would not be a problem to allow any combination, however, in order to give more realism, the pins are limited to specific for each card or account. The pin is then encoded and embedded in the request. This information is hidden from the user in the forthcoming sequence of screens and finally stored. It can only be viewed as part of the logged information upon request of the user on a special screen log. The next step is the check which the application does to determine whether or not any wireless or a mobile network exists. In case of a positive outcome, namely if it can acquire any network, after the required authorization (license) of the user, it sends a request to the bank (the second part of the application software). If within fefteen seconds any timeout occurs, (time out is considered the maximum time which the application waits for the response from the server), then the application responds with a time out response and a relative corresponding message will be displayed on the user screen as an Android toast message to inform for the event. The software that simulates the bank can be installed locally or remotely as well. That is a URL which decides the location and it is set by a special corresponding screen of the app (icon. 16, 17). In the positive outcome of the above response, the application sends the request to the url and the software of the second part of the application takes over the various validity checks of the transferred data and responds accordingly. In any case, either failure or success of the transaction outcome, a dedicated application screen for this reason, is presented to the user by informing him of the outcome status. Also, each result individually, is logged as a record in a Google's remote NO-SQL firebase. Finally, there is a corresponding separate page of the application, which in real time, recovers historical transactions in a list, processes and presents each day grouped and sorted from the most recent event in a fold-out list, solid information about numerical quantities, which show the the totals and the number of successful and failed transactions per day.