FINANCIAL TRANSFERS FROM MOBILE DEVICES

Abstract

Computer-implemented systems, methods, and computer-readable media for financial transfers from a mobile device, comprising: receiving a mobile device identifier, a unique user identifier, a merchant identifier, and an amount from a mobile device; determining whether the transaction is authorized based on the mobile device identifier and the unique user identifier; transmitting an authorization failure message to at least one of the mobile device and a merchant device associated with the merchant identifier if it is determined that the transaction is not authorized; and transmitting to a payment gateway an account identifier associated with the unique user identifier and mobile device identifier, the merchant identifier, and the amount if it is determined that the transaction is authorized.

Description

RELATED APPLICATION DATA

This application claims priority to Indian Patent Application No. 4607/CHE/2011, filed Dec. 27, 2011, and Indian Patent Application No. 4608/CHE/2011, filed Dec. 27, 2011, both of which are hereby incorporated by reference in its entirety.

BACKGROUND

Credit cards allow users to carry less liquid currency. However, despite the security mechanisms implemented in relation to credit card transactions, credit card users continue to place themselves at risk. If a credit card is stolen, the thief can very quickly charge up to the credit limit before the card owner even realizes that the credit card is missing. Additionally, because most credit card authorizations only require information that is plainly visible on the card (e.g., the account number, owner name, expiration date, and Card Security Code (“CSC”)), a duplicitous cashier or call center worker may copy down the credit card authorization information to make unauthorized transactions without even stealing the physical card. More recently, some cards have incorporated Radio Frequency Identification (“RFID”) and similar short-range wireless communication systems to allow for more convenient “touchless” credit card transactions. However, such wireless credit cards have reduced security even further by allowing for hands-free theft by homemade scanning devices.

To both increase security and convenience, many companies have been working to develop mobile device (e.g., mobile phone) based payment systems as substitutes for conventional credit cards. While such payment systems alleviate some security concerns presented by credit cards, they also perpetuate others. For example, mobile device based payment systems generally include personal information and account information on the device itself, so if a thief steals the device they may gain access to the device owner's account information. Additionally, known mobile device payment systems usually include a close-range wireless connection between the mobile device and a Point-of-Sale (“POS”) device (e.g., via Near Field Communication (“NFC”)) for the mobile device to transmit payment information. Such transmissions may still enable sophisticated thieves to intercept account information.

Still other systems attempt to increase security by allowing for a user to provide their account information to a merchant then requiring independent authorization by the user via their mobile device before the payment can be authorized. In such a system, the merchant's POS device may submit a request for authorization of a charge, the submission including the user's account information. A back-end payment system may then send a message (e.g., a Short Message Service (“SMS”) message) to the user's mobile device requesting authorization of the charge. The user may then authorize the completion of the transaction by either providing a code to the merchant (e.g., a code received via an SMS message) or may respond to the message and the back-end system may transmit authorization to the merchant. However, in similar fashion to conventional credit cards and mobile device payment systems using NFC, these systems still require sensitive data relating to a user's account to be transmitted between a user and a merchant or between a user's device and a merchant's device.

Improved mobile financial transfer systems are desired.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an exemplary architecture for making financial transfers from a mobile device.

FIG. 2 shows a process flow for a mobile payment system to receive a request for a financial transfer from a mobile device, determine whether the transfer is authorized, and, if the transfer is authorized, provide the appropriate information to a payment gateway.

FIG. 3 shows an exemplary data flow illustrating that the mobile payment system may be deployed within existing payment gateway architectures without modification.

FIG. 4 shows an exemplary architecture for making financial transfers from a mobile device where the mobile device receives data from the point of sale device.

FIG. 5 shows an exemplary computing device useful for performing processes disclosed herein.

While systems and methods are described herein by way of example and embodiments, those skilled in the art recognize that systems and methods for financial transfers from mobile devices are not limited to the embodiments or drawings described. The drawings and description are not intended to be limiting to the particular form disclosed. Rather, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the appended claims. Any headings used herein are for organizational purposes only and are not meant to limit the scope of the description or the claims. As used herein, the word “may” is used in a permissive sense (i.e., meaning having the potential to) rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to.

DETAILED DESCRIPTION

Disclosed embodiments provide systems, computer-implemented methods, and computer-readable media for performing financial transfers with mobile devices, such as smartphones (e.g., phones using the iOS, Android, or BlackBerry OS operating systems) and tablets. In contrast to the many solutions being developed to allow a person to initiate a financial transfer by having their mobile device operatively couple with a POS device as described in the background, embodiments may allow a user to initiate a secure financial transfer using their mobile device without communicating any account information directly to the merchant. Thus, embodiments may transfer absolutely no account information from a mobile device to a POS device that a duplicitous employee could steal.

Additionally, the systems disclosed in the background each include their own infrastructure which may be expensive to deploy. For example, modern credit card systems generally require scanning devices associated with POS devices that communicate with a payment gateway or front-end credit card processing system via a network connection to determine whether a charge is authorized (i.e., whether both the account is valid and whether the amount is authorized). Currently suggested mobile device payment systems require installation of expensive new equipment at POS devices and new back-end infrastructures. In contrast to these expensive-to-deploy systems, embodiments may utilize existing payment gateways. Thus, embodiments may be less expensive to deploy than current mobile device payment systems because they do not require new hardware to be integrated with POS devices or new back-end infrastructures.

FIG. 1 shows an exemplary architecture 100 for making financial transfers from a mobile device. In a typical POS transaction, a payer 115 purchases goods or services from a merchant 130. Rather than paying with cash or a credit card, embodiments may allow payer 115 to utilize an application on their mobile device 105 to pay the merchant. At the POS, the merchant 130 may provide the payer with a unique Merchant Identification Number (“MIDN”). The MIDN may be a unique identifier useful for a payment gateway 125 (discussed further below) to identify the merchant's account. The merchant 130 may also provide payer 115 with a total amount for a purchase of goods or services.

Next, payer 115 may enter the MIDN identifying who will receive the financial transfer, the amount of the financial transfer, and a unique user identifier (“UUI”) into a user interface (“UI”) of the mobile device. Embodiments may also allow the payer 115 to enter additional information, for example a memo line may allow the payer 115 to include a note relating to the transaction for their own record keeping. The UUI may be a Personal Identification Number (“PIN”), an alpha-numeric password, or an answer to a payer-specific question. In some embodiments, the UUI may be any other user input, such as a pattern or drawing traced on a touch-screen display. In some embodiments, the UUI may be a biometric input (e.g., a voice-recognized word or phrase, a detected fingerprint, a detected iris pattern, a detected face, etc.). Biometric input may be detected via conventional mobile device input devices (e.g., microphones, cameras, touch-displays, etc.) or may be input by special purpose devices integrated into or coupled to the mobile device (e.g., finger print readers). Embodiments may be configured to utilize one or more of these or other UUIs according to specific security needs and device capabilities.

The mobile device 105 may then transmit the UUI, MIDN, and amount, as well as a mobile device identifier (“MDI”) to a back-end mobile payment system 120. The MDI may be a hardware specific identifier, such as an International Mobile Equipment Identity (“IMEI”) number. Such an identifier may identify the exact mobile device making the transmission. Alternatively, the mobile device identifier may be a phone number or identifier assigned to the mobile device by a mobile carrier.

While FIG. 1 shows the transmission directly from mobile device 105 to mobile payment system 120, the transmission may pass through one or more intermediaries. For example, the transmission may be via an application or web app running on mobile device 105 and the connection may be made to a destination Uniform Resource Locator (“URL”), Internet Protocol (“IP”) address, or any other address. In such embodiments, the mobile device 105 may transmit via a mobile carrier's network (e.g., a 4G network) and the mobile carrier may then route the transmission to the mobile payment system 120 via one or more other networks, such as the internet.

Once the mobile payment system 120 receives the MIDN, UUI, MDI, and transfer amount, the mobile payment system may perform the process flow shown in FIG. 2. FIG. 2 shows a process flow 200 for a mobile payment system 120 to receive a request for a financial transfer from a mobile device, determine whether the transfer is authorized, and, if the transfer is authorized, provide the appropriate information to a payment gateway. As shown in process flow 200, at step 205 the payment system may receive the MIDN, at step 210 the payment system may receive the UUI and MDI, and at step 215 the payment system may receive the transfer amount. Steps 205, 210, and 215 may occur in any order or simultaneously. In each of these steps the received information may be encrypted, for example using a private key or certificate. If the received information is encrypted, the system may also decrypt all received information.

Next, at step 220 the system may determine whether the UUI and MDI correspond to an authorized account. For example, a dataset of authorized accounts may store for each account one or more UUIs of authorized users and one or more MDIs of authorized mobile devices. In such embodiments, the system may perform a search of all accounts to determine whether an authorized account corresponds to both the received UUI and the received MDI. At step 225, if it is determined that the received identification information corresponds to an authorized account, the system may transmit account information associated with the UUI and MDI, the MIDN, and the transfer amount to a payment gateway associated with the authorized account in step 230 (e.g., payment gateway 125 shown in FIG. 1). The account information, MIDN, and transfer amount may be transferred to a payment gateway in a conventional format, for example using the format currently utilized for credit cards or debit cards. Alternatively, if it is determined that the request is not valid, an authorization failure message may be transmitted back to the attempting payer's device or any other device or system in step 235.

By way of example, a UUI password “password” and an MDI “12345” may be registered with an account associated with a credit card having a name “John Doe”, a number “1234 5678 9101 1213”, an expiration date “01/13”, and a CSC “123”. If in step 210 the system received the UUI “password” and an MDI “12345”, at step 220 the system may determine that the request is an authorized request for a financial transfer from John Doe's account and at step 230 the system may transmit a request to a payment gateway including account information such as John Doe's name, credit card number, credit card expiration date, and CSC as well as the transfer amount and the MIDN. Because existing payment gateways are configured to receive these data, embodiments may be deployed within existing system architectures without requiring any modification to credit card payment gateways or merchant POS devices.

After the system transmits the MIDN, account information, and transfer amount to a payment gateway in step 230, the system may optionally be configured to receive a confirmation or denial from the payment gateway. The system may then be configured to transmit the confirmation or denial to the payer's mobile device in step 245.

While the above example references a credit card account, embodiments may be configured to work with any account architecture. For example, if being utilized within a debit card account system, the system may have a Personal Identification Number (“PIN”) associated with an account and may transmit the PIN to the payment gateway along with all other necessary information to make the transfer. Still other embodiments may be configured to utilize less conventional systems, such as systems for redeeming accrued bonus points (e.g., airline points on an airline credit card), systems for making PayPal purchases, and the like.

Referring again to FIG. 1, if authorized by the mobile payment system 120, the transfer request (including all necessary account information, the transfer amount, and the MIDN) may be transmitted to the payment gateway 125. While payment gateway 125 is illustrated as a single entity in FIG. 1 and described above in the context of a credit card payment processor, the payment gateway may be any system that facilitates the transfer of information between the mobile payment system 120 and the front-end processor of a credit card provider, a bank, or any other institution that can authorize the payment. In some embodiments, existing systems, such as Sybase 365 systems, may be utilized as the payment gateway 125.

If the payment gateway authorizes or receives authorization of the payment, the payment gateway may transmit the payment authorization to the point of sale device 110. The MIDN may include sufficient information for the payment gateway to contact the POS device (e.g., a URL, IP address, phone number, etc.). The merchant 130 may then observe the confirmed payment and provide the purchased goods or services to the payer 115.

As FIGS. 1 and 2 show, embodiments allow for a payer 115 to transfer finances to merchant 130 without disclosing any potentially sensitive information to the merchant. While the payer 115 may provide a general identifier, such as the payer's name, to the merchant so that the payment authorization may be matched to the specific payer 115, embodiments alleviate the need to provide any account related information (e.g., account numbers, credit card numbers, PINs, etc.) that could be stolen to make fraudulent purchases. This provides a benefit over system that utilize NFC or similar technologies to pass “secure” data between a mobile device and a POS device because even such “secure” data may be intercepted and potentially used to provide unauthorized access to payer 115's account.

These figures also show that the mobile device does not require access to any account information at all. Rather, the mobile device only requires an application to be installed or run from a web browser. Even this application does not need to know any of the payer's account information; it simply detects the MDI and allows a user to enter their UUI. The mobile payment system securely maintains associations between accounts and one or more corresponding MDI and UUI. Thus, even if the mobile device is lost or stolen, it has no account information that could be extracted to make fraudulent payments.

FIG. 3 shows an exemplary data flow 300 illustrating that the mobile payment system may be deployed within existing payment gateway architectures without modification. Additionally, data flow 300 illustrates that the information transmitted from the mobile device may contain no user account information. First, mobile device 305 may receive a request for a transaction from a user. For example, a user may enter a merchant ID, a transaction amount, and a secure identifier (e.g., password) into an application's or web app's UI. Mobile device 305 may then transmit all data required to authorize the transfer in mobile payment system 315 across a mobile network to a mobile carrier system 310. This information may include both the information input by the user and a device identifier. This information does not need to include any account information. The mobile carrier system 310 may then pass the data on without modification to the mobile payment system 315, for example by routing the data from the mobile network to another network (e.g., the internet).

Mobile payment system 315 may receive and process the data to determine whether the secure identifier and the device identifier correspond to an authorized account. If they correspond to an authorized account, the account may include data indicating a payment gateway for the user as well as account details for the user. Mobile payment system 315 may then transmit to the payment gateway 320 all data required to authorize the transaction, such as a credit card's user name, number, expiration date, and CSC, an amount of the transfer, and an identification of the merchant account to receive the transfer. The payment gateway 320 may receive the data transmitted from the mobile payment system 315 and process it in conventional fashion. If the payment is authorized, the payment gateway 320 may transmit a notification of the authorization and any relevant information (e.g., the authorized user, the amount, the date the transaction will settle, etc.) to the POS device 325. Alternatively, if the transaction is not authorized (e.g., the account is overdrawn or has been closed), the payment gateway 320 may transmit a notification of the denial to the POS device 325. While not shown, the payment gateway 320 may also transmit a notification of authorization or denial back to the mobile payment system 315 which may, in turn, ultimately transmit a notification back to the mobile device 305. Once the POS device 325 receives a notification that the payment is authorized, a merchant may give the user the goods or services they are purchasing.

As shown in FIG. 3, a user may avail embodiments across the globe and independent of the telecom service provider providing mobile network access. Because embodiments only require network connectivity (e.g., via wired or wireless networks), embodiments may be completely carrier independent. Alternatively, some embodiments may require all payment requests to be received from a specific mobile carrier to provide an additional level of security at the expense of cross-platform convenience.

While in the above discussed embodiments a user may input all necessary data into their mobile device, in alternative embodiments some necessary data may be received by the mobile device in alternative fashions. FIG. 4 shows an exemplary architecture 400 for making financial transfers from a mobile device where the mobile device receives data from the point of sale device. In such an embodiment, mobile device 105 may receive at least one of the amount of the transaction and the merchant's identification automatically. For example, a camera on a mobile device may be utilized optically recognize at least one of the MIDN and the amount of the transfer from a barcode, Quick Response (“QR”) code, screen readout, and the like. Alternatively, a wireless communication coupling (e.g., via NFC) may be utilized to transmit at least one of the MIDN and the amount from the POS device to the mobile device. However, even though information relating to the transaction may be transmitted from the POS device 110 to the mobile device 105, this embodiment may still avoid transmitting any account related information from the mobile device 105 to the POS device 110. The remaining architecture 400 may process a financial transaction in similar fashion to architecture 100 described in reference to FIG. 1 above.

While the above embodiments generally describe financial transfers occurring at POS devices, embodiments may be implemented to allow for other secure financial transactions to be initiated from a mobile device. For example, embodiments may be utilized for a user to make on-line purchases. In such embodiments, an ecommerce website may provide and MIDN and total amount of a purchase at checkout. The customer (i.e., a user) may then initiate the financial transfer on their mobile device by entering in the MIDN, total, and their UUI into an appropriate application. Alternatively, at least one of the MIDN and total may be automatically received by the mobile device from the ecommerce website (e.g., if the website were accessed via a browser on the mobile device). In such on-line purchase embodiments, a user may purchase from any ecommerce website without disclosing any account information to the website. Such embodiments may prevent an ecommerce website worker from stealing account information to make fraudulent purchases. Such embodiments may also be configured to avoid phishing scams by having the payment gateway validate all MIDNs.

Embodiments may also be configured to allow a user to transfer money to another user. For example, individual users may register accounts with a payment gateway and receive a MIDN in similar fashion to how a merchant would. The receiving user (i.e., payee) may then tell the paying user (i.e., payer) their MIDN and the paying user may enter the amount, the receiving user's MIDN, and their UUI into an application to initiate the transfer in similar fashion to the above description of FIG. 1. In other embodiments, the users' phones may operatively couple to allow the payee's phone to transmit the payee's MIDN to the payer's phone (e.g., the phones may “bump” using NFC). In such embodiments, a payer's phone may transmit no account information to the payee's phone.

Embodiments may be configured to accept voice commands for performing all transactions. Such embodiments may be configured to recognize the voice of only a specific authorized user. Such embodiments may be useful to both biometrically authenticate an authorized user and to allow for hands-free use of the mobile device.

Embodiments may also be configured to store receipts or other transaction related data. For example, a mobile device may be configured to receive a receipt from a POS device, for example over NFC. The mobile device may store a local copy of the receipt for later review, may upload the receipt to cloud storage, may upload the receipt to the mobile payment system (which itself may be in the cloud), or may otherwise process the receipts or other transaction data. In some embodiments, the mobile device may store received receipts locally until the device receives network connectivity and then transfer the receipts to cloud storage.

In addition to allowing the user to pay the amount indicated by a merchant, embodiments may allow a user to enter a tip amount. For example, embodiments may include a tip calculator in an application to allow the user to enter a tip by tip amount, by tip percentage, or by quality of service (e.g., the calculator may add 0% for awful service, 5% for poor service, 15% for good service, and 25% for exceptional service).

Embodiments may also be configured to provide ads or promotions to a user interface. For example, embodiments may provide a user with directed promotions based on previous purchases or other financial transfers. Thus, embodiments may conveniently help a user to find the best deals based on their individual habits. Embodiments may allow the user to redeem promotions directly from their mobile device, for example by selecting a promotion and providing their UUI to authorize the purchase of the promoted goods or services.

Embodiments may also provide account management tools. For example, embodiments may provide tools to allow a user to close an account, view a transaction history, cancel a credit card payment (e.g., because a purchased product is defective), view an account balance, and the like. Embodiments may also allow for a bank or financial institution to push information to a user via their mobile device, for example messages about the user's account (e.g., e-statements), notifications of fee changes, promotions, and the like.

The embodiments described herein may be implemented with an application run on a mobile device. The application may, for example, be downloaded from a bank's website. The downloaded application may be configured to know the authorized payment gateway for the account. When the application is installed, it may automatically retrieve the IMEI and other details of the phone on which it is installed. A user may then simply register their UUI with the bank to complete initial authorization of the mobile financial transfer system.

Other embodiments may utilize web apps (i.e., applications executed through an internet connected browser). Such embodiments may provide a user with convenient access to their account without requiring installation of an application on their mobile device. In such embodiments, the user may register their mobile device's IMEI with their bank. Then, when the web app is used to make a financial transfer, the user may enter their UUI and the web app may automatically detect the mobile devices IMEI to authenticate the transfer.

In still other embodiments, the application may be made an integral part of the operating system image installed on the mobile device. Such embodiments may provide additional security since the application cannot be easily uninstalled or tampered with.

Further, embodiments may be used in conjunction with conventional payments systems. For example, a bank may issue a credit card and authorize a mobile financial transfer account for the same user. In such embodiments a user may chose to use their credit card if they do not have their phone with them or may use their mobile phone to initiate a transaction if they do not have their credit card with them or if they wish to perform the transaction with additional security. In such embodiments, an application useful for performing the secure mobile financial transaction may also be useful for managing transactions made with the credit card. Such embodiments may also utilize other known mobile financial service systems, such as Google Wallet, on the same mobile device.

The above embodiments generally describe the MDI being a mobile phone's IMEI. In alternative embodiments, the MDI may be data stored on a Subscriber Identification Module (“SIM”) card provided by a mobile carrier. In still other embodiments, the MDI may be provided by a soft SIM image, such as the soft SIM image describe in the patent application filed concurrently herewith titled “METHOD AND APPARATUS FOR REGISTERING A COMPUTING DEVICE WITH A SERVICE PROVIDER” invented by Anoop Narayanan having docket number IN-PED-0918, the entire contents of which are incorporated herein by reference. The SIM image may be a read-only, encrypted copy of a physical SIM card. Such embodiments may incorporate an application or operating system level driver in the mobile device for reading the soft SIM. The subscriber may register the IMEI number of his or her mobile device with the service provider and the soft SIM, like a plastic SIM card, may have a unique cell number to identify the Global System for Mobile Communications (“GSM”) subscriber. Embodiments using an MDI associated with a SIM card or soft SIM may conveniently allow a user to maintain the same MDI associated with an account after they upgrade their mobile device.

Thus, a soft SIM may provide a digital signature to securely and uniquely identify an authorized mobile device and user. A single soft SIM may act as a digital signature for all transactions performed from the device in conjunction with a unique device identifier, such as an IMEI number or other data embedded in read-only memory which uniquely identifies the device. In other words, a device registered with a service provider may act as a digital signature of a person. Financial transactions (e.g., transfers) may be required to be performed from the signature device (i.e., the device having the soft SIM) and may require a dynamically changing authentication (e.g., a PIN or password). A single device may have plural soft SIMs but the same soft SIM may not be used on more than one device.

While the above embodiments generally describe financial transfers from a user to another user or to a merchant, embodiments may also be useful for allowing a user to securely withdraw money from an ATM using their mobile device. Such embodiments may add a level of security to conventional ATM withdrawals. In such embodiments, a user may utilize an application on their mobile device and enter a unique identifier for the bank in the MIDN field, the amount of the withdrawal, and their UUI. The application may then give the user a temporary PIN number valid for a specific time interval and for the specific cash amount. The user can then visit the ATM of that respective bank, enter the PIN number, and withdraw the cash within the allowed time limit. In other embodiments, the PIN may be valid for a specific time interval but the cash amount may not be predetermined.

These embodiments may be implemented with software, for example modules executed on computing devices such as computing device 510 of FIG. 5. Of course, modules described herein illustrate various functionalities and do not limit the structure of any embodiments. Rather the functionality of various modules may be divided differently and performed by more or fewer modules according to various design considerations.

Computing device 510 has one or more processing device 511 designed to process instructions, for example computer-readable instructions (i.e., code) stored on a storage device 513. By processing instructions, processing device 511 may perform the steps and functions disclosed herein. Storage device 513 may be any type of storage device (e.g., an optical storage device, a magnetic storage device, a solid state storage device, etc.), for example a non-transitory storage device. Alternatively, instructions may be stored in one or more remote storage devices, for example storage devices accessed over a network or the internet. Computing device 510 additionally may have memory 512, an input controller 516, and an output controller 515. A bus 514 may operatively couple components of computing device 510, including processor 511, memory 512, storage device 513, input controller 516, output controller 515, and any other devices (e.g., network controllers, sound controllers, etc.). Output controller 515 may be operatively coupled (e.g., via a wired or wireless connection) to a display device 520 (e.g., a monitor, television, mobile device screen, touch-display, etc.) in such a fashion that output controller 515 can transform the display on display device 520 (e.g., in response to modules executed). Input controller 516 may be operatively coupled (e.g., via a wired or wireless connection) to input device 530 (e.g., mouse, keyboard, touch-pad, scroll-ball, touch-display, etc.) in such a fashion that input can be received from a user.

Of course, FIG. 5 illustrates computing device 510, display device 520, and input device 530 as separate devices for ease of identification only. Computing device 510, display device 520, and input device 530 may be separate devices (e.g., a personal computer connected by wires to a monitor and mouse), may be integrated in a single device (e.g., a mobile device with a touch-display, such as a smartphone or a tablet), or any combination of devices (e.g., a computing device operatively coupled to a touch-screen display device, a plurality of computing devices attached to a single display device and input device, etc.). Computing device 510 may be one or more servers, for example a farm of networked servers, a clustered server environment, or a cloud network of computing devices.

The above embodiments may utilize MIDNs corresponding to the entity receiving the payment initiated from a mobile device. While each MIDN may be associated with a payee, the MIDN may also be transaction specific. For example, if an MIDN is a determined number of digits, a portion of the MIDN may be configured to identify the payee and a portion of the MIDN may be configured to identify the specific transaction. In this fashion, the payee may determine whether the specific transaction is authorized through the mobile financial transfer system.

Embodiments have been disclosed herein. However, various modifications can be made without departing from the scope of the embodiments as defined by the appended claims and legal equivalents.

Claims

1. A computer-implemented method executed by one or more computing devices for financial transfers from a mobile device, the method comprising:

receiving, by at least one of the one or more computing devices, a mobile device identifier, a unique user identifier, a merchant identifier, and an amount from a mobile device;

determining, by at least one of the one or more computing devices, whether the transaction is authorized based on the mobile device identifier and the unique user identifier;

transmitting, by at least one of the one or more computing devices, an authorization failure message to at least one of the mobile device and a merchant device associated with the merchant identifier if it is determined that the transaction is not authorized; and

transmitting, by at least one of the one or more computing devices, to a payment gateway an account identifier associated with the unique user identifier and mobile device identifier, the merchant identifier, and the amount if it is determined that the transaction is authorized.

2. The method of claim 1, wherein the mobile device identifier is an International Mobile Equipment Identity number;

wherein the unique user identifier is at least one of a Personal Identification Number, a password, and a biometric identifier; and

wherein the determining step determines whether the unique user identifier and the mobile device identifier correspond to an account identifier in an account dataset.

3. The method of claim 1, wherein the step of transmitting to the payment gateway transmits all data in a format accepted by conventional credit card payment gateways.

4. The method of claim 1, wherein the merchant identifier incorporates a merchant account identification and a unique transaction identification.

5. The method of claim 1, wherein the mobile device identifier, unique user identifier, merchant identifier, and amount are received from a mobile device via a wireless data connection.

6. The method of claim 1, wherein the mobile device identifier, unique user identifier, merchant identifier, and amount are received from a mobile device via an encrypted Short Message Service message.

7. The method of claim 1, wherein the mobile device identifier is a soft Subscriber Identification Module.

8. A system for financial transfers from a mobile device comprising:

a memory; and

a processor operatively coupled to the memory, the processor configured to perform the steps of: receiving a mobile device identifier, a unique user identifier, a merchant identifier, and an amount from a mobile device; determining whether the transaction is authorized based on the mobile device identifier and the unique user identifier; transmitting an authorization failure message to at least one of the mobile device and a merchant device associated with the merchant identifier if it is determined that the transaction is not authorized; and transmitting to a payment gateway an account identifier associated with the unique user identifier and mobile device identifier, the merchant identifier, and the amount if it is determined that the transaction is authorized.

9. The system of claim 8, wherein the mobile device identifier is an International Mobile Equipment Identity number;

wherein the unique user identifier is at least one of a Personal Identification Number, a password, and a biometric identifier; and

wherein the determining step determines whether the unique user identifier and the mobile device identifier correspond to an account identifier in an account dataset.

10. The system of claim 8, wherein the step of transmitting to the payment gateway transmits all data in a format accepted by conventional credit card payment gateways.

11. The system of claim 8, wherein the merchant identifier incorporates a merchant account identification and a unique transaction identification.

12. The system of claim 8, wherein the mobile device identifier, unique user identifier, merchant identifier, and amount are received from a mobile device via one of a wireless data connection and an encrypted Short Message Service message.

13. The system of claim 8, wherein the mobile device identifier is a soft Subscriber Identification Module.

14. A non-transitory computer-readable medium having computer-readable code stored thereon that, when executed by a computing device, performs a method for financial transfers from a mobile device, the method comprising:

receiving a mobile device identifier, a unique user identifier, a merchant identifier, and an amount from a mobile device;

determining whether the transaction is authorized based on the mobile device identifier and the unique user identifier;

transmitting an authorization failure message to at least one of the mobile device and a merchant device associated with the merchant identifier if it is determined that the transaction is not authorized; and

transmitting to a payment gateway an account identifier associated with the unique user identifier and mobile device identifier, the merchant identifier, and the amount if it is determined that the transaction is authorized.

15. The medium of claim 14, wherein the mobile device identifier is an International Mobile Equipment Identity number;

wherein the unique user identifier is at least one of a Personal Identification Number, a password, and a biometric identifier; and

wherein the determining step determines whether the unique user identifier and the mobile device identifier correspond to an account identifier in an account dataset.

16. The medium of claim 14, wherein the step of transmitting to the payment gateway transmits all data in a format accepted by conventional credit card payment gateways.

17. The medium of claim 14, wherein the merchant identifier incorporates a merchant account identification and a unique transaction identification.

18. The medium of claim 14, wherein the mobile device identifier, unique user identifier, merchant identifier, and amount are received from a mobile device via one of a wireless data connection and an encrypted Short Message Service message.

19. The medium of claim 14, wherein the mobile device identifier is a soft Subscriber Identification Module.