Patent Application
20150324790
The present disclosure relates to the field of data processing, in particular, to apparatuses, methods and storage media associated with facilitating payments through messaging.
The background description provided herein is for the purpose of generally presenting the context of the disclosure. Unless otherwise indicated herein, the materials described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Parties engage in financial transactions, and in particular transactions involving payment, every day. However, it is sometimes difficult for paid parties to easily accept non-cash payments. This is particularly true in cases where vendors (for goods and/or services) do not have resources easily at hand for taking such non-cash payments. For example, a vendor that sells goods only occasionally, such as at a farmer's market or flea market, may not need to want to contract with a credit card processor, and to pay attendant processor fees, when the vendor does not have a constant use for the processing service. Additionally, vendors may not have equal access to credit/debit/checking accounts to facilitate interaction with traditional credit or debit processing techniques. This can cause difficulty for vendors to accept non-cash payments, and can likewise frustrate potential customers that may wish to make non-cash payments with these vendors.
Embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals designate like structural elements. Embodiments are illustrated by way of example, and not by way of limitation, in the Figures of the accompanying drawings.
In the following detailed description, reference is made to the accompanying drawings which form a part hereof wherein like numerals designate like parts throughout, and in which is shown by way of illustration embodiments that may be practiced. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure. Therefore, the following detailed description is not to be taken in a limiting sense, and the scope of embodiments is defined by the appended claims and their equivalents.
Various operations may be described as multiple discrete actions or operations in turn, in a manner that is most helpful in understanding the claimed subject matter. However, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations may not be performed in the order of presentation. Operations described may be performed in a different order than the described embodiment. Various additional operations may be performed and/or described operations may be omitted in additional embodiments.
For the purposes of the present disclosure, the phrase “A and/or B” means (A), (B), or (A and B). For the purposes of the present disclosure, the phrase “A, B, and/or C” means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B and C).
The description may use the phrases “in an embodiment,” or “in embodiments,” which may each refer to one or more of the same or different embodiments. Furthermore, the terms “comprising,” “including,” “having,” and the like, as used with respect to embodiments of the present disclosure, are synonymous.
As used herein, the term “logic” and “module” may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality. The term “messaging” as used herein may include instant messaging, personal messaging, text messaging, email, and so forth. Text messages may include messages sent using, e.g., short messaging service (SMS), or messages containing image, video, and sound content, e.g., multi-media messaging service (MMS).
In various embodiments, methods, systems, apparatuses, devices, and computer-readable media directed to messaging-based payments are described. In various embodiments, a messaging-based payment system (MBP) may be configured to facilitate payments between parties based via a messaging protocol, such as a text messaging protocol. The MBP may be configured to receive a request via the messaging protocol for a payment to be made from a first party to a second party. The request may be sent from the second party (the party receiving payment) and may include a payment amount as well as identifying information for the first party (the party making payment). For example, a vendor may send a text message to the MBP to request payment from a customer. The text message may include a payment amount, a credit card number, and a phone number for the customer. In other examples, the text message may include only the payment amount and the credit card number of the customer, or only the payment amount and the phone number of the customer. In another example, the customer may send a text message to the MBP to initiate a payment to a vendor.
In response to receipt of the request for payment, the MBP may verify that the requesting party (for example, the vendor) has an account with the MBP. The MBP may also request an authorization of the payment from the first party. In various embodiments, the request for authorization may be performed via the messaging protocol (or another messaging protocol) as used in the request for payment. In various embodiments, after receiving authorization for the payment, the MBP may facilitate the requested payment from the first party to the second party. In various embodiments, funds for the payment may be taken from various accounts of the first party, such as checking accounts, debit accounts, and/or credit accounts. In various embodiments, payment may be made to the second party, such as to an account of the second party. In some embodiments, payment may be made through a payment facilitator, such as a wire payment service, which may be facilitated in generating a check or other wire payment to the second party. In various embodiments, multiple payments may be held and delivered once an issuance threshold, such as a time- or amount-based threshold is reached.
In various embodiments, the messaging-based payment techniques described herein may provide for easier conducting of transaction between parties. For example, by providing facility for requesting a payment through a frequently available interface, such as messaging, the second party may be facilitated in receiving payments in a manner that is easier and/or cheaper than by using more traditional credit card processing systems. Additionally, by utilizing messaging for both request and authorization, the MBP may facilitate payment by not requiring special applications, hardware, or other equipment or resources than are commonly available to vendors and customers. Finally, by providing for payment through payment facilitators, such as wire payment services, a vendor may be allowed to receive payments without enforcing a requirement that the vendor utilize a checking or other account for payment receipt. Other benefits of the techniques described herein may be described below.
Referring now to
In various embodiments, a messaging-based payment system 100 (MBP 100) may be configured to communicate with a vendor device 150 and a customer device 160 via one or more messaging protocols. In various embodiments, the vendor device 150, customer device 160, and/or MBP 100 may include one or more computing devices and/or computing systems, including desktop computers, laptop computers, mobile phones, tablet computers, and/or other mobile or non-mobile devices. In various embodiments, payment may be requested in following a transaction that has been performed between the vendor and the customer. While this is illustrated, for the sake of convenience in the
In various embodiments, the communication may sent and received by respective vendor messaging application 155 and customer messaging application 165 and/or a messaging interface 105 of the MBP 100. In various embodiments, a messaging carrier 170 may be configured to communicate with the vendor messaging application 155 and customer messaging application 165 and/or a messaging interface 105 to mediate messages. Such messaging may be performed with reference to a communication address for a party being messaged (such as a vendor, customer, or the MBP 100 itself). For example, in various embodiments, one or more communications may be performed via a text messaging protocol, such as a short message service (SMS) or multimedia messaging service (MMS). In such embodiments, the messaging carrier may include a wireless telephony carrier and the communication address may be a phone number for the vendor, customer, or MBP 100. In other embodiments, the vendor messaging application 155, customer messaging application 165, and/or messaging carrier 170 may be configured to mediate messages sent over a different messaging protocol, such as iMessage™.
In various embodiments, the MBP 100 may be configured to receive a payment request from the vendor messaging application 155 of the vendor device. In various embodiments, the payment request may be sent from the VMA 155 of the vendor device 150 via a messaging protocol mediated by the messaging carrier 170. In various embodiments, the payment request may include a payment amount, as well as identifying information for the customer, such as credit card, debit, or checking account information and/or a phone number for the customer. In various embodiments, the MBP 100 may be configured, in response to receipt of the request, to request authorization of the payment from the customer. This authorization request may, in various embodiments, be sent to the CMA 165 of the customer device 160 via a messaging protocol mediated by the messaging carrier 170. The MBP 100 may be configured to then send confirmation of the payment to the vendor, such as through another message using a messaging protocol.
In various embodiments, the MBP 100 may additionally or alternatively be configured to receive an authorization message from the CMA 165 of the customer device 160, and, in response to facilitate issuance of payment from the customer to the vendor. While many of the examples provided herein are provided with reference to a request made from the vendor, using the vendor device 150, it may be recognized that payment requests may be made by the customer from the customer device 160 in many embodiments.
In various embodiments, the MBP 100 may include an account storage 110 (AS 110), which may be configured to store information about various persons, including, but not limited to, vendors who may be paid and customers who may pay. In various embodiments, the AS 110 may be located internally or externally to the MBP 100, and may include various techniques and implementations, as may be understood. In various embodiments, the AS 110 may include information about a vendor, such as communication address/phone number information for the vendor device 150 (such as to identify a vendor when receiving a payment request), debit or credit account information, payment service information, etc. In various embodiments, the AS 110 may also include information about a customer, such as communication address/phone number information for the customer device 160 (such as to identify a customer from a payment request), debit or credit account information, etc. Additionally, in some embodiments, the AS 110 may be configured to hold information about accounts internal to the MBP 100. For example, as described below, in some circumstances, payments may be held until a particular issuance threshold is reached. In such embodiments, the AS 110 may be configured to hold one or more held amounts for a vendor until time is reached to make a payment. Additionally, in various embodiments, the AS 110 may also be configured to perform account setup operations, such as those described below.
In various embodiments, the MBP 100 may include one or more modules for performing techniques described herein. in various embodiments, the MBP 100 may include a request/authorization module 120 (RA 120), which may be configured to respond to receipt of a payment request from the VMA 155 of the vendor device 150 to initiate a payment process and to report back to the vendor with a payment confirmation when the payment is complete. The RA 120 may also be configured, in various embodiments, to request authorization of a payment from a customer, such as through messaging to the customer via the CMA 165 of the customer device 160 and to receive an authorization message in response. Techniques for conducting payment request receipt and authorization may be described below.
In various embodiments, the MBP 100 may include a payment issuance module 130 (PI 130). In various embodiments, the PI 130 may be configured to interact with one or more payment entities, such as a credit card system 170, a bank 180, and or a payment servicer 190. In various embodiments, the PI 130 may be configured to request debit and/or credit of one or more accounts, such as debit accounts, credit accounts, checking accounts, savings accounts, etc., which may be controlled by one or more of the credit card system 170 and/or bank 180. In other embodiments, the PI 130 may be configured to request the generation of a payment from a payment servicer 190. In various embodiments, payment servicers may include wire transfer entities, such as Western Union™, or other servicers. In some embodiments, payment servicers may be utilized when credit or other accounts are not available to or desired by the vendor. in such embodiments, the PI 130 may direct the generation of a check or cash payment from the payment service. In some embodiments, the check or cash payment may be generated in response to each payment request from the vendor or may be performed on a less frequent basis, such. For example, payment generation may be request when a particular time-based issuance threshold has been reached (for example at the end of a day or a week) or when a particular amount has been requested (for example, once $300 in total payments has been reached for the vendor). Particular techniques for issuing payment may be described below.
Referring now to
Next, at operation 230, the RA 120 may receive a payment request from the vendor. For example, the vendor may send a text message to the MBP 100 using the VMA 155 of the vendor device 150, which may be received and processed by the RA 120. Particular examples of operation 230 may be described below with reference to process 400 of
Next, at operation 240, the RA 120 of the MBP 100 may request authorization of the payment from the customer. For example, the RA 120 may send a text message requesting authorization of the payment to the CMA 165 of the customer device 160. Particular examples of operation 240 may be described below with reference to process 500 of
Referring now to
Next, at operation 320, the vendor may register one or more methods by which the vendor may receive payment. For example, in some embodiments, the vendor may register financial account information, such as credit, debit, checking, and/or savings account information where the vendor may receive payments. In other embodiments, the vendor may register a preference to receive payments at a payment servicer, such as a wire transfer entity. In some embodiments, the vendor may register a particular servicer, such as one that is physically located in a convenient location.
In some embodiments, the vendor may also provide payment preferences at operation 320. For example, the vendor may register a preference that a payment above (or below) a predetermined amount should be made to a particular account. In other embodiments, at operation 320 the vendor may register a preference of when payment should be made from a payment servicer. For example, in some embodiments, the vendor may tell the MBP 100 to only cause issuance of a payment at the end of a work day (so the vendor can go to the servicer and receive a day's worth of payments at the end of the day). In another example, the vendor may tell the MBP 100 to only cause issuance of a payment when a particular total amount of payments has been received. This total amount may, in some embodiments, be calculated over multiple payments, and even over multiple customers. After registration of payment methods/account information, and/or payment preferences, at operation 330, the AS 110 may create an account for the vendor (or update an account if the account had previously been created). The process may then end.
It may be noted that, in the example of
Referring now to
In various embodiments, the payment request message may include a payment amount for the requested payment. In various embodiments, the payment request message may also include identifying information for the customer from which payment is requested. For example, in some embodiments, the identifying information may include a credit card number for the customer (such as a credit card physically presented to the vendor as part of the transaction). In another example, the identifying information may include a phone number for the customer.
In addition to the payment amount and identifying information, in some embodiments, the vendor may include in the payment request message additional data that facilitates issuance of the payment. For example, in some embodiments, the vendor may include an indication of a preferred method of payment and/or an account at which the vendor wishes to receive payment. In other embodiments, the vendor may include a password, or other proof of identity, in order to avoid fraudulent payments being made to the vendor's account.
Next, after the vendor creates the payment request message, the vendor may send the created payment request message to the MBP 100 via the messaging protocol. In various embodiments, the vendor may have knowledge of a phone number or other communication address of the MBP 100 in order to send the payment request message. Next, at operation 430, the payment request message may be forwarded to the MBP 100 by the messaging carrier 170, and the MBP 100 (and in particular the messaging interface 105) and the MBP 100 may receive the payment request message at operation 440.
After receiving the payment request message, at operation 450, the MBP 100, and in particular RA 120, may confirm that the vendor has an account registered with the AS 110 of the MBP 100. In various embodiments, at operation 450, the RA 120 may confirm that the vendor has an account based on information received in the payment request message. In some embodiments, the RA 120 may be configured to look up an account for the vendor based on a phone number or other commination address of the vendor. For example, if the vendor sends a payment request message as a text message, the RA 120 may confirm the vendor account based on the phone number from which the payment request message was sent. In other embodiments, the RA 120 may confirm an account for the vendor based on security information, such as a password provided by the vendor in the payment request message. After issuance of operation 450, the process may end.
As discussed above, in alternative embodiments, the payment request may be created by the customer and sent from the customer device 160. In such embodiments, the payment request may include identifying information about the vendor, rather than about the customer, as well as payment information, such as the customer's credit card number. Other embodiments described herein may operate in similar manners to those described herein while operating based on the customer-generate payment request.
Referring now to
Next, at operation 520, the RA 120 may create and send an authorization message to the customer requesting authorization of the requested payment. In various embodiments, the RA 120 may send the message to the phone number or communication address that was received in the payment request message (or known to the AS 110 and confirmed at operation 510). In various embodiments, the authorization message may include information regarding the requested payment, such as, for example, payment amount, vendor identity, transaction information, etc. in order that the customer may understand the payment request and provide informed authorization. In other embodiments, the authorization message may also include instructions for replying to the authorization message, such as instructions that the customer may reply with a particular command (e.g., “Authorized” or “Pay”) in order to authorize the requested payment.
Next, at operation 530, the customer may reply to the authorization message to authorize the requested payment. In various embodiments, the customer may reply per instructions provided in the authorization message. In various embodiments, the reply may be made to the communication address from which the authorization message was sent (e.g., a communication address for the MBP 100). Next, at operation 540, the messaging interface 105 of the MBP 100 may receive the reply. At operation 550, the RA 120 may check that the reply is from the same communication address to which the authorization message was originally sent. In various embodiments, the check at operation 550 may help provide security to the customer by better ensuring that authorization for the payment is not faked by another party, such as the vendor. After operation 550, the process may then end.
Referring now to
If, however, the vendor has indicated that he or she would like issuance of cash or a check, then at operation 630, the PI 130 may add an amount to an internal customer account. In various embodiments, the amount added to the internal customer account may be less than the amount requested, such that the difference may be kept by an entity associated with the MBP 100 as a processing fee. In another embodiment the entire amount requested in the payment request may be added at operation 630.
Next, at decision operation 635, the PI 130 may determine whether a payment issuance threshold (hereinafter, issuance threshold or threshold) has yet been reached. As discussed above, in various embodiments, payments may not be issued until a time- or amount-based threshold has been reached. If the issuance threshold has not yet been reached, then the process may end (and the payment issued at a later time). If, however, the threshold has been reached, then at operation 640, the PI 130 may cause a payment servicer 190 to issue payment to the vendor. The process may then end.
Referring now to
Each of these elements may perform its conventional functions known in the art. In particular, system memory 704 and mass storage devices 706 may be employed to store a working copy and a permanent copy of the programming instructions implementing the modules shown in
The permanent copy of the programming instructions may be placed into permanent storage devices 706 in the factory, or in the field, through, for example, a distribution medium (not shown), such as a compact disc (CD), or through communication interface 710 (from a distribution server (not shown)). That is, one or more distribution media having an implementation of the agent program may be employed to distribute the agent and program various computing devices. In embodiments, the programming instructions may be stored in one or more computer readable non-transitory storage media. In other embodiments, the programming instructions may be encoded in transitory storage media, such as signals.
The number, capability and/or capacity of these elements 710-712 may vary. Their constitutions are otherwise known, and accordingly will not be further described.
Although certain embodiments have been illustrated and described herein for purposes of description, a wide variety of alternate and/or equivalent embodiments or implementations calculated to achieve the same purposes may be substituted for the embodiments shown and described without departing from the scope of the present disclosure. This application is intended to cover any adaptations or variations of the embodiments discussed herein. Therefore, it is manifestly intended that embodiments described herein be limited only by the claims.
Where the disclosure recites “a” or “a first” element or the equivalent thereof, such disclosure includes one or more such elements, neither requiring nor excluding two or more such elements. Further, ordinal indicators (e.g., first, second or third) for identified elements are used to distinguish between the elements, and do not indicate or imply a required or limited number of such elements, nor do they indicate a particular position or order of such elements unless otherwise specifically stated.
