Patent Application
20150324797
The present disclosure relates to the field of data processing, in particular, to apparatuses, methods and storage media associated with facilitating payments using phone numbers of payers.
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 perform non-cash payments. This is particularly true in cases where payees (such as vendors of 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 have a payment system available that can take non-cash payments, such as credit or debit cards. Additionally, payers may elect not to use physical cards for non-cash payments, and may instead wish for the ability to conduct payments without sharing either physical cards or sensitive information, such as credit card numbers. This can cause difficulty for payers to use non-cash payment methods, and can frustrate potential customers of 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 phone-number-based payments are described. In various embodiments, a phone-number-based payment system (PBP) may be configured to facilitate payments between parties based on a phone number for a payer party (the party making payment). That is, under the PBP of the present disclosure, the phone number, in addition to its original intended usage as a communication address, also doubles as the primary means for tendering payment, superseding the prior art credit, debit or checking account numbers. The PBP may be configured to receive a payment request for a payment to be made from the payer party to a payee party (the party receiving payment). In embodiments, the request may be sent from the payee party and may include a payment amount and the payer's phone number (or information that enables the payer's phone number to be determined). The request may also include additional identifying information of the first party. For example, a payee vendor may send a request to the PBP to request payment from a payer customer. The payment request may include a payment amount and a phone number for the customer. The payment request may further include other identifying information for the payer. In another example, the payer may send a request, to the PBP to initiate a payment to a payee. The payment request may include the payer's phone number, if it has not been otherwise previously provided to, and determinable by, the PBP. In various embodiments, the payment request may be sent via various means, including text-based messaging and/or requests made with dedicated payment applications.
In embodiments, in response to receipt of the payment request, the PBP may verify that the payee has an account with the PBP. If the payment request is from the payee, the PBP may also request an authorization of the payment from the payer. In various embodiments, the request for authorization may be performed via a messaging protocol, or may be performed via a dedicated payment application. In various embodiment, the payer may provide one or more authentication secrets to the PBP, such as a password, in order to authorize the requested payment or request a payment. In various embodiments, after receiving authorization for the payment (and authenticating the authorization), the PBP may facilitate the requested payment from the payer to the payee. In various embodiments, funds for the payment may be taken from various accounts of the payer, such as checking accounts, debit accounts, and/or credit accounts. In various embodiments, payment may be made to the payee, 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 payee. In some embodiments, the PBP itself may maintain accounts for the payer, and may make payment to the payee itself, without utilizing third-party payment entities; in such embodiments, the phone number of the payer may act as the primary (or sole) account number for the account held by the PBP.
In various embodiments, the phone-number-based payment techniques described herein may provide for easier conducting of payment between parties. For example, by providing facility for requesting a payment using a near-universally recognizable identifier, such as a phone number, the payer may be facilitated in making payments in a manner that is easier, and which may require less equipment, than by using more traditional credit card processing systems, which often requires the vendor to have elaborate credit card processing equipment, and pre-arrangement with credit card companies. Additionally, by allowing the use of a phone number to tender payments over commonly-used communication media, such as text messaging or mobile applications, the PBP may facilitate payment by not requiring special applications, hardware, or other equipment or resources than are commonly available to everyday payers and payees. Other benefits of the techniques described herein may be described below.
Referring now to
In various embodiments, a phone-number-based payment system 100 (PBP 100) may be configured to communicate with a payee device 150 and/or a payer device 160 to facilitate payment between a respective payee and payer associated with the devices. The payee device 150, payer device 160, and/or PBP 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, the payee device 150 may include various devices configured to facilitate transactions, such as, for example, point-of-sale devices, cash registers, etc. In other examples, the payee device may include a device configured to also facilitate traditional payment via a credit or debit card, such as a dedicated card reader, or a mobile device executing a credit/debit card payment application. Such devices may be used, in various embodiments, even the PBP 100 facilitates payments through the use of telephone numbers, without requiring use of a credit or debit card. In various embodiments, such a device may nonetheless be equipped with a card reader to provide the payee the ability to accept a credit/debit card to for payment in the traditional manner. In other words, PBP 100 may co-exist with current payment methods. In embodiments, the traditional methods may handle the larger payments requiring higher level of security, while PBP 100 may handle the smaller payments requiring lower level of security, but higher ease-of-use. In various embodiments, payment may be requested in following a transaction that has been performed between the payee and the payer. While this is illustrated, for the sake of convenience in the
In various embodiments, the payment request, as well as other communication associated with the techniques described herein, may be sent and received by respective payment application 155 (on the payee device 150) and payment application 165 (on the payer device 160) and/or a communication interface 105 of the PBP 100. In other embodiments, other applications or services, such as text messaging services, may be used to perform communication between the payee device 150, payer device 160, and the PBP 100; in some such embodiments, a messaging carrier (not illustrated) may be configured to communicate with payee device 150, payer device 160, and the PBP 100 to mediate messages. 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 communication interface 105 may be configured to facilitate communication via these protocols. In such embodiments, the messaging carrier may include a wireless telephony carrier and the communication address may be a phone number for the payee, payer, or PBP 100. In other embodiments, the payment application 155, and/or payment application 165 may be configured to mediate messages sent over a different protocol, such as iMessage™, or via a non-messaging protocol; the communication interface 105 may similarly be configured to facilitate communication over these communication protocols.
In various embodiments, the PBP 100 may be configured to receive a payment request from the payment application 155 of the payee device 150. In various embodiments, the payment request may include a payment amount, as well as a phone number of the payer (or information enabling the phone number of the payer to be determined). The payment request, as described earlier, may also include identifying information for the payer. In other embodiments, the request may also include identifying information of the payee, such as, for example the payee's name, email address, physical address, etc (especially, if this information is not known to PBP 100.
In various embodiments, the PBP 100 may be configured, in response to receipt of the payment request from the payee, to request authorization of the payment from the payer. This authorization request may, in various embodiments, be sent to the payment application 165 of the payer device 160. In embodiments, PBP 100 may also authenticate the person giving the authorization, such as by requesting a password or a PIN. On authenticating the person providing the authentication, the PBP 100 may be configured to then send confirmation of the payment to the payee, such as at the payment application 155 of the payee device 150. Likewise, in embodiments, PBP 100 may also authenticate a payer requesting payment to a payee.
In various embodiments, the PBP 100 may be configured, in response to receive of the payment request and an authenticated payment authorization, to facilitate issuance of payment from the payer to the payee. In various embodiments, the PBP 100 may include an account storage 110 (AS 110), which may be configured to store information about various persons, including, but not limited to, payees who may be paid and/or payers who may pay. In various embodiments, the AS 110 may be located internally or externally to the PBP 100, and may include various techniques and implementations, as may be understood. In various embodiments, the AS 110 may include information about a payee, such as communication address/phone number information for the payee device 150 (such as to identify a payee 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 payer, such as a phone number associated with the payer through which the payer may use to tender a payment, and secrets which the payer may use to be authorize a payment or authenticate its payment request. The AS 110 may also include communication address information for the payer device 160 (such as to identify a payer from a payment request), debit or credit account information, etc.
In other embodiments, the AS 110 may include information for a payment account held by the PBP 100 itself (or an entity associated with the PBP 100, such as a bank 180). For example, the payer may create an account, such as a credit or checking account, with a bank 180 associated with the PBP 100. The PBP 100 may thereafter utilize the phone number of the payer as the primary (or even sole) account number for the created account. Such usage may facilitate a bank in providing payment options to a payer without requiring the creation or sharing of additional account information, such as credit, debit, or checking account numbers.
In various embodiments, the PBP 100 may include one or more modules for performing techniques described herein. in various embodiments, the PBP 100 may include a request/authorization module 120 (RA 120), which may be configured to respond to receipt of a payment request from the payment application 155 of the payee device 150 to initiate a payment process, as well as to report back to the payee 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 payer (including authentication), such as through requesting authorization from the payer via the payment application 165 of the payer device 160 and to receive authorization and authentication in response. Techniques for conducting payment request receipt and authorization (including authentication) may be described below.
In various embodiments, the PBP 100 may include a payment facilitation module 130 (“PF 130”). In various embodiments, the PF 130 may be configured to interact with one or more payment entities, such as a credit card system 170, a bank 180, or other payment servicer 190, to cause funds to be transferred between accounts associated with the payer and the payee. In various embodiments, the PF 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 PF 130 may be configured to perform debit and or credit itself, in particular if the account being debited or credited is held by the AS 110 of the PBP 100. Particular techniques for facilitating payment may be described below.
Referring now to
Next, at operation 230, the RA 120 may receive a payment request. For example, the payee, such as a vendor, may send a text message to the PBP 100 using the payment application 155 of the payee device 150, which may be received and processed by the RA 120. In another example, a payer may send a text message to the PBP 100 using the payment application 165 of the payer device 160, 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 PBP 100 may request confirmation of payment. The request may include authentication of the payer giving the authorization. For example, the RA 120 may send an authorization request to the payment application 165 of the payer device 160. Particular examples of operation 240 may be described below with reference to process 500 of
Next, at operation 250, the PF 130 may facilitate the authenticated authorized payment. For example, the PF 130 may confirm the existence of funds in an account of the payer and/or may cause a debit and credit of funds between accounts of the payer and payee. In some embodiments, the payment may be made by requesting debit and credit from accounts maintained separately from the PBP 100. In other embodiments, such as when the PBP 100 itself maintains accounts for the payer, the PBP 100 may perform debit and/or credit of accounts it holds internally. Various methods of facilitating or performing payments may be understood by those of skill in the art. Next, at operation 260, the PF 130 (or other module of the PBP 100) may confirm the performance of the payment with the payer and/or the payee. Process 200 may then end.
Referring now to
Next, at operation 320, the payer may register payment information and/or preferences with the PBP 100. For example, the payer may register payment information such as such as credit/debit card account number, checking account number, etc. In other embodiments, at operation 320, the payer may register payment preferences. For example, the payer may register a payment threshold over which an authorization request may be required for payment—below this threshold the PBP 100 may facilitate payments based solely or primarily on receipt of a phone number associated with the payer without requiring additional authorization. In other embodiments, the payer may register a preference that a payment above (or below) a predetermined amount should be made from a particular account. In other embodiments, rather than register account information, the payer may request an account from the PBP 100, such as when the PBP 100 acts as (or is associated with) a bank 180. In such embodiments, the account created may be registered with the PBP 100 and referred to by the payer using the payer's (previously registered) phone number. In various embodiments, this phone number may act as the primary account number for the account with relation to payment performance using the account. After registration of identifying information, payment information and preferences, at operation 330, the AS 110 may create an account for the payer (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 may also include other identifying information for the payer, such as address information, name information, or information identifying communication addresses for the payer. In addition to the payment amount and identifying information, in some embodiments (e.g., the payee has not registered with PBP 100 or wishes to override some of the registered information), the payee may include in the payment request additional data that facilitates issuance of the payment. For example, in some embodiments, the payee may include an indication of a preferred method of payment and/or an account at which the payee wishes to receive payment. In other embodiments, the payee may include a password, or other proof of identity, in order to avoid fraudulent payments being made to the payee's account. In yet other embodiments, the payment request may not include identifying information and may only include a payment amount. In such embodiments, a second request may be sent for a phone number associated with the payer, along with other identifying information as well.
Next, after the payee creates the payment request, the payee may send the created payment request message to the PBP 100. In various embodiments, the payment request may be sent via messaging protocol, such as in a text message to be sent via SMS or MMS; such a message may include only text, or may include additional audio, video, and or images. In other embodiments, the payment request may not take the form of a message, but may be sent via other means using the payment application 155, such as, for example using an API or other interface supported by the PBP 100 through which payment requests may be made. Next, at operation 430, the payment request message may be received by the PBP 100.
After receiving the payment request message, at operation 440, the PBP 100, and in particular the RA 120, may confirm that the payer has an account registered with the AS 110 of the PBP 100. In various embodiments, at operation 450, the RA 120 may confirm that the payer has an account based on the phone number of the payer and other identifying information received in the payment request message. For example, the RA 120 may further determine whether there is indeed an account associated with the phone number based on the other identifying information, such as name, address, communication address. The RA 120 may utilize this identifying information to definitively confirm that the payer has an account registered with the PBP 100. In yet other embodiments, if no identifying information is provided during the initial payment request, the RA may be configured to confirm that the payer has an account at a later time, such as during an authorization action, described below. After operation 440, the process may end.
As discussed above, in alternative embodiments, the payment request may be created by the payer and sent from the payer device 160. In such embodiments, the payment request may include authentication information confirming that the payment request is indeed coming from the registered payer. Other embodiments described herein may operate in similar manners to those described herein while operating based on the payer-generated payment request.
Referring now to
In either event, whether a phone number was originally provided in the payment request or not, the process may continue to decision operation 525, where the RA 120 may determine whether authorization for the payment is needed. In some embodiments, if the payer has previously indicated that authorization is needed only for payments over a certain amount or of a certain type, then the RA 120 may determine whether authorization is needed at decision operation 525 based on this information. In other embodiments, the RA 120 may require authorization for any payment, for no payment, or for any payment by particular payers or to particular payees. In yet other embodiments, if a phone number was requested at operation 510 and received from the payer at operation 520, on authentication, the RA 120 may consider the payment to be authorized and may not require further authorization at decision operation 525.
If no authorization is required, the process may end after decision operation 525. If, however, authorization is determined to be needed, then at operation 530, the RA 120 may create and send an authorization request to the payer, such as through a message, API call, or other communication with the payment application 165. At operation 540, the RA may receive an authorization. In various embodiments, the authorization received may include authentication data indicating that an authorization was performed by the payer, such as by replying with a particular word, password, PIN, or message, or by performing a signature using the payer device 160. The process may then end.
Referring now to
If, however, no phone number was input, then at operation 620, the payment application 155 or 165 may send a payment request to the PBP 100 that does not include a phone number associated with the payer. Next, at operation 630, the payment application 155 or 165 may receive a request from the PBP 100 for a phone number associated with the payer. After receiving the request, at operation 640, the payment application 155 or 165 may request and receive an input of a phone number associated with the payer from the payer or payee. In some embodiments, operations 620 and 630 may not be performed and instead the payment application 155 or 165 may automatically request the phone number from the payer or payee upon the payer or payee attempting to send a payment request. After receiving the phone number, at operation 650, the payment application 155 or 165 may send a payment request, including the phone number, to the PBP 100. The process may then end. In other words, the payment request made be made in one or multiple communication exchanges to provide the payment amount, the phone number of the payer, and optionally, other information.
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.
