MX2012009205A - Mobile payments using sms. - Google Patents

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 SHORT MESSAGE SERVICE CROSS REFERENCE WITH RELATED REQUESTS This application claims priority to the Patent Application Provisional of E.U.A Serial No. 61 / 302,868, incorporated for reference in its entirety.

FIELD OF THE INVENTION The present invention relates in general to payments in person and in particular, to payments made using a mobile device.

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

Therefore, there is a need to allow a buyer to make a purchase in person without the disadvantages discussed above.

BRIEF DESCRIPTION OF THE INVENTION In accordance with one embodiment of the description, a user with a mobile device sends a request to a payment provider, with which the user has an account, to pre-approve a purchase amount. The request can be transmitted by a text message or a call, wherein the request includes the requested quantity and an account / user identifier. This identifier can be automatically included in the request as the telephone number of the mobile device. The payment provider then determines if the identifier matches a valid user account and if 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 returning a voice call. 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 the amount requested.

After receiving the code, the user provides the code to a vendor, which can be a person or a merchant, to make 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's request, the transmission can be made using text or other means, and the vendor's identifier, such as the telephone number of the vendor's device performing the transmission, can be transmitted automatically with the transmission. The payment provider then determines if the received code is valid (for example, it 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 supplier payment. 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 can also invalidate the code for use or keep it active for the remaining amount of time allotted, but deducting the purchase amount from the previously approved amount. After. The payment provider sends the seller a confirmation that the purchase request has been approved and the funds transferred. The user can also receive a message that the funds have been transferred to the seller. The seller then releases the purchased objects to the user or buyer.

A similar process can also be used when the user is returning an object to the initial vendor. In this case, the user presents the object to the vendor, together with a user identifier, such as the telephone number of the user's device. The user can also present the seller with a receipt for 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's identifier. The seller's identifier, which can be the telephone number of the seller's device, can be automatically transmitted with the message. From the information in the message, the payment provider determines whether the seller and the user have a payment provider account and any details of previous transactions between the user and the seller. If the account exists, and at a minimum, there has been at least one previous transaction for at least that amount of refund request, the payment provider proceeds with the refund. This can include the seller's account being charged the refund amount, the user's account being credited the refund amount, and sending a message to the seller and / or the user of the debit and / or credit.

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

BRIEF DESCRIPTION OF THE FIGURES Fig. 1 shows a process where a user obtains a purchase code from a payment provider in accordance with a modality; Fig. 2 shows a process where the user uses the purchase code to make a payment with a salesperson in person in accordance with a modality; Fig. 3 shows a process where the seller requests a refund for a user returning a purchase in accordance with a modality; Fig. 4 is a block diagram of an appropriate network system for implementing the process of Figs. 1-3 in accordance with one modality; Y Fig. 5 is a block diagram of an appropriate computer system for implementing one or more components in Fig. 4 in accordance with one embodiment of the present disclosure.

The embodiments of the present description and their advantages are better understood by referring to the following detailed description. It should be noted that like reference numbers are used to identify like elements illustrated in one or more of the figures, wherein the projections thereof are for purposes of illustrating the embodiments of the present disclosure and not for purposes of limiting the same.

DETAILED DESCRIPTION OF THE INVENTION Fig. 1 is a flow chart 100 showing a process where a user obtains a purchase code from a payment provider to make a payment in accordance with a modality. In 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 via the user's mobile device, tablet, PC, or other communication / computing device. The request can be sent by text (SMS), email, voice, or other appropriate means at a point of sale. Other locations may also be appropriate, 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 if reception, the request can be stored and communicated when the user's device is able to communicate.

The communication transmits a requested quantity and the identity information of the consumer or user. If a mobile device is used, the consumer can simply enter a number associated with the payment provider and a number of the requested amount, which may be below the exact dollar amount or another interval, such as in increments of ten dollars . Consumer information, such as the telephone number of the device, may be contained in the transmitted message. The Consumer information can 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 an access key, 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.

Upon receipt of the request, the payment provider determines, in 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 there is no valid account, an amount can be created in step 106. Account creation can be by any appropriate means. For example, the user may be asked to provide certain information, such as a funding source, name, address, email address, access code / PIN, etc.

The user can also be asked to sign 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 create a certain number of requests or transactions per period. An expiration period can also be established. For example, if the user has the option to set the expiration period, a longer period increases the likelihood of unauthorized use of approved funds, while a shorter period increases the possibility that approved funds will expire before the consumer can make the purchase. The conditions or restrictions can be established only by the user, only by the payment provider, or a combination of the two. If the period is set by the payment provider, the payment provider may want a shorter period to reduce the likelihood of fraud. Conditions can also be location-based. In an example, only requests made in California can be approved, or requests made outside of a certain area be submitted to additional authentication and / or lower limits.

Once the user's account has been identified or created, the payment provider determines, in step 108, whether the necessary information is to proceed with the request. In one embodiment, the minimum information is a requested quantity and a consumer identifier, which can be transmitted automatically without input from the user, such as the telephone number of the mobile device. Even if the minimum information is received, it may not include all the necessary information. For example, if the amount 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 PIN or password. Thus, in step 1 10, the user is asked to provide additional information or correct information requested by the payment provider.

Then, the payment provider determines, in step 112, whether the user's account allows the purchase code feature. If not, the user can be asked to sign or allow the use of the feature in step 1 14. This can be through any available means, such as the selected user a button or box that transmits the acceptance of the feature, including terms of use. The user can also be asked to establish the conditions of the characteristic, as discussed above.

The payment provider then determines, in step 1 16, the amount requested by the user. Conventions can be established, by the user or payment provider, for acceptable ways of communicating the requested quantity. For example, the amount can be indicated by a dollar amount, without decimals or dollar signs. The currency can be established as a standard by the user or can be established automatically by the payment provider based on the user's location when the request is made. Note that the previous steps can be performed in a different order and need to be sequential in the order described.

Processing continues in 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 the conditions, if any, have been met. If the account requires additional authentication, the user may be asked to provide the information requested as part of the determination. Note that in some modalities, the user does not have sufficient funds in the account. In that case, the payment provider may pull the requested amount from one or more sources of user financing and not just from the user's account with the payment provider. For example, the payment provider can deduct the amount from a user's bank account or credit card account. If any condition is not met, the user can be requested to re-send the information. Otherwise, the request is rejected.

If all the necessary conditions are met, the payment provider approves the request and "separates" the requested amount from the rest of the account in step 120. The separate amount is not currently used, but simply maintained. The funds can be held for a predetermined period 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 before the time period. Examples of time periods include an hour or a day. In a modality, if the full requested amount is not approved, a smaller amount may be approved. Thus, the approval process is not "all or nothing".

In step 122, the payment provider generates the purchase code and associates the code with the amount maintained. In one mode, the purchase code is a string of numbers. The length can be variable or fixed. The code can also include letters, characters, symbols, or a combination with numbers. Bar codes or other codes that are readable may also be appropriate.

Once generated, the purchase code is transmitted to the user in step 124. The code can be transmitted by any appropriate means, including by SMS, email, or voice. The transmission may also include the value or amount of the code (for example, $ 50) and any restrictions on its use, such as valid for the next ten minutes. The user can now use the purchase code to create a purchase or payment. Note that in some modalities, if the user is not approved for the full amount, the payment provider can approve a portion, such as when the user has exceeded a dollar amount, but could have been approved for a smaller amount. The transmission of the purchase code could include this smaller amount.

Fig. 2 is a flow chart 200 showing a process where the user uses the purchase code to make a payment with a salesperson in person in accordance with a modality. In other modalities, the payment does not need to be made in person or in the POS, but remotely, such as through a PC or other computing device. In 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 tell the code, write it and show it to the vendor, or show it from the user's mobile device to the vendor for visual identification or scanning.

In 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 can also include the purchase amount. The transmission may automatically include the seller's identification information, such as the telephone number of the seller's transmission device. The message can be transmitted electronically through any wire or wireless means. In an example, the seller sends "9876 47" to "72975", which represents the purchase code and the purchase quantity 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, is described, an identifier of the seller. Other formats or orders may also be appropriate. The information may also be transmitted through a voice call, email, or any other appropriate means.

Once the message is received, the payment provider determines, in step 206, whether the vendor or merchant has an account with the payment provider. For example, the payment provider can determine if a valid account is associated with the seller's identification information, such as the seller's telephone number. If there is no valid account, the seller can create an account in step 208. The seller can be notified by the payment provider that the seller will need to create an account before the purchase request can be processed. The creation of an account can include the seller providing the information required by the payment provider, such as email address, access key / PIN, postal address, user name, credit card information, bank information, etc.

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 in step 210. Note that if the purchase amount is not included or required In the message, the payment provider can simply process the request based on the purchase code.

Then, the purchase code is processed in step 212.

This may include determining if the code is valid, for example, a previously approved code that has not expired, any limitations associated with the code, and / or the amount of the code is approved. Code processing may also include additional analysis to reduce the possibility of the seller fraudulently requesting a money transfer. This may include observing the number of unsuccessful attempts that this particular vendor has made compared to the total number of requests made by the vendor, the number of attempts made by the particular user, and geographic location and frequency of merchant requests. user.

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

If the seller's purchase request is approved, as determined in step 214, the payment provider processes the purchase request in step 216. Processing may include crediting the seller's account with the appropriate amount, debiting the account of the user the appropriate amount, and update the purchase code. The amount credited and charged may be different, such as when there are fees associated with the use of the payment provider's services, which can be paid by the seller or the user. The rates can also be divided equally or in different proportions between the seller and the 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 pre-approved amount of the code has been exhausted, or other limitations met, such as maximum time the user You can use the code has been reached with this use. The code can also be updated and remain valid for future use, such as reducing the pre-approved amount and / or updating the number of allowed transactions, assuming other conditions are met, such as time limit not yet expired and remaining balance sufficient for a Subsequent purchase request.

Then, the payment provider notifies the user and / or the vendor in step 218, informing the latter of the payment. Notification can be made by SMS, email, voice call or any other appropriate means. The notification may include a message that the requested payment has been approved, with the amount of credit to the seller and / or the amount charged by the user.

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 can release the products to the user in step 220. The seller can also provide the user with a physical receipt, or the payment provider can provide an electronic "receipt" to the user and / or the seller.

Fig. 3 is a flow chart 300 showing a process where the vendor / merchant requests a refund for a user returning a purchase in accordance with a mode. In step 302, the user presents the object (s) returned to the vendor or merchant, together with a user identifier, such as a telephone number, email, user name, etc. The object can be a physical product or a digital product. In one embodiment, the user also presents an indication of which item was purchased by the particular merchant, such as a receipt on physical paper or an electronic receipt on the user's mobile device.

Then, in step 304, the vendor sends a message to the payment provider, where the message includes at least user identification information and vendor identification information. The user information may be a telephone number of a user device that the vendor enters manually or registers in the message. The seller's identification information, such as the telephone number of the seller's transmission device, can be transmitted automatically 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 that the request is for a refund. The shipment can be by SMS, email, voice, or any other appropriate method.

Once the message is received, the payment provider processes the message in step 306. Processing may include determining whether the seller has a valid account with the payment provider, and if not, the seller has opened or updated an account. to continue with the refund request. Processing may also include observing past transactions between the user (based on the user's identification) and the seller (based on the seller's identification). This can indicate if the requested refund of the user is currently from a previous purchase between the user and the seller. The payment provider may also observe other information, such as the seller's geographic information, user, and current refund request, number and amount of refund request dollars made by the particular seller, and unsuccessful refund requests against successful ones involving the private user and seller, both together and individually. If the user has a current receipt or other proof of purchase, this analysis may not be necessary. In this case, the seller may indicate in the message of step 304 that the seller has confirmed that the refund request is valid.

The payment provider then determines, in 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 in step 310. For example, if the request was denied due to insufficient funds in the seller's account, the seller may be asked to the seller to deposit more funds in the account. If the request was denied because the initial purchase transaction might not be verified, the seller may be asked to approve the seller's endorsement or obtain additional information, such as from the user, to verify the original transaction. The payment provider again determines whether to approve the transaction, in step 312, based on some new information. The payment provider can then approve, reject, or request additional information.

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

Once processed, the payment provider may send, at step 316, such as SMS, email, or voice, to the user and / or vendor. 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 paid from the seller's account.

Upon confirmation, the user releases the object (s) returned to the vendor in step 318.

Thus, users can 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. These benefits for both merchants and consumers promote easier ways to buy objects. The seller is insured for payment through the payment provider. Thus, both the seller and the user / buyer get what they want, while with conventional payment methods, the transaction may not have happened because the user does not have enough cash, a check or a credit / debit card to use.

Fig. 4 is a block diagram of a network system 400 configured to manipulate a financial transaction between a container (e.g., a merchant or vendor) and an issuer (e.g., user or consumer), as described above. , in accordance with one embodiment of the invention. The system 400 includes a user device 410, a merchant device 462, a merchant server 440, and a payment provider server 470 in communication in a network 460. The payment provider server 470 can be maintained by a provider of payment, such as PayPal, Inc. of San Jose, CA. A user 405, such as the issuer or purchaser, uses the user device 410 to perform a payment transaction with the merchant server 440 using the payment provider server 470 and the merchant device 462.

The 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 to execute instructions such as program code and / or data stored in one more computer readable media 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 the system 400, and / or accessible in the network 460.

The network 460 can 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 network types.

The user device 410 and the merchant device 462 can be implemented using any appropriate hardware and software configured for wired and / or wire communication over the network 460. For example, in one embodiment, the two devices can be implemented as a personal computer (PC), a smartphone, a personal digital assistant (PDA), a laptop, and / or other types of computing devices capable of transmitting and / or receiving data, such as an iPad ™ for Apple ™.

The user device 410 may include one or more browser applications 415 which may be used, for example, to provide a convenient interface to enable the user 405 to search for available information about the 460 network. For example, in one embodiment, the application Search engine 415 can be implemented as a network browser configured to view information available on the Internet. The user device 410 may also include one or more toolbar applications 420 which may be used, for example, to provide client-side processing to perform the desired tasks in response to operations selected by the user 405. In one mode, the toolbar application 420 can display a user interface in combination with the 415 search application.

The user device 410 may further include other applications 425 as may be desired in particular embodiments to provide the desired features to the user device 410. For example, other applications 425 may include security applications to implement client-side security features, programmatic client applications to interconnect with the appropriate application programming interfaces (APIs) over the 460 network, or other types of applications. The applications 425 may also include email, text, voice and IM applications that allow the user 405 to send and receive emails, calls, and texts through the 460 network, as well as applications that allow the user to make payments through the payment provider and create / control the purchase code feature as discussed above. The user device 410 includes one or more identifiers 430 which may be implemented, for example, as operating system registration entities, identification registers associated with the search application 415, identifiers associated with hardware of the user device 410, or other appropriate identifiers, such as used for payment / user / device authentication. In one embodiment, the user identifier 430 may be used by an associated user payment service provider 405 with a particular amount maintained by the payment provider as further described herein. A Communications application 422, with associated interfaces, allows user device 410 to communicate with merchant device 462 and payment provider server 470, as well as other devices within system 400.

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

The merchant device 462 may further include other applications 425 such as security applications for implementing the client-side security features, programmatic client applications for interconnection with the programming interfaces of the client. appropriate application (APIs) on the 460 network, or other types of applications. The applications 425 may also include e-mail, text, IM, and voice applications that allow a 406 merchant to communicate through the 460 network to make a purchase or refund. The merchant device 462 includes one or more user identifiers 430 which may be implemented, for example, as operating system registry entries, verification records associated with the searcher application 415, identifiers associated with merchant device hardware 462 , or other appropriate identifiers, such as those used for payment / user / device authentication, for example, the telephone number or device ID associated with the merchant device 462. Identifiers may be used by a merchant payment service provider. associated 406 with a particular account maintained by the payment service provider. Note that the merchant device 462 and / or the user device 410 may be simpler telephones (ie, not smart phones) capable of only communication and text, such as with the payment provider. Thus, complicated smart phones are not required to perform the transactions described herein.

The merchant server 440 can be maintained, for example, by a merchant or vendor by offering several products and / or services in exchange for the payment to be received on the network 460. The merchant server 440 can be located with or away from the device Merchant 462. Generally, merchant server 440 can be maintained by any or any entry that receives money, including donations as well as retailers. The merchant server 440 includes a database 445 identifying the available products and / or services (eg, collectively referred to as objects) which can be made available for observation and purchase by the user 405. As appropriate, the merchant server 440 also includes a shopping center application 450 which can be configured to serve information about the network 460 to the searcher 415 of the user device 410 and the merchant device 462. In one embodiment, the user 405 can interact with the center application of purchases 450 through the applications of the search engine on the 460 network to observe several products or services identified in the database 445. Note that the merchant server 440 may not be required in simpler systems, where sales and transactions they are made in a physical location.

The merchant server 440 also includes an outbound application 455 which can be configured to facilitate the purchase by the user 405 of products or services identified by the shopping center application 450. The outbound application 455 can be configured to accept information user payment 405 through the payment service provider server 470 over the network 460. For example, the outgoing application 455 can receive and process a payment confirmation from the 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) The exit application 455 can also be configured to accept one or more different payment options, including purchase codes.

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

The 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 financial and private information of users of devices such as account numbers, passwords, device identifiers, user names, teone numbers, credit card information, bank information, conditions of purchase code, or other financial information which can be used to facilitate online transactions by the user 405. Advantageously, the payment application 475 can be configured to interacting with the merchant server 440 on behalf of the user 405 during a transaction with the 455 exit application to track and manipulate purchases made by the users.

A transaction processing application 490, which may be part of or separate from the payment application 475, may be configured to receive information from a user device, merchant device, and / or merchant server 440 to process and store in a payment database 495. The transaction processing application 490 may include one or more applications to process information of the 405 user and / or merchant to process a payment or refund as described herein. The payment application 475 can be further configured to determine the existence of and to handle accounts for the 405 user and / or 406 merchant, as well as to create new accounts if necessary, such as configuration, administration, and use of credit codes. purchase.

Thus, system 400 allows user 405 to create a purchase or refund as described herein, both electronically and physically in person.

Fig. 5 is a block diagram of a computer system 500 suitable for being implemented in one or more embodiments of the present disclosure. In various implementations, the user device may comprise a personal computer device (e.g., a personal computer, mobile computer, smartphone, PDA, Bluetooth device, FOB keyboard, credential, etc.) capable of communicating with the network. The merchant and / or payment provider may use a network computing device (e.g., a network server) capable of communicating with the network. It should be appreciated that each of the devices used by users, merchants, and payment providers can be implemented as a computer system 500 in a manner as follows.

The computer system 500 includes a 502 bus or other communication mechanism to communicate information. The components include an input / output (I / O) component 504 that processes a user action, such as selecting keys of a numeric keypad / keyboard, selecting one or more buttons or links, etc., and sending a corresponding signal to the bus 502. The I / O component 504 may also include an output component, such as a screen 511 and a cursor control 513 (such as a keyboard, numeric keypad, mouse, etc.). An optional audio input / output component 505 can also be included to allow the user to enter information by converting audio signals. The audio I / O component 505 may allow the user to listen and transmit audio. A network transceiver or interface 506 transmits and receives signals between the computer system 500 and other devices, such as another user device, a merchant server, or a payment provider server via the 460 network. In one embodiment, the Transmission is wireless, although other means of transmission and methods may also be appropriate. A processor 512, which may be a microcontroller, digital signal processor (DSP), or other processing component, processes various signals, such as for deployment in the computer system 500 or transmission to other devices via a communication link 518 The processor 512 can also control the transmission of information, such as verification records or IP addresses, to other devices.

The components of the 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. The computer system 500 performs specific operations by the processor 512 and other components by executing one or more sequences of instructions contained in the memory component of the system 514. Logic may be encoded on a computer readable medium, which may refer to any means involved in providing instructions to processor 512 for execution. Said means may take any forms, including without limitation, 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 memory component of system 514, and transmission medium includes coaxial cables, copper wire, and optical fibers, including wires comprising the bus 502. In one embodiment, the logic is encoded in a readable medium in non-transient computer. In one example, the transmission medium can take the form of an acoustic wave or light, such as those generated during radio wave, optical and infrared data communications.

Some common forms of computer readable media include, for example, floppy disk, floppy disk, hard drive, magnetic tape, any other magnetic media, CD-ROM, any other optical media, punched cards, paper tape, any other physical media with patterns or holes, RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or cartridge, or any other means from which a computer is adapted for reading.

In various embodiments of the present disclosure, the execution of sequences of instructions for practicing the present disclosure can be performed by the computer system 500. In various other embodiments of the present disclosure, a plurality of computer systems 500 coupled by the link communication 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 telephone networks) can perform the sequences of instructions for practicing the present description in coordination with another.

Where applicable, the various embodiments provided by the present disclosure can be implemented using hardware, software or combinations of hardware and software. Also, in cases where applicable, the various hardware components and / or Software components set forth in the present description can be combined into composite components comprising software, hardware and / or both without departing from the scope of the present disclosure. Where applicable, the various hardware components and / or software components set forth in the present disclosure may be separated into subcomponents comprising software, hardware and / or both without departing from the scope of the present disclosure. In addition, in cases where it is applicable, it is contemplated that the software components can be implemented as hardware components and vice versa.

The software, in accordance with the present description, such as the program code and / or data, may be stored in one or more computer-readable media. It is also contemplated that the software identified herein may be implemented using one or more general-purpose or purpose-specific computers and / or computer systems, in a network and / or in another manner. Where applicable, the order of the various steps described in the present description can be changed, combined into composite steps, and / or separated into sub-steps to provide the features described herein.

The above description is not intended to limit the present description to the precise forms or particular fields of use described. In such a wayIt is contemplated that various alternative embodiments and / or modifications for the present invention, whether explicitly or implicitly described herein, are possible in the light of the description. With the embodiments of the present description described, those skilled in the art will recognize that changes can be made in form and detail without departing from the scope of the present disclosure. Accordingly, the present disclosure is limited only by the claims.

Claims (24)

1. NOVELTY OF THE INVENTION REVINDICATIONS 1. - A method for carrying out a financial transaction, comprising: receiving, by a processor of a payment provider, a request for purchase code from a user through a user device, wherein the purchase code request comprises an amount and a first user identifier; transmit a purchase code to the user if the authorization request is approved; receiving a purchase request from a beneficiary through a beneficiary device, wherein the purchase request comprises the purchase code, a second user identifier, and a beneficiary identifier; and transmit a message to the beneficiary if the purchase request is approved. 2. - The method according to claim 1, further characterized in that the purchase code expires after a predetermined period of time. 3. - The method according to claim 1, further characterized in that the purchase code expires after a number of predetermined uses. 4. - The method according to claim 3, further characterized in that the predetermined amount of uses is one. 5. - The method according to claim 1, further characterized in that the purchase code is presented to the beneficiary in person. 6. - The method according to claim 1, further characterized in that the user identifier is automatically transmitted with the purchase code request. 7 -. 7 - The method according to claim 6, further characterized in that the first user identifier comprises a telephone number of the user. 8. - The method according to claim 1, further characterized in that the identifier of the beneficiary is automatically transmitted with the purchase request. 9. - The method according to claim 8, further characterized in that the identifier of the beneficiary comprises a telephone number of the beneficiary. 10. - The method according to claim 1, further characterized in that the first and second user identifiers are the same. 1 . - The method according to claim 1, further characterized in that it further comprises transmitting a message to the user if the purchase request is approved. 12. - The method according to claim 1, further characterized in that the transmission and reception are through text. 13. - The method according to claim 1, further characterized by additionally comprising receiving information from the user to establish or modify the purchase code. 14. - The method according to claim 13, further characterized in that the received information comprises limitations and conditions for use of the purchase code by the user. 15. - A method for performing a financial transaction, comprising: receiving, by a processor from a payment provider, a request for reimbursement from a vendor, wherein the request for reimbursement comprises an amount, a vendor identifier, and a vendor identifier; consumer; determine, by the processor, whether the refund request is associated with a previous purchase by the consumer to the seller; pay to a consumer's account and charge to a seller's account with the amount if the refund request is approved; and transmit a message to the consumer if the refund request is approved. 16 -. 16 - The method according to claim 15, further characterized in that the identifiers of the seller and the consumer are telephone numbers. 17. - The method according to claim 15, further characterized in that the vendor identifier is automatically transmitted with the refund request. 18. - The method according to claim 15, further characterized in that the reception and transmission are by SMS 19. - A non-transient 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 request for purchase code from a user through a user device, wherein the request for the purchase code comprises an amount and a first user identifier; transmit a purchase code to the user if the authorization request is approved; receiving a purchase request from a beneficiary through a beneficiary device, wherein the purchase request comprises the purchase code, a second user identifier, and a beneficiary identifier; and transmit a message to the beneficiary if the purchase request is approved. 20. - The machine readable medium according to claim 19, wherein the first user identifier is automatically transmitted with the purchase code request. twenty-one . - The machine readable medium according to claim 19, further characterized in that the beneficiary identifier is automatically transmitted with the purchase request. 22. - The machine readable medium according to claim 19, further characterized in that transmission and reception are through text. 23. - The machine readable medium according to claim 19, further characterized in that the method additionally comprises receiving information from the user to establish or modify the purchase code. 24. - The machine-readable medium according to claim 23, further characterized in that the received information comprises limitations and conditions for use of the purchase code by the user.