WO2011100247A1

WO2011100247A1 - Mobile payments using sms

Info

Publication number: WO2011100247A1
Application number: PCT/US2011/024060
Authority: WO
Inventors: Amol Bhasker Patel
Original assignee: Ebay Inc.
Priority date: 2010-02-09
Filing date: 2011-02-08
Publication date: 2011-08-18
Also published as: BR112012019539A2; MX2012009205A

Abstract

A consumer texts a request to a payment provider with an amount for preapproval, where the request includes a consumer identifier. The payment provider sends a purchase code back to the consumer that the consumer can use to make a payment or purchase. The payee or merchant receives the code from the consumer, such as at the point of sale, and transmits the code to the payment provider, where the transmission includes a payee identifier and a purchase amount. The payment provider processes the transmission, and if approved, processes the payment and informs the payee and/or consumer.

Description

MOBILE PAYMENTS USING SMS

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Patent Application Serial No. 61/302,868, incorporated by reference in its entirety.

BACKGROUND

Field of the Invention

[0002] The present invention generally relates to in-person payments, and in particular, to payments made using a mobile device.

Related Art

[0003] In a typical in-person or face to face purchase transaction, a buyer provides the seller with a funding instrument, which when accepted, the seller provides the purchased items to the buyer. Examples of funding instruments include cash, credit cards, debit cards, and checks. However, a buyer may prefer not to carry too much cash or may not have sufficient cash available to make the purchase. With credit cards, debit cards, and checks, there may be significant portions of the population who do not have credit cards or bank accounts, resulting in the buyer unable to make the purchase if sufficient cash is unavailable.

[0004] Therefore, a need exists to allow a buyer to make an in-person purchase without the disadvantages discussed above. SUMMARY

[0005] According to one embodiment of the disclosure, a user with a mobile device sends a request to a payment provider, which the user has an account with, to pre- approve a purchase amount. The request may be transmitted by a text message or a call, where the request includes the amount requested and an account/user identifier. This identifier may be automatically included in the request as the mobile device phone number. The payment provider then determines whether the identifier matches a valid user account and whether that account has sufficient funds to cover the requested amount. If so, the payment provider transmits a code to the user, which again can be via text or other means, such as voice call back. The code may expire after a period of time, such as 15 minutes, where the expiration may always be the same or differ depending on amount requested.

[0006] After receiving the code, the user provides the code to a seller, which can be a person or merchant, for making a purchase. The seller transmits the code, along with the purchase amount and an account/seller identifier, to the payment provider. As with the user request, the transmission may be performed using text or other means, and the seller identifier, such as the phone number from the seller's device making the transmission, may be conveyed automatically with the transmission. The payment provider then determines whether the received code is valid (e.g., exists and has not expired), the requested purchase amount is less than or equal to the amount associated with the code, and the seller has an account with the payment provider. If so, the payment provider credits the seller' s account with the purchase amount and deducts that same amount from the user's or buyer's account. The payment provider may also invalidate the code for use or keep it active for the remaining amount of allotted time, but deducting the purchase amount from the previously approved amount. Next, the payment provider sends the seller a confirmation that the purchase request has been approved and funds transferred. The user may also receive a message that funds have been transferred to the seller. The seller then releases the purchased items to the user or buyer.

[0007] A similar process can also be used when the user is returning an item to the initial seller. In this case, the user presents the item to the seller, along with a user identifier, such as the user device phone number. The user may also present the seller with a receipt from the purchase. The seller then transmits a message to the payment provider, where the message includes a request for a refund, the user identifier, the refund amount, and the seller identifier. The seller identifier, which may be the phone number from the seller's device, may be transmitted automatically with the message. From the information in the message, the payment provider determines whether the seller and user have an account with the payment provider and any details of prior transactions between the user and seller. If accounts exist and, at a minimum, there has been at least one prior transaction for an amount at least that of the refund request, the payment provider processes the refund. This can include the seller account being debited the refund amount, the user account being credited the refund amount, and sending a message to the seller and/or user of the debit and/or credit.

[0008] These and other features and advantages of the present invention will be more readily apparent from the detailed description of the embodiments set forth below taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE FIGURES

[0009] Fig. 1 shows a process where a user obtains a purchase code from a payment provider according to one embodiment;

[0010] Fig. 2 shows a process where the user uses the purchase code for making a payment with an in-person seller according to one embodiment;

[0011] Fig. 3 shows a process where the seller requests a refund for a user returning a purchase according to one embodiment;

[0012] Fig. 4 is block diagram of a networked system suitable for implementing the process of Figs. 1-3 according to an embodiment; and

[0013] Fig. 5 is a block diagram of a computer system suitable for implementing one or more components in Fig. 4 according to one embodiment of the present disclosure.

[0014] Embodiments of the present disclosure and their advantages are best understood by referring to the detailed description that follows. It should be appreciated that like reference numerals are used to identify like elements illustrated in one or more of the figures, wherein showings therein are for purposes of illustrating embodiments of the present disclosure and not for purposes of limiting the same. DETAILED DESCRIPTION

[0015] Fig. 1 is a flowchart 100 showing a process where a user obtains a purchase code from a payment provider for making a payment according to one embodiment. At step 102, the consumer sends a request to the payment provider, such as PayPal, Inc. of San Jose, CA. In one embodiment, the user sends the request via the user's mobile device, tablet, PC, or other computing/communication device. The request can be sent by text (SMS), email, voice, or other suitable means at a point of sale. Other locations may also be suitable, such as when the user is traveling to or near the point of sale, at the user's home, office, or virtually any location where the user can communicate with the payment provider. Even if there is no current communication, such as an area with no reception, the request may be stored and communicated when the user device is able to communicate.

[0016] The communication conveys a requested amount and identity information of the consumer or user. If using a mobile device, the consumer may simply enter a number associated with the payment provider and a number of the requested amount, which can be down to the exact dollar amount or other interval, such as in increments of ten dollars. The consumer information, such as the device phone number, may be contained in the transmitted message. The consumer information may also take other forms, such as an email address, user name, etc., depending, in part, on how the request is transmitted. Additional information may also be requested, such as a password, for additional security. In one example, the user sends an SMS to

"729725," which corresponds to the payment provider, with a text or message of "50," indicating a request for a $50 approval from the payment provider.

[0017] Upon receiving the request, the payment provider determines, at step 104, whether the user has an account with the payment provider. This may include determining whether the user identifier corresponds to a valid account with the payment provider. If no valid account exists, an account may be created at step 106. Account creation can be by any suitable means. For example, the user may be asked to provide certain information, such as a funding source, name, address, email address, password/PEN, etc.

[0018] The user may also be asked to sign up for the purchase code feature and/or set conditions or restrictions associated with the purchase code feature of the account. For example, the user may only be able to request a certain amount per day, per week, per request, per month, or only make a certain number of requests or transactions per period. An expiration period may also be set. For example, if the user has the option of setting the expiration period, a longer period increases the chances of an unauthorized use of approved funds, while a shorter period increases the possibility that the approved funds will expire before the consumer can make the purchase. The conditions or restrictions may be set solely by the user, solely by the payment provider, or a combination of the two. If the period is set by the payment provider, the payment provider may desire a shorter period to reduce the chances of fraud. Conditions may also be location-based. In one example, only requests made in California may be approved, or requests made outside a certain area may be subject to additional authentication and/or lower limits.

[0019] Once the user account has been identified or created, the payment provider determines, at step 108, whether the necessary information is present to process the request. In one embodiment, the minimum information is a requested amount and a consumer identifier, which may be transmitted automatically without user input, such as the phone number of the mobile device. Even if the minimum information is received, it may not include all the necessary information. For example, if the account has a restriction that additional authentication is required if the request is made from a different location, the user may be asked to provide additional information, such as a ΡΓΝ or password. Thus, at step 110, the user is asked to provide any additional information or correct information requested by the payment provider.

[0020] Next, the payment provider determines, at stepl 12, whether the user account allows for the purchase code feature. If not, the user may be asked to sign up for or allow the use of the feature at step 114. This can be through any suitable means, such as the user selecting a button or box that conveys acceptance of the feature, including terms of use. The user may also be asked to set conditions for the feature, as discussed above.

[0021] The payment provider then determines, at step 116, the amount requested by the user. Conventions can be set up, by the user or payment provider, for acceptable ways to convey the requested amount. For example, the amount by be indicated by a dollar amount, with no decimals or dollar signs. The currency may be set as a default by the user or may be automatically set by the payment provider based on the user location when the request is made. Note that the above steps may be performed in different order and need to be sequential in the order described.

[0022] Processing continues at step 118, where the payment provider determines whether to approve the purchase code request. This determination may include determining whether the user has sufficient funds in the account and whether conditions, if any, have been met. If the account requires additional authentication, the user may be asked to provide the requested information as part of the

determination. Note that in some embodiments, the user does not have to have sufficient funds in the account. In that case, the payment provider may pull the requested amount from one or more funding sources of the user and not just from the user's account with the payment provider. For example, the payment provider may deduct the amount from a user's bank account or credit card account. If any condition is not met, the user may be asked to re-submit information. Otherwise, the request is denied.

[0023] If all necessary conditions are met, the payment provider approves the request and "separates" the requested amount from the rest of the account at step 120. The separated amount is not actually used, but simply held. The funds may be held a predetermined amount of time, as set by the payment provider or the user and may be based on details of the request, unless the funds are used prior to the time period. Examples of time periods include one hour or one day. In one embodiment, if the full requested amount is not approved, a lesser amount may be approved. So, the approval process is not "all or nothing."

[0024] At step 122, the payment provider generates the purchase code and associates the code with the held amount. In one embodiment, the purchase code is a string of numbers. The length can be variable or fixed. The code may also include letters, characters, symbols, or a combination with numbers. Barcodes or other codes that are readable may also be suitable.

[0025] Once generated, the purchase code is transmitted to the user at step 124. The code may be transmitted by any suitable means, including by SMS, email, or voice. The transmission may also include the value or amount of the code (e.g., $50) and any restrictions on its use, such as valid for the next ten minutes. The user may now use the purchase code to make a purchase or payment. Note that in some embodiments, if the user is not approved for the full amount, the payment provider may approve a portion, such as when the user has exceeded a dollar amount, but would have been approved for a lower amount. The purchase code transmission would include this lower amount.

[0026] Fig. 2 is a flowchart 200 showing a process where the user uses the purchase code for making a payment with an in-person seller according to one embodiment. In other embodiments, the payment need not be made in-person or at the POS, but remotely, such as through a PC or other computing device. At step 202, the user presents the purchase code to the seller or merchant at the point of sale. This can be done in any number of ways. For example, the user can say the code, write it down and show it to the seller, or show it from the user's mobile device to the seller for visual identification or scanning.

[0027] At step 204, the seller transmits a message to the payment provider, where the message includes at least the payment code and seller identification information. The message may also include the purchase amount. The transmission may automatically include the seller identification information, such as the phone number of the seller transmitting device. The message may be transmitted electronically through any wired or wireless means. In one example, the seller sends "9876 47" to "729725," which represents the purchase code and the purchase amount to a text number of the payment provider. In another example, the seller sends "9876 47 6503340405" to "729725," which includes an additional telephone number of the seller, i.e., a seller identifier. Other formats or ordering may also be suitable. The information may also be conveyed through a voice call, email, or any other appropriate means.

[0028] Once the message is received, the payment provider determines, at step 206, whether the seller or merchant has an account with the payment provider. For example, the payment provider may determine whether a valid account is associated with the seller identification information, such as the seller phone number. If no valid account exists, the seller may create an account at step 208. The seller may be notified by the payment provider that the seller will need to create an account before the purchase request can be processed. Account creation may include the seller providing requested information from the payment provider, such as email address, password/PEN, mailing address, user name, credit card information, bank information, etc.

[0029] After the seller account has been accessed or created, the payment provider further processes the message to determine the payment code and possibly the purchase amount at step 210. Note that if the purchase amount is not included or required in the message, the payment provider may simply process the request based on the purchase code. [0030] Next, the purchase code is processed at step 212. This may include determining whether the code is valid, e.g., a previously approved code that has not expired, any limitations associated with the code, and/or the amount the code is approved for. Code processing may also include further analysis to reduce the possibility of the seller fraudulently requested a money transfer. This may include looking at the number of unsuccessful attempts this particular seller has made in comparison with the total number of requests made by the seller, the number of attempts made for the particular user, and geographical location and frequency of requests from merchants of the same user.

[0031] If the purchase code is valid, the payment provider determines whether conditions or restrictions, if any, are met. For example, the payment provider may determine whether the approved amount of the purchase code is less than or equal to the requested payment amount. Other examples include determining whether the transaction details are within any purchase restrictions, such as frequency of use of a purchase code by the user, merchant name or type, merchant location, etc.

[0032] If the purchase request from the seller is approved, as determined at step 214, the payment provider processes the purchase request at step 216. Processing may include crediting the seller account by the appropriate amount, debiting the user account by the appropriate amount, and updating the purchase code. The amount credited and debited may be different, such as when there are fees associated with using services of the payment provider, which may be paid by the seller or the user. Fees may also be split equally or in different ratios between the seller and user.

Updating the purchase code may include invalidating the code for future use, such as when the code is a one-time use code, the maximum preapproved amount of the code has been exhausted, or other limitations met, such as maximum times the user can use a code has been reached with this use. The code may also be updated and remain valid for future use, such as by reducing the preapproval amount and/or updating the number of transactions allowed, assuming other conditions are met, such as time limit not yet expired and sufficient remaining balance for a subsequent purchase request.

[0033] Next, the payment provider notifies the user and/or the seller at step 218, informing them of the payment. Notification may be by SMS, email, voice call, or any other suitable means. The notification may include a message that the payment request has been approved, with the amount credit to the seller and/or the amount debited from the user.

[0034] Once the seller has been notified of the payment, which can be through the user/buyer instead of directly through the payment provider, the seller may release the goods to the user at step 220. The seller may also provide the user with a physical receipt, or the payment provider may provide a "receipt" electronically to the user and/or the seller.

[0035] Fig. 3 is a flowchart 300 showing a process where the seller/merchant requests a refund for a user returning a purchase according to one embodiment. At step 302, the user presents the returned item(s) to the seller or merchant, along with a user identifier, such as a phone number, email address, user name, etc. The item may be a physical good or a digital good. In one embodiment, the user also presents an indication that the item was purchased from the particular merchant, such as a physical paper receipt or an electronic receipt on the user's mobile device.

[0036] Next, at step 304, the seller sends a message to the payment provider, where the message includes at least user identification information and seller identification information. The user information may be a phone number of a user device that the seller manually enters or records into the message. The seller identification information, such as the phone number of the seller transmitting device, may be automatically transmitted when the message is sent. The message may also include the requested refund amount and/or other information about the refund request, such as a transaction ID, or an indication the request is for a refund. The sending may be by SMS, email, voice, or any suitable method.

[0037] Once the message is received, the payment provider processes the message at step 306. Processing may include determining whether the seller has a valid account with the payment provider, and if not, having the seller open or update an account to continue with the refund request. Processing may also include looking up previous transactions between the user (based on the user identification) and the seller (based on the seller identification). This may indicate whether the requested refund from the user is actually from a previous purchase between the user and seller. The payment provider may also look at other information, such as geographical information of the seller, user, and current refund request, number and dollar amount of refund requests to the particular user, number and dollar amount of refund requests made by the particular seller, and unsuccessful versus successful refund requests involving the particular user and seller, both together and individually. If the user has an actual receipt or other proof of purchase, this analysis may not be needed. In that case, the seller may indicate in the message from step 304 that the seller has confirmed the refund request is valid.

[0038] The payment provider then determines, at step 308, whether to approve the refund request. If the refund request is not approved, the payment provider may request the seller to provide additional information or take certain actions at step 310. For example, if the request was denied because of insufficient funds in the seller's account, the seller may be asked to deposit more funds into the account. If the request was denied because the initial purchase transaction could not be verified, the seller may be asked to approve on the seller's end or obtain additional information, such as from the user, to verify the original transaction. The payment provider determines again whether to approve the transaction, at step 312, based on any new information. The payment provider may then approve, deny, or again request additional information.

[0039] If the payment provider approves the refund request, the refund request is processed at step 314. This may include debiting an appropriate amount from the seller account and crediting an appropriate amount to the user's account. The amounts may vary, depending on whether fees are imposed for the service, which may be incurred by the seller, the user, or both. The payment provider may also update the database associated with the seller and user to reflect the processed refund, including amount, date, location, etc.

[0040] Once processed, the payment provider may send a message, at step 316, such as SMS, email, or voice, to the user and/or seller. The user receives confirmation on the user device that the refund amount has been credited to the account, and/or the seller receives confirmation that the refund amount has been debited from the seller account.

[0041] Upon confirmation, the user releases the returned item(s) to the seller at step 318. [0042] Thus, users can easily conduct financial transactions (purchases and refunds) in-person at physical points of sale without having to carry cash, checks, credit cards, bank cards or open credit or bank accounts. This benefits both merchants and consumers to promote easier ways to purchase items. The seller is assured of payment through the payment provider. Thus, both the seller and user/buyer get what they want, whereas with conventional payment methods, the transaction may not have occurred due to the user not having sufficient cash, a check, or a credit/debit card to use.

[0043] Fig. 4 is a block diagram of a networked system 400 configured to handle a financial transaction between a recipient (e.g., merchant or seller) and a sender (e.g., - user or consumer), such as described above, in accordance with an embodiment of the invention. System 400 includes a user device 410, a merchant device 462, a merchant server 440, and a payment provider server 470 in communication over a network 460.

Payment provider server 470 may be maintained by a payment provider, such as PayPal, Inc. of San Jose, CA. A user 405, such as the sender or purchaser, utilizes user device 410 to perform a payment transaction with merchant server 440 using payment provider server 470 and merchant device 462.

[0044] User device 410, merchant device 462, merchant server 440, and payment provider server 470 may each include one or more processors, memories, and other appropriate components for executing instructions such as program code and/or data stored on one or more computer readable mediums to implement the various applications, data, and steps described herein. For example, such instructions may be stored in one or more computer readable media such as memories or data storage devices internal and/or external to various components of system 400, and/or accessible over network 460.

[0045] Network 460 may be implemented as a single network or a combination of multiple networks. For example, in various embodiments, network 460 may include the Internet or one or more intranets, landline networks, wireless networks, and/or other appropriate types of networks.

[0046] User device 410 and merchant device 462 may be implemented using any appropriate hardware and software configured for wired and/or wireless

communication over network 460. For example, in one embodiment, the two devices may be implemented as a personal computer (PC), a smart phone, personal digital assistant (PDA), laptop computer, and/or other types of computing devices capable of transmitting and/or receiving data, such as an iPad™ from Apple™.

[0047] User device 410 may include one or more browser applications 415 which may be used, for example, to provide a convenient interface to permit user 405 to browse information available over network 460. For example, in one embodiment, browser application 415 may be implemented as a web browser configured to view information available over the Internet. User device 410 may also include one or more toolbar applications 420 which may be used, for example, to provide client-side processing for performing desired tasks in response to operations selected by user 405. In one embodiment, toolbar application 420 may display a user interface in connection with browser application 415.

[0048] User device 410 may further include other applications 425 as may be desired in particular embodiments to provide desired features to user device 410. For example, other applications 425 may include security applications for implementing client-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network 460, or other types of applications. Applications 425 may also include email, texting, voice and ΓΜ applications that allow user 405 to send and receive emails, calls, and texts through network 460, as well as applications that enable the user to make payments through the payment provider and create/control the purchase code feature as discussed above. User device 410 includes one or more user identifiers 430 which may be

implemented, for example, as operating system registry entries, cookies associated with browser application 415, identifiers associated with hardware of user device 410, or other appropriate identifiers, such as used for payment/user/device authentication. In one embodiment, user identifier 430 may be used by a payment service provider to associate user 405 with a particular account maintained by the payment provider as further described herein. A communications application 422, with associated interfaces, enables user device 410 to communicate with merchant device 462 and payment provider server 470, as well as other devices within system 400.

[0049] Merchant device 462 may have similar applications and modules as user device 410, but can be the same or a different device than user device 410. For example, the user device may be a smart or mobile phone, and the merchant device may be a POS terminal, tablet, or other computing/communication device. Merchant device 462 may also include one or more browser applications 415 and one or more toolbar applications 420 which may be used, for example, to provide a convenient interface to permit user 406 to browse information and perform tasks over network 460. For example, in one embodiment, browser application 415 may be implemented as a web browser configured to view information available over the Internet and communicate with payment provider server 470 to receive and send information about processing a purchase code or a refund.

[0050] Merchant device 462 may further include other applications 425 such as security applications for implementing client-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network 460, or other types of applications. Applications 425 may also include email, text, IM, and voice applications that allow a merchant 406 to communicate through network 460 to conduct a purchase or refund. Merchant device 462 includes one or more user identifiers 430 which may be implemented, for example, as operating system registry entries, cookies associated with browser application 415, identifiers associated with hardware of merchant device 462, or other appropriate identifiers, such as used for payment/user/device authentication, e.g., the phone number or device ID associated with merchant device 462. Identifiers may be used by a payment service provider to associate merchant 406 with a particular account maintained by the payment service provider. Note that merchant device 462 and/or user device 410 may be simpler phones (i.e., not smart phones) capable of only communication and text, such as with the payment provider. Thus, complicated smart phones are not required to conduct transactions described herein.

[0051] Merchant server 440 may be maintained, for example, by a merchant or seller offering various products and/or services in exchange for payment to be received over network 460. Merchant server 440 may be located with or away from merchant device 462. Generally, merchant server 440 may be maintained by anyone or any entity that receives money, which includes charities as well as retailers. Merchant server 440 includes a database 445 identifying available products and/or services (e.g., collectively referred to as items) which may be made available for viewing and purchase by user 405. Accordingly, merchant server 440 also includes a marketplace application 450 which may be configured to serve information over network 460 to browser 415 of user device 410 and merchant device 462. In one embodiment, user 405 may interact with marketplace application 450 through browser applications over network 460 in order to view various products or services identified in database 445. Note that merchant server 440 may not be required in simpler systems, where sales and transactions are performed at a physical location.

[0052] Merchant server 440 also includes a checkout application 455 which may be configured to facilitate the purchase by user 405 of goods or services identified by marketplace application 450. Checkout application 455 may be configured to accept payment information from user 405 through payment service provider server 470 over network 460. For example, checkout application 455 may receive and process a payment confirmation from payment service provider server 470, as well as transmit transaction information to the payment provider and receive information from the payment provider (e.g., a transaction ID). Checkout application 455 may also be configured to accept one or more different payment options, including purchase codes.

[0053] Payment provider server 470 may be maintained, for example, by an online payment service provider which may provide payment between user 405 and the operator of merchant server 440. In this regard, payment provider server 470 includes one or more payment applications 475 which may be configured to interact with user device 410, merchant device 462, and/or merchant server 440 over network 460 to facilitate the purchase or return of goods or services by user 405 of user device 410.

[0054] Payment provider server 470 also maintains a plurality of user accounts 480, each of which may include account information 485 associated with individual users and merchants. For example, account information 485 may include private financial information of users of devices such as account numbers, passwords, device identifiers, user names, phone numbers, credit card information, bank information, purchase code conditions, or other financial information which may be used to facilitate online transactions by user 405. Advantageously, payment application 475 may be configured to interact with merchant server 440 on behalf of user 405 during a transaction with checkout application 455 to track and manage purchases made by users.

[0055] A transaction processing application 490, which may be part of or separate from payment application 475, may be configured to receive information from a user device, merchant device, and/or merchant server 440 for processing and storage in a payment database 495. Transaction processing application 490 may include one or more applications to process information from user 405 and/or merchant 406 for processing a payment or refund as described herein. Payment application 475 may be further configured to determine the existence of and to manage accounts for user 405 and/or merchant 406, as well as create new accounts if necessary, such as the set up, management, and use of purchase codes.

[0056] Thus, system 400 allows user 405 to make a purchase or refund as described herein, both electronically in physically in person.

[0057] Fig. 5 is a block diagram of a computer system 500 suitable for implementing one or more embodiments of the present disclosure. In various implementations, the user device may comprise a personal computing device (e.g., a personal computer, laptop, smart phone, PDA, Bluetooth device, key FOB, badge, etc.) capable of communicating with the network. The merchant and/or payment provider may utilize a network computing device (e.g., a network server) capable of communicating with the network. It should be appreciated that each of the devices utilized by users, merchants, and payment providers may be implemented as computer system 500 in a manner as follows.

[0058] Computer system 500 includes a bus 502 or other communication mechanism for communicating information data, signals, and information between various components of computer system 500. Components include an input/output (I/O) component 504 that processes a user action, such as selecting keys from a keypad/keyboard, selecting one or more buttons or links, etc., and sends a corresponding signal to bus 502. I/O component 504 may also include an output component, such as a display 511 and a cursor control 513 (such as a keyboard, keypad, mouse, etc.). An optional audio input/output component 505 may also be included to allow a user to use voice for inputting information by converting audio signals. Audio I/O component 505 may allow the user to hear and transmit audio. A transceiver or network interface 506 transmits and receives signals between computer system 500 and other devices, such as another user device, a merchant server, or a payment provider server via network 460. In one embodiment, the transmission is wireless, although other transmission mediums and methods may also be suitable. A processor 512, which can be a micro-controller, digital signal processor (DSP), or other processing component, processes these various signals, such as for display on • computer system 500 or transmission to other devices via a communication link 518. Processor 512 may also control transmission of information, such as cookies or IP addresses, to other devices.

[0059] Components of computer system 500 also include a system memory component 514 (e.g., RAM), a static storage component 516 (e.g., ROM), and/or a disk drive 517. Computer system 500 performs specific operations by processor 512 and other components by executing one or more sequences of instructions contained in system memory component 514. Logic may be encoded in a computer readable medium, which may refer to any medium that participates in providing instructions to processor 512 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. In various implementations, non-volatile media includes optical or magnetic disks, volatile media includes dynamic memory, such as system memory component 514, and transmission media includes coaxial cables, copper wire, and fiber optics, including wires that comprise bus 502. In one embodiment, the logic is encoded in non- transitory computer readable medium. In one example, transmission media may take the form of acoustic or light waves, such as those generated during radio wave, optical, and infrared data communications.

[0060] Some common forms of computer readable media includes, for example, floppy disk, flexible disk, hard disk, magnetic tape, any other magnetic medium, CD- ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or cartridge, or any other medium from which a computer is adapted to read.

[0061] In various embodiments of the present disclosure, execution of instruction sequences to practice the present disclosure may be performed by computer system 500. In various other embodiments of the present disclosure, a plurality of computer systems 500 coupled by communication link 518 to the network (e.g., such as a LAN, WLAN, PTSN, and/or various other wired or wireless networks, including telecommunications, mobile, and cellular phone networks) may perform instruction sequences to practice the present disclosure in coordination with one another.

[0062] Where applicable, various embodiments provided by the present disclosure may be implemented using hardware, software, or combinations of hardware and software. Also, where applicable, the various hardware components and/or software components set forth herein may be combined into composite components comprising software, hardware, and/or both without departing from the spirit of the present disclosure. Where applicable, the various hardware components and/or software components set forth herein may be separated into sub-components comprising software, hardware, or both without departing from the scope of the present disclosure. In addition, where applicable, it is contemplated that software components may be implemented as hardware components and vice- versa.

[0063] Software, in accordance with the present disclosure, such as program code and/or data, may be stored on one or more computer readable mediums. It is also contemplated that software identified herein may be implemented using one or more general purpose or specific purpose computers and/or computer systems, networked and/or otherwise. Where applicable, the ordering of various steps described herein may be changed, combined into composite steps, and/or separated into sub-steps to provide features described herein.

[0064] The foregoing disclosure is not intended to limit the present disclosure to the precise forms or particular fields of use disclosed. As such, it is contemplated that various alternate embodiments and/or modifications to the present disclosure, whether explicitly described or implied herein, are possible in light of the disclosure. Having thus described embodiments of the present disclosure, persons of ordinary skill in the art will recognize that changes may be made in form and detail without departing from the scope of the present disclosure. Thus, the present disclosure is limited only by the claims.

Claims

WHAT IS CLAIMED IS:

1. A method of conducting a financial transaction comprising:

receiving, by a processor of a payment provider, a purchase code . request from a user through a user device, wherein the purchase code request comprises an amount and a first user identifier;

transmitting a purchase code to the user if the authorization request is approved;

receiving a purchase request from a payee through a payee device, wherein the purchase request comprises the purchase code, a second user identifier, and a payee identifier; and

transmitting a message to the payee if the purchase request is approved.

2. The method of claim 1, wherein the purchase code expires after a predetermined amount of time.

3. The method of claim 1, wherein the purchase code expires after a predetermined amount of uses.

4. The method of claim 3, wherein the pre-determined amount of uses is one.

5. The method of claim 1, wherein the purchase code is presented to the payee in person.

6. The method of claim 1, wherein the first user identifier is automatically transmitted with the purchase code request.

7. The method of claim 6, wherein the first user identifier comprises a phone number of the user.

8. The method of claim 1, wherein the payee identifier is automatically transmitted with the purchase request.

9. The method of claim 8, wherein the payee identifier comprises a phone number of the payee.

10. The method of claim 1 , wherein the first and second user identifiers are the same.

1 1. The method of claim 1 , further comprising transmitting a message to the user if the purchase request is approved.

12. The method of claim 1, wherein the transmitting and receiving are through text.

13. The method of claim 1, further comprising receiving information from the user to set up or modify the purchase code.

14. The method of claim 13, wherein the information received comprises limitations and conditions for use of the purchase code by the user.

15. A method of conducting a financial transaction comprising:

receiving, by a processor of a payment provider, a refund request from a seller, wherein the refund request comprises an amount, a seller identifier, and a consumer identifier;

determining, by the processor, whether the refund request is associated with a previous purchase by the consumer from the seller;

crediting a consumer account and debiting a seller account with the • amount if the refund request is approved; and

transmitting a message to the consumer if the refund request is approved.

16. The method of claim 15, wherein the seller and consumer identifiers are phone numbers.

17. The method of claim 15, wherein the seller identifier is automatically transmitted with the refund request.

18. The method of claim 15, wherein the receiving and transmitting are by

SMS.

19. A non-transitory machine-readable medium comprising a plurality of machine-readable instructions which when executed by one or more processors of a server are adapted to cause the server to perform a method comprising:

receiving a purchase code request from a user through a user device, wherein the purchase code request comprises an amount and a first user identifier;

transmitting a message to the payee if the purchase request is approved.

20. The machine-readable medium of claim 19, wherein the first user identifier is automatically transmitted with the purchase code request.

21. The machine-readable medium of claim 19, wherein the payee identifier is automatically transmitted with the purchase request.

22. The machine-readable medium of claim 19, wherein the transmitting and receiving are through text.

23. The machine-readable medium of claim 19, wherein the method further comprises receiving information from the user to set up or modify the purchase code.

24. The machine-readable medium of claim 23, wherein the information received comprises limitations and conditions for use of the purchase code by the user.