Patent Application
20150324778
The present disclosure relates to the field of data processing, in particular, to apparatuses, methods and storage media associated with facilitating authorization of payments through use of phone numbers.
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 parties to easily utilize non-cash payments. In particular, parties may wish to obtain authorization for non-cash payments before completing a transaction. For example, if a vendor is transacting to sell an expensive good to a customer, the vendor may wish to obtain surety that the customer has adequate credit or account funds to pay for the good. However, obtaining such authorization may difficult, and frequently requires the use of credit or account information, such as a credit card or checking account number (or even possession of the physical credit card itself). However, the customer may be uninterested or unwilling to provide sensitive information to a vendor, or may not have such information readily available when conducting the transaction. As such, obtaining authorization may be difficult or impossible using current techniques.
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 payment authorization are described. In various embodiments, a phone-number-based payment authorization system (PBA) may be configured to authorize payments from a payer party (the party making payment) to a payee party (the party receiving payment) based on a phone number of a payer party. The PBA may be configured to receive a payment authorization request for a payment to be made from the payer party to a payee party. The payment authorization request may be sent, in various embodiments, from the payee party or the payer. The payment authorization request may include a payment amount as well as a phone number for the payer party. For example, a payee vendor may send a request to the PBA to request payment authorization for payer customer to make a payment of a particular amount for the sale of goods or services. In various embodiments, the payment authorization request may be sent via various means, including a text message sent via a messaging protocol, an email, one or more application programming interface (“API”) calls, and/or other communication techniques.
In response to receipt of the payment authorization request, the PBA may be configured, in various embodiments, make a determination of whether the payer is capable of making a payment of the requested amount. The determination may include determination of payment capabilities from various payment servicers, such as credit card servicers, banks, etc. In other embodiments, the PBA may be configured to make an authorization request from a third-party authorizing entity. In various embodiments, the PBA may be facilitated in making this authorization request based on identifying and/or financial information known to the PBA.
In various embodiments, the phone-number-based payment authorization techniques described herein may provide for easier conducting of payment between parties, while protecting sensitive information of the payer. For example, by providing facility for requesting a payment authorization using a near-universally recognizable identifier, such as a phone number, the payer and/or payee may be facilitated in performing transactions in a manner that is easier, and which may require less equipment, than by using more traditional authorization techniques, such as check-based or credit-card-based authorization systems. Additionally, by allowing the use of a phone number to facilitate payments over commonly-used communication media, such as text messaging or mobile applications, the PBA may facilitate payment by not requiring special applications, hardware, or other equipment or resources to authorize payment than are commonly available to everyday payers and payees. At the same, sensitive financial information of the payer party, such as his/her credit/debit card or checking account information may be protected, and reduce the risk of fraud. Other benefits of the techniques described herein may be described below.
Referring now to
In various embodiments, a phone-number-based payment system 100 (PBA 100) may be configured to communicate with a payee device 155 and/or a payer device 165 to facilitate payment between a respective payee 150 and payer 160 associated, respectively, with the devices. The payee device 155, payer device 165, and/or PBA 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 155 and/or payer device 165 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 155 may include a device configured to facilitate 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 in scenarios where the PBA 100 facilitates payment authorization without requiring use of a credit or debit card. In various embodiments, payment may be requested in support of a transaction that has been performed between the payee 150 and the payer 160.
In various embodiments, the payment authorization request, as well as other communication associated with the techniques described herein, may be sent and received communication interface 105 of the PBA 100. As discussed above, in various embodiments, these communications may be facilitated at the payee device 155 and/or payee device 165 using various means, such as messaging via a text messaging application using a text messaging protocol, such as a short message service (SMS) or multimedia messaging service (MMS). In some such embodiments, a messaging carrier (not illustrated) may be configured to communicate with payee device 155, payer device 165, and the PBA 100 to mediate messages. In other embodiments, these communications may be facilitated using dedicated payment authorization applications (not illustrated) at the payee device 155 and/or the payer device 165.
In various embodiments, the PBA 100 may be configured to receive a payment authorization request from the payee device 155. In various embodiments, the payment authorization request may include a payment amount, as well as a phone number identifying the payer. In some embodiments, the payment authorization request may include identifying information other than a phone number for the payer, such as, for example the payer's name, email address, physical address, etc. In some embodiments, the payment authorization request may also include information about the payee and/or the transaction for which payment authorization is being requested, such as, for example, transaction type, a description of goods or services associated with the payment authorization, payment terms, etc.
In various embodiments, the PBA 100 may be configured, in response to receipt of the payment authorization request from the payee device 155 or the payer device 165, to determine whether the payer 160 may make the payment for which the request was made. The PBA 100 may be configured to then send confirmation of the authorization to the payee 150, such as at the payee device 155. In some embodiments, the PBA 100 may be configured to reply to the payment authorization request with a confirmation code that indicates that the requested payment is authorized. In such embodiments, this confirmation code may be given from the requesting party (such as the payer) to the requesting party (such as the payee) in order that the payee may then confirm the requested authorization with the PBA 100 using the confirmation code itself. In various embodiments, the payee 150 may use the received confirmation to then request payment from the payer 160.
In various embodiments, the PBA 100 may include one or more modules for performing techniques described herein. In various embodiments, the PBA 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 payers who may pay. In various embodiments, the AS 110 may be located internally or externally to the PBA 100, and may include various techniques and implementations, as may be understood. In various embodiments, the AS 110 may include phone number information for the payer 160; the phone number information may be the phone number of the payer device 165. In other embodiments, the AS 110 may include financial information for the payer 160, such as debit or credit account information, payment service information, financial history information, etc. In various embodiments, the AS 110 may also include identifying information for the payer 160; this information may be utilized, in some embodiments, in facilitating use of a third-party authorization entity to make payment authorization determinations for the PBA 100. In various embodiments, the AS 110 may also include information about a payee 150, such as a communication address through which the payee may be identified and/or communicated with; this communication address may be associated with the payee device 155.
In various embodiments, the PBA 100 may include an authorization determination module 120 (AD 120), which may be configured to respond to receipt of a payment request from the payment application 155 of the payee device 155 to initiate a payment process, as well as to report back to the payee with a payment confirmation when the payment is complete. The AD 120 may also be configured, in various embodiments, to receive a payment authorization request with a payment amount from the payee 150 or payer 160, and to make a determination of whether the payer 160 may make the payment. In various embodiments, the AD 120 may be configured to make a determination by requesting a determination from a third-party authorizing entity 180. In other embodiments, the AD 120 may be configured to make a determination based on information that is available to the AD 120. In various embodiments, the AD 120 and/or third-party authorizing entity 180 may be configured to make determinations for authorization determination based on information obtained from various entities. Examples of such entities include the payer 160 itself, one or more banks 190, one or more credit card servicers 193, and one or more credit reporting agencies 195. Particular examples of determination for authorization of payments are described below.
Referring now to
Next, at operation 230, the AD 120 may receive a payment authorization request from the payee 150 or payer 160. For example, the payee 150 may send a text message to the PBA 100 using the payee device 155, which may be received and processed by the AD 120. Particular examples of operation 230 may be described below with reference to process 400 of
Next, at operation 240, the AD 120 of the PBA 100 may determine whether payment is authorized for the payer 160. Particular examples of operation 240 may be described below with reference to process 500 of
Referring now to
Next, at operation 340, the PBA 100 may register financial history information for the payer 160. For example, the payer 160 may provide one or more credit reports from credit reporting agencies that have financial history information for the payer 160. In other embodiments, the payer 160 may manually register financial history information on an account-by-account, or event-by-event basis. Next, at operation 360, an account may be created for the payer 160. Thereafter, the process may then end.
Referring now to
Next, at operation 440, the payee 150 may generate a payment authorization request that may include the payment amount and the previously obtained phone number for the payer 160. In various embodiments, to generate the request, the payee 150 may generate a message, such as a text message, with the phone number and payment amount information (as well as account information in some scenarios). In other embodiments, the payee 150 may utilize a dedicate application on the payee device 155 to generate the payment authorization request. Next, at operation 450, the payee 150 may send the payment authorization request to the PBA 100, such as by sending the generated text to the PBA 100, or by submitting the request through a dedicated application. The process may then end.
Referring now to
Next, the AD 120 may obtain account and/or history information for the payer 160. In various embodiments, the AD 120 may obtain locally-stored information, such as information registered during operation of process 300 of
Next, at decision operation 535, the AD 120 may determine whether third-party authorization is needed. This determination may be made in various manners. In some embodiments, the AD 120 may be specifically requested to request authorization from a particular account holder, such as a bank or credit card servicer. In other embodiments, the AD 120 may be requested to determine merely whether the payer 160 has sufficient funds and/or credit throughout his or her accounts to make a payment, and may have sufficient information to make this determination without reference to third-parties.
If the AD 120 determines that third-party authorization is needed, then at operation 540, the AD 120 may generate an authorization request of its own. This authorization request may include the payment amount previously requested in the payment authorization request submitted to the PBA 100, as well as identifying information for the payer 160 known to the AD 120. Next, the AD 120 may send the request to the authorizing third party. In various embodiments, the authorizing third party may be identified by the AD 120 based on a specific account requested in the payment authorization request submitted to the PBA 100. In other embodiments, the authorizing third party may be identified by the AD 120 based on account or balance information known to the AD 120. Next, at operation 560, the AD 120 may receive authorization from the third party, an the process may end.
If the AD 120 determines that third-party authorization is not needed, then at operation 570, the AD 120 may review account and/or history information to determine whether payment may be authorized by the AD 120 itself. In various embodiments, the information reviewed may include numbers and types of accounts, payment history, account balances, credit scores, etc. Next, based on the review of the information, at operation 580, the AD 120 may generate an authorization for the payment requested. 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 604 and mass storage devices 606 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 606 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 610 (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 610-612 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.
