RU2672132C2 - Systems and methods of mobile payments - Google Patents

Abstract

FIELD: information technology.SUBSTANCE: invention relates to device for carrying out a purchase operation with the aim of acquiring goods in online stores. Settlement system implemented on the mobile communication device includes: store application or browser application, communication processor that interacts with payment server, settlement application installed on a mobile communication device providing: receiving the payment information of the user, including data from the magnetic strip, from the data carrier from the magnetic strip (MSC) interacting with the mobile communication device, while the MSC stores data from the magnetic strip encrypted in the memory of the MSC for subsequent use in the purchase operation, and interaction with the settlement server to complete the purchase operation of the payment server and display the result.EFFECT: higher security of recording, storage, transmission of data on the magnetic strip of the card, as well as the expanded arsenal of technical means for performing settlement operations.18 cl, 11 dwg

Description

FIELD OF TECHNOLOGY

The present invention relates to systems and methods for implementing the Mobile Wallet application and mobile payments.

BACKGROUND

Data transfer from a magnetic strip is initially carried out when conducting a magnetic card through a magnetic strip reader (NSR) to activate payment, identification (ID) and access to management functions. The interaction of the Mobile Wallet applications on smartphones and tablets with existing POS devices or other devices equipped with SMP caused difficulties. POS terminals equipped with proximity readers (which typically use the ISO 14443 standard) are not so common as to accept contactless payments or payments based on Near Field Communication (NFC) technology. Replacing millions of commercial POS devices or door locks that work only with magnetic cards to ensure their interaction with NFC phones or other data transfer methods like barcodes will require significant financial and time costs.

In many countries, the number of contactless payment cards issued is still small compared to the number of magnetic cards. Contactless NFC chips are built into some mobile phones and are used by companies such as Google and ISIS as digital wallets for storing secure cardholder information. Such NFC-based digital wallets can be used for contactless payments with a limited number of POS devices supporting NFC, and such NFC-based digital wallets have significant limitations.

Most phones do not have a built-in NFC chip, seriously limiting the introduction of this technology of mobile wallets to the masses. Moreover, the process of downloading the cardholder’s payment data to the NFC chip’s memory is complicated and costly. In particular, a trusted security manager (TSM) is required to load the NFC chip into memory. Payment card issuers are forced to use TSM and pay for its services.

There are some technical difficulties in ensuring an uninterrupted download process, especially when some part of it fails in the middle of the data transmission chain by the issuer to TSM, to the Internet, via the networks of mobile operators to the phone, to the chip. Moreover, not all standards have yet been developed, and there are a large number of competitors that make the distribution process even more difficult.

In Internet commerce, basically, there are two general methods for making payments with online purchases. In the first method, the buyer presses the payment button, selects the payment method and completes the payment process on the website of the online store. The seller’s server interacts with the payment system server to complete the payment. The specified method allows the buyer not to leave the seller’s site, remaining on it; however, this interaction process between the merchant’s server and the payment system is complex and costly. At the same time, the mere entry of confidential information on an unfamiliar web page / unfamiliar site may cause the buyer doubts.

In the second method, the customer’s browser is temporarily redirected to the settlement web page of the payment system, such as PayPal ™. The buyer completes the operation directly on the website of the payment system, after which his browser is redirected back to the original website of the online store. This method is easier for sellers to distribute and interact with. The recognition of the payment system also inspires customers with greater confidence and a greater sense of security. At the same time, this method also ensures greater process uninterruptedness, when the buyer has previously used similar payment services.

DESCRIPTION OF THE INVENTION

The present invention describes devices, systems and methods, including a magnetic stripe data recorder, a storage and transmission device used in combination with a mobile wallet application for recording, storing and transmitting magnetic stripe data of a card to POS terminals and other devices equipped with SMP , or in settlement systems operating in a physical and virtual environment. The present invention also describes systems and methods for mobile payments. This system provides customers with convenient shopping, sellers a secure and informative operation, and in some cases, the transfer of additional information to the SMP in order to use loyalty, identification (ID) and access control programs.

In one aspect, a system for securely recording, storing and transmitting magnetic data of a magnetic card of a payment card includes a mobile communication device, a mobile application, and an electronic key transmitter of data from a magnetic strip (MST). An electronic key-PMP or PMP includes a microprocessor, a magnetic field transmitter including a driver and an inductor capable of generating variable magnetic fields, a battery, a power supply unit, a magnetic stripe reader (MSR), a memory or security element, and an audio jack and a communication interface (for example, a USB interface, a 30- or 9-pin Apple interface, Bluetooth, etc.), working in conjunction with a customer’s mobile device and wallet application to record the magnetic stripe data of the card, securely store it and transfer it to POS- devices or settlement systems of sellers in a physical and virtual environment.

Aspects of the present invention may have one or more features. The mobile communication device may have a mobile application that initializes the PMP for use with a specific wallet account and which unlocks the PMP for transfer and use. A mobile communication device can be used with a settlement application on a mobile communication device or on the Internet, which interact with the PMP in order to receive payment card data from the PMP and transmit it to the payment server to perform the transaction as a seller’s POS terminal application or a buyer's settlement application . The Mobile Wallet application can interact with the PMP via an audio jack or other communication interface in various operating modes, including, for example, Initialization and Reset Mode, Card Download and Removal Mode, Transfer and Use Mode, Offline Transfer Mode and POS Card Read Mode .

In one aspect, a PMP operating in Initialization and Reset Mode is configured so that a user can connect or disconnect / reset a specific PMP to a mobile wallet account, allowing only one such device to be used for one account. The PMP operating in the Card Download and Removal Mode is configured so that the user can download the magnetic card data by passing the existing plastic magnetic card of the user through the SMP with which the PMP is equipped and store the data of the track of the car in the memory or safety element. For payment cards, the application downloads information about the main account number (PAN) of the card into a digital online wallet through the Mobile Wallet application. Data on the card can also be deleted from memory and from the server using the specified application. The PMP operating in the Transfer and Use Mode is configured so that the user can select a specific payment card as the default wallet or default card for use when transferring the stored data of the card’s track to the seller’s POS system at the time of pressing or activating the button. In another aspect, if non-payment cards are stored at the PMP, one such card can be stored on it as a default card for transferring without authentication to the Mobile Wallet application and the need to select it. Such cards can be hotel keys and door keys, or ID cards and loyalty cards that can be downloaded to the PMP in its separate memory for subsequent transfer.

The PMP operating in the POS Card Reading Mode is configured so that the user can transfer the payment card through the SMP that the PMP is equipped with and transfer the card data to the POS application on the mobile communication device, and then to the server and processor. The mobile communication device may be a smartphone, tablet or personal computer. The PMP also has a battery and a power supply. The microprocessor is configured to provide security and interact with a mobile communication device. The memory securely stores payment card data. PMP is configured to transmit card track data to the seller’s settlement application on a mobile communication device in order to conduct an operation with the card physically present for the seller. The PMP can also be configured to read payment cards and transfer their data to the address of the mobile communication device and the associated POS application, which subsequently transfers the operation and card data to payment servers and processors, such as POS.

In another aspect, a feature of the invention is a method for securely recording, storing and transmitting magnetic card data. The PMP electronic key consists of a microprocessor, a driver configured to transmit current and a signal to an inductor that generates alternating magnetic fields; battery, power supply, NSR, memory or security element, audio jack and communication interface (for example, USB interface, 30- or 9-pin Apple interface, Bluetooth, etc.), working in conjunction with the customer’s mobile device and wallet application or a mobile application for the secure recording of magnetic card data, their secure storage and transmission to the seller’s POS terminal, billing system or other SMP devices, in a physical and virtual environment.

The systems and methods disclosed in this invention provide several advantages, for example, magnetic card track data can be recorded and stored in the protected memory of the PMD directly by the user or server without changing the magnetic strip data for subsequent use by the SMP device. For payment cards, changing the magnetic strip data is not required, unlike contactless or NFC track data, which has special parts that must be encoded by card issuers for their correct operation with contactless POS without fail. The PMP can be equipped with a button configured to send magnetic card data to the POS address if the PMP is disconnected or disconnected from the mobile device.

In one aspect, the unique binding of the NOS to a specific wallet account can provide greater security, and the ability to reset the NMP allows you to untie and reuse the NMP. Moreover, the system and method in accordance with the present invention provides the ability to connect to a mobile communication device through various interfaces in addition to audio jack and USB. Also, the process of downloading the encrypted data of the magnetic card track to the PMP memory element can subsequently be decrypted and transferred to the SMP with which the POS is equipped, or for data to be transmitted to the mobile communication device in encrypted form and then sent to the payment server for their decryption and processing and to upload a wallet account to a server or to process a POS transaction.

The system and method in accordance with the present invention provide the ability to use the stored or read data of the card track for virtual payments in order to provide greater security and reduce transaction costs for sellers, as well as use the remote download of card track data from the card issuer to the wallet server, in a mobile application wallet on a mobile communication device and in the memory or security element of the PMP for their further use. Moreover, the system and method provide the ability to download information about the premium account (account of loyalty programs) along with payment card data in the discretionary fields of the track data for reading by the issuer during the operation, which can provide the opportunity to use special offers and use loyalty programs in conjunction with payment operations.

Sharing all the aforementioned technologies in an uninterrupted process for customers can increase the frequency of their use of mobile wallets and provide a platform for applications and functions, such as special offers (promotions) and loyalty programs, which will make the process more visual and will also bring all the benefits to customers and sellers.

In another aspect, the magnetic card data can be transmitted to the address of the settlement application of the mobile communication device and used in mobile settlement systems. Systems and methods of mobile payments help to reduce the ratio of imperfect purchases and increase their conversion to sales. It should be borne in mind that the systems and methods of mobile settlements described here can be executed with or without PMP.

Basically, mobile settlement systems and methods include a mobile communication device with a seller’s application installed and / or a browser application installed on a mobile communication device that allows a user to select items to buy on a seller’s website. The settlement application is also installed on a mobile communication device that interacts with the settlement server, which hosts one or more software interfaces of settlement Internet applications (APIs). The settlement application can be launched in response to receiving information about the purchase, for example, when the user selects an item for purchase and proceeds to the calculation (placing an order). The settlement application interacts with the settlement server in order to complete the purchase operation by means of communication with the payment system operator. Upon completion of the operation, the seller’s application or the browser application used to search and select the item to purchase is restarted.

In other aspects, the settlement application may be launched in response to receiving purchase information from the settlement server via a PUSH notification, email, or SMS. The settlement application can also be launched in response to receiving information about the purchase using the QR code displayed on the mobile communication device.

BRIEF DESCRIPTION OF THE DRAWINGS

Variants of the design of devices, systems and methods are presented in the figures of the accompanying drawings, which are illustrations and are not restrictive, in which the links refer to similar or corresponding parts, where:

FIG. 1 is a functional block diagram of a general view of a PMP, a mobile communication device, and a seller’s POS device;

FIG. 2 is a sequence diagram of a method of operating in the Initialization and Reset Mode;

FIG. 3 is a sequence diagram of a method of operating in a mode of loading and deleting a card;

FIG. 4 is a sequence diagram of a method of operating in a Transmission and Use Mode;

FIG. 5 is a sequence diagram of a method of operating in an offline transmission mode;

FIG. 6 is a sequence diagram of a method of operating in a Read Mode of a POS card;

FIG. 7 is a functional block diagram of a general view of a mobile settlement process execution system;

FIG. 8 is a functional block diagram of components of a mobile communication device;

FIG. 9 is a sequence diagram of a method for performing a mobile settlement process using an online store website and a mobile shopping application;

FIG. 10 is a sequence diagram of a method for performing a mobile settlement process using an online store website and a browser application; and

FIG. 11 is a sequence diagram of a method for performing a mobile settlement process by launching a settlement application using a PUSH notification, SMS, or QR code.

DETAILED DESCRIPTION OF THE INVENTION

The following is a detailed description of the design options for devices, systems and methods, however, it should be borne in mind that they only illustrate devices, systems and methods that can be executed in various forms. Thus, certain functional characteristics described herein should not be construed as limiting, but merely as the basis of the claims and as a demonstration of how the present invention is used by those skilled in the art.

In general, the devices, systems, and methods described herein can include and can be applied to a number of different devices and computer systems, including, for example, general-purpose computer systems, server-client computer systems, client-seller computer systems, universal computer systems, cloud computing infrastructure, telephone computer systems, laptops, desktop computers, smartphones, cell phones, handheld computers (PDAs), tablet computers and other mobile devices. Devices and computer systems may have one or more databases, as well as other storage media, servers, and additional components, such as processors, modems, terminals and displays, computer readable media, algorithms, modules and applications, and other computer related components . Devices and computer systems and / or computer infrastructures are configured, programmed and adapted to perform the functions and processes of the systems and methods described in this invention.

The General scheme of the system 10 for recording, storage and transmission of magnetic card data to the address of the point of sale (POS) of the seller in accordance with the design is given with reference to FIG. 1. The System 10 includes a PMP 100 adapted to interact with a mobile communication device 200. The PMP 100 and the mobile communication device 200 may communicate through audio jacks 102 and 202 and / or through appropriate communication interfaces, including but not limited to USB ports 104 and 204, respectively, or through other interfaces, including but not limited to 30- or 9-pin Apple, Bluetooth, and other serial interfaces. The PMP 100 also interacts with the seller’s POS 300, being adapted to transmit magnetic strip data from the magnetic field transmitter 150, including the driver and inductor, to the SMP 302 that the seller’s POS 300 is equipped with.

Mobile communication device 200 includes a Mobile Wallet application 220 and a POS application or a settlement application 230. A Mobile Wallet application 220 initializes and unlocks the SMS 100. The POS or settlement application 230 interacts with the SMS 100 and receives payment card data from the SMS 100. POS or settlement application 230 may facilitate the transfer of payment card data to wallet server 260 via network 170. Payment card data can then be transferred from wallet server 260 to the address of payment system operator 270.

The PMP 100 includes a microprocessor 112, a light emitting diode (LED) 114, a battery 116, a power supply 118, an SMP 106, a memory component or security element 108, an audio jack 102 (for example, 3.5 mm or another standard audio port), USB -port / jack 104 or other communication interface, including, but not limited to 30- or 9-pin Apple interfaces, Bluetooth and other serial interfaces, as well as a magnetic field transmitter 150, including a driver and an inductor for transmitting magnetic pulses to any POS- a device equipped with an SMP.

Microprocessor 112 is responsible for security and interconnection with mobile communication device 200. Microprocessor 112 can also transmit encrypted card data to security element 108 and receive it from it. The magnetic field transmitter 150 transmits the magnetic strip data of the card holder to the POS device 300 using magnetic pulses sent to the SMP 302. The PMP 100 can also be used to read other magnetic cards using the SMP 106 as a POS device. The SMP 106 can be used to download payment card data to security element 108 and to record card track data for a POS or settlement application 230 on a mobile communication device 200.

Mobile communications device 200 is equipped with the Mobile Wallet 220 application, a POS or settlement application 230, an audio jack 202 and / or a communication interface, including but not limited to USB port 204, or another communication interface, including but not limited to 30 - or 9-pin Apple, Bluetooth, and other serial interfaces. The mobile communications device 200 is also equipped with a display with a keyboard or touchpad 240 and a central processing unit (CPU) 250.

Each PMP 100 is initially available for binding to a wallet account. After the PMP 100 is attached, the PMP 100 can be locked with the need to unlock it to change the operating modes and parameters of the PMP 100. The PMP 100 is able to store the card holder data downloaded to it both by the manufacturer initially at the factory and via the wireless communication network after setting wallet accounts, and / or downloaded directly by the client to the PMP 100 through the Mobile Wallet application. In general, a wallet user is a person who has set up a wallet account, for example, on a remote server using the cloud computing infrastructure and installed the Mobile Wallet application on his mobile communication device.

The Mobile Wallet application 220 on a mobile communication device 200 interacts with the PMP 100 to provide various operating modes, including, for example, Initialization and Reset Mode, Card Download and Removal Mode, Transfer and Use Mode, Offline Transfer Mode, POS Card Read Mode and other operating modes to choose from.

The method of operation of the Initialization and Reset Mode in accordance with the design is given with reference to FIG. 2. The PHC is initialized for the first time with a wallet account by connecting or attaching a new PHP or PMP that has not been previously used or has been “reset”, which does not have any wallets and does not store card data, to the mobile communication device shown in block 400 After attaching the PMP to the mobile communication device, the wallet application recognizes and determines the status of the PMP as tied / untethered, as shown in block 402.

If the PMP electronic key is already linked to another wallet account, the wallet application defines the PMP as an untethered but connected to another wallet account, as shown in block 404, and says “The electronic key cannot be used, Linked to a different account”, as shown in block 406. The wallet application can also inform the server of unauthorized attempts to bind, as shown in block 408, in order to prevent fraud in order to prevent improper use of the user information s purses.

If the PMP electronic key is tied to the correct user account, the wallet application will recognize the PMP as tied, as shown in block 410. The PMP can be used or "reset", as shown in block 412. If the user wants the correct account (authorized user) “Reset” the PMP and erase all data on the security element, it needs to go into the wallet application settings and select the “Reset Electronic Key” function, as shown in block 414. If an authorized user re I didn’t “reset” the PMP, it can be used and the procedure is considered to be performed, as shown in block 416. In one aspect, any user can have access to “reset” the PMP electronic key from the wallet application authorized by the user. After the device is "reset", it must be initialized and tied to the wallet account again, even if the device was "reset" by the same user, it will be determined as a new (clean) one and designed to load new cards.

If the PMP electronic key was not associated and if there is no account associated with the PMP when connecting the PMP with a mobile communication device, for example, with a smartphone on which the wallet application is installed, the specified application identifies the SMS as untethered, as shown in block 418 Then the wallet application may be faced with a choice whether the PMP should be linked to the wallet account, as shown in block 420. If the authorized wallet user does not want to bind the PMP, the procedure is considered completed as depicted in block 416.

Otherwise, if the authorized user wants to bind the PMP, the bind procedure begins. The specified procedure may include recording the serial number of the PMP, as shown in block 422, re-authenticating the user, as shown in block 424, and matching the PMP with the wallet account, as shown in block 426. The binding procedure may also include storing information about binding, for example, saving the serial number of the PMP in the wallet account, as shown in block 428, for subsequent authentication, each time matching the used PMP electronic key with the wallet application for inclusion PMP. In this regard, the PMP can be unlocked and used in the future only with the appropriate wallet account.

The method of operation of the mode of loading and removing cards in accordance with the design is given with reference to FIG. 3. The PMP is connected to the mobile communication device, as shown in block 430, and is defined as “tied”, as shown in block 432. After binding the PMP to the wallet account, the wallet user can use the wallet application to download their cards by holding them through the NSR built into the PMP, as shown in block 434. The received data is digitized, encrypted, as shown in block 436, and stored in the memory or security element of the PMP for later use, as shown in block 438.

The encrypted data can also be transmitted to a mobile communication device, as shown in block 440. The Mobile Wallet application can transfer data to the wallet server, as shown in block 442. The data can be decrypted on the wallet server, a PAN, card number, term actions and owner name - extracted from the track data of the map, as shown in block 444.

The Mobile Wallet application or wallet server can also determine whether the magnetic card is payment / non-payment, as shown in block 445. If the magnetic card is non-payment, the system can automatically save the track data of the card to the memory for “non-payment”, and allow the user give the specified card a name and save it in memory, for example, in the PHC, as shown in block 447.

If the magnetic card is a payment, for example, with a specific format recognized by the system, the card can be defined as a payment, and the system determines whether the name on the payment card matches the name of the wallet account, as shown in block 449. If the name does not match, it can be displayed the error message “The name on the card does not match the account”, as shown in block 451. If the name on the payment card matches the name of the wallet account, the system can determine that the PAN number matches the existing card, wound not stored on the server to either create a new account or leave an existing one. When creating a new card, the system can save the card track data in the payment section of the protected memory of the PMP in encrypted form, as described below.

Such a determination can also be made by correlating the data obtained during the card with any cards that were previously saved in the wallet account, as shown in block 446. If no such matches are found, a new one is created in the wallet account on the server card, as shown in block 448. When a new card is created, the system can save the card track data in the payment section of the protected memory of the PMP in encrypted form, as shown in block 438. If matches are found, the card is identified as existing and loading is carried out, as shown in block 450.

In this aspect, the PMP is able to load any type of magnetic card into memory, and not just payment cards. Non-payment cards can be stored separately with a lower level of protection for convenience. For example, some non-payment applications may include cards for opening doors, loyalty cards, etc. Downloading payment and non-payment data can be divided into two different fields or into two storage zones. For example, payment cards may not be loaded into the storage area for non-payment cards. Also, for example, payment data may have a certain format, the availability of which can be established, and such cards may be denied downloads to a storage area intended for non-payment data. Payment cards may also require authentication in the application before transferring them. On the other hand, non-payment card data set as default data can be transmitted without authentication.

In this aspect, another loading procedure for the PMP is to dynamically route the magnetic stripe data from the server to the PMP through the mobile device and application. This methodology allows magnetic stripe data to be transmitted from the server to the PMP after authentication of the wallet user, so that after its execution the dynamic magnetic stripe data is transmitted to the mobile device and stored and / or transmitted further. In this aspect, the card track data generated by the server can be dynamically downloaded for payment purposes, acting as one-time payment data and dynamically generated for the wallet user directly during payment.

In another aspect, the key to a room in a hotel or casino can be transferred to the user's mobile wallet or digital wallet, and then to the PMP so that the user does not have to physically register at the hotel and wait in line. The wallet user can register at the hotel using the application on his mobile device (as an option, the location of the mobile device can be correlated with the reservation address of the room to provide more security), then the reservation server sends a “key” to the wallet server address, which is subsequently transferred to the wallet application or into a digital wallet and loaded into the PMP memory element for non-payment purposes. The user can press the transfer button on the PMP, and transfer the magnetic strip data stored on the PMP for non-payment purposes to the wallet application without authentication. The “key” for a hotel room or magnetic stripe data has a validity period that can expire on the server, which makes this method relatively safe and comparable to not returning a magnetic key card from the hotel.

In these aspects, the system is able to remotely download data to the PMP from the server, allowing third parties, for example, card issuers, to dynamically send payment or non-payment card data to the PMP for transmission. Properly bound PMP can be used for remote loading. This system is able to control whether the magnetic stripe data is saved as payment or non-payment card data, which makes it possible to use the system offline in various ways. The application of this method may include sending dynamic payment card tokens from the server for one-time use and remote registration in a hotel room without a direct visit to the registration desk.

If a new “key” or magnetic stripe data is downloaded to the PMP and stored in the memory for non-payment cards installed as default cards, they can be used in “Offline mode” in the manner described in detail below. When a payment card is selected by the wallet application, a certain card can be activated for a period of time, for example, for 5 minutes, during which the non-payment card installed as the default card cannot be used for transferring funds. To distinguish a payment card from a non-payment one, payment cards can have their own special format, as well as a bank identifier (BIN), which is recognized by the application in the process of determining a payment card. The BIN can be correlated with the name of the account and saved by the user if the specified names match.

In some aspects, the server does not store map track data, but only PAN data. Several cards can be loaded into memory or a security element for their selection or further use, they can also be divided into payment and non-payment cards. In this aspect, payment cards can only be transferred after authentication to the wallet application, a time interval can also be set for their offline transfer from the moment the card is selected, while non-payment cards can be transferred as offline cards by default without authentication to the wallet application for comfort.

In this aspect, the name contained in the card track data read from the physical card must match the wallet account name to save the card on the PMP and on the server, otherwise the application may not complete the process of loading the specified card with the error message “Error: The name on the card does not match the account. ” Once the card track data is stored in the security element (SE), the user can view the cards in the wallet application and select the default primary card for transferring payment / non-payment data. Cards stored in the cloud infrastructure and designed for correspondence transactions (CNP), which are not stored at the PMP and are not used for face-to-face transactions (CP), can also be used. However, each of the cards stored on the PMP must have an equivalent copy of the PAN in the cloud infrastructure, and such cards may need to be removed from the cloud infrastructure individually using an application or the Internet. Resetting the PMP does not affect the data of cards stored in the cloud infrastructure. Duplicate cards with the same PAN are not displayed as different cards, i.e. if the user has already entered the card number in the account of his wallet in the cloud infrastructure remotely and then held the same card for uploading to the PHP for the purpose of its physical use, the card stored in the cloud infrastructure will be saved and there will be no need to copy it if if the PAN data matches.

Once cards are uploaded to the PMP, they can be selected by the wallet application. Selected cards can also be deleted from the PMP and application memory.

In other aspects, the wallet account is able to start downloading the encrypted card track data to a secure memory element or the PMP security element directly from the wallet server so that the issuer can choose whether to create a card account for the wallet user and then load the security element as the main card by means of the wallet application, data from the card track, which are transmitted from the wallet server to the mobile communication device and to the PMP. This type of remote loading of map track data into the user's PMP wallet is intended for physical use. For example, a card issuer may be a payment card provider, such as a credit card provider or a bank, or a non-payment card provider, such as a hotel, door entry system manufacturer, or a loyalty program creator. A payment card can be a standard payment card or a one-time payment card, where the card number is a token related to the payment card account on the server of its issuer. This ensures greater security even when the token is compromised or copied, since such a number is one-time.

Once the magnetic card track data is loaded into the PMP, the wallet application can also be configured to record images of the front and / or back side of the card using the camera of a mobile device, and allow the user to select cards on the PMP for use in data transfer. Cards selected in the application using the wallet application can also be deleted and erased from the memory element. The wallet application can also be used to record identification cards of wallet users for the purpose of showing them to sellers by clicking on a button in the wallet application.

The method of operation of the Transmission and Use Mode in accordance with the design is given with reference to FIG. 4. The operation with POS starts at block 452. For physical operations with POS, the encrypted data of the card track stored in the memory or security element (SE) can be decrypted by the PMP, as shown in block 454, and then transmitted to the POS, as shown in block 456. POS can also transmit data to the payment system operator, as shown in block 458.

For remote operations, the encrypted data of the card track can be transmitted to the address of the settlement application on the mobile communication device, as shown in block 460. The settlement application can then transfer data to the payment server, as shown in block 462. The specified data can only be decrypted by the corresponding payment server in the calculation process, as shown in block 464, and without such a decryption, the indicated data cannot be used by the mobile application or any person who intercepted them during the transfer via wireless Fresh or wired Internet or other network. The payment server may also transmit encrypted data to the payment system operator, as shown in block 466.

The method of operation of the Offline Transmission Mode in accordance with the design is given with reference to FIG. 5. The wallet user enters the wallet application with the PMP connected to it, for example, through an audio jack or other communication interface, as shown in block 468. Assuming that a card or several cards are safely loaded into a security element / protected memory element, in case when more than one card is loaded, the user can change the default card / main card in order to transfer its data to the POS when the PMP is turned on. In one aspect, a particular card may be “Selected” to begin with. The “selected card” to the PMP can then be transferred to the POS address by pressing the “Send” button in the wallet application with the PMP electronic key connected or by pressing the “Transfer” button on the PMP itself, as shown in block 470, for a certain period of time before how PMP will stop the possibility of transferring payment card data. When the transfer process begins, the LED may light up, for example, a green light for approximately 500 ms or another desired amount of time, as shown in block 472. For non-payment cards stored in the PMP, at any time when the payment card does not overlap the default position of the card, the non-payment card installed as the default card is available for transmission by a simple button press on the PMP, and at the same time, the LED indicator indicates data transfer.

If the PMP has been authenticated by the wallet application running in the Transfer Mode set by default, and the PMP has been disconnected from the mobile communication device, as shown in block 474, the electronic key remains on and will be in the unlocked state for about 4 minutes or longer, as shown in block 476. The above allows the seller or user to move and use the PMP electronic key to complete the transfer of card data in the case when the PMP is near the POS, by pressing the button on the PMP for e of the specified period, as shown in block 478, after which the electronic key may be disconnected and will have to be turned on and unlocked again through the wallet application. This function will be useful for many restaurants, where for payment it is necessary to take cards from the table to the POS system. This function allows the waiter to simply take the PMP electronic key and take it to the POS system for 4 minutes (while the PMP key is on) without having to take away the visitor’s mobile communication device with it.

In one aspect, the card track data can either be stored in memory during production, downloaded by the server remotely, downloaded by the buyer by converting the magnetic strip data into contactless card track data, if necessary, using the wallet application through a special procedure, or can be saved directly to the memory or PMP security element for their further use.

The method of operation of the Reading Mode of the POS Card in accordance with the design is given with reference to FIG. 6. This mode allows the SMP with which the PMP is equipped not only to download cards, but also to perform POS functions by reading and encrypting any magnetic cards that is used with the POS application on a mobile device to accept payments, like any other POS application seller. The user can pass the magnetic card through the NSR, which is equipped with the PMP, as shown in block 480. The PMP reads and encrypts the data on the card, as shown in block 482. These data can be transferred to the POS application of the mobile communication device, as shown in block 484 , which can subsequently transfer them to the address of the payment server, as shown in block 486. The payment server can also transmit the specified data to the address of the payment system operator for processing the payment, as shown in block 488.

The devices, systems and methods described here allow the data of the magnetic card track to be recorded and stored in the protected memory element of the PMP by the user directly without changing them, and also to be subsequently used with a POS or other device equipped with SMP, which differs from contactless or NFC- data with special fields that are subject to mandatory encoding by the card issuer to ensure their operation with contactless POS. The PMP is equipped with a button that allows the transfer of magnetic card data to the POS address when the PMP is disconnected or disconnected from the mobile device, such a transfer, if it is performed correctly, also activates the LED indicator. The unique binding of the PMP to a specific wallet account, which consists in the fact that such a PMP can only be used with the specified account in order to store and transfer card track data, provides greater protection, and the ability to reset the PMP allows you to "untie" it from the specified record and use again. PMP is able to connect to mobile communication devices not only through audio jack and USB, but also through various other interfaces.

The devices, systems and methods described here allow you to download the encrypted data of the magnetic card track to the PMP memory, which can subsequently be decrypted and transmitted to the POS address or transferred in encrypted form to the address of the mobile communication device and then sent to the payment server to decrypt them and processing to upload a wallet account to a server or perform a POS operation. Devices, systems and methods provide the ability to use the stored or read card track data during virtual calculations for greater security and lower transaction costs for sellers.

Devices, systems and methods allow you to remotely download and transfer card track data from its issuer to the address of the wallet server provider, to the wallet application address installed on the mobile communication device, as well as to the security element and the PMP memory for their subsequent use. Devices, systems and methods also provide the ability to load account information in loyalty programs along with payment card data in one or several discretionary fields of a card’s track with the aim of reading them by the issuer during and after the transaction, which may provide the opportunity to provide special offers and use of loyalty programs along with the implementation of payment transactions.

As described above, the data of the magnetic strip of the card, for example, stored on the security element 108 PMP 100 can be transmitted to the address of the settlement application of the mobile communication device and used in mobile settlement systems. In one aspect, systems and methods of mobile payments help to understand the decrease in the ratio of imperfect purchases and increase their conversion to sales. However, it should be borne in mind that the systems and methods of mobile settlements described here can be used both with and without PMP 100.

The General scheme of the system 20 processes of mobile settlements in accordance with the design is given with reference to FIG. 7. The system 20 includes a mobile communication device 500, which is or is similar to the mobile communication device 200 described above, and the settlement server 600. As shown, the mobile communication device 500 and the settlement server 600 can communicate with each other over a network (networks) 170.

On the settlement server 600, one or more settlement interfaces of settlement Internet applications (APIs) 602 and a database 604 are located. The database 604 may store user data and payment information. Optionally, a settlement web page intended for settlement in a browser may be placed on the settlement server 600.

On the mobile communication device 500, a mobile settlement application 502, one or more shopping applications 504, and one or more browser applications 506 can be installed. Mobile settlement application 502 can be activated or launched from the store’s web page or from a mobile shopping application . It was created to make payment transactions. Mobile payment application 502 stores payment information and personal data on hardware and / or on peripheral devices of a mobile communication device 500, such as the above-described PMP 100, wallet application, remote payment server 600, or “cloud”. Mobile payment application 502 recovers or receives customer data and payment card data from hardware, from peripheral devices such as PMP 100, from the wallet application described above or from the “cloud” during the calculation process to reduce data entry, such as credit card number , its validity period and billing address entered during the calculation. Other applications, such as the shopping application 504 and the browser application 506 downloading the store website, may also be installed on the mobile communication device 500.

Multiple versions of 502 settlement application can be created for various mobile platforms, including but not limited to Android ™, iOS ™, and Windows ™ -based mobile phones and tablets.

The billing application 502 allows the user to complete an operation initiated either from the same mobile communication device 500 or from another computing device, such as a desktop PC or other computer device. The billing application 502 may also be switched or redirected to or from another mobile application, such as the shopping application 504; switched to or from a web page in a browser application 506 launched on the mobile communication device 500, launched by means of a PUSH notification sent by the settlement server 600, and / or started by the user and used to scan the QR-code of the operation. Each of these operating modes is described in detail below.

Settlement application 502 may store billing information and personal data on the hardware of the mobile device or its peripheral devices. The billing application can also store information in the cloud or on a remote billing server 600. The billing application 502 retrieves the customer and payment card data, such as the card number, expiration date and billing address, from hardware, peripherals or from the cloud during the calculation process in order to reduce data entry during the calculation process.

The billing application 502 running on the mobile communication device 500 may access one or more hardware components of the mobile communication device 500. For example, as shown in FIG. 8, billing application 502 can access hardware components, including but not limited to SIM card 508, security element 510, and memory storage 512 onto which data can be stored. Calculation application 502 may also address hardware components, including but not limited to camera 514, accelerometer 516, gyroscope 518, GPS receivers 520, electronic compass 522 and biometric sensors 524, with which the recorded parameters can be used for added security .

The billing application 502 can access peripheral components and accessories through various communication interfaces 526, including but not limited to USB, audio jack, Bluetooth, Serial Port, Wi-Fi, etc. The list of peripheral components and accessories may include, but is not limited to, payment card readers 700, such as PMP 100, SMP, smart card readers, NFC and EMV card readers; PIN pads 702; 704 barcode scanners; printers 706; displays scanners of payment checks, etc. for data input and output.

Settlement application 502 can be launched directly by the user to manage their saved cards and personal data after successful user authentication. In case the calculation application 502 is used with a peripheral device, such as PMP 100, the calculation application 502 can transmit an electromagnetic signal of the data of the card track in order to emulate the magnetic reading process without the need for physical drawing of the card. This allows settlement application 502 to be used in conventional (traditional) retail stores for the purpose of conducting transactions as if using virtual, but magnetic cards.

In one aspect, when the billing application 502 is directed to or launched from another mobile application or a web page in a browser, after the payment transaction is completed, the user is redirected to the used shopping web page in the browser or to the mobile shopping application indicated by a back link (URL). In the specified redirection mechanism, the calculation application 502 may register a conventional URL scheme with the operating system. After such registration, the operating system can use part of the specified scheme, for example, "sarr: //" in the URL, to associate the URL with the settlement application 502.

The operating system can then control the specified URL / protocol by launching the calculation application 502. For example, in iOS and Android systems, the URL may be in the form “customScheme: // mydomain.com/myparameters”. In Android systems, this registration is performed by adding an intent filter to the AndroidManifest.xml file. On iOS systems, this registration is done by adding the line “CFBundledURLTypes” to the file “plist.info”. As a result of the described registration, the settlement application 502 can subsequently be opened / launched / switched at the moment when other applications or websites access the specified URL link. Moreover, parameters can be passed to billing application 502 via the “myparameters” part of the URL link. Through the use of a redirect mechanism using a special URL scheme, various shopping applications can be redirected to the settlement application 502 to complete a payment transaction. Depending on various scenarios, the results of the operation can be directed / redirected back to the application or other initiator in various ways.

If settlement application 502 is launched by a PUSH notification or as a result of scanning a QR code, the store’s main page on a PC or communication device updates the operation results after it has been completed.

Since the calculation application 502 is a native application on the mobile communication device 500, it can access hardware or peripheral components that cannot be accessed from a mobile browser. In addition, since settlement application 502 is a centralized application for launching / enabling it from other store or application websites, or for redirecting to or from other store or application websites, each seller no longer needs to integrate a hardware driver into his application. Instead, a simple redirect from his application or website through a URL redirect is sufficient.

In order to use the settlement system, the user logs in and sets up an account by setting a username and password. When opening an account, the user's personal information, for example, his name, surname, billing address and delivery address, is recorded and stored on the billing server 600. For example, information about the user account is stored in database 604. An optional verification step can be used to confirm validity user credentials. Optionally, information related to the mobile communication device 500 may also be stored and linked to a user account.

Settlement server 600 hosts one or more web services that are offered to them as API 602. They are called Settlement APIs for online and mobile stores and are intended for the development of shopping applications. As described above, database 604 is used to store personal data and payment information of registered users. The settlement server 600 also houses a settlement web page for the user, intended to complete the operation in the browser during online purchases.

In one aspect, the shopping application creates a settlement token used to uniquely identify a payment transaction by accessing an API method hosted on a settlement server 600. Transaction information including product, price and quantity information as well as data flow control information, for example redirecting URLs are provided as input parameters. URLs can be used to set redirects or to return to the application or web page you are using. All forwarding and flow control operations can be performed using the specified settlement token, which is used to track the payment transaction. An application or a store website may request a payment transaction status by accessing an API hosted on a settlement server 600.

In one aspect of FIG. 9 shows an exemplary process of completing an online ticket purchase operation using a store website and a mobile shopping application. In the above example, the user or buyer 900 searches for information on the Internet using the shopping application 504 on his mobile communication device 500. The customer 900 launches the shopping application 504, for example, the application for buying tickets to the opera. Buyer 900 uses the shopping app 504 to view and add products to the cart for later settlement and purchase. In the above example, the shopping application 504 manages the basket and interacts 902 with the seller’s server 904 in order to obtain updated product information, such as the name of the presentation (opera), airtime, and ticket price. When the buyer 900 decides to purchase the product, he selects it and proceeds to settlement 906. During the settlement, the buyer 900 presses the settlement button 908 to complete the purchase. Application 504 accesses 910 the settlement server 600 via the seller’s server 904 and transmits information about the specified product, transaction amount, etc. The seller’s server receives 912 settlement tokens 914 from the settlement server 600.

Application 504 receives 916 settlement tokens 914 and redirects 918 to settlement application 502 using the URL and the settlement token as a parameter. In the billing application 502, the customer 900 passes authentication 920 to the billing server 600. After the authentication, the customer 900 confirms the transaction on the billing server 600, and the billing application 502 contacts 922 the billing server 600 or the website API 602 to complete the transaction identified by the billing token. The settlement server 600 sends 924 the transaction to the address of the payment system operator 926. The payment system operator 926 returns 928 the results of its processing to the settlement application 502 through the settlement server 600, as shown in block 930.

After the operation is completed, the settlement application 502 redirects 932 back to the initiating application for purchases together with the settlement token and transaction processing results as parameters, which shows the page with the results of 934. The application receives the results of the operation in one or several ways, including: (A) the application for purchases gets the results of transaction processing using the redirect URL parameters; the shopping application updates 936 transaction status on the seller’s server, where (B) the settlement server 600 transmits 938 results to the seller’s server or (C) the seller’s server independently learns 940 the latest transaction status or results from the settlement server 600 using API 602.

An example use case is the sports equipment store application developed by Acme Corp., which can redirect to settlement application 502 to make a payment. The following may be cited as additional exemplary methods of use: the BuyMore grocery store application developed by BuyMore.com can use its own loyalty program in its application at the moment when it is redirected to settlement application 502 to make a payment; likewise, the Contoso Restaurant pizza ordering application can create a mobile delivery service application and use settlement account 502 to make a payment. In this case, application developers (from various companies) can focus directly on the product selection process and the conditions of its purchase, leaving the payment process to settlement application 502.

In one aspect of FIG. 10 shows an exemplary process for completing an online ticket purchase operation using a store website and a browser application. In the above example, the buyer 900 browses the goods on the store’s website using the browser application 506 on his mobile communication device 500. The buyer 900 visits the store’s website, for example, the website for purchasing opera tickets, using the browser application 506. The buyer 900 uses the browser application 506 for viewing and adding goods to the basket for the purpose of subsequent calculation and purchase. In the above example, the store’s website interacts 1002 with seller’s server 904 in order to obtain updated product information, such as the name of the presentation (opera), airtime, and ticket price. Seller's server 904 plays the store website and manages the cart. When the buyer 900 decides to purchase the product, he selects it and proceeds to settlement 1006. During the settlement, the buyer 900 presses the settlement button 1008 to complete the purchase. The store’s website directly accesses or uses seller’s server 904 to contact 1010 the settlement server 600 and transmits information about the specified product, transaction amount, etc. The seller’s server receives 1012 settlement tokens 1014 from the settlement server 600.

Application 506 receives 1016 settlement token 1014, and the seller’s website redirects 1018 to settlement application 502 using a special URL and a settlement token as a parameter. In billing application 502, customer 900 passes authentication 1020 to billing server 600. After it is completed, buyer 900 confirms the operation on billing server 600, and billing application 502 contacts 1022 to billing server 600 or website API 602 to complete the operation identified by the billing token. The settlement server 600 sends a 1024 operation to the address of the payment system operator 926. The payment system operator 926 returns 1028 the results of its processing to the settlement application 502 through the settlement server 600, as shown in block 1030.

After the operation is completed, the settlement application 502 redirects 1032 back to the browser application along with the settlement token and the results of processing the operation as parameters, which shows the page with the results 1034. The store website receives the operation results in one or several ways, including: (A) the store website receives the results Operations using redirect URL parameters the store’s website updates 1036 the status of the operation on the seller’s server, where (B) the settlement server 600 transmits 1038 results to the seller’s server or (C) the seller’s server independently learns 1040 the latest transaction status or results from the settlement server 600 using API 602.

In one aspect of FIG. 11 shows an exemplary process for launching a settlement application from a store website in a browser running on a PC with a PUSH notification or SMS. In the above example, the user or buyer 900 views the goods on the store’s website using a browser 1102 on the PC 1100. The buyer 900 launches the store’s website, for example, a website for purchasing tickets to the opera, using the browser 1102. User 900 uses the browser to view and add products to the basket for the purpose of subsequent calculation and purchase. In the above example, the store’s website interacts 1104 with seller’s server 904 in order to obtain updated product information, such as the name of the presentation (opera), display time and ticket price. Seller's server 904 plays the store website and manages the cart. When the buyer 900 decides to purchase the product, he selects it and proceeds to settlement 1106. During the settlement, the buyer 900 presses the settlement button 1108 to make a purchase. The store’s website directly accesses or uses seller’s server 904 to contact 1110 the settlement server 600 and transmits information about the specified product, transaction amount, URL, etc. The seller’s server receives 1112 settlement token 1114 from the settlement server 600.

The user may be asked for a username and password for authentication in the Internet browser. The store website accesses the settlement server 600 for user authentication. After user authentication, the settlement server can find the phone number of the user's 500 mobile communication device or its identifier and send 1116 PUSH notification or SMS to the registered 500 mobile user communication device with the settlement token. Upon receipt of the notification, settlement application 502 starts up. In the billing application 502, the customer 900 authenticates 1120 itself to the billing server 600. After authentication, the user 900 confirms the operation on the billing server 600, and the billing application 502 contacts 1122 the billing server 600 or the website API 602 to complete the operation identified by the billing token. The settlement server 600 sends the operation 1124 to the payment system operator 926. The payment system operator 926 returns 1128 the results of its processing to the settlement application 502 through the settlement server 600, as shown in block 1130. The store website updates the status of the operation 1136, for example, by means of a survey, and the browser displays a page with the results of 1134. The store’s website receives the results of the operation in two possible ways: (A) the settlement server 600 transfers 1138 results to the seller’s server or (B) the seller’s server independently recognizes 1140 after Nij operation status or results from the settlement server 600 using the API 602.

In one aspect of FIG. 11 shows an exemplary process for launching a settlement application from a store website in a browser running on a PC by scanning a QR code. In the above example, the user or buyer 900 views the goods on the store’s website using a browser 1102 on the PC 1100. The buyer 900 launches the store’s website, for example, a website for purchasing tickets to the opera, using the browser 1102. User 900 uses the browser to view and add products to the basket for the purpose of subsequent calculation and purchase. In the above example, the store’s website interacts 1104 with seller’s server 904 in order to obtain updated product information, such as the name of the presentation (opera), display time and ticket price. Seller's server 904 plays the store website and manages the cart. When the buyer 900 decides to purchase the product, he selects it and proceeds to settlement 1106. During the settlement, the buyer 900 presses the settlement button 1108 to make a purchase. The store’s website directly accesses or uses seller’s server 904 to contact 1110 the settlement server 600 and transmits information about the specified product, transaction amount, URL, etc. The seller’s server receives 1112 settlement token 1114 from the settlement server 600.

In the above example, the store’s website or the seller’s server accesses 1118 the settlement server 600 via API 602 in order to obtain a QR code 1142 containing the settlement token. The user launches the settlement application 502 on the mobile communication device 500 and scans 1144 the QR code 1142. As soon as the settlement application 502 is launched, the process continues as described above with reference to FIG. 11 ways.

Although the methods and algorithms described above, including those described with reference to the above flowcharts and FIGURES, are described separately, it should be appreciated that any two or more of the methods described herein may be combined in any combination. Any of the methods, algorithms, designs, any of the procedures described here may include instructions that can be read by machines (devices) to perform: (A) a processor, (B) a controller and / or (C) any other suitable processing device information. Any algorithm, software, or method described herein may be implemented as software stored on non-transferable tangible media such as flash memory, a CD, a hard disk, a digital versatile disk (DVD), or other media, but specialists in In this area, they will easily understand that the entire algorithm and / or its parts can be, alternatively, executed by a device other than the controller and / or executed in the form of firmware or in the form of specialized hardware in a generally accepted way, etc., it can be implemented by specialized integrated circuit (ASIC), programmable logic device (PLD), their series, discrete logic, etc. In addition, although special methods and algorithms are described with reference to the flowcharts presented here, specialists in this field will easily understand that many other methods may be used to implement exemplary instructions capable of being read by machines. For example, the execution order of the steps may be changed, and / or some of the steps described may be changed, deleted, or combined.

It should be borne in mind that the methods and algorithms shown and described here may have various modules that perform certain functions and interact with each other. It should be borne in mind that these modules are divided by functionality for description purposes; they represent computer hardware and / or executable software code stored on a medium capable of being read by a computer in order to be executed on the corresponding computer hardware. Various functions of different modules and blocks can be combined or separated as hardware and / or software stored on non-transferable media capable of being read by a computer, in the form of any of the above modules, and can be used separately or in combination.

A mobile communication device may be a laptop, a cell phone, a personal digital assistant (PDA), a tablet computer, and other similar mobile devices. The interaction between components and / or devices in the system and methods described herein may be one-way or two-way electronic communication via wired or wireless means or networks. For example, one component or device can be connected by wire or wirelessly, directly or indirectly, through a third-party intermediate node, via the Internet, or in another way to another component or device in order to ensure interaction between components or devices. Examples of wireless networks include, but are not limited to, a radio network, an infrared connection, Bluetooth, a wireless local area network (WLAN) (e.g., Wi-Fi), or a wireless radio network that is connected to, for example, Long Term Evolution (LTE), WiMAX, 3G, 4G and other communication networks of this type.

Although the devices, systems and methods are described and illustrated by certain embodiments, their many different variations and modifications that can be made, within the essence and scope of the present invention, will be clear to experts in this field, the present invention is not limited to the exact description of the method or design, the above, since these options and modifications are only included in the scope of the present invention.

Claims (30)

1. A settlement system implemented on a mobile communication device and including a store application or a browser application, accessible on a mobile communication device and adapted to provide the user with the ability to select seller goods for purchase, including: a communication processor that interacts with a billing server that hosts one or more web service billing application programming interfaces (APIs) adapted to interact with a mobile communication device; and settlement application installed on a mobile communication device and adapted to: launch in response to receiving information relevant to the purchase operation; receiving user payment information, including magnetic stripe data, from a magnetic stripe data carrier (PMP) interacting with a mobile communication device, while the PMP stores data from the magnetic stripe encrypted in the PMP memory for subsequent use in the purchase operation; interaction with the settlement server and ensuring the completion of the purchase operation by the settlement server; and restarting the store application or browser application after the operation is completed. 2. The settlement system according to claim 1, in which the settlement server creates a settlement token identifying the purchase operation in response to the initialization of the purchase operation by the user. 3. The settlement system according to claim 2, in which the settlement server sends the settlement token to the store application or browser application. 4. The settlement system according to claim 3, in which the settlement application receives the settlement token from the store application or the browser application. 5. The settlement system according to claim 4, in which the settlement application authenticates the user. 6. The settlement system according to claim 5, in which the settlement application confirms the purchase operation using the settlement server in response to user authentication. 7. The settlement system according to claim 6, in which the settlement application sends the settlement token and the results of the purchase operation to the store application or browser application in the process of restarting the store application or browser application. 8. The settlement system according to paragraph 7, in which the store application or browser application displays a page with the results corresponding to the purchase operation in response to restarting it. 9. The settlement system according to claim 1, wherein the settlement server completes the purchase operation by sending it to the payment system operator. 10. The settlement system according to claim 1, wherein the settlement application is adapted to be launched in response to receiving information corresponding to a purchase operation from a store application or a browser application. 11. The settlement system according to claim 1, in which the settlement application is adapted to be launched in response to receiving information related to the purchase operation from the settlement server. 12. The settlement system according to claim 1, in which the settlement application is adapted to be launched in response to receiving information related to the purchase operation from the settlement server via a PUSH notification, e-mail message, or short message service. 13. The settlement system according to claim 1, wherein the settlement application is adapted to be launched in response to receiving information corresponding to a purchase operation from a QR code displayed on a mobile communication device. 14. A method of conducting settlement operations, including: giving the user the ability to view and select seller’s products through the first application or browser; launching a settlement application installed on a mobile communication device in response to receipt by the settlement application of information corresponding to a purchase operation; receiving by the settlement application a settlement token identifying the purchase operation created by the settlement server; receiving by the settlement application of the payment information of the user, including data from the magnetic strip, from the data carrier from the magnetic strip (PMP) interacting with the mobile communication device, while the PMP stores data from the magnetic strip encrypted in the memory of the PMP for subsequent use in the purchase operation; interaction by the settlement application with the settlement server in order to ensure the completion of the purchase operation by the settlement server; and restarting the first application or browser in response to the completion of the purchase operation. 15. The method of claim 14, wherein obtaining the settlement token includes receiving it from a first application or from a browser application. 16. The method according to p. 14, further comprising authenticating the user with the settlement application until connecting to the settlement server. 17. The method according to p. 14, in which the launch of the settlement application includes the launch of the settlement application in response to receiving information corresponding to the purchase operation from the settlement server via a PUSH notification, e-mail message or short message service. 18. The method according to p. 14, in which the launch of the settlement application includes the launch of the settlement application in response to receiving information corresponding to the purchase operation from a QR code displayed on a mobile communication device.

Images