The present disclosure generally relates to systems and methods for facilitating transactions to payment accounts, and in particular, to systems and methods for facilitating such payment account transactions via SMS (short message service) messaging.
This section provides background information related to the present disclosure which is not necessarily prior art.
Purchases of products, e.g., goods and services, are often funded through transactions to payment accounts. In general, the transactions are coordinated through merchants (offering the products for purchase), acquirers associated with the merchants, one or more service providers (or payment network interchanges), and issuers of the payment accounts. Separately, consumers are known to use SMS (short message service) messaging, commonly referred to as text messaging, to communicate information to other persons and/or entities.
The drawings described herein are for illustrative purposes only of selected embodiments and not all possible implementations, and are not intended to limit the scope of the present disclosure.
Corresponding reference numerals indicate corresponding parts throughout the several views of the drawings.
The description and specific examples included herein are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure. The description and specific examples included herein are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure.
To use payment accounts to fund transactions, merchants must have the ability of verify the payment accounts, and to communicate the transactions to one or more entities responsible for processing the transactions (e.g., acquirers, payment networks, issuers, etc.). Generally, point of sale (POS) devices (e.g., card readers, etc.) collect payment account information from payment devices, and generate authorization requests, which are automatically transmitted, via the acquirers and the payment networks, to the issuers of the payment accounts, which then approve or decline the transactions. Depending on the size, location, sophistication, etc. of the merchants, POS devices suitable for payment account transactions may not be available, largely leaving merchants/consumers with only the option of paying with cash or check. The systems and methods described herein rely on short message service (SMS) messaging to provide data transmissions in connection with payment account transactions, including authorization (and/or confirmation) thereof, whereby the payment account transactions may be completed. In this manner, merchants are able to accept payment account transactions, without investment in POS devices, and often regardless of the location, size and/or sophistication of the merchants.
The system 100 generally includes a merchant 102, an acquirer 104, a payment network 106, an issuer 108, and a message transaction host 110, each coupled to (and in communication with) network 112. The network 112 may include, without limitation, a local area network (LAN), a wide area network (WAN) (e.g., the Internet, etc.), a mobile network, and/or another suitable public and/or private network capable of supporting communication among two or more of the components illustrated in
As shown in
The consumer 114, on the other hand, interacts with the merchant 102 to purchase products. The consumer 114, as shown, is also associated with portable communication device 116 (also configured to exchange SMS messages with other devices). Each of the consumer 114 and the merchant 102 is registered to the message transaction host 110, so that SMS messages from the portable communication devices 116, 120 are identified to the respective consumer 114 or merchant 102 (e.g., based on the telephone number associated with the particular portable communication device 116, 120; etc.). The registration further includes the association of a payment account, with the consumer 114, with which the consumer 114 expects to fund transactions, and the association of an account (e.g., bank account, payment account, etc.) with the merchant 102, with which the merchant 102 expects to receive funds for the consumer's purchases.
While only one merchant 102 (and one communication device 120 associated therewith) and one consumer 114 (and one communication device 116 associated therewith) are illustrated in
Likewise, a different number of acquirers, payment networks, and/or issuers may be included. For example, different merchants (not shown) may have one or more different acquirers, and different consumers (not shown) may employ payment accounts issued by one or more different issuers.
As shown in
The message transaction host 110 is generally configured to provide payment account transactions to the payment network 106, via SMS messaging. In particular, when the consumer 114 attempts a transaction at merchant 102, the sales person 118, via the portable communication device 120, transmits a SMS message (i.e., a transaction request) to the message transaction host 110. The message transaction host 110, in turn, receives the transaction request, including the consumer's telephone number, and transmits a verification message, via SMS, to the consumer 114. The consumer 114, via the portable communication device 116, transmits a confirmation response (approving or declining the transaction), via SMS, back to the message transaction host 110. In turn, the message transaction host 110 transmits an approval/decline message, via SMS, to the merchant 102, and in particular, the sales person 118 (at portable communication device 120) indicting the approval or decline of the transaction. It should be appreciated that various additional messages and/or message contents (e.g., codes, etc.) may be exchanged between the merchant 102, the message transaction host 110, and the consumer 114, to provide, for example, verifications, authorizations, and confirmations, etc., in connection with the transaction.
Once the transaction is approved by the consumer 114, prior to informing the merchant 102, the message transaction host 110 causes the transaction to be processed to the consumer's payment account and/or the merchant's account, by coordinating with the acquirer 104 (i.e., holder of the merchant's account), payment network 106, and/or the issuer 108 (i.e., holder of the consumer's account), as necessary. For example, the message transaction host 110, prior to or after seeking approval from the consumer 114, may submit an authorization request to the issuer 108 (i.e., the issuer of the payment account associated with the consumer 114) via the payment network 106 (e.g., via MasterCard®, VISA®, Discover®, American Express®, etc.) to determine whether the payment account is in good standing and whether sufficient credit/funds exist to complete the transaction. The authorization request generally includes the payment account number, a merchant ID, and an amount of the transaction. In certain embodiments, the authorization request may include other information, such as, for example, a time/date, a PIN, a ZIP code, or other information (including verification information) received from the consumer 114 and/or merchant 102 regarding the transaction or otherwise, or appended by the message transaction host 110. The issuer 108, in turn, responds to the authorization request (i.e., approving or declining), to the message transaction host 110, via the payment network 106, which permits the message transaction host 110 to proceed as described above.
After the transaction is approved (and completed between the merchant 102 and consumer 114), the message transaction host 110 may further participate in clearing and/or settlement of the transaction by and between the merchant 102, the acquirer 104, and the issuer 108.
Transaction data is generated, collected, and stored as part of the above interactions among the merchant 102, the acquirer 104, the payment network 106, the issuer 108, and the message transaction host 110. The transaction data represents at least a plurality of transactions, e.g., completed transactions, attempted transactions, etc. The transaction data, in this exemplary embodiment, is stored by (or at) at least one of: the message transaction host 110 and the payment network 106, in a data structure associated therewith, depending on the particular embodiment, etc. Additionally, or alternatively, the merchant 102, the acquirer 104, and/or the issuer 108 may store the transaction data, or part thereof, in memory. The transaction data may include, for example, payment account numbers, amounts of the transactions, consumer IDs, merchant IDs, merchant category codes, dates/times of the transactions, product identifiers, transaction numbers, etc. It should be appreciated that more or less information related to processing, approving, and/or declining transactions may be included in transaction data and stored within the system 100, at the message transaction host 110, the acquirer 104, the payment network 106, and/or the issuer 108.
In various exemplary embodiments, consumers (e.g., consumer 114, etc.) involved in the different transactions herein are prompted to agree to legal terms associated with their payment accounts, for example, during enrollment in their accounts, etc. In so doing, the consumers may voluntarily agree, for example, to allow merchants, issuers, payment networks, etc., to use data collected during enrollment and/or collected in connection with processing the transactions herein, subsequently for one or more of the different purposes described herein.
Each of the merchant 102, the acquirer 104, the payment network 106, the issuer 108, and the message transaction host 110, in the exemplary embodiment of
Referring to
The memory 204 may include one or more computer-readable media, such as, without limitation, dynamic random access memory (DRAM), static random access memory (SRAM), read only memory (ROM), erasable programmable read only memory (EPROM), solid state devices, flash drives, CD-ROMs, thumb drives, floppy disks, tapes, flash drives, hard disks, and/or any other type of volatile or nonvolatile physical or tangible computer-readable media. Memory 204 may be configured to store, without limitation, transaction data, payment account numbers, phone numbers, consumer profiles, clearing and/or settlement logs, transaction numbers, verification numbers, PINs, and/or other types of data suitable for use as described herein.
In the exemplary embodiment, the computing device 200 includes a presentation unit 206 that is coupled to (and in communication with) the processor 202 (however, it should be appreciated that the computing device 200 could include output devices other than the presentation unit 206, etc.). The presentation unit 206 outputs information (e.g., SMS messages, etc.), either visually or audibly, to the user, for example, the consumer 114, the sales person 118, etc. It should be further appreciated that various interfaces (e.g., screens, etc.) may be displayed at computing device 200, and in particular at presentation unit 206, to display information, such as, for example, SMS messages, etc. The presentation unit 206 may include, without limitation, a liquid crystal display (LCD), a light-emitting diode (LED) display, an organic LED (OLED) display, and/or an “electronic ink” display, etc. In some embodiments, presentation unit 206 includes multiple devices.
The computing device 200 also includes an input device 208 that receives inputs from the user (i.e., user inputs) such as, for example, message typing, send commands, etc. The input device 208 is coupled to (and is in communication with) the processor 202 and may include, for example, a keyboard, a pointing device, a mouse, a stylus, a touch sensitive panel (e.g., a touch pad or a touch screen, etc.), another computing device, and/or an audio input device. Further, in various exemplary embodiments, a touch screen, such as that included in a tablet, a smartphone, or similar device, behaves as both presentation unit 206 and input device 208.
In addition, the illustrated computing device 200 also includes a network interface 210 coupled to (and in communication with) the processor 202 and the memory 204. The network interface 210 may include, without limitation, a wired network adapter, a wireless network adapter, a cellular network adapter, or other device capable of communicating to one or more different networks, including the network 112. Generally, in this exemplary embodiment, the network interface 210 is at least configured to transmit and receive SMS messages. Further, in some embodiments, the computing device 200 includes the processor 202 and one or more network interfaces incorporated into or with the processor 202.
As shown in
Once the account is created, it is generally verified by the message transaction host 110. As shown in
As shown, the merchant 102 creates an account with the message transaction host 110, at 402. As described above with reference to
Once the merchant 102 has created the account, at 402, the message transaction host 110 sends a verification message, via SMS (or otherwise), to the merchant 102 (and, in particular to the portable communication device 120), at 404. The SMS message includes a verification code, associated with the merchant 102 and/or the created account (e.g., with the merchant's the account number, etc.). In turn, to complete the registration, the merchant 102 provides the verification code back to the message transaction host 110, at 406. As indicated above, the verification code may be provided back to the transaction host 110, for example, via SMS messaging, via a website, application, or other web-based platforms associated with (or provided by) the message transaction host 110, via a voice call, and/or via email, etc. Upon receipt of the verification code at the computing device associated with the message transaction host 110, the message transaction host 110 completes the registration of the merchant 102, stores the account in memory (e.g., memory 204, etc.), and designates the account as active for transactions.
It should be appreciated that numerous variations may be employed in the registrations of the consumer 114 and/or the merchant 102 in other embodiments, depending on, for example, the information collected by the message transaction host 110, any variation to the system 100, the types of accounts involved in the registration, additional and/or alternative security measures, etc.
Additionally, if the initial transaction request at 502 did not include transaction specific information, the verified transaction request at 506 will include this information. The transaction specific information may include, for example, the telephone number of the consumer 114, the amount of the transaction, etc. Other information may be included regarding the product, the consumer 114, and/or the merchant 102, as desired.
It should be appreciated that a verification code in the method 500 (as well as in methods 300 and 400) may be time sensitive, i.e., it may be only valid for a predefined interval. Specifically, for example, the verification code may expire after 10 seconds, 1 minute, 5 minutes, or 10 minutes, or another suitable interval, etc. Further, the verification code may be valid for only one transaction. Further still, the verification code may be a unique number, as compared to prior verification codes sent to the merchant 102, and/or may be randomly generated by the message transaction host 110, such that the verification code is at least different than any prior verification code transmitted to the merchant 102 in the last day, week, month, or year, etc. In certain instances, the receipt and transmittal of the time-sensitive, one-use verification code in the method 500 provides a measure of security to the transaction (e.g., to help combat telephone number spoofing devices, etc.).
With continued reference to
Upon receipt of the confirmation response from the consumer 114 at 510, if an approval, the message transaction host 110 causes the transaction to be processed to the consumer's payment account (i.e., the payment account linked to the consumer's telephone number during registration with the message transaction host 110), at 512. Specifically, the message transaction host 110 (depending on where in the system 100 it is located and/or integrated), transmits an authorization request to the issuer 108 (via, for example, the acquirer 104, payment network 106, etc., as necessary).
Prior to transmitting the authorization request, the message transaction host 110 retrieves the payment account number associated with the consumer's payment account, based on the telephone number included in the transaction request received from the merchant 102 (in the initial or verified transaction request). The authorization request includes the payment account (determined based on the consumer's telephone number), the amount of the transaction, a merchant ID, a merchant account number, the acquirer ID, etc. As described above in connection with the system 100, in response, the issuer 108 verifies the payment account, and provides an authorization response, which approves or declines the transaction. The message transaction host 110 receives the authorization response, and at 514, transmits a transaction conformation, including an approval or decline of the transaction, to the portable communication device 120 associated with the merchant 102. The merchant 102 then either completes the purchase with the consumer 114, when approved by the issuer 108, or acts accordingly when the transaction is declined (e.g., requests a different form of payment from the consumer 114, etc.). When the authorization response approves the transaction, in this exemplary embodiment, a transaction confirmation and receipt is also transmitted by the message transaction host 110, at 516, to the portable communication device 116 associated with the consumer 114.
Finally, in this exemplary embodiment, at 518, the message transaction host 110 sends settlement, by way of a settlement confirmation, to the merchant 102. Settlement may be accomplished immediately by causing funds to be added/deposited to the merchant's account, or alternatively, settlement may be accomplished at the end of the business day, or within a predefined interval (e.g., 24 hours, 48 hours, etc.). Regardless of the manner of settlement, in this exemplary embodiment, the acquirer 104 submits the request for settlement to the payment network 106, which in turn, issues a credit to the acquirer 104 (and specifically, the merchant account) and a debit to the issuer 108 (and specifically, the consumer's payment account), i.e., the payment network 106 effects settlement. In one or more other embodiments, the acquirer 104 and the issuer 108 may interact directly, or otherwise, to avoid the payment network 106.
In one or more embodiments, the message transaction host 110 may employ one or more velocity thresholds relating to prior transactions (i.e., transaction history) (alone or in combination with the requested transaction), and various transaction limits or restrictions, involving the merchant 102. For example, as illustrated in
Similarly, transactions to the consumer's payment account, via the message transaction host 110, may be subject to one or more velocity thresholds as well. As shown in
It should be appreciated that as transaction data and other information is compiled for the consumer 114 and/or the merchant 102, various additional (or alternative) criteria may be employed to permit or decline transactions, as illustrated, for example, in
In response to the transaction request, at interface 602, the message transaction host 110 transmits a confirmation request to the consumer 114, and in particular, the portable communication device 116, for example, as shown at interface 608 (e.g., at 508 in method 500, etc.). The interface 608 includes a request to confirm a charge of “$24.34” to the merchant “ABC Grocery.” The message further includes a code to approve (i.e., 123) and a code to decline (i.e., 987) the transaction. As shown in interface 610, the consumer 114, in this example, enters “123” to approve the transaction and transmits it, via SMS, to the message transaction host 110 (e.g., at 510 in method 500, etc.).
In response to the approve code “123,” in the chain of exemplary messages in
It should be appreciated that the functions described herein, in some embodiments, may be described in computer executable instructions stored on a computer readable media, and executable by one or more processors. The computer readable media is a non-transitory computer readable storage medium. By way of example, and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Combinations of the above should also be included within the scope of computer-readable media.
It should also be appreciated that one or more aspects of the present disclosure transform a general-purpose computing device into a special-purpose computing device when configured to perform the functions, methods, and/or processes described herein.
As will be appreciated based on the foregoing specification, the above-described embodiments of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof, wherein the technical effect may be achieved by performing at least one of the following steps: (a) receiving a transaction request from a merchant relating to a transaction between a consumer and the merchant; (b) transmitting a verification message to the merchant, the verification message including a verification code; (c) receiving a verified transaction request from the merchant, the verified transaction request including said verification code, and at least one of the transaction request and the verified transaction request including a telephone number associated with a consumer and an amount of the transaction; (d) transmitting a confirmation request to the consumer, the confirmation request including a confirmation code; (e) receiving a confirmation response from the consumer; (f) transmitting an authorization request for the transaction when the confirmation response includes said confirmation code; (g) retrieving a payment account number for the consumer from memory, based on the telephone number associated with the consumer; (h) receiving an authorization response, indicating the transaction is approved; (i) transmitting a first transaction confirmation to the merchant, and transmitting a second transaction confirmation to the consumer; (j) registering the merchant and the consumer; (k) correlating a phone number associated with the merchant to an account for the merchant, whereby funds can be added to the merchant's account during clearing and/or settlement of the transaction; (l) correlating the phone number associated with the consumer to a payment account for the consumer, whereby funds can be debited from the consumer's account during clearing and/or settlement of the transaction; or any other method operations, as recited in the claims below, or the description above.
It should be further understood that each computing device, or component illustrated in
Exemplary embodiments are provided so that this disclosure will be thorough, and will fully convey the scope to those who are skilled in the art. Numerous specific details are set forth such as examples of specific components, devices, and methods, to provide a thorough understanding of embodiments of the present disclosure. It will be apparent to those skilled in the art that specific details need not be employed, that example embodiments may be embodied in many different forms and that neither should be construed to limit the scope of the disclosure. In some example embodiments, well-known processes, well-known device structures, and well-known technologies are not described in detail.
The terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. As used herein, the singular forms “a,” “an,” and “the” may be intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms “comprises,” “comprising,” “including,” and “having,” are inclusive and therefore specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. The method steps, processes, and operations described herein are not to be construed as necessarily requiring their performance in the particular order discussed or illustrated, unless specifically identified as an order of performance. It is also to be understood that additional or alternative steps may be employed.
When an element or layer is referred to as being “on,” “engaged to,” “connected to,” “coupled to,” “associated with,” “included with,” or “in communication with” another element or layer, it may be directly on, engaged, connected or coupled to, or associated with, or in communication with the other element or layer, or intervening elements or layers may be present. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.
The foregoing description of exemplary embodiments has been provided for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure. Individual elements or features of a particular embodiment are generally not limited to that particular embodiment, but, where applicable, are interchangeable and can be used in a selected embodiment, even if not specifically shown or described. The same may also be varied in many ways. Such variations are not to be regarded as a departure from the disclosure, and all such modifications are intended to be included within the scope of the disclosure.
This application claims the benefit of, and priority to, U.S. Provisional Application No. 62/159,640 filed on May 11, 2015. The entire disclosure of the above application is incorporated herein by reference.
Number | Date | Country | |
---|---|---|---|
62159640 | May 2015 | US |