JP2017500629A - Mobile checkout system and method - Google Patents

Abstract

A mobile checkout system and method for completing a purchase transaction to purchase goods from an internet retailer is provided. A user browses and selects items through a shopping application or browser to purchase from a retailer. During transaction processing, a checkout application installed on the mobile communication device is launched. The checkout application receives a checkout token created by a checkout server that identifies the purchase transaction. The checkout application uses this token to communicate with the checkout server and cause the checkout server to end the purchase transaction. When the transaction ends, the shopping application or browser is restarted and the results page is displayed.

Description

  The present disclosure relates to systems and methods for implementing mobile wallet applications and checkout processes.

  The transmission of magnetic stripe data mainly enables the magnetic stripe card to pass through a magnetic stripe reader (MSR: Magnetic Stripe Reader), pays, identifies (ID: Identification), and enables the access control function Has been done by. It is difficult for mobile wallet applications on smartphones and tablets to interact with existing retailer point-of-sale (POS) devices or other devices with MSRs. Non-contact reader enabled POS terminals (typically using, for example, ISO 14443 standard) are not ubiquitous to accept non-contact or near field communication (NFC) payments. Replacing a large number of retail POS devices or door locks that simply accept magnetic stripe cards just to interact with NFC phones or other transmission means such as barcodes is costly and time consuming Will take.

  In many countries, the number of contactless payment cards issued is still small compared to the number of magnetic stripe cards issued to consumers. NFC chips with contactless communication capabilities are embedded in some mobile phones and are used by companies such as Google and ISIS as digital wallets for storing secure cardholder information. These NFC chip-based digital wallets can be used in contactless payment transactions with a limited number of NFC-enabled POS devices, but these NFC chip-based digital wallets have considerable limitations .

  Since few phones have NFC chips embedded, the penetration of this mobile wallet solution into the general public is greatly limited. Also, the process of loading cardholder payment credentials into the NFC chip memory is complex and expensive. In particular, loading the memory of the NFC chip requires a trusted security manager (TSM). The payment card issuer must sign such TSM and pay for such services.

  In particular, when a part of the load process to the chip ends in the middle of a series of transmissions from the issuer to the TSM, to the Internet, to the phone via the mobile phone company network, the load process works smoothly There are a variety of technical complexity to do. In addition, not all standards solve the problem, and there are many competing products, making it more difficult to make ubiquitous.

  In electronic commerce, there are generally two general methods for performing an online shopping checkout process. In the first method, the customer selects a payment button, selects a payment method, and ends the payment process within the retailer's online shopping website. The retailer server communicates with the payment service provider's server to execute the payment transaction. This method allows customers to be on the same retailer site, but the development and integration process between the retailer server and the payment service provider is complex and expensive. In addition, customers may be reluctant to enter sensitive information on web pages or websites that they do not know well.

  In the second method, the customer's browser is temporarily redirected to a checkout web page hosted by the payment service provider, such as a PayPal® checkout process. The customer ends the transaction on a web page hosted by the payment service provider. After the transaction, the browser is redirected back to the original online shopping website. This method makes it easier for retailers to develop and integrate. For customers, payment service provider awareness provides greater security and reliability. Also, this process can be performed more smoothly when the customer has already performed a similar payment process.

  The present disclosure provides a magnetic stripe card to a retailer's conventional point-of-sale (POS) terminal and other devices having a magnetic stripe reader (MSR) or checkout system in physical and virtual environments. It relates to an apparatus, system and method including a magnetic stripe capture, storage and transmission device for use in conjunction with a mobile wallet application to capture, store and transmit data. The present disclosure also relates to a mobile checkout system and method. The system allows a consumer-friendly purchasing experience, a transaction that is secure and beneficial to the retailer, and in some cases, additional data sent to the MSR for loyalty, identification (ID), or access control purposes. Brought about.

  In one aspect, a system for secure capture, storage, and transmission of magnetic stripe payment card data includes a mobile communication device and application, and a magnetic stripe transporter (MST) dongle. including. MST dongle and MST are a magnetic field transmitter including a microprocessor, a driver, and an inductor capable of generating a variable magnetic field, battery, charging circuit, magnetic stripe reader (MSR), memory means or secure element, audio jack Captures magnetic stripe card data in the interface, as well as physical and virtual environments, stores the data securely, and stores such data in a retailer point-of-sale (POS) or checkout system Communication interfaces (eg USB interface, 30-pin or 9-pin Apple interface, Bluetooth® interface, etc.) that work in conjunction with consumer mobile devices and wallet applications for transmitting No.

  One aspect of the present disclosure can include one or more features. The mobile communication device may include a mobile application that initializes the MST for use with a particular wallet account, and unlocks the MST for transmission and use. The mobile communication device is used with a mobile communication device that interacts with the MST or a payment checkout application on the Internet to accept payment card data from the MST and send the payment card data to a payment server for retail Transactions can be processed as merchant POS applications or consumer checkout applications. The mobile wallet application can operate in an audio jack or in various operating modes including, for example, initialization and reconfiguration mode, card load / card deletion mode, transmission and use mode, disconnect transmission mode, and POS card reading mode. It can interact with the MST through other communication interfaces.

  In one aspect, an MST operating in initialization and reconfiguration mode allows users to pair and unpair / reconfigure a specific MST with a mobile wallet account, and allows only one device per account Configured to be. The MST operating in card load / card delete mode loads the magnetic stripe card data by the user by swiping the user's existing plastic magnetic stripe card with the MSR on the MST, and It is arranged to be able to store card track data in a memory means or secure element. For payment cards, the application loads the card's primary account number (PAN) data into the online digital wallet via the mobile wallet application. The card information can also be deleted from the memory means and the server using the application. The MST operating in the send and use mode selects the specific payment card as the top wallet or default card in the wallet when the user activates or presses the button and stores it in the retailer POS system. It is configured so that the card can be used when sending track data. In another embodiment, if a non-payment card is stored in the MST, one non-payment card is stored as the default card, does not authenticate to the wallet application, and does not select such a card Can be sent to. Non-payment cards include hotel keys, entrance pass or ID and loyalty cards that can be loaded into the MST with a separate memory means and transmitted later.

  The MST operating in POS card read mode allows the user to read the payment card by the MST's MSR and send the card data to the POS application on the mobile communication device and then to the payment server and processor. Composed. The mobile communication device may be a smartphone, a tablet, or a personal computer. The MST further includes a battery and a charging circuit. The microprocessor is configured to provide security and communication to the mobile communication device. The memory means securely stores the payment card data. The MST is configured to send card track data to a retailer checkout application on the mobile communications device, resulting in a card presentation transaction for the retailer. The MST reads the payment card and sends the payment card data to the mobile communication device and the associated POS application, which further transfers the transaction and card data to a payment such as a POS. It may be configured to transmit to the server and the processor.

  In another aspect, this disclosure features a method for securely capturing, storing, and transmitting magnetic stripe card data. A magnetic stripe transporter (MST) dongle is a microprocessor, driver configured to send current and signals to an inductor that provides a variable magnetic field, battery, charging circuit, magnetic stripe card reader, memory means or Captures magnetic stripe card data and securely stores card data in secure elements, audio jack interfaces, and physical and virtual environments, and stores such data in a point-of-sale (POS) ) Consumer mobile communication devices for transmission to terminals, checkout systems, or other MSR devices, and communication interfaces that work in conjunction with a wallet application or mobile application (eg, USB interface, 0 pin or 9 pin Apple interface, and a Bluetooth interface, etc.).

  Numerous advantages are provided by the systems and methods disclosed herein. For example, Magnetic card track data, Without modifying the magnetic stripe card data Capture and store in the secure memory means of the MST by the user or directly from the server, It can later be used with an MSR device. In payment card, In order to function correctly with a non-contact POS, In contrast to contactless or NFC track data with special magnetic fields that must be encoded by the card issuer, There is no need to change the magnetic stripe data. The MST can include buttons that allow transmission of magnetic card data to the POS, Meanwhile, the MST has been disconnected or removed from the mobile device.

  In one aspect, the unique pairing between the MST and a particular wallet account provides good security, and the ability to reconfigure the MST allows the MST to be unpaired and reused. Furthermore, the systems and methods according to the present disclosure provide the ability to connect to mobile communication devices via various interfaces other than audio jacks and USB. Also, the process of loading the encrypted magnetic stripe track data into the MST memory means is later decrypted and sent to the POS MSR, or the data is encrypted and sent to the mobile communication device and then paid It can be transmitted to the server for decryption and processing, loading the wallet account on the server or processing the POS transaction.

  The system and method according to the present disclosure provides the ability to perform more secure and low cost transactions for retailers using stored track data or read track data for a virtual checkout environment, and card issuance. It provides remote loading of track data into the MST SE or memory means for later use from the user to the wallet server provider, to the wallet application on the mobile communications device. Furthermore, the system and method can load the loyalty account information along with the payment card data into any field of track data that is read by the issuer at the time of the transaction, thereby combining the offer and loyalty Brings the ability to connect with the program.

  Combine and use all of the above technologies in a seamless user experience for consumers, making mobile wallets more frequent and more compelling and bring value to consumers and retailers Many applications and functionality such as consumer offers and loyalty can be enabled.

  In another aspect, the magnetic stripe card data may be sent to a mobile communication device checkout application and used in a mobile checkout system. Disclosed are mobile checkout systems and methods that help reduce shopping cart dropout rates and increase conversion rates to sales. However, it should be understood that the mobile checkout system and method disclosed herein can be implemented with or without MST.

  In general, mobile checkout systems and methods include mobile communication devices. The mobile communication device has a retailer application and / or browser application installed on the mobile communication device that allows a user to select items for purchase from a retailer website. The checkout application is also installed on a mobile communication device that communicates with a checkout server that hosts one or more web service checkout application program interfaces (APIs). The checkout application may be launched in response to receiving information corresponding to a purchase transaction, such as when a user selects an item to purchase and selects a checkout. The checkout application communicates with the checkout server by communicating with the payment processor to cause the checkout server to complete the purchase transaction. When the transaction ends, the retailer application or browser application used to browse and select the item for purchase is relaunched.

  In other aspects, the checkout application is launched in response to receiving information corresponding to a purchase transaction from a checkout server through a push notification, email, or short message service. It's okay. The checkout application may be launched in response to receiving information corresponding to the purchase transaction from a quick response (QR) code displayed on the mobile communication device.

  Embodiments of the apparatus, system, and method are illustrated in the accompanying drawing figures, which are meant to be illustrative and not limiting. In the figures, like reference numerals are intended to refer to like or corresponding parts.

1 is a functional block diagram of an overview of a magnetic stripe transporter (MST), a mobile communication device, and a point of sale (POS) device. It is a flowchart of the operation | movement method in initialization and reset mode. It is a flowchart of the operation | movement method in card | curd load / card deletion mode. FIG. 6 is a flowchart of an operation method in a transmission and use mode. It is a flowchart of the operation | movement method in cutting | disconnection transmission mode. It is a flowchart of the operation | movement method in POS card reading mode. 1 is a functional block diagram of an overview of a system for performing a mobile checkout process. FIG. FIG. 3 is a functional block diagram of components of a mobile communication device. FIG. 4 is a flow diagram of a method for performing a mobile checkout process using an online shopping website and a mobile shopping application. FIG. 4 is a flow diagram of a method for performing a mobile checkout process using an online shopping website and browser application. Flow of how to perform a mobile checkout process by launching a checkout application using an push notification, short message service (SMS), or quick response (QR) code FIG.

  Although detailed embodiments of the devices, systems, and methods are disclosed herein, the disclosed embodiments are merely illustrative of devices, systems, and methods that can be embodied in various forms. I want to be understood. Accordingly, the specific functional details disclosed herein are not intended to be limiting, but merely as a basis for the claims and to teach those skilled in the art to make various uses of the present disclosure. It shall be interpreted as a symbolic base.

  In general, the devices, systems, and methods disclosed herein include, for example, general purpose computing systems, server client computing systems, consumer-retailer computing systems, mainframe computing systems. Systems, cloud computing infrastructures, telephone computing systems, laptop computers, desktop computers, smartphones, cellular phones, personal digital assistants (PDAs), tablet computers, and other mobile Many different devices, including devices, and those within the scope of computer systems can be included and implemented. Devices and computing systems include one or more databases and other storage devices, servers, and, for example, processors, modems, terminals and display devices, computer readable media, algorithms, modules and applications, and other computers. There can be additional components, such as related components. The apparatus, and the computer system and / or computing infrastructure, are configured, programmed, and adapted to perform the functions as disclosed herein and to perform the processing of the system and method. The

  An overview of a system 10 for capturing, storing and transmitting magnetic stripe card data to a retailer's conventional point-of-sale (POS), according to an illustrative embodiment, is illustrated with reference to FIG. explain. The system 10 includes a magnetic stripe transporter (MST) 100 adapted to interface with a mobile communication device 200. The MST 100 and mobile communication device 200 may be connected through corresponding audio jacks 102 and 202 and / or through corresponding communication interfaces, eg, USB ports 104 and 204, respectively, or a 30-pin or 9-pin Apple interface, Bluetooth It can communicate through other communication interfaces, including but not limited to interfaces and other serial interfaces. The MST 100 also interacts with the retailer POS 300 by adapting it to transmit magnetic stripe data from the magnetic field transmitter 150 including the driver and inductor to the magnetic stripe reader (MSR) 302 of the retailer POS 300. connect.

  The mobile communication device 200 includes a mobile wallet application 220 and a POS application or payment checkout application 230. The mobile wallet application 220 initializes and unlocks the MST 100. The POS or checkout application 230 interacts with the MST 100 and accepts card payment data from the MST 100. The POS or checkout application 230 causes card payment data to be transmitted to the wallet server 260 via the network 170. The card payment data may then be sent from the wallet server 260 to the transaction processor 270.

  The MST 100 includes a microprocessor 112, a light-emitting diode (LED) indicator 114, a battery 116, a charging circuit 118, a magnetic stripe reader (MSR) 106, a memory storage component or secure element 108, an audio jack Includes interface 102 (eg, 3.5mm or other standard audio port), USB port / jack interface 104, or 30-pin or 9-pin Apple interface, Bluetooth interface, and other serial interfaces Other communication interfaces, including but not limited to, and drivers for transmitting magnetic pulses received by any POS device having an MSR, and Including a magnetic field transmitter 150 including the inductor.

  The microprocessor 112 handles security and communication for the mobile communication device 200. The microprocessor 112 can also send and receive encrypted card data to and from the secure element 108. The magnetic field transmitter 150 transmits the cardholder's magnetic stripe data to the POS device 300 by transmitting magnetic pulses to the MSR 302. The MST 100 may also be used to read other magnetic stripe cards by using the MSR 106 as a POS device. The MSR 106 can be used to load payment card data into the secure element 108 and capture card track data for a POS or checkout application 230 on the mobile communication device 200.

  The mobile communication device 200 can be a mobile wallet application 220, a POS or payment checkout application 230, an audio jack port 202, and / or a USB port 204 or a 30-pin or 9-pin Apple interface, for example. Communication interfaces such as, but not limited to, Bluetooth interfaces, and other serial interfaces. The mobile communication device 200 may also include a display device having a keypad or a touchpad display device 240 and a central processing unit (CPU) 250.

  Each MST 100 is initially open to be paired with a wallet account. Once the MST 100 is paired, the MST 100 may be locked and must be unlocked in order to change modes and parameters on the MST 100. The MST 100 loads via the wireless communication network after setting up the wallet account, by initial load at the time of manufacture and / or using the mobile wallet application, the consumer directly to the MST 100 with his card ) Data can be stored by storing the cardholder data. In general, a wallet user sets up a digital wallet account and initializes a mobile wallet application on his mobile communications device, for example, on a remote server via a cloud computing infrastructure It is a person who did.

  A mobile wallet application 220 on the mobile communication device 200 interacts with the MST 100 to provide various modes of operation. Various operating modes include, for example, an initialization and reset mode, a card load / card deletion mode, a transmission and use mode, a disconnect transmission mode, a POS card reading mode, and other optional modes.

  An operation method in the initialization and reset mode according to the illustrative embodiment will be described with reference to FIG. The MST is initially a “new” MST, or is not used or “reset” before “reset”, and the associated wallet and card data are stored. No MST is initialized for the wallet account by plugging or connecting to the mobile communication device, as shown as block 400. Upon connecting the MST to the mobile communication device, the wallet application recognizes or determines the state of the paired and unpaired MST, as shown as block 402.

  When an MST dongle is already paired to another wallet account, the wallet application is paired to another wallet account, although that MST is unpaired, as shown as block 404. And, as shown as block 406, “Dongle unavailable, paired with another account” will be displayed. The wallet application may also report unauthorized pairings to the server, as shown as block 408, for fraud management to prevent wallet users from using the MST inappropriately.

  When the MST dongle is paired with the appropriate wallet account, the wallet application recognizes that the MST is paired, as shown as block 410. As shown as block 412, MST can be used or reconfigured. If the appropriate wallet account user wants to reset the MST to completely erase all data in the SE, the user can access the settings section of the wallet application, as shown as block 414, and “Reset dongle” can be selected. If the appropriate wallet account user desires not to reset the MST, the MST can be used, as shown as block 416, and the process ends. In one embodiment, for any user, the MST dongle can be reconfigured from the user's respective authenticated wallet application. When a unit is reconfigured, it must be re-initialized or paired to the wallet account, and even if the same user reconfigures the device, a new card will load like a completely new device Is done.

  When the MST dongle is not paired and there is no wallet account paired with the MST, when the MST is connected to a mobile communication device, eg, a smartphone with a wallet application, as shown as block 418, The wallet application recognizes that the MST has been unpaired. The wallet application may then have to make a determination as to whether the MST should pair with the wallet account, as shown as block 420. If the appropriate wallet account user does not want MST pairing, the process ends, as shown as block 416.

  Alternatively, if the appropriate wallet account user desires MST pairing, the pairing process begins. The pairing process captures the serial number of the MST, as shown as block 422, authenticates the wallet user again, as shown at block 424, and MST, as shown at block 426. And correlating the wallet account with each other. The pairing process may include pairing information in the wallet account, eg, as shown at block 428, for future authentication matching each time the MST dongle is used in the wallet application and turned on. , Storing the serial number of the MST. In this regard, the MST can only be unlocked and used from now on by an appropriate wallet account.

  An operation method in the card load / card deletion mode according to an illustrative embodiment will be described with reference to FIG. As shown as block 430, the MST is connected to the mobile communication device, and as shown as block 432, the MST is recognized as paired. Once the MST is “paired” with the wallet account, the wallet user uses his wallet application to see his card on the MST's built-in magnetic stripe reader (MSR), as shown as block 434. Can be loaded by reading. The resulting data is digitized and encrypted as shown as block 436 and stored in memory means or SE in the MST for later use as illustrated by block 438.

  The encrypted data may be transmitted to the mobile communication device, as shown as block 440. The mobile wallet application can send the data to the wallet server, as shown as block 442. As shown as block 444, the data is decrypted at the wallet server and the cardholder primary account number (PAN) data, card number, expiration date and name are stripped from the track data.

  The mobile wallet application or wallet server can also determine whether the magnetic card is a payment card or a non-payment card, as shown as block 445. If the magnetic card is a non-payment card, the system automatically stores the track data in the non-payment transmission memory and the user names the card and is shown as block 447, for example, Non-payment cards can be stored in memory means on the MST.

  If the magnetic card is, for example, a payment card that has a specific format that the system can recognize, the card can be detected as a payment card, and the system displays the name on the payment card as shown as block 449 Determine if it matches the name of the wallet account. If the names do not match, as shown in block 451, an error message may display “The name on the card does not match the account”. If the name on the payment card matches the name of the wallet account, the system will determine if the PAN number matches an existing card already stored on the server and create a new account, You can either keep your existing account. When a new card is created, the system can store the track data encrypted as described below in the secure memory payment section of the MST.

  As indicated as block 446, a determination may be made as to whether the removed data matches any previously stored card stored in the wallet account. If not, a new card is created in the wallet user account on the server, as shown as block 448. When a new card is created, the system may also store the track data encrypted in the secure memory payment section of the MST, as shown at block 438. If there is a match, the card is identified as existing, as shown as block 450, and the card is loaded.

  In one embodiment, the MST has the ability to load any type of magnetic stripe card into the memory means, not just a payment card. Non-payment cards can be stored separately for convenience without adding much security. For example, some non-payment applications can include cards for opening doors, loyalty cards, and the like. Payment data and non-payment data can be loaded separately into two separate fields or storage areas. In some instances, payment cards may not be loaded into non-payment storage. For example, payment data may have a specific format that can be detected and may not be loadable into a non-payment storage area. The payment card can also require authentication to the application before transmission. On the other hand, default non-payment data may be sent without authentication.

  In one embodiment, another process that the MST loads is to dynamically send magnetic stripe data from the server to the MST through mobile devices and applications. In this manner, the magnetic stripe data can be transmitted from the server to the MST after authenticating, storing and / or transmitting the wallet user so that the dynamic magnetic stripe data can be transmitted to the mobile device. it can. In one embodiment, the track data generated by the server can be dynamically loaded for payment purposes, so that a one-time payment certificate can be provided to the wallet user at the time of payment. Can be generated dynamically.

  In another embodiment, the hotel or casino room key can be sent to the user's wallet application or digital wallet and then sent to the MST, which allows the user to physically check in or You don't have to wait in line. The wallet user can “check in” to the hotel via an application on the user's mobile device (optionally, the location of the mobile device can be matched to the reservation address for additional security. The reservation server then sends a “key” to the wallet server, which is then sent to the wallet application or digital wallet and loaded into the MST's memory means for non-payment purposes Is done. The user can press the send key on the MST to send the magnetic stripe data stored in the MST for non-payment purposes without authenticating to the wallet application. Because the “key” or magnetic stripe data from the hotel can expire on the server side after a period of time, this method is relatively secure and returns the party's magnetic stripe hotel key. Even if you forget it, you can respond equally.

  In these embodiments, the system has the ability to load the MST remotely from the server, and a third party, eg, a card issuer, dynamically sends payment or non-payment card data to the MST for transmission. To be able to. A correctly paired MST may have to be used to load remotely. Since the system can control whether magnetic stripe data is stored as paid or unpaid card data, the system can be used in disconnected mode in a variety of ways. Applications of this method include sending a dynamic payment card token from a server for use in a one-time payment, and remotely checking in a hotel room without going to the front desk be able to.

  After loading a new “key” or magnetic stripe card data into the MST and storing it in the default non-payment card container of the memory means, it can be used in “disconnect mode” as described in more detail below. it can. Once a payment card is selected by the wallet application, a particular card can be valid for a period of time, eg, 5 minutes, during which time non-payment default cards cannot be sent by MST. In order to distinguish between a payment cart and a non-payment card, the payment card may have a special format and a bank identification number (BIN) that can be recognized when the application detects the payment card. The BIN can be checked against the account name and can be stored for the user if the account name matches.

  In some embodiments, track data is not stored on the server, only PAN data is stored. Multiple cards can be loaded into the memory means or SE for later selection or use and separated into payment cards and non-payment cards. In some embodiments, the payment card may only be sent after it has been authenticated to the wallet application, and the time after selecting the card and sending it in disconnected mode may be limited. For convenience, the payment card can be selected as the default card sent in disconnected mode without authenticating to the wallet application.

  In one embodiment, the name on the card's track data read from the physical payment card should match the name of the wallet account in order to successfully store the card on both the MST side and the server side. Yes, otherwise, the application does not finish the card loading process and displays an error message to the user as "Error: name on card does not match account". Once the track data is stored in the SE, the user browses the card stored in the wallet application and selects the top wallet card as the default card for sending payments and non-payments can do. There may also be cards stored in the cloud computing architecture via card-not-present methods that are not stored on the MST for card present payment. However, any card stored against the MST should have an equivalent copy of the PAN data only in the cloud computing infrastructure, and those cards can be stored in the cloud via the application or the web / internet. It may have to be removed separately from the computing infrastructure. Reconfiguring the MST is not erasing card data in the cloud computing infrastructure. Duplicate cards with the same PAN data do not appear as different cards, that is, the user has already entered the card number remotely in his wallet account in the cloud computing infrastructure and he later read the same card and physically When loaded into the MST for general use, the cards in the cloud computing infrastructure remain intact and do not need to be replicated if the PAN data is the same.

  Once the card is loaded onto the MST, it can be selected by the wallet application. The selected card can also be deleted from the MST memory and from the application.

  In yet another embodiment, the wallet account may allow the loading of encrypted track data on the MST's secure memory means or SE directly from the wallet server, thereby issuing The person chooses to create a card account for the wallet user and then the top-level wallet with track data from the wallet server to the mobile communication device and through the wallet application communicated to the MST. Allows SE to be loaded as a card. This is a type of remote loading of track data into the wallet user's MST for physically accepted use. For example, the card issuer may be a credit card provider or bank, or a non-payment card provider such as a hotel card, doorway pass, or loyalty card issuer. Payment card can be a standard payment card, or a one-time payment card so that the card number is a token that refers to the actual payment card account on the issuer's server It can be. As a result, the number can only be used once, and even if the token is illegally accessed or copied, stronger security can be provided.

  Once the magnetic card track data is loaded into the MST, the wallet application uses the mobile device's camera to capture images of the front and / or back of the card and its own MST that the user uses for transmission. It is also possible to configure so that a card can be selected. Cards selected by the application can also be deleted using the wallet application and erased from the memory means. The wallet application can also be used to show the retailer what can be identified by capturing the wallet user's identification card and touching a button on the wallet application.

  A method of operation in transmission and usage mode according to an illustrative embodiment will be described with reference to FIG. A POS transaction begins at block 452. In a POS face-to-face transaction, the encrypted track data stored in the memory means or SE can be decrypted by the MST as illustrated as block 454 and then as illustrated as block 456. , Can be sent to POS. The POS can also send data to the transaction processor, as shown as block 458.

  In a remote transaction, the encrypted track data can be sent to the mobile communication device's checkout application, as shown as block 460. The checkout application can then send the data to the payment server, as shown as block 462. As shown as block 464, this data can only be decrypted by the corresponding payment server at checkout, otherwise being transmitted over a wireless or wired internet network, or other communications network It is not useful for mobile applications or people who intercept such data. The payment server may also send the decrypted data to the transaction processor, shown as block 466.

  An operation method in the disconnected transmission mode according to an illustrative embodiment will be described with reference to FIG. As shown as block 468, the wallet user logs into his wallet application, for example, by an MST connected via an audio jack or other communication interface. If a card or cards are securely loaded into SE / Secure memory, when more than one card is loaded, the user is used to send to the POS when the MST unit is turned on. You can change the default / top-level wallet card. In one embodiment, a particular card may initially be “selected”. Thereafter, the “selected card” on the MST will receive a “send” in the wallet application by the plugged MST dongle, as shown as block 470, within a specific period before the MST can no longer send payment cards. Can be sent to the POS by pressing the "" button or by pressing the send button on the MST itself. Upon attempting to end the transmission, the LED indicator may flash light, eg, green light, for approximately 500 ms or other desired time, as shown as block 472. Because of the non-payment card stored in the MST, whenever the payment card does not invalidate the default card position, the default non-payment card is sent and available by simply pressing a button on the MST, and the LED The indicator indicates that transmission is taking place.

  If the MST is authenticated by a wallet application that is enabled in default transmission mode and the MST is removed from the mobile communication device, as shown as block 474, the dongle remains on as shown at block 476, It remains unlocked for about 4 minutes or more. Thus, as shown as block 478, by pressing a button on the MST during this period, the MST dongle can be either a retailer or a merchant to terminate the transmission of card data when the MST is near POS. After the user can be transported and used, the dongle may then be stopped, turned on again by the wallet application and unlocked. This feature is useful for many restaurants that need to return the card to a POS system away from the dining table. This feature allows the waiter to move to the POS using only the MST dongle for 4 minutes while the unit is on, without having to use the consumer's mobile communication device with the MST dongle.

  In one aspect, the consumer stores the track data in its own magnetic stripe, if necessary, through a wallet application using special procedures, storing the track data in memory means at the time of manufacture, or remotely loading by a server. It can be loaded by converting the track data into contactless track data or stored directly directly in the MST memory means or SE for later use.

  An operation method in the POS card reading mode according to an illustrative embodiment will be described with reference to FIG. This mode allows MST's Magnetic Stripe Reader (MSR) to be used with a POS application on a mobile device to not only load the card but also accept payments like any retail POS application. It is possible to play the role of POS by reading and encrypting the magnetic stripe card. As shown as block 480, the user can read the magnetic card on the MSR of the MST. The MST reads and encrypts the data on the card as shown as block 482. The data can be sent to a POS application on the mobile communication device, shown as block 484, and the mobile communication device can then send the data to the payment server, shown as block 486. The payment server can also send data to the transaction processor to process the payment, as shown as block 488.

  By the device, system, and method disclosed herein, it is captured and stored by the user in the secure memory means of the MST without modification and by the card issuer to operate with a contactless POS. Unlike contact-type or NFC track data with special fields that need to be encoded, magnetic card track data is provided for later use by POS or other MSR devices. The MST includes a button that allows the magnetic card data to be sent to the POS, while the MST is disconnected or removed from the mobile device. When the MST is transmitting correctly, the LED indicator is active. The unique pairing between the MST and a specific wallet account allows the MST to be used only by that account to store track data, giving it better security for use for transmission. Thus, the ability to re-set the MST enables the MST pairing to be released and reused. The MST can be connected to mobile communication devices via various interfaces other than audio jack and USB connection.

  Depending on the apparatus, system and method, encrypted magnetic stripe track data can be loaded into the memory means of the MST. The encrypted magnetic stripe track data can be later decrypted and sent to the POS, or sent encrypted to the mobile communication device and then transmitted to the payment server for decryption and processing And load the wallet account on the server or process the POS transaction. The apparatus, system, and method provide the ability to use stored or read track data for a virtual checkout environment so that retailers conduct more secure and less expensive transactions. Is done.

  Depending on the device, system, and method, the track data can be remotely transferred from the card issuer to the wallet server provider, to the wallet application on the mobile communication device, and to the SE or memory means of the MST for later use. Loading and transmission are performed. The apparatus, system, and method provide the ability to load loyalty account information along with payment card data into one or more arbitrary fields of track data that is read by the issuer during or after the transaction. Allows you to combine offer and loyalty programs with payment transactions.

  As described above, for example, magnetic stripe card data stored on the secure element 108 of the MST 100 is transmitted to the checkout application of the mobile communication device and used in the mobile checkout system. Good. In one aspect, a mobile checkout system and method is disclosed that helps reduce the shopping cart dropout rate and increase the conversion rate to sales. However, it should be understood that the mobile checkout system and method disclosed herein can be implemented with or without MST 100.

  An overview of the system 20 for a mobile checkout process according to an illustrative embodiment is described with reference to FIG. The system 20 includes a mobile communication device 500 and a checkout server 600 that may be similar to or the same as the mobile communication device 200 described above. As shown, mobile communication device 500 and checkout server 600 can communicate with each other over network (s) 170.

  The checkout server 600 houses one or more web service application program interface (API) 602 (also referred to as a checkout API) and a database 604. Database 604 can store user and payment data. Checkout server 600 may optionally include a checkout web page for online checkout in a browser.

  The mobile communication device 500 can include a mobile checkout application 502, one or more shopping applications 504, and one or more browser applications 506. Mobile checkout application 502 may be activated or launched from an online shopping web page or from a mobile shopping application and is designed to perform payment transactions. The mobile checkout application 502 can be used for payment and payment at the hardware and / or peripheral device of the mobile communication device 500, such as the MST 100 or wallet application described above, and / or at the remote checkout server 600 or cloud. Store personal data. The mobile checkout application 502 retrieves or receives customer data and payment card data from the hardware, peripheral devices such as the MST 100, the wallet application described above, and / or the cloud during the checkout process. Thus, during the checkout process, the amount of data input such as credit card number, expiration date and billing address is reduced. Other applications such as a shopping application 504 that loads a shopping website and a browser application 506 may also be installed on the mobile communication device 500.

  There may be many versions of the checkout application 502 for various mobile platforms including, but not limited to, Android (R), iOS (R) and Windows (R) mobile phones and tablet devices. There is.

  Checkout application 502 allows a customer to terminate a transaction originating from either the mobile communication device 500 or another computing device, such as a desktop or other computing device. Checkout application 502 is also switched or redirected to another mobile application, such as shopping application 504, and switched to a web page on browser application 506 running on mobile communication device 500. Initiated by an push notification sent by the checkout server 600 and / or activated by the user and may be used to scan a quick response (QR) code display of a transaction. Each of these operating modes will be described in further detail below.

  The checkout application 502 can store payment and personal data on the mobile phone hardware or peripheral device. The checkout application can also store information in the cloud or remote checkout server 600. Checkout application 502 retrieves customer data and payment card data such as card number, expiration date and billing address from the hardware, peripherals, or cloud during the checkout process and checks out・ Reduce the amount of data input during the process.

  A checkout application 502 running on the mobile communication device 500 can access one or more hardware components of the mobile communication device 500. For example, as shown in FIG. 8, the checkout application 502 includes a SIM card 508, a secure element (SE) 510, and a memory storage device 512, which can store data. Access to non-limiting hardware components is possible. Checkout application 502 can use parameters captured for further security measures, such as camera 514, accelerometer 516, gyroscope 518, GPS receiver 520, electronic compass 522, and biosensor 524. Hardware components can also be accessed including but not limited to.

  Checkout application 502 accesses peripheral components and accessories through various communication interfaces 526 including, but not limited to, USB, audio jack, Bluetooth, serial port, WiFi, and other interfaces. be able to. Peripheral components and accessories include payment card reader 700, such as MST 100, magnetic stripe card reader, smart card reader, NFC card reader, and EMV card reader, for inputting and outputting data. A PIN pad 702, a bar code scanner 704, a printer 706, a display unit, a check scanner, etc. can be included, but is not limited to these.

  The checkout application 502 may be launched independently by the user to manage the user's stored card and personal information after successful user authentication. When the checkout application 502 is used by a peripheral device such as the MST 100, the checkout application 502 emulates a magnetic swipe and does not need to physically read the card and sends an electromagnetic signal of track data can do. This allows the checkout application 502 to be used in a real retail store for virtual card magnetic stripe transactions.

  In one embodiment, when the checkout application 502 targets or is launched from another mobile application or browser web page after a payment transaction, the customer may return URL (Return Uniform Resource Locator). ) To return to the call shopping browser web page or call mobile shopping application. In this redirect mechanism, the checkout application 502 can register a custom URL scheme by the operating system. After registration, the operating system can associate the URL with the checkout application 502 using a scheme portion in the URL, eg, “capp: //”.

  The operating system can then handle the custom URL scheme / protocol by launching the checkout application 502. For example, in the iOS and Android systems, the custom URL is customSchema: // mydomain. com / myparameters. In Android, Android Manifest. Registration is done by adding an intent filter in the xml file. In iOS, the “CFBundledURLTypes” setting is set to plist. Registration is performed by adding to the info file. By performing the above registration, the checkout application 502 may then be opened / activated / switched when another application or website calls this URL. In addition, parameters can be passed to the checkout application 502 through the myparameters portion of the custom URL. By using a custom URL scheme redirection mechanism, various shopping applications can be redirected to the checkout application 502 to perform payment operations. Depending on the various scenarios, the transaction results may be sent / redirected back to the calling application or caller in various ways.

  When the checkout application 502 is triggered by an push notification message or QR code scan after a payment transaction, the originating shopping page on the computer or communication device updates the transaction result.

  Since the checkout application 502 is a native application on the mobile communication device 500, the checkout application 502 can access hardware or peripheral components that are otherwise not accessible from the mobile browser. Furthermore, since the checkout application 502 is a centralized application that is launched / switched from or redirected to other shopping websites or applications, each retailer is no longer There is no need to integrate hardware drivers into those applications. Instead, simple redirects from those applications or websites in the form of URL redirects are sufficient.

  To use the checkout system, the user registers and sets up an account by setting a username and password. During the account setup process, the user's personal information, such as name, last name, billing address, and shipping address, is captured and stored at the checkout server 600. For example, user account information is stored in database 604. An optional identity verification step can be used to validate the user identity. Optionally, information associated with the mobile communication device 500 can be stored and associated or associated with the user's account.

  The checkout server 600 hosts one or more of the web services and exposes those web services as an application program interface (API) 602 called a checkout API for online / mobile retailers. Develop their shopping application (s). As described above, the database 604 is used to store registered user personal information and payment information. Checkout server 600 also places a checkout web page for the user when the user is shopping online and ends the transaction in the browser.

  In one aspect, the shopping application creates a checkout token that is used to uniquely identify a payment transaction by calling an API method hosted by the checkout server 600. Product information, information about the transaction including price and quantity, and flow control information such as a redirect URL are given as input parameters. The URL can be used to set a redirect or switch back to the calling application or web page. With this checkout token used to track payment transactions, all redirection and flow control can be done. A retailer application or website can query the status of the payment transaction by calling an API method hosted by the checkout server 600.

  In one aspect, FIG. 9 illustrates an exemplary operational flow for issuing tickets online using an online shopping website and a mobile shopping application. In this example, the user or customer 900 is browsing a shopping application 504 on the user's mobile communication device 500. The customer 900 activates a shopping application 504 such as an opera ticket application. Customer 900 uses shopping application 504 to browse and add items to a shopping cart to check out and purchase. In this illustrative example, shopping application 504 manages a shopping cart and communicates with retailer server 904 to obtain updated product information such as opera title, play time, and price (902). ). If customer 900 decides to buy the product, the customer selects the product and proceeds to checkout step 906. In the checkout step, customer 900 selects a checkout button to purchase a product (908). Application 504 calls checkout server 600 via retailer server 904 (910) and passes information about products, transaction volumes, and the like. The retailer server receives a checkout token 914 from the checkout server 600 (912).

  Application 504 receives checkout token 914 (916) and redirects 918 to checkout application 502 with the custom URL and checkout token as parameters. In the checkout application 502, the customer 900 authenticates itself with the checkout server 600 (920). Once authenticated, the customer 900 confirms the transaction with the checkout server 600 and the checkout application 502 can checkout server 600 or website API 602 to terminate the transaction identified by the checkout token. (922). Checkout server 600 forwards the transaction to payment processor 926 (924). The payment processor 926 returns the transaction result to the checkout application 502 via the checkout server 600, shown as 930 (928).

  After the transaction ends, the checkout application 502 redirects back (932) back to the originating shopping application with the checkout token as a parameter and the transaction result, which displays the results page 934. To do. The application (A) receives the transaction result from the redirect URL parameter, and the shopping application updates the transaction status with the retailer server (936). Here, (B) the checkout server 600 pushes the result to the retailer server (Push) (938), or (C) the retailer server sends the latest transaction status or result from the checkout server 600 through the API 602. Get (or receive) the transaction result by one or more possible paths, including pulling (940).

  For example use, a sporting goods shopping application developed by Acme can be redirected to a checkout application 502 for payment. For further exemplary uses, BuyMore. The grocery store BuyMore application developed by com can implement its loyalty program in its own application and redirect it to the checkout application 502 for payment, as well as a pizza ordering application by Contoso Restaurant , Building a mobile application for delivery service and using a checkout application 502 for payment can be included. In this way, application developers (from various companies, etc.) can focus on the product browser and shopping experience, leaving the payer to the checkout application 502.

  In one aspect, FIG. 10 illustrates an exemplary operational flow for online ticketing using an online shopping website and browser application. In this example, a user or customer 900 is browsing on an online shopping retailer website using a browser application 506 on the user's mobile communication device 500. Customer 900 uses browser application 506 to launch a retailer's website, such as an opera ticket website. Customer 900 uses browser application 506 to browse and add items to a shopping cart for checkout and purchase. In this example, the retailer website communicates with the retailer server 904 to obtain updated product information, such as opera title, play time, and price (1002). Retailer server 904 renders a retailer website and manages the shopping cart. If customer 900 decides to buy the product, the customer selects the product and proceeds to checkout step 1006. In the checkout step, customer 900 selects a checkout button to purchase a product (1008). The retailer website calls or uses the retailer server 904 directly to call 1010 the checkout server 600 and passes information about the product, transaction volume, etc. The retailer server receives a checkout token 1014 from the checkout server 600 (1012).

  Application 506 receives checkout token 1014 (1016) and the retailer website redirects to checkout application 502 with the custom URL and checkout token as parameters (1018). In the checkout application 502, the customer 900 authenticates itself with the checkout server 600 (1020). Once authenticated, the customer 900 confirms the transaction with the checkout server 600 and the checkout application 502 can checkout server 600 or website API 602 to terminate the transaction identified by the checkout token. (1022). Checkout server 600 forwards the transaction to payment processor 926 (1024). The payment processor 926 returns the transaction result to the checkout application 502 via the checkout server 600 (1028), shown as 1030.

  After the end of the transaction, the checkout application 502 redirects (1032) back to the browser application 506, which displays a result page 1034 with the checkout token as a parameter and the transaction result. The retailer website (A) receives the transaction result from the redirect URL parameter, and the retailer website updates the transaction status with the retailer server (1036). Here, (B) the checkout server 600 pushes the result to the retailer server (1038), or (C) the retailer server retrieves the latest transaction status or result from the checkout server 600 through the API 602 ( 1040) to obtain or receive the transaction result by one or more possible paths.

  In one aspect, FIG. 11 illustrates an exemplary operational flow for launching a checkout application from a shopping web page in a desktop browser running on a computer by push notification or short message service (SMS). . In this illustration, a user or customer 900 is browsing on an online shopping website using a desktop browser 1102 on a computing device 1100 such as a computer. Customer 900 uses browser 1102 to launch a retailer's website, such as an opera ticket website. Customer 900 uses the browser to browse and add items to a shopping cart for checkout and purchase. In this example, the retailer website communicates 1104 with retailer server 904 to obtain updated information about the product, such as opera title, play time, and price. Retailer server 904 renders a retailer website and manages the shopping cart. If customer 900 decides to buy the product, the customer selects the product and proceeds to checkout step 1106. In the checkout step, customer 900 selects a checkout button to purchase a product (1108). The retailer website calls or uses the retailer server 904 directly to call the checkout server 600 (1110) and passes information about the product, transaction volume, URL, and the like. The retailer server receives a checkout token 1114 from the checkout server 600 (1112).

  The user may be prompted for credentials to authenticate the user on the web browser. The retailer website calls the checkout server 600 to authenticate the user. After user authentication, the checkout server looks up the phone number or device identifier of the user's mobile communication device 500 and pushes the user's registered mobile communication device 500 with a checkout token. Can be transmitted (1116). Upon receipt of the notification, the checkout application 502 is activated. In the checkout application 502, the customer 900 authenticates itself with the checkout server 600 (1120). Once authenticated, the customer 900 confirms the transaction with the checkout server 600 and the checkout application 502 can checkout server 600 or website API 602 to terminate the transaction identified by the checkout token. Is called (1122). Checkout server 600 forwards the transaction to payment processor 926 (1124). Payment processor 926 returns the transaction result to checkout application 502 via checkout server 600 (1128), shown as 1130. The retailer website updates the transaction status (1136), for example by polling, and the desktop browser displays the results page 1134. The retailer website may either (A) checkout server 600 push the results to the retailer server (1138), or (B) retailer server may update the latest transaction status or results from checkout server 600 through API 602. Get or receive the transaction result by two possible paths, such as withdraw (1140).

  In one aspect, FIG. 11 also illustrates an exemplary operational flow for launching a checkout application from a shopping web page in a desktop browser running on a computer by QR code scanning. In this illustration, a user or customer 900 is browsing on an online shopping retailer website using a desktop browser 1102 on a computing device 1100 such as a computer. Customer 900 uses browser 1102 to launch a retailer's website, such as an opera ticket website. Customer 900 uses the browser to browse and add items to a shopping cart for checkout and purchase. In this example, the retailer website communicates with the retailer server 904 to obtain updated product information, such as opera title, play time, and price (1104). The retailer server 904 renders the retailer website and manages the shopping cart. If customer 900 decides to buy the product, the customer selects the product and proceeds to checkout step 1106. In the checkout step, customer 900 selects a checkout button 1108 to purchase the product. The retailer website calls or uses the retailer server 904 directly to call the checkout server 600 (1110) and passes information about the product, transaction volume, URL, and the like. The retailer server receives a checkout token 1114 from the checkout server 600 (1112).

  In this example, the retailer website or retailer server calls the checkout server 600 through the API 602 to obtain a QR code 1142 indication of the checkout token (1118). The user activates the checkout application 502 on the mobile communication device 500 and scans the QR code 1142 (1144). When the checkout application 502 is launched, the process proceeds as described above with reference to FIG.

  Although the methods and algorithms described above, including those described above with reference to flowcharts and diagrams, are described separately, any two or more of the methods disclosed herein may be combined in any combination. It should be understood that Any of the methods, algorithms, implementations or procedures described herein may be performed by (A) a processor, (B) a controller, and / or (C) machine-readable instructions executed by any other suitable processing device. Can be included. Any algorithm, software, or method disclosed herein can be, for example, flash memory, CD-ROM, floppy disk, hard drive, digital versatile disk (DVD), or Although implemented in software stored on non-transitory tangible media, such as other memory devices, as will be readily appreciated by those skilled in the art, all and / or part of the algorithm is Instead, it may be implemented by the device and / or embodied in firmware or dedicated hardware in a well-known manner, for example, Application Specific Integrated Circuit (ASIC: Application Specific Integrated Circuit). ), A programmable logic device (PLD), a field programmable logic device (FPLD), a discrete logic, and the like. In addition, although particular methods and algorithms are described with reference to the flowcharts presented herein, many other implementations of examples of machine-readable instructions will be appreciated by those skilled in the art. A method may be used instead. For example, the order in which the steps are performed can be changed and / or some of the described steps can be changed, omitted, or combined.

  It should be noted that the methods and algorithms shown and discussed herein may have various modules that perform specific functions and interact with each other. These modules are simply separated based on their functionality for purposes of explanation and stored on computer readable media for execution on computer hardware and / or appropriate computing hardware. It should be understood to represent executable software code. The various functions of the various modules and units can be combined or separated in any way as hardware and / or software stored on a non-transitory computer readable medium as described above as modules. Can be used separately or in combination.

  The mobile communication device can be a laptop computer, cellular phone, personal digital assistant (PDA), tablet computer, and other mobile devices of that type. Communication between components and / or devices in the systems and methods disclosed herein may be wired or wireless configurations or unidirectional or bidirectional electronic communication through a network. For example, one component or device can be connected to a wired or wireless network, directly or indirectly by a third party on the Internet, or by another component or device. Communication between components or between devices becomes possible. Examples of wireless communication include radio frequency (RF), infrared, Bluetooth, wireless local area network (WLAN) (such as WiFi), or long term evolution (LTE). Including, but not limited to, wireless network radios such as radios that can be communicated by wireless communication networks such as Term Evolution) networks, WiMAX networks, 3G networks, 4G networks, and other types of communication networks of that type.

  Although the apparatus, system, and method have been described and illustrated in connection with certain embodiments, many variations and modifications will be apparent to those skilled in the art and may be made without departing from the spirit and scope of the disclosure. Is possible. Thus, the present disclosure is not intended to be limited to the precise details of methodology or construction shown above, as such modifications and alterations are intended to be included within the scope of the present disclosure.

Claims (20)

A checkout implemented on the mobile communication device that includes a retailer application or browser application that is available on the mobile communication device and adapted to allow a user to select and purchase items from the retailer A system,
A communication processor in communication with a checkout server that houses one or more web service checkout application program interfaces (APIs) adapted to communicate with the mobile communication device;
Installed on the mobile communication device; and
To be launched in response to receiving information corresponding to a purchase transaction,
Communicating with the checkout server, causing the checkout server to terminate the purchase transaction; and
A checkout system comprising: a checkout application adapted to restart the retailer application or browser application when the transaction ends.   The checkout server of claim 1, wherein the checkout server is responsive to the user initiating the purchase transaction, the checkout server creating a checkout token that identifies the purchase transaction. ·system.   The checkout system of claim 2, wherein the checkout server sends the checkout token to the retailer application or browser application.   The checkout system of claim 3, wherein the checkout application receives the checkout token from the retailer application or a browser application.   The checkout system of claim 4, wherein the checkout application authenticates the user.   The checkout system of claim 5, wherein the checkout application confirms the purchase transaction by the checkout server in response to the user authentication.   The checkout application of claim 6, wherein the checkout application sends the checkout token and result of the purchase transaction to the retailer application or browser application during restart of the retailer application or browser application. Checkout system.   8. The checkout system of claim 7, wherein the retailer application or browser application displays a result page corresponding to the purchase transaction in response to being restarted.   The checkout system of claim 1, wherein the checkout server terminates the transaction by communicating the purchase transaction to a payment processor.   The checkout system of claim 1, wherein the checkout application is adapted to receive user payment information from a magnetic stripe transporter in communication with the mobile communication device.   The checkout system of claim 1, wherein the checkout application is adapted to be launched in response to receiving information corresponding to the purchase transaction from the retailer application or a browser application. .   The checkout system of claim 1, wherein the checkout application is adapted to be launched in response to receiving information corresponding to the purchase transaction from the checkout server.   The checkout application is adapted to be launched in response to receiving information corresponding to the purchase transaction from the checkout server through an push notification, email, or short message service. The checkout system of claim 1.   The checkout application is adapted to be launched in response to receiving information corresponding to the purchase transaction from a quick response (QR) code displayed on the mobile communication device; The checkout system of claim 1. Allowing a user to browse and select items for purchase from a retailer through a first application or browser;
Activating a checkout application installed on the mobile communication device in response to the checkout application receiving information corresponding to a purchase transaction;
Receiving by the checkout application a checkout token that identifies the purchase transaction created by a checkout server;
Communicating with the checkout server by the checkout application to cause the checkout server to terminate the purchase transaction;
Restarting the first application or browser in response to the end of the transaction.   The method of claim 15, wherein receiving the checkout token includes receiving the checkout token from the first application or a browser application.   The method of claim 15, further comprising authenticating the user by the checkout application prior to communicating with the checkout server.   The method of claim 15, further comprising receiving user payment information from a magnetic stripe transporter in communication with the mobile communication device by the checkout application.   Invoking the checkout application is responsive to receiving information corresponding to the purchase transaction from the checkout server through an push notification, email, or short message service. 16. The method of claim 15, comprising launching an out application.   Invoking the checkout application is responsive to receiving information corresponding to the purchase transaction from a quick response (QR) code displayed on the mobile communication device. The method of claim 15 comprising launching an application.