HK1230763A1 - Mobile checkout systems and methods - Google Patents

Description

Mobile settlement system and method

Cross reference to related applications

This application is a continuation-in-part application of united states patent application number 14/806,219 filed on day 22, 7/2015, whereas united states patent application number 14/806,219 is a continuation-in-part application of 14/185,111 filed on day 20, 2/2014, whereas 14/185,111 is a continuation-in-part application of united states patent application serial number 13/781, 964, now united states patent application number 9,022,285, filed on day 1, 3/2013, and claims the benefit thereof, the contents of all of which are incorporated herein by reference in their entirety.

Technical Field

The present disclosure relates to a system and method for implementing mobile wallet applications and settlement processing.

Background

The transmission of magnetic stripe data is accomplished primarily by sliding (swipe) the magnetic stripe card relative to a Magnetic Stripe Reader (MSR) to enable payment, Identification (ID), and access control functions. Mobile wallet applications on smartphones and tablet devices have difficulty employing MSRs to interact with existing merchant point of sale (POS) devices or other devices. Contactless reader-enabled POS terminals (typically using, for example, the ISO 14443 standard) for receiving contactless or Near Field Communication (NFC) payments are not widespread. Replacing millions of merchant POS devices or door locks that accept only magnetic stripe cards, interact only with NFC phones or other means of transmission like barcodes would be expensive and would take time.

In many countries, the number of contactless payment cards issued remains small compared to the number of magnetic stripe cards issued to consumers. NFC chips with contactless communication capabilities have been embedded in some mobile phones and 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 for contactless payment transactions with a limited number of NFC capable POS devices, but these NFC chip based digital wallets have significant limitations.

Most phones do not have an embedded NFC chip, which severely limits the penetration of this mobile wallet solution to the public. Furthermore, the process for loading the cardholder's payment credentials into the memory of the NFC chip is complex and expensive. Specifically, loading the memory of the NFC chip requires a Trusted Security Manager (TSM). The payment issuer needs to register (sign up) for such TSM services and pay money for such services.

In order to make the loading process work smooth, there are various technical complexities, especially when some parts of the loading process fail in the middle of the transmission chain from the issuer to the TSM, to the internet, to the phone via the mobile operator's network, to the chip. Furthermore, all standards have not been implemented and there are multiple competing parties that make it more difficult to become widespread.

In electronic commerce (eCommerce), there are generally two common approaches to implementing an online shopping settlement process. In a first method, a customer selects a payment button, selects a payment method, and completes a payment process within a merchant online shopping website. The merchant server communicates with a server of the payment service provider to perform the payment transaction. The method enables customers to stay on the same merchant site; however, the development and integration process between the merchant server and the payment service provider is complex and expensive. Additionally, consumers may be reluctant to enter sensitive information on unfamiliar web pages or websites.

In a second method, the customer's browser is temporarily redirected to a settlement webpage hosted by the payment service provider (hosted by), such as PayPal^TMAnd (5) settlement processing. The customer is atThe transaction is completed in a web page hosted by the payment service provider. After the transaction, the browser is redirected back to the originating online shopping website. The method is easier for merchants to develop and integrate. For the customer, identifying the payment service provider provides a better sense of security and trust. It may also make the process smoother when the customer has previously undergone similar payment processing.

Disclosure of Invention

The present disclosure relates to devices, systems, and methods that include: magnetic stripe capture, storage and transmission devices for use in conjunction with a mobile wallet application to capture, store and transmit magnetic stripe card data in physical and virtual environments to merchant traditional point of sale (POS) terminals and other devices or settlement systems having Magnetic Stripe Readers (MSRs). The present disclosure also relates to mobile settlement systems and methods. The system provides a convenient shopping experience for the consumer, a secure and informative transaction for the merchant, and in some cases additional data will be transferred to the MSR for the purpose of offer (royal), Identification (ID), or access control.

In one aspect, a system for securely capturing, storing and transmitting magnetic stripe payment card data includes a mobile communication device and a mobile application, and a Magnetic Stripe Transmitter (MST), which may be in the form of an external dongle (dongle) or an essential component thereof may be part of a consumer mobile communication device. The MST dongle or built-in MST includes: examples of software protectors include microprocessors, magnetic field transmitters including drivers and inductors that can generate varying magnetic fields, batteries, charging circuits, Magnetic Stripe Readers (MSRs), memory devices or secure elements, and embodiments of dongle, audio jack interfaces and communication interfaces (e.g., USB interfaces, 30-pin or 9-pin Apple interfaces, bluetooth interfaces, etc.) that work in conjunction with consumer mobile devices and wallet applications to capture magnetic stripe card data, securely store data (which may include inclusion of cryptograms into the magnetic stripe card data), and transmit such data to merchant point of sale (POS) or settlement systems in physical and virtual environments.

Aspects of the present disclosure may include one or more features. The mobile communication device may include a mobile application that initiates MST for use with a particular wallet account and unlocks the MST for transmission and use. The mobile communication device may be used with a mobile communication device or a payment settlement application on the internet that interacts with the MST to accept payment card data from the MST that may include dynamic cryptogram for protecting the payment data as a merchant POS application or a consumer settlement application and transmit the payment card data to a payment server for processing of the transaction. The mobile wallet application may interact with the MST via an audio jack or other interface in various modes of operation including, for example, an initialization and reset mode, a load card delete card mode, a transfer and use mode, a disconnect transfer mode, and a POS card read mode.

In one aspect, the MST operating in the initialization and reset mode is configured to allow the user to pair with and unpaid/reset a particular MST with the mobile wallet account and only allow one device per account. The MST operating in the load card delete card mode is configured to allow a user to load magnetic stripe card data by sliding the user's existing plastic magnetic stripe card over the MSR onboard the MST and store the card track data in a memory device or secure element. For payment cards, the application loads Primary Account Number (PAN) data for the card to the online digital wallet via the mobile wallet application. The application may also be used to delete card information from the memory device and the server. The MST operating in the transmit and use mode is configured to allow the user to select a particular payment card as: when the button is activated or pressed, it is used to transfer the stored track data to the card at the top of the wallet of the merchant POS system or to the default card. In another aspect, if non-payment cards are stored in the MST, one non-payment card may be stored as a default card for transfer without authenticating the wallet application and selecting such a card. The non-payment cards include hotel keys, gate entry, or ID and coupon cards that may be loaded into the MST in a separate memory device for later transmission.

The MST operating in the POS card reading mode is configured to allow the user to swipe the payment card with the MST's MSR and transfer the card data to the POS application on the mobile communication device and then to the payment server and processor. The mobile communication device may be a smartphone, a tablet device, or a personal computer. The MST further includes a battery and a charging circuit. The microprocessor is configured to provide security and communication for the mobile communication device. The memory device securely stores payment card data. The MST is configured to transmit the card track data to a merchant settlement application on the mobile communication device to create a card-present transaction for the merchant. The MST may also be configured to read the payment card and transmit the payment card data to the mobile communication device and associated POS application, which in turn transmits the transaction and card data to a payment server and processor like a POS.

In another aspect, the disclosure features a method for securely capturing, storing, and transmitting magnetic stripe card data. A Magnetic Stripe Transmitter (MST) dongle comprising: a microprocessor, a driver configured to send current and signals to an inductor creating a changing magnetic field, a battery, a charging circuit, a magnetic stripe card reader, a memory device or secure element, an audio jack interface and a communication interface (e.g., USB interface, 30-pin or 9-pin Apple interface, and bluetooth interface, etc.), which work in conjunction with consumer mobile devices and wallet applications or mobile applications to capture magnetic stripe card data, securely store card data, and transmit such data to merchant point of sale (POS) terminals, accounting systems, or other MSR devices in physical and virtual environments.

The systems and methods disclosed herein provide a number of advantages, for example, magnetic card track data may be captured by a user or directly from a server and stored in a secure memory device of an MST without modification to the magnetic strip data for later use with an MSR device. For payment cards, no changes need to be made to the magnetic stripe data, as opposed to contactless or NFC magnetic track data having a specific field that must be encoded by the issuer to properly function with the contactless POS. The MST may include a button that allows transmission of magnetic card data to the POS when the MST is disconnected or detached from the mobile device.

In one aspect, unique pairing of MSTs to specific wallet accounts provides better security and provides the ability to reset MSTs that allow unpairing and reuse of MSTs. Further, systems and methods according to the present disclosure provide the ability to connect to a mobile communication device via a different interface in addition to an audio jack and USB. Additionally, the process of loading the encrypted magnetic stripe track data into the memory device of the MST may be later decrypted and transmitted to the MSR of the POS, or a process for the data to be encrypted for transmission to the mobile communication device and then routed to the payment server for decryption and loading of the wallet account onto the server or processing of the POS transaction.

Systems and methods according to the present disclosure provide the following capabilities: the stored track data or slipped track data is used for a more secure and lower transaction cost virtual settlement environment for the merchant, and the track data from the issuer to the wallet server provider to the wallet application on the mobile communication device is remotely loaded to the Secure Element (SE) or memory device of the MST for later use. Still further, the system and method provide the following capabilities: when transacting, the offer account information is loaded along with the payment card data into any field of the track data to be read by the issuer, which may result in an offer (offer) and offer plan in conjunction with the payment transaction.

The combined use of all of the above techniques for a consumer's seamless user experience can increase the frequency of use of the mobile wallet and allow the host of applications and functions to give consumers such as discounts and offers, making it more interesting and delivering value to consumers and merchants.

In another aspect, magnetic stripe card data may be transmitted to a settlement application of a mobile communication device and used in a mobile settlement system. Mobile settlement systems and methods are disclosed to help reduce the rate of discarding shopping carts and increase the conversion rate to sales. However, it should be appreciated that the mobile settlement systems and methods disclosed herein may be implemented with or without MST.

In general, mobile settlement systems and methods include a mobile communication device having a merchant application and/or browser application installed thereon that allows a user to select items from a merchant website for purchase. The settlement application is also installed on a mobile communication device in communication with a settlement server hosting one or more web service settlement Application Program Interfaces (APIs). The settlement application may be launched in response to receiving information corresponding to the purchase transaction, such as when the user selects an item to purchase and selects settlement. The settlement application communicates with the settlement server to cause the settlement server to complete the payment transaction by communicating with the payment processor. When the transaction is completed, the merchant application or browser application that was used to browse and select items for purchase is restarted.

In other aspects, the settlement application may be launched in response to receiving information corresponding to the purchase transaction from the settlement server through a push notification, email, or short message service. The settlement application may also be launched in response to receiving information corresponding to the shopping transaction from a Quick Response (QR) code read, captured, and/or displayed on the mobile communication device.

Drawings

Embodiments of the apparatus, system, and method are illustrated in the figures of the accompanying drawings, which are meant to be schematic and not limiting, in which like references are intended to refer to the same or corresponding parts, and in which:

FIG. 1 is a functional block diagram of an overview of a Magnetic Stripe Transmitter (MST) and a mobile communication device and a merchant point of sale (POS) device;

FIG. 2 is a flow chart of a method of operation in an initialization and reset mode;

FIG. 3 is a flow diagram of a method of operation in a load card delete card mode;

FIG. 4 is a flow chart of a method of operation in a transmit and use mode;

FIG. 5 is a flow chart of a method of operation in a disconnected transmission mode;

FIG. 6 is a flow chart of a method in a POS card reading mode of operation;

FIG. 7 is a functional block diagram of an overview of a system for performing mobile settlement processing;

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

FIG. 9 is a flowchart of a method of performing mobile settlement processing using an online shopping website and a mobile shopping application;

FIG. 10 is a flow chart of a method of performing mobile settlement processing using an online shopping website and a browser application; and

fig. 11 is a flowchart of a method of performing mobile settlement processing by launching a settlement application using a push notification, Short Message Service (SMS), or Quick Response (QR) code.

Detailed Description

Detailed embodiments of devices, systems, and methods are disclosed herein; however, it is to be understood that the disclosed embodiments are merely exemplary of devices, systems, and methods that may be embodied in various forms. Therefore, specific details described herein are not to be interpreted as limiting, but merely as a basis for the claims and as a representative basis for teaching one skilled in the art to variously employ the present disclosure.

In general, the devices, systems, and methods disclosed herein may include and may be implemented within a number of different devices and computer systems, including, for example, general purpose computing systems, server-client computing systems, consumer-merchant computing systems, mainframe computing systems, cloud computing infrastructure, telephone computing systems, laptop computers, desktop computers, smart phones, cellular phones, Personal Digital Assistants (PDAs), tablet computers, and other mobile devices. The devices and computing systems may have one or more databases and other storage, servers, and additional components, such as processors, modems, terminals and displays, computer-readable media, algorithm modules and applications, and other computer-related components. The devices and computer systems and/or computing infrastructure are configured, programmed and adapted to perform the functions and processes of the systems and methods as disclosed herein.

Referring to fig. 1, an overview of a system 10 for capturing, storing, and transmitting magnetic stripe card data to a merchant's conventional point of sale (POS) is depicted in accordance with an illustrative embodiment. The system 10 includes a Magnetic Stripe Transmitter (MST)100 adapted to couple with a mobile communication device 200. MST100 and mobile communication device 200 may communicate through respective audio jacks 102 and 202 and/or through respective communication interfaces, e.g., USB ports 104 and 204, respectively, or through other communication interfaces including, but not limited to, a 30-pin or 9-pin Apple interface, a bluetooth interface, and other serial interfaces. MST100 also interacts with merchant POS 300 through a Magnetic Stripe Reader (MSR)302 adapted to transmit magnetic stripe data from magnetic field transmitter 150, which includes a drive and an inductor, to merchant POS 300.

The mobile communication device 200 includes a mobile wallet application 220 and a POS application or payment settlement application 230. The mobile wallet application 220 initializes and unlocks the MST 100. POS or settlement application 230 interacts with MST100 and accepts card payment data from MST 100. The card payment data may include dynamic cryptogram to protect the data. The POS or settlement application 230 may cause the card payment data to be transmitted to the wallet server 260 via the network 170. The card payment data may then be communicated from the wallet server 260 to the transaction processor 270.

MST100 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 interface 102 (e.g., a 3.5mm or other standard audio port), a USB port/jack interface 104 or other communication interface including, but not limited to, a 30-pin or 9-pin Apple interface, a bluetooth interface, and other serial interfaces, and a magnetic field transmitter 150 including a driver and an inductor for transmitting magnetic pulses to be received by any POS device having an MSR.

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

The mobile communication device 200 includes a mobile wallet application 220, a POS or payment settlement application, an audio jack port 202, and/or a communication interface, such as a USB port 204 or other communication interface, including, but not limited to, a 30-pin or 9-pin Apple interface, a bluetooth interface, and other serial interfaces. The mobile communication device 200 may also include a display or touch panel display 240 having a keypad and a Central Processing Unit (CPU) 250.

Each MST100 initially opens to pair with a wallet account. Once MST100 is paired, MST100 may be locked and needs to be unlocked to change the mode and parameters for MST 100. MST100 may store cardholder data by initially loading at the time of manufacture, loading via a wireless communication network after setting up a wallet account, and/or loading his/her own card data directly into MST100 by the consumer using a mobile wallet application. Typically, wallet users are the following: it has set up a digital wallet account on a remote server, e.g., via a cloud computing infrastructure, and has initialized a mobile wallet application on his/her mobile communication device.

The mobile wallet application 220 on the mobile communication device 200 interacts with the MST100 to provide different modes of operation, including, for example: an initialization and reset mode, a load card delete card mode, a transfer and use mode, a disconnect transfer mode, a POS card read mode, and optionally other modes.

A method of operation in initialization and reset modes according to an exemplary embodiment is described with reference to fig. 2. The MST is initialized for the wallet account for the first time by inserting or connecting a "new" MST, or a MST that has not been previously used or is "reset" and has no associated wallet and card data in storage, to the mobile communication device, as shown at block 400. When the MST is connected to the mobile communication device, the wallet application identifies or determines the status of the MST as paired and unpaired, as shown at block 402.

When the MST dongle has been paired to another wallet account, the wallet application will recognize the MST as unpaired but paired with another wallet account, as shown at block 404, and display "dongle may not be used, paired with another account", as shown at block 406. The wallet application may also report the unauthorized pairing to the server, as shown at block 408, for fraud management to prevent the wallet user from improperly using the MST.

When the MST dongle has been paired to the appropriate wallet account, the wallet application identifies the MST as paired, as shown at block 410. The MST may be used or reset as indicated by block 412. If the appropriate wallet account user desires to reset the MST and completely eliminate all data in the SE, the user may access the settings portion of the wallet application and select "reset dongle," as shown at block 414. If the appropriate wallet account user does not desire to reset the MST, the MST may be used and the process is complete, as shown at block 416. In one aspect, any user may be allowed to reset the MST dongle from the user's respective authenticated wallet application. Once the unit is reset, it will need to be initialized and paired again with the wallet account, even if the same user resets the device, it will look like a clean device with a new card to be loaded.

When the MST dongle has not been paired and there is no wallet account paired to the MST, the wallet application may identify the MST as unpaired when the MST is connected to a mobile communication device, e.g., a smartphone having a wallet application thereon, as shown at block 418. The wallet application may then face a determination as to whether the MST should be paired to a wallet account, as shown at block 420. If the appropriate wallet account user does not wish to pair the MST, processing is complete, as shown at block 416.

Alternatively, if the appropriate wallet account user desires to pair MSTs, the pairing process is started. The pairing process may include capturing the serial number of the MST, as shown at block 422; authenticating the wallet user again, as shown at block 424; and associating the MST to the wallet account, as shown at block 426. The pairing process may also include storing pairing information, e.g., the serial number of the MST, in the wallet account, as shown at block 428, for future authentication for matching with the wallet application to turn on the MST each time the MST dongle is used. In this regard, MSTs may only be unlocked and used with the appropriate wallet account in the future.

A method of operation in a load card delete card mode according to an exemplary embodiment is described with reference to fig. 3. The MST is connected to the mobile communication device, as shown in block 430, and the MST is identified as paired, as shown in block 432. Once the MST has been "paired" with the wallet account, the wallet user may use the wallet application to load his/her card by swiping the card over the MST's built-in Magnetic Stripe Reader (MSR), as shown at block 434. The generated data may be digitized and encrypted, as shown at block 436, and stored in the MST's storage or SE for later use, as shown at block 438. It should be appreciated that MST data may alternatively be transformed into a secure form. In one embodiment, in addition to or as an alternative to encryption, MST data may be protected by generating and containing dynamic cryptograms that may be used to protect payment transactions.

The encrypted or protected data may also be transmitted to the mobile communication device, as shown in block 440. The mobile wallet application may transmit the data to the wallet server, as shown at block 442. The data may be decrypted at the wallet server and the Primary Account Number (PAN) data, card number, expiration date, and cardholder name stripped (strip) from the track data, as shown at block 444.

The mobile wallet application or wallet server may also make a determination as to whether the magnetic card is a payment card or a non-payment card, as shown at block 445. If the magnetic card is a non-payment card, the system may automatically store the track data in memory for non-payment transmission and allow the user to name the card and store the non-payment card on a memory device, e.g., MST, as shown at block 447.

If the magnetic card is a payment card, e.g., having a particular format recognizable to the system, the card may be detected as a payment card and the system determines if the name on the payment card matches the name of the wallet account, as shown at block 449. If the names do not match, an error message may display "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 may determine if the PAN number matches an existing card already stored on the server to create a new account or retain an existing account. If a new card is created, the system may store encrypted track data as described below in the payment portion of the MST's secure memory.

A determination may also be made as to whether the data matches any previously stored cards stored in the wallet account, as shown at block 446. When no match is found, then a new card is created in the account of the wallet user on the server. As indicated at block 448. When a new card is created, the system may also store the track data in the payment portion of the MST's secure memory, such as shown at block 438, encrypted or in another secure form or state (e.g., using ciphertext). When a match is found, the card is identified as existing and loaded into the card, as shown at block 450.

In one aspect, the MST has the ability to load any type of magnetic stripe card, not just a payment card, into the memory device. For convenience, the non-payment cards may be stored separately with less security. For example, some non-payment applications may include cards for opening doors, coupon cards, and the like. The loading of payment data relative to non-payment data may be separated into two separate fields or memory areas. In an example, the payment card may not be loaded into the non-payment storage device. For example, the payment data may have the following specific format: which may be detected and may not be allowed to be loaded into the non-payment memory area. The payment card may also request authentication with an application before being transmitted. On the other hand, default non-payment data may be transmitted without authentication.

In one aspect, the additional process of loading the MST will dynamically and securely send (e.g., using the ciphertext) the magnetic stripe data from the server to the MST through the mobile device and the application. The method enables magnetic stripe data to be transmitted from the server to the MST after authentication of the wallet user is performed so that the dynamic magnetic stripe data can be transmitted to the mobile device and stored and/or transmitted. In one aspect, the track data generated by the server may be dynamically loaded for payment purposes, such that one-time-use payment credentials may be dynamically generated for a wallet user at the time of payment.

The one-time-use payment credential may be dynamically generated for the wallet user at the time of payment using dynamic cryptogram. For example, dynamic cryptogram such as dynamic cvv (dcvv) may be generated at the time of payment. When payment is made using a card in both Card Not Present (CNP) and Card Present (CP) transactions, the cryptogram may be generated using a key, a Primary Account Number (PAN), an expiration date or expiration date (EXP), a timestamp, and/or a counter. The resulting ciphertext generated at payment may be based on some method: the method depends on the level of security required or desired. The ciphertext may be generated locally at the mobile device, or it may be generated from a secure server and delivered via the server for use with the mobile application. The MST can transmit different track data payloads each having a different cryptogram in an appropriate magnetic card format recognizable by the point-of-sale terminal. The PAN (whether static or dynamic/token) along with the expiration date (which may be used as a token mode indication to the issuer's TSP) and the one-time-use cryptogram (which may be used for the CVV2 field) may also be used for remote purchases via existing websites or intra-app settlement that require this field.

In another aspect, hotel or casino room keys may be transmitted to the user's wallet application or digital wallet application and then to the MST so that the user will not have to physically queue to check-in (check in) or wait. The wallet user may "check in" to a hotel via an application on the user's mobile device (optionally, the mobile device location may be matched with the address of the subscription to ensure further security), and then the subscription server sends a "key" to the wallet server, which is then transferred to the wallet application or digital wallet and loaded into the memory device of the MST for non-payment purposes. The user may press a transmit button on the MST and transmit magnetic stripe data stored in the MST for non-payment purposes without authenticating the wallet application. The "key" from the hotel or magnetic stripe data can expire on the server side after a period of time, so this method is relatively secure, which can equate to forgetting to return your magnetic stripe hotel key.

In these aspects, the system has the ability to remotely load the MST from the server, allowing a third party, e.g., an issuer, to dynamically send payment card data or non-payment card data to the MST for transmission. It may be necessary to use a properly paired MST in order to load remotely. The system may control whether the magnetic stripe data is stored as payment card data or non-payment card data, so the system may be used in a disconnected mode in different ways. Application of this method may include sending a dynamic payment card token from a server for one-time payment use, and remotely check-in to a hotel room without going to the foreground.

When new "key" or magnetic stripe card data is loaded into the MST and stored in the default non-payment card container of the memory device, then it may be used in a "disconnect mode," which will be described in further detail below. When a payment card is selected by the wallet application, the particular card may be enabled for a period of time, e.g., 5 minutes, and during this period, the non-payment default card will not be able to be transmitted by the MST. To distinguish between payment cards and non-payment cards, a payment card may have a particular format and Bank Identification Number (BIN) that is recognizable when an application detects the payment card. The BIN may be checked against the name of the account and may be stored for the user if the names match.

In some aspects, the track data is not stored on the server, only the PAN data is stored. The plurality of cards may be loaded into a memory device or SE for later selection or use, and the plurality of cards may be separated into payment cards and non-payment cards. In one aspect, the payment card may be transmitted only after authenticating the wallet application, and there may be a time limit after selecting the card to be transmitted in the disconnected mode, while the non-payment card may be selected as a default card to be transmitted in the disconnected mode without authenticating the wallet application for convenience.

In one aspect, the name on the track data of the card being slipped in the physical payment card should match the name of the wallet account for use in successfully storing the card for both the MST and server sides, otherwise the application may not be able to fully load the processing for the card and display an error message "error: name on card does not match account ". Once the track data is stored in the SE, the user can view the cards stored in the wallet application and select the card at the top of the wallet as the default card for transmission of payments and non-payments. There may also be cards stored in the cloud computing architecture via a cardless approach that are not stored on the MST for cardless payment. However, each card stored to the MST should have an equivalent copy of PAN data only in the cloud computing infrastructure, and these cards can be deleted separately from the cloud computing infrastructure via the application or Web/internet. Resetting the MST does not erase card data in the cloud computing infrastructure. The copied cards with the same PAN data will not be shown as different cards, in other words, if the user has remotely entered the card number into his/her wallet account in the cloud computing infrastructure, and later he/she clears the same card to load into the MST for actual use, the cards in the cloud computing infrastructure will remain and need not be copied if the PAN data is the same.

Once cards are loaded into the MST, they may be selected by the wallet application. The selected card may also be deleted from the memory of the MST and from the application.

In yet other aspects, the wallet account may enable encrypted track data to be loaded from the wallet server directly to the secure memory device or SE of the MST, such that the issuer may choose to create a card account for the wallet user, and then load the SE to the mobile communication device and to the MST as a card on top of the wallet with the track data communicated from the wallet server via the wallet application. This is the type of remote loading of track data to the wallet user's MST for actual accepted use. For example, the issuer may be a payment card provider, such as a credit card provider or a bank, or a non-payment card provider, such as issuing hotel cards, gate entry, loyalty cards. The payment card may be a standard payment card or it may be a one-time-use payment card, such as a card number referring to a token of the actual payment card account on the issuer's server. This may provide security even if the token is damaged or copied, since the number may only be used once.

Once the magnetic card track data is loaded into the MST, the wallet application may also be configured to capture images of the front and/or back of the card using the camera of the mobile device and allow the user to select the card to be used for transmission in his/her MST. The wallet application may also be used to delete a card selected in the application and erase the card from storage. The wallet application may also be used to capture the wallet user's identification card to show the merchant a form of identification by touching a button in the wallet application.

A method of operation in a transmit and use mode according to an example embodiment is described with reference to fig. 4. A transaction with a POS begins at block 452. For POS face-to-face transactions, the encrypted track data stored in the memory device or SE may be decrypted by the MST, as shown in block 454, and then transferred to the POS, as shown in block 456. The POS may also transmit data to the transaction processor, as shown at block 458.

In other embodiments, the track data stored in the memory device or SE may be securely transferred to the POS through the MST. For example, the MST may generate the dynamic cryptogram at the time of payment and transmit the dynamic cryptogram to the POS in the form of an appropriate magnetic card recognizable by the POS. The resulting cryptogram generated at payment may be based on a number of methods, depending on the level of security required or desired. The cryptogram may be generated locally at the mobile device, or may be generated from a secure server and delivered to the mobile application for use via the server. The MST can transmit different track data payloads with different ciphertexts each in the form of an appropriate magnetic card recognizable by the point-of-sale terminal. The PNAs (whether static or dynamic/token) along with the expiration date (which may be used as a token mode indicator for the issuer's TSP) and the one-time-use cryptogram (which may be used in the CVV2 field) may also be used for remote purchases via existing websites or intra-app settlements that require this field.

For remote transactions, the encrypted magnetic stripe data may be transmitted to a settlement application of the mobile communication device, as shown at block 460. The settlement application may then transmit the data to the payment server, as shown at block 462. This data may be decrypted at settlement time only by the corresponding payment server, as shown at block 464, and otherwise useless to mobile applications or anyone intercepting such data during transmission via a wireless or wired internet network or other communication network. The payment server may also transmit the decrypted data to the transaction processor, as shown at block 464.

Similarly, for remote transactions, dynamic cryptograms may be generated using track data and transmitted to a settlement application of the mobile communication device. The settlement application may then transmit the data to the payment server. This data can only be interpreted by the corresponding payment server when settling.

A method of operation in a disconnected transfer mode according to an example embodiment is described with reference to fig. 5. The wallet user logs into his/her application through the MST connected via, for example, an audio jack or other communication interface, as shown at block 468. Assuming one or more cards are securely loaded into the SE/secure memory, if more than one card is loaded, the user may change the default/top card to be used for the wallet that is transferred to the POS when the MST unit is turned on. In one aspect, a particular card may first be "selected". The "selected card" on the MST may then be transferred to the POS by pressing a "transfer" button in the wallet application with the MST dongle inserted, or by pressing a transfer button on the MST itself, for a specified period of time before the MST will no longer allow transmission of the payment card (which may include transmission of the cryptogram), as shown in block 470. When the transmission attempt is complete, the LED indicator may flash a light, e.g., a green light, for approximately 500ms or other amount of time desired, as shown in block 472. For non-payment cards stored in the MST, whenever the payment card does not override (override) the default card position, the default non-payment card may be used to be transferred by simply pressing a button on the MST and an LED indicator indicates that a transmission is occurring.

If the MST is authenticated by the wallet application enabled in the default transfer mode and the MST is unplugged from the mobile communication device, as shown in block 474, the dongle will stay ON and remain unlocked for approximately 4 minutes or longer, as shown in block 476. This allows the MST dongle to be transmitted and used by the merchant or user to complete the transmission of the card data (which may include cryptogram) by pressing a button on the MST during this time when the MST is close to the POS, as shown in block 478, after which the dongle may shut down and need to be turned on again or unlocked by the wallet application. This feature is useful for many restaurants where the card must be brought back to a POS system remote from the table. This feature allows the waiter to simply take the MST dongle only and walk to the POS during the 4 minutes of the MST dongle being turned on, without having to take the consumer's mobile communications device with the MST dongle.

In one aspect, the magnetic stripe data may be stored in the memory device at the time of manufacture, remotely loaded by the server, loaded by the consumer as needed by using a special program to convert his/her magnetic stripe track data into contactless track data via a wallet application, or stored directly as if it were stored in the memory device or SE of the MST for future use.

A method of operation in a POS card read mode according to an example embodiment is described with reference to fig. 6. This mode allows the MST's Magnetic Stripe Reader (MSR) to not only load the card, but also function as a POS by reading and encrypting the magnetic stripe card for use with the POS application on the mobile device to receive payment as with any merchant POS application. The user may slide the magnetic card over the MSR of the MST, as shown in block 480. The MST reads and encrypts the data on the card as shown in block 482. The data may be transmitted to the POS application on the mobile communication device, as shown at block 484, and then the data may be transmitted to the payment server, as shown at block 486. The payment server may also transmit data to the transaction processor for payment processing, as shown at block 488.

The devices, systems, and methods disclosed herein provide magnetic card track data to be captured by a user and stored in a secure memory device of an MST without modification, and later used with a POS or other MSR device, unlike contactless or NFC track data that has a special field that must be encoded by an issuer in order to work with a contactless POS. The MST includes a button that allows transmission of magnetic card data to the POS when the MST is disconnected or detached from the mobile device, and an LED indicator activates when the MST transmits properly. The unique pairing of the MST to a particular wallet account allows the MST to be used only with that account to provide better security for track data storage and transfer usage, and the ability to reset the MST allows unpairing and reuse of the MST. MSTs can connect to mobile communication devices via different interfaces beyond audio jacks and USB connections.

The apparatus, system and method allow for the loading of encrypted magnetic stripe track data into the memory device of the MST, which may later be decrypted and transmitted to the POS, or may be transmitted encrypted to the mobile communication device and then routed to the payment server for decryption and for loading of wallet accounts onto the server to process or process POS transactions. The apparatus, system, and method provide the following capabilities: stored track data or slipped track data for a virtual settlement environment is used for greater security and to reduce merchant cost transactions.

Devices, systems, and methods provide for remote loading and transmission of track data from an issuer to a wallet server provider, to a wallet application on a mobile communication device, and to a SE or storage of a MST for later use. The apparatus, system, and method also provide the following capabilities: the loading of the offer account information along with the payment card data into any field of the track data read by the issuer during or after the transaction may result in a combination of a discount and offer plan with the payment transaction.

As described above, magnetic stripe card data stored on, for example, the secure element 108 of the MST100, may be transferred to a settlement application of the mobile communication device and used in a mobile settlement system. In one aspect, a mobile settlement system and method is disclosed that facilitates reducing a rate of discarding shopping carts and increasing a rate of conversion to sales. However, it should be appreciated that the mobile settlement systems and methods disclosed herein may be implemented with or without the MST 100.

An overview of a system 20 for mobile settlement processing according to an exemplary embodiment is described with reference to fig. 7. The system 20 includes a mobile communication device 500, which may be similar or identical to the mobile communication device 200 described above, and a settlement server 600. As shown, the mobile communication device 500 and the settlement server 600 may communicate with each other via the network(s) 170.

The settlement server 600 hosts one or more web service Application Program Interfaces (APIs) 602 (also referred to as settlement APIs) and a database 604. Database 604 may store user and payment data. The settlement server 600 may optionally further include a settlement web page for online settlement in a browser.

The mobile communication device 500 can include a mobile settlement application 502, one or more shopping applications 504, and one or more browser applications 506. The mobile settlement application 502 may be activated or launched from an online shopping web page or from a mobile shopping application and designed to perform payment transactions. The mobile settlement application 502 stores payment and personal data on hardware and/or peripherals in the mobile communication device 500, such as the MST100 or wallet application described above; and/or in remote settlement server 600 or the cloud. The data may also be stored using dynamic cryptograms to secure payment and/or personal data. Mobile settlement application 502 is driven from hardware during the settlement process; peripheral peripherals such as MST 100; the wallet application described above; and/or the cloud retrieves or receives customer data and payment card data to reduce the amount of data entries, such as credit card numbers, expiration dates, and billing addresses, during the settlement process. Other applications may also be installed on the mobile communication server 500, such as a shopping application 504 and a browser application 506 that load a shopping website.

For different mobile platforms-including but not limited to Android^TM、iOS^TMAnd Windwos^TMMobile phones and tablet devices, many versions of the settlement application 502 may exist.

The settlement application 502 allows the customer to complete a transaction originating from the same mobile communication device 500 or from another computing device, such as a desktop or other computing device. The settlement application 502 can also be switched or redirected to another mobile application or can be readily switched or redirected from another mobile, such as the shopping application 540; switched to or from a web page on the browser application 506 running on the mobile communication display section 500; initiated by a push notification sent by the settlement server 600; and/or a Quick Response (QR) code representation initiated by the user and used to scan the transaction. Each of these modes of operation will be described further below.

The settlement application 502 may store payment and personal data in the mobile phone hardware or peripheral. The settlement application may also store information in the cloud or remote settlement server 600. The settlement application 502 retrieves customer data and payment card data, such as card number, expiration date, and billing address, from hardware, peripherals, or the cloud during the settlement process to reduce the amount of data entries.

A settlement 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 settlement application 502 may access hardware components including, but not limited to, a SIM card 508, a Secure Element (SE)510, and a memory storage 512 that may store data. The settlement application 502 may also access hardware components including, but not limited to, a camera 514, an accelerometer 516, a gyroscope 518, a GPS receiver 520, an electronic compass 522, and a biosensor 524, where the captured parameters may be used for additional security measures.

Settlement application 502 can access peripheral components and accessories via different communication interfaces 526, including but not limited to USB, audio jack, bluetooth, serial port, WiFi, and other interfaces. Peripheral components and accessories may include, but are not limited to, payment card readers 700, such as MST100, magnetic stripe card readers, smart card readers, NFC card readers, and EMV card readers; a PIN pad (pad) 702; a barcode scanner 704; a printer 706; a display unit; check scanners, etc., for input and output of data.

The settlement application 502 may be initiated independently by the user for managing his stored cards and personal information after successful user authentication. When the settlement application 502 is used with a peripheral device, such as MST100, the settlement application 502 can transmit electromagnetic signals of track data to simulate magnetic swipe without physically swiping the card. This allows the settlement application 502 to be used in physical retail stores for virtual card magnetic stripe transactions.

In one aspect, when the settlement application 502 is directed to or launched from another mobile application or from a web page in a browser after a payment transaction, the customer may be redirected back to invoking the shopping browser web page or invoking the mobile shopping application as indicated by a Uniform Resource Locator (URL). In this redirection mechanism, the settlement application 502 may employ an operating system to register a custom URL scheme. After registration, the operating system may use a scheme portion in the URL, such as "capp://" to associate the URL with the settlement application 502.

The operating system may then handle the custom URL scheme/protocol by launching the settlement application 502. For example, in the iOS and Android systems, the custom URL may take the form of custom mCheme:// mydomain. In Android, registration is performed by adding an intention filter in an Android manifest. In iOS, registration is performed by adding the "cfbundledurypes" setting to the plist. With the above registration performed, the settlement application 502 can then be opened/launched/switched when other applications or websites call this URL. In addition, the parameters may be passed to the settlement application 502 through the myparameter portion of the custom URL. Through the use of a custom URL scheme redirection mechanism, different shopping applications may be redirected to the settlement application 502 to perform payment operations. Depending on the different scenarios, the transaction results may be sent/redirected back to the calling application or caller through various methods.

When the settlement application 502 is initiated by a push notification message or QR code scan after a payment transaction, the initial shopping page on the computer or communication device updates the transaction results.

Because the settlement application 502 is a native application on the mobile communication device 500, the settlement application 502 can access hardware or peripheral components that would otherwise be inaccessible from the mobile browser. Further, because the settlement application 502 is a centralized application to launch/switch from, or be redirected to or from, other shopping websites or applications, each merchant no longer needs to inherit the hardware drivers to their applications. Instead, a simple redirection from their application or website in the form of a URL redirection is sufficient (suffice).

To use the settlement system, the user registers and sets an account by setting a user name and a password. During the account setting process, personal information of the user, for example, a last name, a first name, a billing address, and a mailing address, is captured and stored in the settlement server 600. For example, the user account information is stored within the database 604. An optional identification verification step may be used to verify the validity of the user's identification. Optionally, information related to the mobile communication device 500 may also be stored and bound to, or associated with, the user's account.

The settlement server 600 hosts and exposes one or more of the web services as an Application Program Interface (API)602, referred to as a settlement API, for online/mobile merchants to develop their shopping application(s). As described above, the database 604 is used to store personal information and payment information of registered users. The settlement server 604 also hosts a settlement web page for the user to complete the transaction inside the browser when the user performs online shopping.

In one aspect, the shopping application creates a settlement token that is used to uniquely identify the payment transaction by calling an API method hosted by settlement server 600. Information about the transaction, including product information, price and volume, and flow control information, such as a redirect URL, are provided as input parameters. The URL may be used to set a redirect or switch back to the calling application or web page. All redirection and flow control can be performed with this settlement token, which is used to track payment transactions. The merchant application or website may query the status of the payment transaction by calling API methods hosted by the settlement server 600.

In one aspect, FIG. 9 illustrates an exemplary operational flow for online ticketing using an online shopping website and a mobile shopping application. In this example, the user or customer 900 browses using a shopping application 504 on the user's mobile communication device 500. The customer 900 launches a shopping application 504, such as a theater ticketing application. The customer 900 uses the shopping application 504 to browse and add items to the shopping cart for settlement and purchase. In this example, shopping application 504 manages shopping carts and communicates 902 with merchant service 904 to obtain updated information for items, such as theater show names, show times, and prices. In the checkout step, the customer 900 selects 908 a checkout button to purchase the product. Application 504 invokes 910 settlement server 600 via merchant server 904 and passes information about the product, transaction amount, etc. The merchant server receives 912 a settlement token 914 from settlement server 600.

Application 504 receives 916 settlement token 914 and redirects 918 to settlement application 502 using the customer URL and settlement token as parameters. In the settlement application 502, the customer 900 authenticates 920 himself/herself using the settlement server 600. Once authenticated, the customer 900 confirms the transaction with the settlement server 600 and the settlement application 502 calls 922 the settlement server 600 or the website API602 to complete the transaction identified by the settlement token. Settlement server 600 forwards 924 the transaction to payment processor 926, which may include generating and forwarding transaction/payment data including the dynamic cryptogram to payment processor 926. The payment processor 926 returns 928 the transaction results to the settlement application 502 via the settlement server 600, as shown at 930. When the transaction/payment data includes ciphertext, payment processor 926 may interpret the ciphertext to complete the transaction.

The cryptogram may be generated at the time of the transaction using a settlement token, a primary account number, an expiration date or expiration date (EXP), a timestamp, and/or a counter. The resulting cryptogram generated at the time of the transaction may be based on a variety of methods, depending on the level of security required or desired, and may be in an appropriate format recognizable by the payment processor 926. The ciphertext may be generated locally at the mobile device, or may be generated from a secure server and delivered to the mobile application for use via the server. The MST can transmit different track data payloads each having a different cryptogram in an appropriate magnetic card format recognizable by the point-of-sale terminal. The PAN (whether static or dynamic/token) along with the expiration date (which may be used as a token mode indicator to the issuer's TSP) and the one-time-use cryptogram (which may be used for the CVV2 field) may also be used for remote purchases via existing websites or intra-app settlement that require this field.

After the transaction is completed, the settlement application 502 redirects 932 back to the originating shopping application, which displays a results page 934, using the settlement token and the transaction results as parameters. The application obtains or receives transaction results through one or more possible paths, including: (A) the shopping application receiving a transaction result from the redirect URL parameter; shopping application updates 936 the transaction status with merchant server, where (B) settlement server 600 pushes 938 the results to merchant server or (C) merchant server pulls 940 the most recent transaction status or results from settlement server 602 through API 602.

In an exemplary use case, the sports equipment shopping application developed by Acme Corp may be redirected to the settlement application 502 for payment. Additional exemplary use cases may include: com, may implement its own coupon program in its own program while being redirected to the settlement application 502 for payment; similarly, a pizza ordering application for a Contoso restaurant may build a mobile application for delivering services and use the settlement application 502 for payment. In this way, application developers (such as from different companies) can focus on the product browser and shopping experience and leave the payment portion to the settlement application 502.

In one aspect, FIG. 10 illustrates an exemplary operational flow for online ticketing using an online shopping website and a browser application. In this example, a user or customer 900 browses an online shopping merchant website using a browser application 506 on the user's mobile communication device 500. The customer 900 uses the browser application 506 to launch a merchant's website, such as a theater ticketing website. The customer 900 uses the browser application 506 to browse and add items to the shopping cart for settlement and purchase. In this example, the merchant website communicates 1002 with the merchant server 904 to obtain updated information for the items, such as theater show names, show times, and prices. The merchant server 904 presents a merchant website and manages shopping carts. When the customer 900 decides to purchase a product, the customer selects the product and proceeds to a settlement step 1006. In the checkout step, the customer 900 selects 1008 a checkout button to purchase the product. The merchant web site invokes 1010 the settlement server 600 directly or using the merchant server 904 and passes information about the product, transaction amount, etc. The merchant server receives 1012 settlement token 1014 from settlement server 600.

The application 560 receives 1016 the settlement token 1014 and the merchant website redirects 1018 to the settlement application 502 using the customer URL and the settlement token as parameters. In the settlement application 502, the customer 900 authenticates 1020 himself/herself with the settlement server 600. Once authenticated, the customer 900 confirms the transaction with the settlement server 600 and the settlement application 502 calls 1022 the settlement server 600 or the website API602 to complete the transaction identified by the settlement token. Settlement server 600 forwards 1024 the transaction to payment processor 926, which may include generating and forwarding transaction/payment data including the dynamic cryptogram to payment processor 926. Payment processor 926 returns 1028 the transaction results to settlement application 502 via settlement server 600, as shown at 1030. When the transaction/payment data includes ciphertext, payment processor 926 may interpret the ciphertext to complete the transaction.

After the transaction is completed, the settlement application 502 redirects 1032 back to the browser application 506, which displays a results page 1034, with the settlement token and the transaction results as parameters. The merchant website obtains or receives transaction results through one or more possible paths, including: (A) the merchant website receives a transaction result from the redirection URL parameter; the merchant website updates 1036 the transaction status with the merchant server, where (B) the settlement server 600 pushes 1038 the results to the merchant server or (C) the merchant server pulls 1040 the most recent transaction status or results from the settlement server 602 through the API 602.

In one aspect, FIG. 11 illustrates an exemplary operational flow for launching a checkout application from a shopping webpage running in a desktop browser on a computer via push notification or Short Message Service (SMS). In this example, a user or customer 900 is browsing an online shopping merchant website using a desktop browser 1102 on a computing device 1100, such as a computer. The customer 900 uses the browser 1102 to launch a merchant website, such as a theater ticketing website. The customer 900 uses a browser to browse and add items to the shopping cart for settlement and purchase. In this example, the merchant website communicates 1104 with the merchant server 904 to obtain updated information for the goods, such as theater show name, show time, and price. In this example, the merchant website communicates 1104 with the merchant server 904 to obtain updated information for the goods, such as theater show name, show time, and price. The merchant server 904 presents a merchant website and manages shopping carts. When the customer 900 decides to purchase a product, the customer selects the product and proceeds to a settlement step 1106. In the checkout step, the customer 900 selects 1008 a checkout button to purchase the product. The merchant web site invokes 1110 the settlement server 600, either directly or using the merchant server 904, and passes information about the product, transaction amount, URL, etc. The merchant server receives 1112 a settlement token 1114 from settlement server 600.

The user may be prompted to provide credentials to authenticate the user on the web browser. The merchant web site invokes the settlement server 600 to authenticate the user. After user authentication, the settlement server may look up the phone number or device identifier of the user's mobile communication device 500 and send 1116 a push notification or SMS to the user's registered mobile communication device 500 with the settlement token. When the notification is received, the settlement application 502 is started. In the settlement application 502, the customer 900 authenticates himself/herself with the settlement server 600. Once authenticated, the customer 900 confirms the transaction with the settlement server 600 and the settlement application 502 calls 1122 the settlement server 600 or the website API602 to complete the transaction identified by the settlement token. Settlement server 600 forwards 1124 the transaction to payment processor 926, which may include generating and forwarding transaction/payment data including the dynamic cryptogram to payment processor 926. The payment processor 926 returns 1128 the transaction results to the settlement application 502 via the settlement server 600, as shown at 1130. When the transaction/payment data includes ciphertext, payment processor 926 may interpret the ciphertext to complete the transaction.

The merchant website updates 1136 the transaction status, for example by polling, and the desktop browser displays the results page 1134. The merchant web site obtains or receives the transaction results through two possible paths: (A) the settlement server 600 pushes 1138 the results to the merchant server or (B) the merchant server pulls 1140 the most recent transaction status or results from the settlement server 600 through the API 602.

In one aspect, FIG. 11 also shows launching a settlement application from a shopping webpage running in a desktop browser in a computer by QR code scanning. In this example, a user or customer 900 browses an online shopping merchant website using a desktop browser 1102 on a computing device 1100, such as a computer. The customer 900 uses the browser 1102 to launch a merchant website, such as a theater ticketing website. The customer 900 uses a browser to browse and add items to the shopping cart for settlement and purchase. In this example, the merchant website communicates 1104 with the merchant server 904 to obtain updated information for the goods, such as theater show name, show time, and price. The merchant server 904 presents a merchant website and manages shopping carts. When the customer 900 decides to purchase a product, the customer selects the product and proceeds to a settlement step 1106. In the checkout step, the customer 900 selects 1108 the checkout button to purchase the product. The merchant web site invokes 1110 the settlement server 600, either directly or using the merchant server 904, and passes information about the product, transaction amount, URL, etc. The merchant server receives 1112 a settlement token 1114 from settlement server 600.

In this example, the merchant website or merchant server calls 1118 the settlement server 600 through the API602 or obtains a QR code 1142 representation of the settlement token. The user launches the settlement application 502 on the mobile communication device 500 and scans 1144 the QR code 1142. Once the settlement application 502 is launched, processing continues as described above with reference to FIG. 11.

Although the above-described methods and algorithms including these have been described individually with reference to the foregoing flowcharts and figures, it should be understood that any two or more of the methods disclosed herein may be combined in any combination. Any of the methods, algorithms, implementations, or processes described herein may include machine-readable instructions for execution by: (A) a processor, (B) a controller, and/or (C) any other suitable processing device. Any of the algorithms, software, or methods disclosed herein may be combined into software stored on a non-transitory tangible medium such as, for example, a flash memory, a CD-ROM, a floppy disk, a hard drive, a digital versatile disk DVD, or other storage device, but persons of ordinary skill in the art should readily appreciate that the entire algorithm and/or parts thereof could alternatively be executed by a device other than a controller and/or embodied in firmware or dedicated hardware in a well-known manner, e.g., it may be implemented by an Application Specific Integrated Circuit (ASIC), a Programmable Logic Device (PLD), a Field Programmable Logic Device (FPLD), discrete logic, etc. Moreover, although specific methods and algorithms are described with reference to flowcharts depicted herein, persons of ordinary skill in the art will readily appreciate that other methods of implementing the example machine readable instructions may alternatively be used. For example, the order of execution of the steps may be changed and/or some of the steps described may be changed, eliminated, or combined.

It should be noted that the methods shown and discussed herein may have various modules that perform particular functions and interact with each other. It should be understood that these modules are separated based on their functionality for description only, and represent computer hardware and/or executable software code stored on a computer readable medium for execution on suitable computing hardware. The various functions of the different modules and units may be combined or separated in any way as described above as hardware and/or software stored on a non-transitory computer readable medium as modules, and may be used separately or in combination.

The mobile communication devices may be of the type of laptop computers, cellular telephones, Personal Digital Assistants (PDAs), tablet computers, and other mobile devices. Communication between components and/or devices in the systems and methods disclosed herein may be unidirectional electronic communication or bidirectional electronic communication over a wired or wireless configuration or network. For example, one component or device may be networked directly or indirectly, wired or wirelessly, through a third party intermediary, via the internet, or otherwise employing additional components or devices to enable communication between the components or devices. Examples of wireless communications include, but are not limited to, wireless devices (RF), infrared, bluetooth, Wireless Local Area Networks (WLAN), such as WiFi, or wireless network radios, such as radios capable of communicating with a wireless communication network, wireless communication networks such as Long Term Evolution (LTE) networks, WiMAX networks, 3G networks, 4G networks, and types of other communication networks.

While the apparatus, systems, and methods have been described and illustrated in connection with specific 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. Therefore, the disclosure is not limited to the precise details of methodology or construction set forth above, and thus variations and modifications are intended to be included within the scope of the disclosure.

Claims (18)

1. A settlement system implemented on a mobile communication device, the settlement system comprising a merchant application or browser application available on the mobile communication device and adapted to allow a user to select an item from a merchant for purchase, the settlement system comprising:

a communication processor in communication with a settlement server hosting one or more web service settlement Application Program Interfaces (APIs) adapted to communicate with the mobile communication device; and

a settlement application installed on the mobile communication device and adapted to:

initiated in response to receiving information corresponding to a purchase transaction;

receiving user payment information including magnetic stripe data from a Magnetic Stripe Transmitter (MST) embedded in or in communication with the mobile communication device, wherein a cryptogram is generated at a time of a purchase transaction and included in the magnetic stripe data to protect the magnetic stripe data; and

using magnetic stripe data from the magnetic stripe transmitter to communicate with the settlement server and cause the settlement server to complete the purchase transaction.

2. The checkout system of claim 1, wherein the checkout server creates a checkout token identifying the purchase transaction in response to a user initiating the purchase transaction.

3. The settlement system of claim 2 wherein the settlement server sends the settlement token to a merchant application or a browser application.

4. The settlement system of claim 3 wherein the settlement application receives the settlement token from a merchant application or a browser application.

5. The settlement system of claim 4 wherein the settlement application authenticates the user.

6. The settlement system of claim 5 wherein the settlement application confirms the purchase transaction with the settlement server in response to user authentication.

7. The settlement system of claim 6, wherein the settlement application sends the settlement token and the results of the purchase transaction to a merchant application or a browser application during a restart of the merchant application or the browser application.

8. The checkout system of claim 7, wherein the merchant application or the browser application displays a results page corresponding to the purchase transaction in response to being restarted.

9. The settlement system of claim 1, wherein the settlement server completes the purchase transaction by communicating to a payment processor a transaction that includes the magnetic stripe data, the magnetic stripe data including cryptogram.

10. The settlement system of claim 1, wherein the settlement application is adapted to be launched in response to receiving information corresponding to the purchase transaction from a merchant application or a browser application.

11. The settlement system of claim 1, wherein the settlement application is adapted to be launched in response to receiving information corresponding to the purchase transaction from the settlement server.

12. The settlement system of claim 1, wherein the settlement application is adapted to be launched in response to receiving information corresponding to the purchase transaction from the settlement server through a push notification, an email, or a short message service.

13. The settlement system of claim 1, wherein the settlement application is adapted to be launched in response to receiving information corresponding to the purchase transaction from a Quick Response (QR) code scanned through the mobile communication device.

14. A method, comprising:

allowing a user to browse from a merchant through a first application or browser and select an item for purchase;

initiating a settlement application installed on a mobile communication device in response to the settlement application receiving information corresponding to a purchase transaction;

receiving, by the settlement application, a settlement token created by a settlement server identifying the purchase transaction;

receiving, by the settlement application, user payment information including magnetic stripe data from a Magnetic Stripe Transmitter (MST) embedded in or in communication with the mobile communication device, wherein a cryptogram is generated at a time of the purchase transaction and included in the magnetic stripe data to protect the magnetic stripe data; and

communicating, by the settlement application, with the settlement server using the protected magnetic stripe data from the magnetic stripe transmitter to cause the settlement server to complete the purchase transaction; and

restarting the first application or browser in response to completion of the transaction.

15. The method of claim 14, wherein the receiving of the settlement token comprises receiving the settlement token from a first application or a browser application.

16. The method of claim 14, further comprising: authenticating a user by the settlement application prior to communicating with the settlement server.

17. The method of claim 14, wherein the launching of the settlement application comprises launching the settlement application in response to receiving information corresponding to the purchase transaction from the settlement server through a push notification, email, or short message service.

18. The method of claim 14, wherein the launching of the settlement application comprises launching the settlement application in response to receiving information corresponding to the purchase transaction from a user scanning a Quick Response (QR) code.