JP7038969B2 - Electronic money (E-money) payment processing - Google Patents

Description

This application claims the priority of US Provisional Application No. 62 / 959,082 filed January 9, 2020, the entire contents of which are incorporated herein by reference.

Electronic (or digital) currencies such as electronic money and digital money are a type of currency that can be used in electronic form (for example, instead of physical forms such as banknotes, coins and cash), and electronic currency is physical. It has the same characteristics as a currency, but can enable instantaneous transactions and unrelated transfer of ownership. As with physical currencies, electronic currencies can be used to purchase items through transactions (eg, goods, services, etc.). Electronic currencies are often used for cryptocurrencies, online bank deposits, games and / or credits in social networks.

The features, properties, and various advantages of the present disclosure will become more apparent by considering the following detailed description in conjunction with the accompanying drawings.

FIG. 1 shows an exemplary environment for processing the electronic commerce payments described herein.

FIG. 2 shows communications related to processing electronic commerce payments, as described herein.

, 3A and 3B show exemplary processes for processing e-commerce payments from the perspective of a reader device, as described herein.

, , 4A-4C show exemplary processes for processing electronic commerce payments from the perspective of a merchant device, as described herein.

, , 5A-5C show exemplary processes for processing electronic commerce payments from the perspective of a proxy server (s), as described herein.

FIG. 6 shows an exemplary process for processing e-commerce payments from a server perspective, as described herein.

FIG. 7 shows an exemplary process associated with error handling as described herein.

FIG. 8 shows an exemplary process related to the balance check flow as described above.

FIG. 9 shows, among other things, an exemplary environment for facilitating the techniques described herein.

FIG. 10 shows additional details related to the individual components of the environment described above in FIG.

In drawings, the leftmost digit of the reference number identifies the drawing in which the reference number first appears. The drawings are not on scale.

The techniques described herein are intended to process payments for transactions involving electronic money (e-money). Payment for transactions involving electronic money can be called "electronic money payment". In one example, the payment processing service provides a payment processing service to a merchant. To accommodate e-commerce payments, payment processing services can take advantage of the complex configuration of networked devices that can be located remotely (eg, across states or borders) from each other. In some examples, payment processing services can exchange communications with third-party payment processors to process e-commerce payments. In such an example, a payment processing service leverages a proxy server computing device (s) to monitor communication between a merchant device and a third-party payment processor in a POS (eg, a merchant). can do. A proxy server computing device can send an indication to a server computing device (s) associated with a payment processing service, which server computing device is a proxy server computing device (s). It can be located remotely (eg, across states or borders) from one or more, so that the payment processing service uses the payment processing service (using a third-party payment processor) of the merchant. instead of. In some examples, such indications can be sent based on information received by a proxy server computing device via communication from a third-party payment processor. That is, the techniques described herein are merchant devices that can be operated by merchants who use payment processing services, proxy server computing devices (s) related to payment processing services, and (proxy server computing devices (s). ) Remotely from) server computing devices (s) related to payment processing services, and third-party payment processors for processing electronic money payments can be leveraged.

Electronic (or digital) currencies such as electronic money and digital money are a type of currency that can be used in electronic form (instead of physical forms such as banknotes, coins, cash, etc.), and electronic currencies are physical. It has the same characteristics as a currency, but can enable immediate transactions and borderless transfer of ownership. As with physical currencies, electronic currencies can be used to purchase items (eg, goods, services, etc.). That is, electronic money can be bid (offered) as a form of payment (that is, "payment of electronic money") for a transaction involving the purchase or acquisition of goods from a merchant.

In at least one example, a smart card, which can be a physical payment instrument with an embedded microchip, can be used for electronic commerce payments. A smart card can include a microchip (eg, which can include one or more electronic circuits) and an antenna that allows the smart card to interact with other computing devices such as payment readers. .. In at least one example, the microchip can store one or more applications called applets that allow a smart card to provide multiple services. An example of such a service allows a smart card to be used as an e-commerce payment instrument. In such an example, the e-commerce balance can be written to or otherwise associated with the smart card's microchip. An example of such a smart card is the FeliCa card (“FeliCa”) from Sony®. Communication technologies related to such smart cards, including FeliCa, are described in the non-contact IC card international standard ISO / IEC 14443, which specifies Type A and Type B communication technologies called NFC-A and NFC-B, respectively. Has been done. Such smart cards can enable e-commerce payments without communication with central bank authorities. That is, in some examples, a smart card encoded with the functionality of configuring the smart card as an e-commerce payment instrument will be stored in the e-commerce balance on the smart card without the use of central banking authorities. Funds can be added or deducted. In at least one example, a smart card can be a source of truth about the e-commerce balance associated with a smart card.

At the point of sale, the customer may present a smart card configured as an e-commerce payment instrument for payment of transactions (or parts thereof) with merchants. In at least one example, a merchant can subscribe to a service called a payment processing service that processes payments for a merchant's transactions on behalf of the merchant. That is, in at least one example, the payment processing service (i) communicates with one or more other payment processors described below and / or (ii) records the transaction in one or more ledgers. This allows the transaction to be processed on behalf of the merchant. In at least one example, the payment processing service can analyze the transaction data received for a transaction to determine the amount of funds to be paid to the merchant for the transaction. In at least one example, such amount can be the total purchase price minus the charges charged by the payment processing service to provide the payment processing service. Based on determining the amount of funds to be paid to the merchant, the payment processing service can deposit the funds in the merchant's account maintained by the payment processing service. Such accounts are managed through at least the ledger of payment processing services, and the relevant funds include scheduled deposits, same-day deposits, immediate deposits, and linked payment instruments, as described below. It may differ from traditional bank accounts as it is accessible through a variety of withdrawal channels, not limited to it. In some examples, the account can be accessed through a payment instrument configured as an e-commerce payment system and / or transferred to another e-commerce account (which cannot be managed by the payment processing service). Can be associated with an e-commerce balance.

In at least one example, the payment processing service can exchange communications with a third-party payment processor that processes electronic commerce payments. An example of such a third-party payment processor is Transaction Media Networks (TMN). Such a third-party payment processor can decide whether to approve the payment (for example, for a transaction or part thereof) based on the e-commerce balance associated with the smart card. If the e-commerce balance is greater than or equal to the cost of the transaction (or part of it), the third-party payment processor will reduce the current e-commerce balance and write the new e-commerce balance to the smart card or otherwise associate it with the smart card. Can be done. As a result, the third-party payment processor can process the e-commerce payment for the transaction (for example, thereby causing the transfer of funds from the e-commerce balance of the payment instrument to the payment processing service), while processing the payment. The service can record e-commerce payments for its payment processing purposes.

The techniques described herein provide a solution to the aforementioned configuration of network devices for processing e-commerce payments (eg, payment processing services that communicate with third-party payment processors via proxy server computing devices). Relevant to one or more technical issues. In one example, exchanging communications with payment processing services that can be located across states or borders, and third-party payment processors (eg, the amount of time required to send data over long distances). Because) it can cause delays in the processing of transactions at the point of sale. In some examples, such delays are the result of network bandwidth constraints. For example, Bluetooth® Low Energy (BLE) can be constrained by data packet size (eg, about 100 bytes per packet) and BLE interval (eg, how often data packets can be sent and received). Therefore, using BLE to process e-commerce payments can cause significant latency. Such delays can be inconvenient for customers and merchants. However, the techniques described herein provide a technical solution to such latency. As described below, the techniques described herein utilize data compression in the reader device prior to encryption in order to reduce the amount of data transmitted for individual communications. As a result, communication between merchant devices at sales points, third-party payment processors, payment processing services, etc. can be accelerated (faster than without the technology described herein). The performance of electronic payment processing technology can be improved.

Moreover, unlike traditional payment processing for third-party payment processors, the techniques described herein are associated with processing electronic commerce payments for transactions that are also processed by payment processing services. As far as third-party payment processors are concerned, payment processing services can be considered as a single entity. However, payment processing services can process payments to a plurality of different merchants, as described below. That is, the payment processing service can be an aggregator. Accordingly, the techniques described herein allow third-party payment processors to process e-commerce payments, and payment processing services (i) determine to which merchant an individual transaction is associated. (Ii) Target communications that allow such transactions to be recorded on behalf of such merchants (eg, record associated transactions in a ledger, as described above). Therefore, the techniques described herein are intended to be improvements over traditional electronic commerce payment processing techniques.

FIG. 1 shows an exemplary environment 100 for processing electronic commerce payments as described herein. An exemplary environment 100 is a tablet computing device, smartphone, mobile communication device, laptop, netbook, or other portable computer, desktop computing device, terminal computing device, or other semi-fixed or fixed computing device. , Dedicated devices, wearable computing devices, or other body-mounted computing devices, augmented reality devices, virtual reality devices, Internet of Things (IoT) devices, combinations of the above, and the like, but not limited to merchant devices. Includes 102. In at least one example, the merchant device 102 may be operational by the merchant to handle transactions between the merchant and one or more customers in point-of-sale information management. Such a transaction can be associated with the sale (or other transfer of ownership) of an item between a merchant and one or more customers.

In at least one example, the merchant device 102 can have an instance of a point-of-sale (POS) application 104 stored on it, which allows the merchant to have a payment processing service. It will be possible to process payments. The POS application 104 is an example of a functional component (eg, an instruction or program that can be executed by a processor) that can be associated with the merchant device 102. Functional components of additional or alternative processing may be associated with merchant device 102 to allow the merchant device 102 to perform additional or alternative processing functions.

In at least one example, the POS application 104 can configure the merchant device 102 (s) as a POS terminal, whereby the merchant processes payments (for transactions) through a payment processing service. can do. In at least one example, the merchant device 102 can be configured such that the POS application 104 exchanges communications with the reader device 106. Further, in at least one example, the POS application 104 configures the merchant device 102 to exchange communications with payment processing services and / or other entities within the exemplary environment 100, and in some examples to customers and / or merchants. A user interface for communicating information can be presented. That is, in some examples, the POS application 104 receives payment data from the reader device 106 associated with the merchant device 102, generates transaction data associated with the transaction, and processes the payment for the transaction. In order to do so, it can be possible to send transaction data to a payment processing service. Additional details related to the POS application 104 will be described later.

In at least one example, the merchant device 102 (s) can be associated with the reader device 106. In some examples, the reader device 106 can be plugged into a port within the merchant device 102, such as a microphone port, headphone port, audio jack, data port, or other suitable port. In an additional or alternative example, the reader device 106 can be coupled to the merchant device 102 by another wired or wireless connection via Bluetooth®, BLE, etc. (eg, illustrated in FIG. 1). ). In such an example, the reader device 106 can encrypt the information received from the payment instrument 108 before passing it to the merchant device 102 (eg, a malicious person obtains unencrypted information). Make things difficult). In some examples, the reader device 106 may encrypt information in a format specific to a third-party payment processor. Further details are given below.

In some examples, the reader device 106 can be integrated into the merchant device (s) 102. In such an example, the reader device 106 uses technologies such as Near Field Communication (NFC), Radio Frequency Identification (RFID), Bluetooth®, BLE, etc. embedded in the merchant device 102 to make payment means 108. Information can be read from. Such techniques can facilitate contact and / or contactless payments. In at least one example, the functional component associated with the reader device 106 (eg, an instruction or program executable by the processor) was received from the payment instrument 108 via NFC, RFID, Bluetooth®, BLE, and the like. The information can be configured to be encrypted. In an example where the reader device 106 is integrated into the merchant device 102, the functional component "reads" information from the payment instrument 108, in contrast to the dedicated hardware device 106 shown (and described above) in FIG. .. For this purposes, "reader device" can refer to a dedicated hardware device, a functional component configured to read information from a payment instrument, and / or a combination of those described above. Additional details related to reader devices are described below.

In at least one example, the reader device 106 can be associated with NFC type F technology. That is, the reader device 106 can communicate with the payment instrument 108 using the NFC type F. The specifications of NFC type F are specified in Japanese Industrial Standard JIS X 6319-4.

In at least one example, the reader device 106 can be associated with a different processor (eg, a computer processing unit (CPU)) to perform different aspects of electronic commerce payment processing. For example, the first processor, processor 109 (A), can control the input / output components of the payment reader 106. That is, the processor 109 (A) can control the behavior and / or power management of the light emitting diode (LED). In addition, processor 109 (A) can perform encryption and the process for doing so can be provided by a third party payment processor. For example, the processor 109 (A) can encrypt the data sent from the reader device 106 in an encryption format specific to a third-party payment processor. In at least one example, processor 109 (A) may send a request to a payment processing service (eg, to record a transaction, as described below). In at least one example, processor 109 (A) can act as a pass-through for communication between a third-party payment processor, described below, and a second processor, processor 109 (B).

In at least one example, the processor 109 (B) can analyze and process the received communication (eg, a packet of data received from another entity in the exemplary environment 100). That is, in at least one example, processor 109 (B) can analyze and process communications (eg, commands) received from a third-party payment processor. In at least one example, such analysis and processing can include decoding and / or decoding of such communications. In some examples, processor 109 (B) can do this in a specified order.

In some examples, processor 109 (B) may transmit communication to processor 109 (A) and / or merchant device 102 based on communication received from a third-party payment processor. In at least one example, such communication can include payment instrument operations, LEDs, audio, and / or UI operations and the like. In some examples, LED operations can be transmitted to processor 109 (A) and voice and / or UI operations can be transmitted to merchant device 102 (eg, via processor 109 (A)). In at least one example, processor 109 (B) may send back a response (reply) indicating the result of a command sent by a third-party payment processor to the third-party payment processor.

In at least one example, the processor 109 (B) can manage communication with the payment instrument 108 and the reader device 106.

In some examples, the reader device 106 can interact with the payment instrument, for example, by swiping, dipping, and / or tapping. Swipe is a dialogue in which a user slides a payment card with a magnetic strip through a reader device that captures payment data contained in the magnetic strip. A dip is a dialogue in which a user first inserts a payment card with an embedded microchip (ie, a chip) into the reader device chip side. The tap can tap or hover a payment instrument such as an NFC-enabled electronic device or NFC-enabled payment card via a reader device for the user to send information stored in the payment instrument via the NFC protocol. It is a dialogue. In some examples, additional or alternative short-range communication technologies (eg RFID, Bluetooth®, BLE, etc.) can be used with tap dialogue. In some examples, taps can also be referred to as contactless payments. In at least one example, the reader device 106 may acquire information stored in the payment instrument via one or more of the dialogues described above (eg, swipes, dips, taps, etc.).

FIG. 1 shows a tap between the payment instrument 108 and the reader device 106, i.e., contactless payment. The payment means 108 is shown as a payment card such as a credit card or a debit card. That is, in at least one example, the payment instrument 108 can be a physical payment instrument (eg, a smart card) having a microchip embedded therein. In at least one example, the payment instrument 108 interacts with the microchip (which may include, for example, one or more electronic circuits) and the payment instrument 108 with other computing devices such as the reader device 106. Can include antennas that enable. In at least one example, the payment instrument 108 uses an existing antenna and / or circuit to transmit information stored on it (eg, over an NFC network using the NFC protocol) to a reader device 106. It can be an NFC compatible card that can be used. In additional or alternative processing examples, the payment instrument 108 does not have to be a card and instead (eg, runs an application that stores information related to the payment instrument, or otherwise stores such information). It may be a mobile device (eg, a wearable device that stores information related to the payment instrument, or otherwise runs an application that stores such information).

As mentioned above, in at least one example, the microchip may store one or more applications called applets that allow the payment instrument 108 to store data that may be associated with multiple services. can. In at least one example, such data can include an e-commerce balance 110. That is, an example of such a service allows the payment instrument 108 to be used as an electronic money payment instrument. In such an example, the electronic commerce balance 110 can be written to or otherwise associated with the microchip of the payment instrument 108. As mentioned above, an example of such a payment instrument is FeliCa provided by Sony®. As mentioned above, payment instruments that enable e-commerce services can enable e-commerce payments without communication with central bank authorities. That is, in some examples, the payment instrument 108 can add or deduct funds to the e-commerce balance 110 without using the central banking authority. In at least one example, the payment instrument 108 can be the material that tells the truth about the electronic commerce balance 110 associated with it.

In addition to the electronic commerce balance 110, the payment instrument 108 can store payment data 112. The payment data 112 is associated with the name of the customer with which the payment instrument 108 is associated, the address of the customer, the type of the payment instrument 108 (eg, credit, debit, etc.), the number associated with the payment instrument 108, and the payment instrument 108. Verification values (eg, PIN verification key indicator (PVKI), PIN verification value (PVV), card verification value (CVV), card verification code (CVC), etc.), expiration date associated with payment instrument 108, customer support Primary account number (PAN) (which may or may not match the number associated with the payment instrument), restrictions on what type of charge / debt may be made, and so on. However, it is not limited to these. In some examples, the payment data 112 may be encrypted.

In at least one example, the merchant device 102 includes the Internet, cable networks, cellular networks, cloud networks, wireless networks (eg Wi-Fi) and wired networks, as well as Bluetooth®, BLE and the like (shown in FIG. 1). A third-party payment processor server computing device 114 (in the present specification, "third-party") associated with a third-party payment processor, including, but not limited to, via one or more networks. (Abbreviated as "server") and / or may exchange communications with the payment processing service server computing device 116 (abbreviated herein as "server") associated with the payment processing service. In at least one example, the server 116 can be remotely located from the merchant device 102. In some examples, the server 116 can be located in a different state or country than the merchant device 102.

In at least one example, to facilitate communication between the merchant device 102 and the third party server 114 and / or server 116, the payment processing service is the payment processing service proxy server computing device 118 (as used herein). (Abbreviated as "proxy server") can be used. In at least one example, the proxy server 118 is a compute associated with a payment processing service that allows a merchant device 102 (eg, a POS application 104), a third party server 114, and / or a server 116 to exchange communications. It can contain a cluster of wing devices. In some examples, the merchant device 102, the proxy server 118, and the third party server 114 can be located in a first geographic location (eg, state or country), and the server 116 is a first geographic location. It can be located in a second geographical location (eg, state or country) that is different from the location.

In at least one example, the proxy server 118 can have an instance of the communication application 120 installed therein. The communication application 120 may be a functional component associated with the proxy server 118 (eg, an instruction or program executable by the processor). In at least one example, the communication application 120 can send and receive communication to and from the merchant device 102, the third party server 114, and / or the server 116. In some examples, the communication application 120 can function as a pass-through node in the exemplary environment 100. That is, the communication application 120 can receive the communication and transfer it to the intended receiver. In some examples, the communication application 120 can analyze the received communication, which can include decoding and / or decoding such communication and is associated with such communication. You can perform one or more actions based on the information you want to do. That is, in some examples, the communication application 120 monitors communications transmitted through the proxy server 118 (s) and decodes and / or decodes such communications as needed. One or more actions can be performed in response.

In at least one example, proxy server 118 (s) associates an identifier with a transaction so that the communication associated with the transaction (eg, related to the processing of payments for it) is associated with the identifier. Can be done. As a result, the proxy server 118 can maintain a connection with the third party server 114 while the transaction payment is processed.

In at least one example, the proxy server 118 can communicate with the third party server 114 over an encrypted channel established via the secure socket layer (SSL). Further, in at least one example, the proxy server 118 can communicate with the merchant device 102 over the cryptographic channel using a cryptographic protocol. In some examples, the proxy server 118 can sign the data intended for the third party server 114 in order to reduce the work and payload size for the reader device 106.

As mentioned above, the third party server 114 can be associated with a third party payment processor. Third-party processors can be different from payment processing services and can process e-commerce payments. As mentioned above, an example of such a third-party payment processor is TMN. In at least one example, the third party server 114 (s) can maintain a record of the e-commerce balance associated with the payment instrument (eg, in a data storage device) and the payment instrument 108. You can decide whether to approve payments based on the associated e-commerce balance (eg, for a transaction or part thereof). In another example, the third party server 114 (s) cannot keep a record of the e-commerce balance, and as a result, from the reader device 106 (eg, in connection with a merchant request). The current e-commerce balance associated with the payment instrument 108 can be determined, at least in part, on the basis of receiving an indication.

In at least one example, a third-party payment is made to see if the current e-commerce balance of the payment instrument 108 is greater than or equal to the amount the payment instrument 108 is bidding for payment (eg, the cost of the transaction or a portion thereof). The processor can determine. In at least one example, if the current e-commerce balance is less than the amount the payment instrument 108 is bidding on, the third party server 114 does not approve the payment instrument 108 (eg, the payment data associated therewith) for the amount. That can be communicated to the merchant device 102 (eg, via proxy server 118). However, if the current e-commerce balance is greater than or equal to the amount the payment instrument 108 is bidding on, the third party server 114 approves the merchant device 102 (eg, via the proxy server 118) for the amount. You can communicate what is being done.

As described below, the third party server 114 will write a new e-commerce balance (eg, an amount based on the current e-commerce balance and the amount bid by the payment instrument 108 for payment) to the payment instrument 108. Can send a command to the merchant device 102. The merchant device 102 may write the new e-commerce balance to or associate with the payment instrument 108 and send such confirmation to the third party server 114 via the reader device 106. In some examples, in response to receiving such confirmation, the third party server 114 (s) is the indie of the payment instrument 108 (eg, in the data storage associated with it). You can update the current e-commerce balance associated with the application. Further, in response to receiving such confirmation, the third party server 114 can facilitate the settlement of payments and transfer the funds to be paid to the merchant to the server 116 associated with the payment processing service. If the third party server 114 does not receive such a confirmation message, the third party server 114 may initiate the error handling process as described below.

The server 116 can store an instance of the payment processing application 122 on it. The payment processing application 122 can be a functional component associated with the server 116 (eg, an instruction or program that can be executed by a processor). In this way, the payment processing service (i) communicates with one or more other payment processing companies and / or (ii) records the transaction in one or more ledgers managed by the payment processing service. By doing so, the transaction can be processed on behalf of the merchant (and other different merchants). In at least one example, the payment processing application 122 can analyze the transaction data received for a transaction to determine the amount of funds to be paid to the merchant for the transaction. In at least one example, such amount is charged by the payment processing service to provide the payment processing service from the total purchase price (eg, of one or more items purchased through the transaction). It can be deducted from the charge. Based on determining the amount of funds to be paid to the merchant, the payment processing application 122 can deposit the funds in the merchant's account maintained by the payment processing service. Such accounts are managed through at least the ledger of payment processing services, and the relevant funds include scheduled deposits, same-day deposits, immediate deposits, and linked payment instruments, as described below. It may differ from traditional bank accounts because it is accessible through a variety of withdrawal channels, not limited to it. In some examples, such deposits and / or linked payment instruments are configured as electronic money repositories (eg, electronic commerce payment instruments and / or electronic money accounts managed by payment processing services or other services. It can be associated with the payment method).

In some examples, the funds may be transferred to the merchant's account in response to receiving the funds (eg, their indication) from the third party server 114. In some examples, the funds can be transferred to the merchant's account before receiving the funds (eg, their indication) from the third party server 114. In at least one example, transferring funds to a merchant's account before receiving the funds can be based on a risk analysis that can inform the timing and amount of the transfer.

As described below, the payment processing service may provide one or more additional or alternative services that can be provided to the merchant (and other different merchants). In some examples, such services are available via the POS application 104 and the payment processing application 122. In some examples, such services are available on the merchant device 102 and / or server 116 via a separate application or functional component.

Further details relating to communication between the merchant device 102, the third party server 114, the server 116, and / or the proxy server 118 are described below. For the purposes of this discussion, actions due to the payment processing service can be performed by server 116 (eg, payment processing application 122) and actions due to the third party payment processor are performed by the third party server 114. be able to. In some examples, the actions performed by the proxy server 118 (eg, communication application 120) (for example, communication application 120) can further depend on the payment processing service. That is, in some examples, actions resulting from the payment processing service can be performed by proxy server 118 (eg, communication application 120) and / or server 116 (eg, payment processing application 122).

In some examples, the techniques described herein have been transmitted from the reader device 106 to another entity in the exemplary environment 100 and / or received by the reader device 106 from another entity in the environment 100. You can refer to the communication. In such an example, the communication can first pass through the merchant device 102. That is, in some examples, the reader device 106 does not have to be associated with connectivity so that the reader device 106 is directly with the third party server 114, server 116, and / or proxy server 118. It does not have to be possible to exchange communications. Thus, the merchant device 102 can transmit and / or receive communications on behalf of the reader device 106 and provide such communications to the intended recipient. In some examples, the communication may be encrypted and / or in a format that cannot be read by the merchant device 102 (eg, a format specific to a third-party payment processor). In at least one example, the communication exchanged between the reader device 106 and the merchant device 102 can be securely exchanged over an encryption channel using a secure session or another encryption mechanism.

In addition, the techniques described herein can refer to communications transmitted to and / or received by third party servers 114 and / or servers 116. For the purposes of this discussion, such communications may pass through proxy server 118 before being delivered to the intended recipient. That is, communications can be sent from the merchant device 102 to the third party server 114 (or vice versa), but such communications can be sent from the merchant device 102 to the proxy server 118 and then to the third party server 114 (or vice versa). Can be sent. In at least one example, the communication exchanged between the proxy server 118 and the third party server 114 can be securely exchanged over the encryption channel using the SSL protocol or another encryption mechanism. Further, if the third party server 114 sends communication to server 116 (or vice versa), such communication may be sent from the third party server 114 to the proxy server 118 and then to server 116 (or vice versa). can. In at least one example, the communication exchanged between the merchant device 102, the proxy server 118, and / or the server 116 is securely exchanged over the encryption channel using an encryption mechanism (eg, SSL). can do.

FIG. 2 illustrates the communications associated with the processing of electronic money payments described herein. FIG. 2 is illustrated with reference to FIG. 1 for convenience and ease of understanding. However, the communication or other operation described in FIG. 2 is not limited to being performed using the components described in FIG. 1, such components being the communication described in FIG. Or it is not limited to performing other actions.

In at least one example, the merchant interacts with the merchant device 102 (eg, one or more UIs presented via the POS application 104 associated with the merchant device 102) to make a transaction between the merchant and the customer. Can be started. In some examples, a transaction can be associated with one or more items offered to a customer by a merchant (eg, by purchase, transaction, lease, borrowing, etc.). In FIG. 2, the circled number 1 represents one or more dialogues between the merchant and the POS application 104 at the time of sale.

In at least one example, the customer may present a payment instrument 108 (eg, an electronic commerce payment instrument) associated with an electronic commerce balance for payment of at least a portion of a transaction. In response to the customer presenting such payment instrument 108, the merchant interacts with the merchant device 102, eg, via the UI (instead of, for example, cash, a check, or another form of bidding). You can select the payment flow. In at least one example, in response to a selection of a toll payment flow, the POS application 104 may have the merchant device 102 present a UI that allows the merchant to select electronic money as the type of charge. In at least one example, in response to the merchant providing an input indicating that the charge is an e-commerce charge, the POS application 104 sets the activation communication 202 indicating the type of charge (eg, electronic money) into a reader device. It can transmit to 106 and instructs the reader device 106 to activate an antenna associated with the technique for reading payment data from a payment instrument (eg, NFC type F). The activation communication 202 can be a signal to the reader device 106 as to which type of payment instrument is being listened to.

In some examples, in response to receiving an e-commerce selection as the type of charge, the POS application 104 may use one or more types of payments associated with an e-commerce payment instrument that the merchant may choose. Means can present a brand. In such an example, the activation communication 202 may further include payment instrument brand indications.

In at least one example, the reader device 106 may transmit the start communication 204 to the third party server 114 in response to the reception of the start communication 202. That is, in at least one example, the reader device 106 may send a communication to a third party server 114 to initiate an electronic commerce payment for a transaction (or a portion thereof). In the example where the merchant provided the payment instrument brand, the initiation communication 204 may include such an indication. In at least one example, as described above, the initiation communication 204 can be sent from the reader device 106 to the POS application 104, to the proxy server 118, and to the third party server 114. In at least one example, the communication application 120 associated with the proxy server 118 can receive the start communication 204 and can associate the identifier with the transaction (represented by the circled number 2 in FIG. 2). ing). In such an example, the identifier can be unique to the transaction and can be associated with subsequent communications associated with the transaction, while the payment for the transaction is processed (eg, the merchant device 102 is the third party server 114). Allows the proxy server 118 to maintain a connection with a third-party server 114 (instead of maintaining a connection with).

In at least one example, the third party server 114 may send a read instruction 206 to the reader device 106 in response to receiving the start communication 204. The read instruction 206 can instruct the reader device 106 to wait for a dialogue between the reader device 106 and the payment instrument 108 associated with the electronic commerce balance. That is, the read instruction 206 can communicate to the reader device 106 that a tap or other dialogue (eg, dip, swipe, etc.) is coming. In at least one example, in response to receiving the read instruction 206, the reader device 106 may send the UI communication 208 to the POS application 104. In response to such reception of UI communication 208, the POS application 104 can present a UI that prompts the customer to trigger a dialogue between the payment instrument 108 and the reader device 106, which is rounded. It is represented by the enclosed number 3.

In at least one example, the customer can trigger a dialogue between the payment instrument 108 and the reader device 106, which dialogue is represented by the circled number 4. In at least one example, the reader device 106 can read information from the payment instrument 108, which may include payment data associated with the payment instrument 108. In at least one example, the reader device 106 can encrypt the payment data and send the payment data 210 to the POS application 104. A single set of communications (eg, read instructions 206 and payment data 210) is shown, but in some examples, multiple network trips (eg, back-and-forth communications) are taken when retrieving payment data 210. Can include. In at least one example, such communication can be based on the SSL protocol for securely transmitting data between at least the proxy server 118 and the third party server 114.

In some examples, the POS application 104 can present a UI that includes an option for the merchant to cancel the transaction before the customer triggers a dialogue between the payment instrument 108 and the reader device 106. If the merchant interacts with the UI to indicate that he wants to cancel the transaction, the POS application 104 can send such an indication to the third party server 114, which will make the transaction and related payments. You can cancel. The proxy server 118 can intercept the communication indicating it, send a notification to the server 116, and cancel the transaction. After the customer triggers a dialogue between the payment instrument 108 and the reader device 106, or after the payment instrument is detected, the POS application 104 can disable the option for the merchant to cancel the transaction. You can remove that option from the UI.

In at least one example, the POS application 104 can send the first request 212 to the third party server 114 and the second request 214 to the server 116, which in some examples is the proxy server 118. Can be done via. In at least one example, the first request 212 is that the electronic commerce balance associated with the payment instrument 108 is greater than or equal to the amount the payment instrument 108 is bidding for payment (eg, at least a portion of the total cost of the transaction). The third party server 114 can be requested to provide an indication of whether or not it is. That is, the first request 212 can be an approval request for determining whether the payment instrument 108 is approved for the amount of money the payment instrument 108 is bidding for payment. In at least one example, the first request 212 has payment data 210 (eg, which can correspond to payment data 112 described above with reference to FIG. 1) and electronic money balance 110 associated with payment instrument 108. Can be associated with the indication of. Further, in some examples, the first request 212 can be associated with an indication of the amount of money the payment instrument 108 is bidding for payment (eg, the total cost of the transaction or a portion thereof).

In at least one example, the second request 214 can be associated with payment data 210 and / or transaction data, such as an identifier associated with a merchant, an identifier associated with a customer, the total cost of a transaction, and a transaction. Includes, but is not limited to, one or more items associated with, additional or alternative POS information, and the like. As mentioned above, in at least one example, such information can be encrypted. In at least one example, the second request 214 can be sent directly to the server 116 without being initially sent to the proxy server 118. In another example, the second request 214 may be sent to the proxy server 118 before being sent to the server 116. In some examples, the second request 214 can be held by the proxy server 118 (not sent to the server 116 until a later time) or returned to the proxy server 118, as shown in FIG. It can be retained by proxy server 118 until a later time.

In some examples, the first request 212 and / or the second request 214 can originate on the reader device 106 (as indicated by the dashed line) and transmit to the third party server 114 or server 116, respectively. Can be provided for merchant device 102. That is, in some examples, payment data 210 may be transmitted to the merchant device 102 with a first request 212 and / or a second request 214. Alternatively, although the first request 212 and the second request 214 are shown to originate from the POS application 104, in an alternative example, the POS application 104 can transfer the payment data 210 to the proxy server 118. , The proxy server 118 can send the first request 212 and the second request 214.

As mentioned above, the third party server 114 is the current payment instrument 108 (eg, received in the data storage associated with the third party server 114 and / or in connection with the first request 212). The electronic commerce balance can be accessed and it can be determined whether the current electronic commerce balance is greater than or equal to the amount the payment instrument 108 is bidding for payment. The third party server 114 can send a response to the first request 212. In at least one example, if the current e-commerce balance is greater than or equal to that amount, the first response 216 to the first request 212 may indicate that the payment instrument 108 is approved for e-commerce payment. can. In an example where the current e-commerce balance is less than that amount, the third party server 114 may send an indication that the payment instrument 108 is not approved for that amount. That is, the response to the first request 212 in such an example can indicate that the payment instrument 108 has not been approved for that amount. Such indications are not shown in FIG. 2, but are described in more detail below.

In at least one example, the first response 216 can be associated with a new e-commerce balance. In some examples, the first response 216 may include an instruction for the reader device 106 to write a new e-commerce balance to the payment instrument 108 or to associate it with the payment instrument 108. In at least one example, the new e-commerce balance can be at least partially based on the old e-commerce balance and the amount the payment instrument 108 is bidding for payment. In response to receiving the first response 216, the reader device 106 may write a new e-commerce balance to the payment instrument 108. That is, the reader device 106 can associate the new electronic commerce balance with the payment instrument 108.

In response to writing the new e-commerce balance to the payment instrument 108, the reader device 106 may send write confirmation 218 to the third party server 114. In at least one example, in response to receiving write confirmation 218, the third-party server 114 (s) pays the new e-commerce balance (eg, in the data storage associated with it) 108. Can be associated with the indication of. In at least one example, in response to the receipt of write confirmation 218, the third party server 114 (s) may send the payment result 220 to the reader device 106. In one example, the payment result 220 can indicate whether the electronic commerce payment was successful or unsuccessful, and may include an instruction to output an indication that the payment was successful (or unsuccessful). As indicated by the circled number 5, the reader device 106 can output a visual and / or audio indication that the payment was successful (or unsuccessful). Further, based at least in part on the receipt of write confirmation 218, the third party server 114 clears the payment and, as described above, to the server 116 associated with the payment processing service (eg, the payment instrument 108 for payment). You can transfer the funds (at the amount bid on). In at least one example, the payment can be associated with an identifier associated with the merchant (eg, a terminal identifier) so that the payment processing application 122 determines which merchant is associated with the funds received. And such received funds or parts thereof can be associated with the merchant's account maintained by the payment processing service, as described above.

For the purposes of this discussion, a "successful" e-commerce payment is that (i) if the e-commerce balance is greater than or equal to the amount of the transaction for which the payment instrument 108 is provided, (ii) the payment instrument 108 has a new e-commerce balance. If written or otherwise associated, and (iii) the third-party server 114 facilitates the transfer of funds from the e-commerce balance to the intended recipient (eg, for a merchant). Payment processing service), which can be electronic money payment. A "failed" e-commerce payment is (i) if the e-commerce balance is less than the amount of the transaction for which the payment instrument 108 is provided, (ii) a new e-commerce balance has not been written to the payment instrument 108. Or otherwise not associated (or associated write confirmation was not received during the timeout period) and / or (iii) the third party server 114 from the e-commerce balance to the intended recipient. If it does not facilitate the transfer of funds (eg, payment processing services for merchants), it could be an attempted e-commerce payment.

In some examples, write confirmation 218 may not be received (eg, by (eg, one or more) third party servers 114), so payment result 220 is (POS application 104 and / or reader device). It does not have to be received (by 106). In such an example, if write confirmation 218 is not received and / or payment result 220 is not received, an error handling process is performed to ensure that the e-commerce balance associated with payment instrument 108 is accurate. You can start. Additional details related to such an error handling process are described below.

As mentioned above, in at least one example, the communication application 120 associated with the proxy server 118 can monitor communication from the third party server 114, as represented by the number 6 listed. That is, in at least one example, the communication application 120 can decode the communication transmitted from the third party server 114 to determine whether the payment result 220 indicates that the electronic commerce payment was successful or unsuccessful. .. In at least one example, in response to determining that the payment result 220 indicates that the electronic money payment was successful, the communication application 120 sends the payment confirmation 222 to the server 116 to confirm that the payment was successful. Can be sent to. In such an example, the payment confirmation 222 can be a response to a second request 214 (eg, from a proxy server 118).

In some examples, if the proxy server 118 holds the second request 214, the proxy server 118 can hold the second request 214 until the payment confirmation 222 is sent to the server 116. In such an example, the proxy server 118 may send the second request 214 and the payment confirmation 222 to the server 116 simultaneously or substantially simultaneously. In another example, the proxy server 118 confirms payment without sending the second request 214 (because, for example, the server 116 has already received the second request 214 and sent it back to the proxy server 118). 222 can be transmitted. In an example where payment is unsuccessful, the communication application 120 may send such an indication to server 116 instead of payment confirmation 222, or if proxy server 118 has not sent a second request 214. Can refrain from sending a second request 214 and payment confirmation 222.

In response to receiving the payment confirmation 222, the payment processing application 122 associated with the server 116 may send a second response 224 to the second request 214. That is, based at least in part on the receipt of the payment confirmation 222, the payment processing application 122 can record the transaction and send such an indication to the POS application 104. In at least one example, the POS application 104 can output a UI that presents information related to electronic commerce payments via the merchant device 102, as represented by the circled number 7. In some examples, the UI can indicate that the e-commerce payment was successful and can include the current e-commerce balance (written to the payment instrument 108 by the reader device 106). In some examples, the UI can be associated with a digital receipt.

In some examples, in order to reduce the size of a data packet (eg, bytes) being transmitted over the communications described herein, the reader device 106 (eg, the data packet to proxy server 118, The data packet size can be compressed before sending the data packet to the POS application 104 by encrypting the data associated with the data packet (for further transmission to the third party server 114 and / or the server 116). In at least one example, by reducing the size of data packets transmitted over the communications described herein, such data packets may be transmitted faster than if they were uncompressed in size. can.

In addition, to speed up the processing of e-commerce payments, in some examples, proxy server 118 communicates with other entities in environment 100 without waiting for a response (eg, without affecting subsequent communication). Can be sent. For example, in response to receiving the payment result 220, the proxy server 118 sends an indication to the third party server 114 that the process is complete, without waiting for a response from the reader device 106 to indicate that the process is complete. can do.

FIG. 2 is described with reference to a card presentation transaction. A card presentation transaction is a transaction in which both the customer and the payment instrument are physically present at the time of the transaction. Card presentation transactions are processed by swipes, dips, taps, or any other dialogue between a physical payment instrument (eg, a card) or other existing payment instrument and a reader device such as the reader device 106. The reader device 106 may be able to obtain payment data from the payment instrument.

In an alternative example, customers and merchants can participate in transactions that are non-card presentation (CNP) transactions. A CNP transaction is a transaction in which the card or other payment instrument is not physically present at the time of sale, and as a result, payment data can be manually keyed in (eg, by a merchant, purchaser, etc.) or payment. Data can be recalled from the card-on-file data store to complete the transaction. In such an example, instead of sending a read instruction 206, the third-party server 114 may request payment data to be entered via the UI, and / or the third-party server 114 would otherwise. For example, the merchant device 102 (or payment processing service) may be requested to provide payment data (eg, via a card-on-file). Further, in such an example, it may be optional to write the new e-commerce balance to the payment instrument.

In some examples, the POS application 104 can exchange communications with the server 116 without using the reader device 106 to facilitate dialogue between the customer and the merchant. For example, the merchant can interact with the POS application 104 (eg, via the UI presented via the merchant device 102) to request a refund and / or cancellation of the transaction. In such an example, the POS application 104 can send a refund and / or cancellation indication to the proxy server 118, which communicates directly with the third party server 114 to issue a refund and / or transaction cancellation. can do.

3-8 are described with reference to FIG. 1 for convenience and for ease of understanding. However, the processes described in FIGS. 3-8 are not limited to being performed using the components described in FIG. 1, and such components are the processes described in FIGS. 3-8. Is not limited to executing.

Processes 300-800 represent a set of blocks in a logical flow graph that represent a sequence of operations that can be performed by hardware, software, or a combination thereof. In the context of software, it represents a computer-executable instruction stored on one or more computer-readable storage media that performs the described actions when the block is executed by the processor. In general, computer-executable instructions include routines, programs, objects, components, data structures, etc., performing specific functions or implementing specific abstract data types. The order in which the behavior is described is not intended to be construed as limiting, and any number of blocks described may be combined in any order and / or in parallel to implement the process. In some embodiments, one or more blocks of the process can be omitted altogether.

3-6 show exemplary e-commerce payment processes 300-600 associated with each of the entities described in FIG. 1, FIG. 3A and 3B show e-commerce payments from the perspective of reader device 106. An exemplary process 300 for processing is shown. 4A-4C show an exemplary process 400 for processing electronic commerce payments in terms of the merchant device 102. 5A-5C show an exemplary process 500 for processing electronic commerce payments from the perspective of proxy server 118. FIG. 6 shows an exemplary process 600 for processing e-commerce payments from the perspective of server 116.

3A and 3B show an exemplary process 300 for processing electronic commerce payments from the perspective of reader device 106.

Block 302 indicates that the reader device associated with the merchant device receives an instruction to activate the technology associated with the electronic commerce (e-money) payment. As mentioned above, in at least one example, the merchant interacts with the merchant device 102 (eg, one or more UIs presented via the POS application 104 associated with the merchant device 102) to interact with the merchant and the customer. You can start trading with. In at least one example, the customer may present a payment instrument 108 associated with an e-commerce balance for payment of at least a portion of a transaction. In at least one example, in response to the merchant providing an input indicating that the charge is an e-commerce charge, the POS application 104 sends a communication indicating the type of charge (eg, electronic money) to the reader device 106. It can transmit and commands the reader device 106 to activate an antenna associated with the technique for reading payment data from a payment instrument (eg, NFC type F). This activation communication can signal the reader device 106 which type of payment instrument is being listened to. In response to receiving such communications, the reader device 106 can activate the appropriate technology.

Block 304 indicates that the merchant device sends an indication that a transaction between the merchant and the customer has begun, and the transaction is associated with an e-commerce payment. In at least one example, in response to receiving the boot communication, the reader device 106 may send the communication to the third party server 114 to indicate that the transaction has started. That is, in at least one example, the reader device 106 may send a communication to a third party server 114 to initiate an electronic commerce payment for a transaction (or a portion thereof). In at least one example, as described above, the communication for initiating the electronic commerce payment can be sent from the reader device 106 to the POS application 104, to the proxy server 118, and then to the third party server 114.

Block 306 indicates that it receives a command from the merchant device (s) to wait for a dialogue with the payment instrument. In at least one example, the third party server 114 may send a read instruction to the reader device 106 after the communication indicating that the transaction has started is transmitted by the reader device 106. The read command can instruct the reader device 106 to wait for a dialogue between the reader device 106 and the payment instrument 108 associated with the electronic commerce balance. That is, the read instruction can communicate to the reader device 106 that a tap or other dialogue (eg, dip, swipe, etc.) is coming. In at least one example, in response to receiving a read instruction, the read device 106 can prepare for the dialogue (eg, listen to the dialogue). Further, in at least one example, in response to receiving a read instruction, the reader device 106 sends a communication to the POS application 104 to the POS application 104 between the payment instrument 108 and the reader device 106 to the customer. You can have a UI presented that tells you to trigger a dialogue. In response to receiving such UI communication, the POS application 104 can present the UI via the merchant device 102.

Block 308 indicates whether a dialogue between the payment instrument and the reader device has been detected. In at least one example, the customer can trigger a dialogue between the payment instrument and the reader device 106. In at least one example, the reader device 106 can read information from the payment instrument 108, which may include payment data associated with it. In at least one example, the reader device 106 can encrypt the payment data as shown in block 310 and can send the payment data to the merchant device 102 as shown in block 312. In at least one example, such encryption can include encrypting payment data in a format specified by a third-party payment processor. In additional or alternative examples, such encryption can include encrypting payment data using a private key or other SSL encryption format. As mentioned above, in some examples, the payment data can be associated with a first request sent to the third party server 114 and / or a second request sent to the server 116. In another example, payment data can be sent to the merchant device 102, which can generate a first request and / or a second request.

If the dialogue has not yet been received, process 300 can return to block 308 and wait for the dialogue between the payment instrument 108 and the reader device 106. In some examples, the reader device 106 may wait for a dialogue until it receives an instruction that the transaction has been canceled or until the timeout period expires.

Block 314 indicates whether an instruction to write a new e-commerce balance to the payment instrument has been received. As mentioned above, in at least one example, in response to receiving payment data from the reader device 106, the POS application 104 sends a first request to a third party server 114 and a second request to server 116. Can be sent to. As mentioned above, the first request can be an approval request for the payment instrument 108 to determine whether the payment instrument 108 is approved for the amount bid for the payment. In one example, the third party server 114 can access the current e-commerce balance of the payment instrument 108 to determine if the current e-commerce balance is greater than or equal to the amount the payment instrument 108 is bidding on for payment. It can be determined. If the current electronic commerce balance is greater than or equal to that amount, the third party server 114 may send a first response to the first request. The first response can indicate that the payment instrument 108 is approved for electronic money payment. In at least one example, the first response can be associated with a new e-commerce balance. In some examples, the first response may include an instruction for the reader device 106 to write a new e-commerce balance to the payment instrument 108 or otherwise associate it with the payment instrument 108. In at least one example, if the first response (and the instruction to write to the payment instrument 108) is received, process 300 can proceed to FIG. 3B. If the first response (and the instruction to write to the payment instrument 108) is not received, process 300 can return to block 314 and wait for the first response. In some examples, the reader device 106 may wait for the first response until it receives an indication that the transaction has been canceled or until the timeout period has elapsed.

Block 316 indicates writing a new e-commerce balance to the payment instrument. In response to receiving the first response, the reader device 106 may write the new e-commerce balance to the payment instrument 108. That is, the reader device 106 can associate the new electronic commerce balance with the payment instrument 108.

Block 318 indicates sending a confirmation to the merchant device that a new e-commerce balance has been written to the payment instrument. In at least one example, in response to writing a new e-commerce balance to the payment instrument 108, the reader device 106 writes the new e-commerce balance to the payment instrument 108 or otherwise associates it with the payment instrument 108. A communication confirming that has been done (for example, write confirmation) can be transmitted to the third party server 114. That is, the reader device 106 can send the write confirmation to the merchant device 102, and the POS application 104 can send the write confirmation to the proxy server 118 (which can send the write confirmation to the third party server 114). Can be done. In at least one example, in response to receiving a write confirmation, the third party server 114 may settle the payment and, as described above, transfer the funds to the server 116 associated with the payment processing service. can.

Block 320 indicates whether or not the payment result has been received. In at least one example, in response to receiving a write confirmation, the third party server 114 may send the payment result to the reader device 106 (eg, via the proxy server 118 and the merchant device 102). In one example, the payment result can indicate whether the electronic commerce payment was successful or unsuccessful, and can include an instruction to output an indication of whether the electronic commerce payment was successful. In at least one example, as shown in block 322, in response to receiving a successful payment result, the reader device 106 can output an indication that the electronic commerce payment was successful. In some examples, the indication can be a visual and / or audio indication that the electronic money payment was successful.

Figures 3A and 3B cover processes related to successful card presentation transactions. In an example where the current e-commerce balance is less than the amount, the third party server 114 may send an indication that the payment instrument 108 is not approved for the amount. In such an example, the reader device 106 can receive an indication that the payment instrument 108 has not been approved and can output such an indication. In such an example, the payment of electronic money and / or the transaction can be cancelled. Similarly, the payment result can indicate that the e-commerce payment has failed for the above reasons. In such an example, the reader device 106 can receive a "failure" notification and output such an indication. In some examples, e-commerce payments and / or transactions can be cancelled.

As mentioned above, in the alternative example, customers and merchants can participate in transactions that are CNP transactions. In such an example, the reader device 106 may not be used in the payment processing flow, instead the merchant may send payment data via input to the POS application 104 (eg, the UI associated with it). Can be provided.

4A-4C show an exemplary process 400 for processing electronic commerce payments in terms of the POS application 104.

Block 402 indicates that the merchant device receives an indication of the transaction between the merchant and the customer, and the transaction is associated with an electronic money (e-money) payment. As mentioned above, in at least one example, the merchant interacts with the merchant device 102 (eg, one or more UIs presented via the POS application 104 associated with the merchant device 102) with the merchant. You can start a transaction with a customer. In at least one example, the customer may present a payment instrument 108 associated with an e-commerce balance for payment of at least a portion of a transaction. In response to the customer presenting such a payment instrument 108, the merchant interacts with the POS application 104, for example via the UI (eg, instead of cash, a check, or another form of bidding). ) You can select the payment flow. In at least one example, in response to a selection of toll payment flows, the POS application 104 can be made to present a UI that allows the merchant to select e-commerce as the type of toll.

Block 404 indicates sending an instruction to activate a technique related to electronic commerce payment to a reader device associated with a merchant device. In at least one example, in response to the merchant providing an input indicating that the charge is an e-commerce charge, the POS application 104 sends a communication indicating the type of charge (eg, electronic money) to the reader device 106. It can transmit and commands the reader device 106 to activate an antenna associated with the technique for reading payment data from a payment instrument (eg, NFC type F). This activation communication can be a signal to the reader device 106 as to which type of payment instrument should be heard.

Block 406 indicates that the transaction indication is sent to the proxy server. In at least one example, in response to the reception of the boot communication 202, the reader device 106 may send a communication to the third party server 114 to indicate that the transaction has started. That is, in at least one example, the reader device 106 may send a communication to a third party server 114 to initiate an electronic commerce payment for a transaction (or a portion thereof). In at least one example, as described above, communication for initiating electronic commerce payment can be sent from the reader device 106 to the POS application 104, which can send the indication to the proxy server 118. This eventually sends the application to the third party server 114.

Block 408 indicates determining whether a read instruction has been received. In at least one example, the third-party server 114 may send a read command to the reader device 106 via the POS application 104 after a communication indicating that a transaction has begun has been sent to the proxy server 118. The read command can instruct the reader device 106 to wait for a dialogue between the reader device 106 and the payment instrument 108 associated with the electronic commerce balance. That is, the read instruction can communicate to the reader device 106 that a tap or other dialogue (eg, dip, swipe, etc.) is coming. In at least one example, the POS application 104 can receive a read instruction and transfer the read instruction to the reader device 106. In at least one example, in response to receiving a read instruction, the reader device 106 sends a communication to the POS application 104 to have the POS application 104 interact with the payment instrument 108 and the reader device 106. A UI that prompts the customer to provoke can be presented via the merchant device 102. In response to receiving such communications, the POS application 104 can present the UI via the merchant device 102.

If the read instruction has not yet been received, process 400 can return to block 408 and wait for the read instruction. In some examples, the POS application 104 can take advantage of a timeout period, which (if no read instructions are received before the timeout period has elapsed) can time out the transaction. In some examples, the POS application 104 may retry sending the transaction indication (eg, to the proxy server 108) one or more times, the number of times being configurable. In some examples, the POS application 104 can send an indication to the proxy server 118 indicating that the read instruction has not yet been received and / or the timeout period has expired, which is a third party server. Instructions can be provided to 114 and / or server 116. In some examples, such indications can cause payments and / or transactions to be cancelled.

Block 410 indicates whether payment data related to the payment instrument is received. In at least one example, the customer can trigger a dialogue between the payment instrument 108 and the reader device 106. In at least one example, the reader device 106 can read information from the payment instrument 108, which may include payment data associated with it. In at least one example, the POS application 104 can determine if such payment data has been received. Upon receiving the payment data, process 400 can proceed as shown in FIG. 4B. That is, upon receiving the payment data, the POS application 104 sends a first request related to the payment data to the proxy server 118 (which can be sent to the third party server 114), as shown in block 412. As shown in block 414, a second request related to payment data can be sent to the server 116.

As mentioned above, the first request can be an approval request for the payment instrument 108 to determine whether the payment instrument 108 is approved for the amount bid for the payment. In at least one example, the first request can be associated with payment data (eg, read via payment instrument 108). In some examples, the first request can be associated with the current e-commerce balance associated with the payment instrument 108 and the amount the payment instrument 108 is bidding for payment. In at least one example, the first request can be sent to the proxy server 118, which can send the first request to the third party server 114 upon receipt. In some examples, the proxy server 118 can associate the first request with an identifier and / or encrypt the first request before sending it to the third party server 114.

As mentioned above, the second request can be associated with payment data and / or transaction data, such as the identifier associated with the merchant, the identifier associated with the customer, the total cost of the transaction, and the transaction. Includes, but is not limited to, one or more items, additional or alternative POS information, and the like. As mentioned above, in some examples, the second request can be sent to the server 116, which can return the second request to the proxy server 118 until the payment result is received. In such an example, the POS application 104 can send a second request to the proxy server 118, which can hold the second request until the payment result is received. As mentioned above with reference to FIG. 2, in some examples, the second request is sent through the proxy server 118 to the server 116 and to the proxy server 118 to hold the payment result until it is received. Can be returned. Then, when the payment result is received, the proxy server 118 can send the second request and the payment confirmation to the server 116 at the same time or almost at the same time. In some examples, the second request does not have to be sent to server 116 (s), but the response to the second request (from proxy server 118 (s)). As payment confirmation can be provided to the server 116 (s).

As mentioned above, in some examples, the first and / or second request can originate on the reader device 106 and to the merchant device 102 for transmission to the third party server 114 or server 116, respectively. Can be provided. That is, in some examples, payment data may be transmitted to the merchant device 102 with a first request and / or a second request.

If the dialogue has not yet been received, process 400 can return to block 410 and wait for payment data. In some examples, the POS application 104 can take advantage of a timeout period, which (if payment data is not received before the timeout period has elapsed) can time out the transaction. In some examples, the POS application 104 may retry sending a read request one or more times (eg, to the reader device 106), the number of times being configurable. In some examples, the POS application 104 can send an indication to the proxy server 118 indicating that payment data has not been received and / or the transaction has timed out, which is the third party server 114 and / Or the indication can be provided to the server 116. In some examples, such indications can cause payments and / or transactions to be cancelled.

Block 416 indicates whether the first response (to the first request) has been received. As mentioned above, in response to the receipt of the first request, the third party server 114 can access the current e-commerce balance of the payment instrument 108, and the current e-commerce balance is paid by the payment instrument 108. It is possible to determine if it is more than or equal to the amount bid for. If the current electronic commerce balance is greater than or equal to the above amount, the third party server 114 may send the first response to the first request. In such an example, the first response can indicate that the payment instrument 108 is approved for electronic money payment. In at least one example, if the first response is received, is the POS application 104 approved for the payment instrument 108 presented in connection with the electronic commerce payment for the transaction, as shown in block 418? You can judge whether or not. In at least one example, the first response can be associated with a new e-commerce balance.

If no first response is received, process 400 can return to block 416 and wait for the first response. In some examples, the POS application 104 can take advantage of a timeout period, which (if the first response is not received before the expiration of the timeout period) allows the transaction to time out. In some examples, the POS application 104 may retry sending the first request one or more times (eg, through the proxy server 118 to the third party server 114), the number of times being configurable. Is. In some examples, the POS application 104 can send an indication that the first response has not yet been received and / or that the transaction has timed out to the proxy server 118, which is a third party. The indication can be provided to the server 114 and / or the server 116. In some examples, such indications can cause payments and / or transactions to be cancelled.

Block 420 indicates that the reader device is to write a new e-commerce balance to the payment instrument. In some examples, the first response may include an instruction for the reader device 106 to write a new e-commerce balance to the payment instrument 108 or otherwise associate it with the payment instrument 108. If the first response indicates that the payment instrument 108 presented in connection with the electronic commerce payment for the transaction is approved, the POS application 104 forwards the first response to the reader device 106. This causes the reader device 106 to write the new e-commerce balance to the payment instrument 108. The process 400 can then proceed to FIG. 4C.

Block 422 indicates that the customer is presented with an indication that the payment of electronic money has failed. In at least one example, the first response can indicate that the payment instrument 108 has not been approved for an electronic commerce transaction. That is, if the electronic commerce balance associated with the payment instrument 108 is less than the amount for which the payment instrument 108 is being bid, the electronic commerce payment may not be approved. In such an example, the POS application 104 can cause the merchant device 102 (eg, via the display of the merchant device 102) to present an indication that the electronic commerce payment has failed. In some examples, the POS application 104 can forward the first response to the reader device 106 to notify the reader device 106 that the electronic commerce payment has failed. In some examples, the POS application 104 can be made to present such an indication in response to an instruction from the reader device 106.

In some examples, as described above, if the proxy server 118 holds the second request until the payment result is received, the first response indicates that the electronic money payment has failed (eg, payment). (Because means 108 has not been approved), the proxy server 118 can refrain from sending the second request to the server 116, and / or give the server 116 an indication that the electronic money payment has failed. It can transmit, so that the server 116 can indicate such a thing.

Block 424 indicates whether a confirmation has been received that a new e-commerce balance has been written to the payment instrument. As mentioned above, in at least one example, the reader device 106 may send a write confirmation to a third party server 114 in response to writing a new e-commerce balance to the payment instrument 108. In at least one example, the reader device 106 can send write confirmations to the POS application 104, write confirmations to the proxy server 118, as shown in block 426, and finally write confirmations to third parties. It can be transferred to the party server 114. In at least one example, in response to receiving a write confirmation, the third party server 114 may settle the payment and transfer the funds to the server 116 associated with the payment processing service. The third party server 114 can send the payment result to the reader device 106. The payment result can indicate whether the electronic commerce payment was successful or unsuccessful. As described above, the POS application 104 can receive the payment result from the proxy server 118 and send the payment result to the reader device 106, as shown in block 430.

In at least one example, if no write confirmation is received, process 400 can return to block 424 and wait for write confirmation. In some examples, the POS application 104 can take advantage of a timeout period, which (if no write confirmation is received before the expiration of the timeout period) allows the transaction to time out. In some examples, the POS application 104 may retry transmitting a write instruction (eg, to the reader device 106) one or more times, the number of times being configurable. In some examples, the POS application 104 can send an indication that a write confirmation has not yet been received and / or an indication that the transaction has timed out to the proxy server 118, which is the third party server 114. And / or the indication can be provided to the server 116. In some examples, such indications can cause payments and / or transactions to be cancelled.

Further, in at least one example, if no payment result is received, process 400 can return to block 428 and wait for the payment result. In some examples, the POS application 104 can take advantage of a timeout period, which (if the payment result is not received before the expiration of the timeout period) can time out the transaction. In some examples, the POS application 104 may retry sending write confirmations (eg, via proxy server 118 to third party server 114) one or more times, the number of times being configurable. .. In at least one example, if the POS application 104 does not receive a payment result before the timeout period elapses, the POS application 104 determines that an error has occurred and the POS application 104 sends such an indication to the proxy server 118. It can transmit, which can provide an indication to a third party server 114 and / or server 116. Such indications can trigger the error handling process described below.

Block 432 indicates whether a second response (to the second request) has been received. As mentioned above, in at least one example, the communication application 120 associated with the proxy server 118 can monitor the communication from the third party server 114. That is, in at least one example, the communication application 120 can decode the communication transmitted from the third party server 114 to determine whether a success or failure notification has been transmitted. In at least one example, the communication application 120 asks the server 116 to confirm the payment to confirm that the payment was successful, at least in part based on determining that the success notification was sent via the payment result. Can be sent. As mentioned above, in at least one example, if the second request is held by the proxy server 118, the communication application 120 can send the payment confirmation and the second request simultaneously or substantially simultaneously. In another example, the communication application 120 can send a payment confirmation without sending a second request.

In response to receiving the payment confirmation, the payment processing application 122 of the server 114 can send a second response to the second request. That is, the payment processing application 122 can record the transaction and send such an indication to the POS application 104 via the proxy server 118, at least in part based on the receipt of the payment confirmation. When the second response is received, the POS application 104 can determine if the second response indicates that the transaction was recorded by the payment processing service, as shown in block 434.

In at least one example, if no second response is received, process 400 can return to block 432 and wait for the second response. In some examples, the POS application 104 can take advantage of a timeout period, which (if no second response is received before the expiration of the timeout period) allows the transaction to time out. In some examples, the POS application 104 can send an indication to the proxy server 118 indicating that a second response has not yet been received and / or that a timeout period has expired, which is a third party. Applications can be provided to the party server 114 and / or the server 116. In some examples, such indications can cause payments and / or transactions to be cancelled.

Block 436 indicates that it presents an indication that the transaction has been completed. In at least one example, the POS application 104 outputs the UI through the merchant device 102, at least in part, based on the transaction recorded by the payment processing service (and the second response indicating such). Can be made to. The UI can include information related to e-commerce payments. In some examples, the UI can include an indication that the e-commerce payment was successful and the current e-commerce balance (as written to the payment instrument 108 by the reader device 106). As mentioned above, in at least one example, the UI can be a digital receipt.

Block 438 indicates that it presents an indication that the transaction has failed. In at least one example, the POS application 104 fails the transaction, at least partially based on the transaction not recorded by the payment processing service (and the second response indicating such) and / or the transaction timeout. You can output a UI that indicates that you have done so. In some examples, the information associated with the UI may indicate the cause of the failure. In such an example, a third-party payment processor approves the payment (eg, the first response is associated with a success notification), but the transaction fails through the payment processing service (eg, the second response fails). (Notice), the POS application 104 can urge the merchant to request a refund. Such a refund request can be sent to server 116 for processing.

Process 400 includes operations related to sending a first request and a second request, but as mentioned above, in an alternative example, the POS application 104 may transfer payment data to a proxy server 118. The proxy server 118 can send the first request and the second request. In such an example, blocks 412 and 414 may be omitted from process 400, but process 400 can proceed as described otherwise.

Further, in some examples, as described above, if the proxy server 118 holds the second request until the payment result is received and the payment result indicates that the e-commerce payment has failed, the proxy server 118 , It is possible to refrain from sending the second request to the server 116. In such an example, the process 400 can exit at block 430 and send the payment result indication to the reader device 106. That is, in some cases, it may not be necessary to wait for the second response because the second request may not be sent due to the failure of the electronic commerce payment.

5A-5C show an exemplary process 500 for processing electronic commerce payments from the perspective of proxy server 118.

Block 502 indicates that it receives an indication of the transaction between the merchant and the customer at the proxy server and from the merchant device. As mentioned above, in at least one example, the merchant interacts with the merchant device 102 (eg, one or more UIs presented via the POS application 104 associated with the merchant device 102) with the merchant. You can start a transaction with a customer. In at least one example, the customer may present a payment instrument 108 associated with an e-commerce balance for payment of at least a portion of a transaction. As mentioned above, in at least one example, in response to the merchant providing an input indicating that the charge is an electronic money charge, the POS application 104 communicates indicating the type of charge (eg, electronic money). Can be transmitted to the reader device 106, instructing the reader device 106 to activate an antenna associated with the technique for reading payment data from a payment instrument (eg, NFC type F). In at least one example, in response to receiving the boot communication, the reader device 106 may send the communication to the third party server 114 to indicate that the transaction has started. That is, in at least one example, the reader device 106 may send a communication to a third party server 114 to initiate an electronic commerce payment for a transaction (or a portion thereof). In at least one example, as described above, the communication for initiating the electronic commerce payment can be sent from the reader device 106 to the POS application 104, which can send the indication to the proxy server 118. ..

Block 504 indicates that the identifier is associated with the transaction. In at least one example, the communication application 120 associated with the proxy server 118 can receive the indication and associate the identifier with the transaction. In such an example, the identifier can be unique to the transaction and can be associated with subsequent communications associated with the transaction, while the proxy server 118 processes the e-commerce payment for the transaction. Allows the POS application 104 to maintain a connection with the third party server 114 (instead of maintaining a connection with the third party server 114, for example).

Block 506 indicates sending an indicator of a transaction having an identifier to a third party server (eg, associated with a third party payment processor). In at least one example, the communication application 120 can send an indicator of a transaction having an identifier to a third party server 114. In some examples, the communication application 120 can encrypt the indication before sending the communication to the third party server 114. In some examples, the indication may already be encrypted (eg, by reader device 106).

Block 508 indicates whether a read instruction has been received. In at least one example, the third party server 114 may send a read command to the reader device 106 after the communication indicating that the transaction has started has been sent to the third party server 114. In at least one example, as shown in block 510, the communication application 120 may receive a read instruction and send the read instruction to the merchant device 102 (eventually providing the read instruction to the reader device 106). Yes (it ultimately provides a read instruction to the reader device 106). The read command can instruct the reader device 106 to wait for a dialogue between the reader device 106 and a payment instrument related to the electronic commerce balance, such as the payment instrument 108. That is, the read instruction can communicate to the reader device 106 that a tap or other dialogue (eg, dip, swipe, etc.) is coming.

If the read instruction has not yet been received, process 500 can return to block 508 and wait for the read instruction. In some examples, the communication application 120 may take advantage of a timeout period, which (if no read instruction is received before the timeout period has elapsed) to time out the transaction. In some examples, the communication application 120 may retry sending the transaction indication to the third party server 114 one or more times, the number of times being configurable. In some examples, the communication application 120 provides an indication that the read instruction has not yet been received and / or that the timeout period has expired, such as the POS application 104, the third party server 114, and / or the server 116. Can be sent to. In some examples, such indications can cause payments and / or transactions to be cancelled.

Block 512 indicates whether the first request has been received from the merchant device. As mentioned above, in at least one example, the customer can trigger a dialogue between the payment instrument 108 and the reader device 106. In at least one example, the reader device 106 can read information from the payment instrument 108, which may include payment data associated with it. Upon receiving the payment data, the POS application 104 can send a first request associated with the payment data to the communication application 120 (which can be sent by the communication application 120 to the third party server 114). As described above, the first request is that the payment instrument 108 presented in connection with the payment of electronic money for a transaction is approved for the amount of money the payment instrument 108 is bidding for payment. It can be an approval request to determine whether or not. As shown in block 514, the communication application 120 can determine that the first request has been received and send the first request to the third party server 114. In at least one example, the proxy server 118 may send the first request to the third party server 114 upon receipt. In some examples, the proxy server 118 can associate the first request with an identifier and / or encrypt the first request before sending it to the third party server 114. Next, process 500 can proceed to block 516 of FIG. 5B.

If the first request has not yet been received, process 500 can return to block 510 and wait for the first request. In some examples, the communication application 120 can take advantage of a time-out period (if the first request is not received before the time-out period has elapsed), which can time out the transaction. In some examples, the communication application 120 may retry sending the read instruction to the POS application 104 one or more times, the number of times being configurable. In some examples, the communication application 120 provides an indication that the first request has not yet been received and / or that the transaction has timed out, the POS application 104, the third party server 114, and / or the server. It can be sent to 116. In some examples, such indications can cause payments and / or transactions to be cancelled.

Block 516 indicates whether the second request has been received from the merchant device. As mentioned above, the second request can be associated with payment data and / or transaction data, such as the identifier associated with the merchant, the identifier associated with the customer, the total cost of the transaction, and the transaction. Includes, but is not limited to, one or more items, additional or alternative POS information, and the like. The communication application 120 can determine that a second request has been received and, in some examples, can send the second request to the server 116, as shown in block 518. Block 518 is shown by the dashed line, but in some examples the communication application 120 can hold the second request until a later time, as shown below (ie, the second). Do not send the request to server 116). In some examples, the communication application 120 may send a second request to the server 116 upon receipt, which server 116 sends the second request to the proxy server 118 for a later time. Can be sent back. In some examples, the second request can be sent directly to the server 116 without being sent to the proxy server 118, which can receive the second request from the server 116. As mentioned above, in some examples, the second request may be retained by proxy server 118 until the payment result is received. In some examples where the proxy server 118 holds the second request, the proxy server 118 can send the second request and payment confirmation simultaneously or nearly simultaneously, as described below. In some examples, if the proxy server 118 holds the second request, the proxy server 118 does not send the second request back to the server 116, as described below (eg, the second request). You can send a payment confirmation (in response to).

If the second request has not yet been received, process 500 can return to block 516 and wait for the second request. In some examples, the communication application 120 can take advantage of a time-out period (if a second request is not received before the time-out period has elapsed), which can time out the transaction. In some examples, the communication application 120 may retry sending the read request to the POS application 104 one or more times, the number of times being configurable. In some examples, the communication application 120 provides an indication that the second request has not yet been received and / or that the transaction has timed out, the POS application 104, the third party server 114, and / or the server. It can be sent to 116. In some examples, such indications can cause payments and / or transactions to be cancelled.

Block 520 indicates whether the first response (to the first request) has been received. As mentioned above, in response to the receipt of the first request, the third party server 114 can access the current e-commerce balance of the payment instrument 108, and the current e-commerce balance is paid by the payment instrument 108. It is possible to determine if it is more than or equal to the amount bid for. If the current e-commerce balance is greater than or equal to the amount, the third-party server 114 may send a first response to a first request indicating that the payment instrument 108 is approved for e-commerce payment. .. In some examples, the first response may include an instruction for the reader device 106 to write a new e-commerce balance to the payment instrument or otherwise associate it with the payment instrument. In at least one example, if the first response is received, the communication application 120 can send the first response to the merchant device 102, as shown in block 522.

If the first response is not received, process 500 can return to block 520 and wait for the first response. In some examples, the communication application 120 may utilize a timeout period, which (if the first response is not received before the expiration of the timeout period) allows the transaction to time out. In some examples, the communication application 120 may retry sending the first request to the third party server 114 one or more times, the number of times being configurable. In some examples, the communication application 120 provides an indication that the first response has not yet been received and / or that the transaction has timed out, the POS application 104, the third party server 114, and / or the server. It can be sent to 116. In some examples, such indications can cause payments and / or transactions to be cancelled.

Block 524 indicates whether a write confirmation has been received. As mentioned above, in response to receiving the first response, the reader device 106 may write the new e-commerce balance to the payment instrument 108 or otherwise associate it with the payment instrument 108. In response to writing the new e-commerce balance to the payment instrument 108 or otherwise associating it, the reader device 106 may send a write confirmation to the third party server 114 via the proxy server 118. In at least one example, as shown in block 526, the communication application 120 may receive a write confirmation and send the write confirmation to a third party server 114. In some examples, the proxy server 118 may associate a write confirmation with an identifier and / or encrypt the write confirmation before sending it to the third party server 114. Process 500 can be continued in FIG. 5C.

If the write confirmation has not yet been received, process 500 can return to block 524 and wait for the write confirmation. In some examples, the communication application 120 may take advantage of a timeout period, which (if no write confirmation is received before the timeout period expires) allows the transaction to time out. In some examples, the communication application 120 may retry sending a first response (and associated write instruction) to the POS application 104 one or more times, the number of times being configurable. In some examples, the communication application 120 sends an indication to the POS application 104, the third party server 114, and / or the server 116 that the write confirmation has not yet been received and / or the transaction has timed out. Can be sent. In some examples, such indications can cause payments and / or transactions to be cancelled.

Block 528 indicates whether a payment result has been received. In at least one example, in response to receiving a write confirmation, the third party server 114 may send the payment result to the reader device 106 via the proxy server 118. In one example, the payment result can indicate whether the e-commerce payment was successful or unsuccessful. Upon receiving the payment result, the surrogate server 118 can send the payment result to the merchant device 102, as shown in block 530. The POS application 124 can send the payment result to the reader device 106 as described above.

If no payment result is received, process 500 can return to block 528 and wait for the payment result. In some examples, the communication application 120 may utilize a timeout period, which (if the payment result is not received before the expiration of the timeout period) allows the transaction to time out. In some examples, the communication application 120 may retry sending write confirmations to the third party server 114 one or more times, the number of times being configurable. In some examples, the communication application 120 sends an indication to the POS application 104, the third party server 114, and / or the server 116 that the payment result has not yet been received and / or the transaction has timed out. Can be sent. In some examples, such indications can cause payments and / or transactions to be cancelled.

Block 532 indicates whether the electronic commerce payment is successful. As mentioned above, in at least one example, the communication application 120 can monitor the communication from the third party server 114. That is, in at least one example, the communication application 120 can decode the communication transmitted from the third party server 114 to determine if the payment result is associated with a success or failure notification. In at least one example, the communication application 120 may send a payment confirmation to the server 116 in response to determining that the payment result is associated with a success notification. That is, the proxy server 118 can send an indication to the server 116 that the electronic commerce payment has been successful, as shown in block 534. As mentioned above and also with reference to FIG. 2, the second request is described as being transmitted / received in block 512, but in some examples the second request is the payment result received. It can be retained by proxy server 118 until it is done. In such an example, the proxy server 118 may send a second request and a payment confirmation indicating that the payment was successful at the same time or at about the same time, or pay without sending the second request. A confirmation can be sent (eg, in response to a second request).

Block 536 indicates whether a second response (to the second request) has been received. In at least one example, the server 116 may send a second response to the second request in response to receiving a payment result indicating that the electronic payment was successful. That is, based at least in part on receiving an indication that the e-commerce payment was successful, the server 116 can record the transaction and send such an indication to the POS application 104 via the proxy server 118. can do. As shown in block 538, the communication application 120 can receive the second response and send the second response to the merchant device 102.

In at least one example, if the second response is not received, process 500 can return to block 532 and wait for the second response. In some examples, the communication application 120 may take advantage of a timeout period, which (if no second response is received before the expiration of the timeout period) allows the transaction to time out. In some examples, the communication application 120 may retransmit the indication that the payment instrument 108 presented in connection with the electronic money payment for a transaction has been made one or more times, the number of times being configurable. Can be. In some examples, the communication application 120 provides an indication that the second response has not yet been received and / or that the transaction has timed out, the POS application 104, the third party server 114, and / or the server. It can be sent to 116. In some examples, such indications can cause payments and / or transactions to be cancelled.

If the e-commerce payment is unsuccessful (for example, if the payment result indicates that the e-commerce payment has failed), the proxy server 118 indicates that the e-commerce payment was unsuccessful, as shown in block 540. The indication can be sent to the server 116. In some examples, if the second request is held by a proxy server, neither the second request nor the payment confirmation need to be sent to the server 116. That is, in some examples, the proxy server 118 may refrain from sending a second request and payment confirmation if the payment result does not indicate a successful e-commerce payment.

FIG. 6 shows an exemplary process 600 for processing e-commerce payments from the perspective of server 116.

Block 602 indicates that on the server associated with the payment processing service, the request is received from the proxy server associated with the payment processing service, the request is associated with a transaction between the merchant and the customer, and the transaction is electronic money. Associated with payment. As described above, upon receiving payment data associated with the payment instrument 108 presented for payment of a transaction, or a portion thereof (eg, from a reader device 106), the POS application 104 makes a request related to the transaction. It can be sent to proxy server 118, which can be sent to server 116. In at least one example, the request can be associated with payment data and / or transaction data, where the payment data and / or transaction data is an identifier associated with a merchant, an identifier associated with a customer, the total cost of a transaction, It can include, but is not limited to, one or more items associated with a transaction, additional or alternative POS information, and the like. As mentioned above, in at least one example, such information can be encrypted. In at least one example, the request can be associated with an order to record at least one transaction of a merchant or customer.

Block 604 indicates whether the indication associated with the transaction is received from the proxy server. As mentioned above, in at least one example, the communication application 120 associated with the proxy server 118 can monitor the communication from the third party server 114. That is, in at least one example, the communication application 120 can decode the communication transmitted from the third party server 114 to determine whether the payment result indicates whether the electronic commerce payment was successful or unsuccessful. .. In at least one example, the communication application 120 can send a payment result, or an indication based on it, to the server 116.

In at least one example, if no indication is received, process 600 can return to block 604 and wait for the indication. In some examples, the payment processing application 122 associated with the server 116 (s) can take advantage of a timeout period (if no response is received before the timeout period expires). Transactions can be timed out. In some examples, the payment processing application 122 may send an indication to the proxy server 118 that the response has not yet been received and / or that the timeout period has expired. In some examples, such indications (eg, the timeout period has expired) can cause payments and / or transactions to be cancelled.

As mentioned above, in some examples, the request may be received before the transaction-related indication (eg, successful or unsuccessful electronic commerce payment) is received. That is, in such an example, the proxy server 118 can send the request at or near the time the request is received. In some examples, proxy server 118 may hold the request until an indication is received. In such an example, if the indication associated with the transaction indicates a successful e-commerce payment, the proxy server 118 can send the request and indication at the same time or at about the same time, thus sending the request and indication at about the same time. Can be received at the same time.

Block 606 indicates whether the indication determines whether the electronic money payment has been successful. In at least one example, the payment processing application 122 can analyze the indication based on the payment result to determine whether the electronic commerce payment was successful or unsuccessful. Based, at least in part, on determining that the e-commerce payment was successful, the payment processing application 122 can record the transaction for the merchant, as shown in block 608, as shown in block 610. Can send a response to the proxy server 118 indicating that the transaction was recorded by the payment processing service.

Thus, the payment processing service, on behalf of the merchant (and other different merchants), (i) communicates with one or more other payment processors as described above, and / or (ii) transactions. Can be processed by recording in one or more ledgers. In at least one example, the payment processing application 122 can receive an indication that the electronic money payment has been successful and can determine the amount of funds to be paid to the merchant for the transaction. In at least one example, such amount may be the total purchase price minus the charges charged by the payment processing service to provide the payment processing service. Based on determining the amount of funds to be paid to the merchant, the payment processing application 122 can deposit the funds in the merchant's account managed by the payment processing service. As mentioned above, such accounts are managed at least through the ledger of the payment processing service, and the relevant funds are scheduled deposits, same-day deposits, instant deposits, and linked payment instruments, as described below. It may differ from traditional bank accounts because it is accessible through a variety of withdrawal channels, including but not limited to. In some examples, such deposits and / or linked payment instruments can be associated with an e-commerce repository.

In at least one example, the payment processing application 122 can record a transaction in the profile of a merchant and / or a customer, as described below. In some examples, such profiles and related data can be leveraged for one or more services associated with payment processing services.

Based, at least in part, on determining that the e-commerce transaction has failed, the payment processing application 122 may refrain from recording the merchant's transaction, as shown in block 612, as shown in block 614. , A response can be sent to the proxy server 118 indicating that the transaction has not been recorded by the payment processing service and / or has been recorded as not approved by the payment processing service. As mentioned above, in some examples, the request can be sent before receiving the indication associated with the transaction. In some such examples, the server 116 may refrain from recording the transaction if the indication indicates that the e-commerce payment has failed. Further, in some examples, the server 116 can record the transaction, but can indicate that the payment instrument 108 presented in connection with the electronic commerce payment for the transaction has not been approved.

In some examples, if the proxy server 118 holds the request and the transaction-related indication indicates a failure to pay the e-commerce payment, the proxy server 118 may refrain from sending the request and the indication. In such an example, process 600 can be terminated at block 604. However, if the proxy server 118 sends both the request and the indication despite the failure of the electronic commerce payment, the process 600 can proceed as described above in FIG.

In some examples, the one or more communications described above can fail for one or more reasons. For example, connectivity issues between the merchant device 102 and the proxy server 118, the third party server 114, and / or the server 116 (eg, related to one or more networks) are the proxy server 118 and / or the server 116. / Or prevent write confirmation communication (eg, write confirmation 218 in FIG. 2 above) from being received by the third party server 114 and / or be paid by proxy server 118 and / or merchant device 102 (eg, payment in FIG. 2 above). Result 220) can be prevented from being received. In at least one example, such a failure can help ensure that the electronic commerce balance associated with the payment instrument 108 matches the electronic commerce balance associated with the payment instrument 108 at the third party server 114. You can trigger an error-handling process that you can. That is, when the balance related to the payment means 108 is deducted, it can be determined that the electronic money payment is successful. Thus, in an example where a request to write a new e-commerce balance to the payment instrument 108 is sent and no confirmation is received indicating that the new e-commerce balance has been written to the payment instrument 108, the third party server 114 and / or the merchant device. 102 cannot know whether the new e-commerce balance has been written to the payment instrument 108. In at least one example, the electronic commerce balance associated with the payment instrument 108 can be the truth-telling material. Therefore, write-aware communication may be important to ensure that the third-party server 114 knows if a new e-commerce balance has been written to the payment instrument 108.

7 and 8 below describe details related to the error handling process. Exemplary processes 700 and 800 describe aspects of the error handling process for failures and / or errors that occur after an approval response (eg, a response to an approval request) has been sent to the reader device 106. As mentioned above, the approval response can include an order (eg, a write order) to write a new e-commerce balance to the payment instrument 108. Therefore, the reader device 106 can initiate writing to the payment instrument 108 in response to receiving such a notification. If a failure and / or error occurs before the authorization response is sent from the third party server 114, the third party server 114 may cancel the payment.

FIG. 7 shows an exemplary process 700 associated with error handling as described herein.

Block 702 indicates that a third party server (s) sends a write command to cause the reader device to write the electronic commerce balance to the payment instrument. As mentioned above, the third party server 114 can send a response to the approval request received from the merchant device 102. In at least one example, the approval response can be associated with an instruction for the reader device 106 to write a new e-commerce balance to the payment instrument 108, or otherwise associate it with the payment instrument 108. In at least one example, the new e-commerce balance can be at least partially based on the old e-commerce balance and the amount the payment instrument 108 has bid for payment. In at least one example, in response to receiving an approval response, the reader device 106 may write a new e-commerce balance to the payment instrument 108. That is, the reader device 106 can associate the new electronic commerce balance with the payment instrument 108.

Block 704 indicates determining whether a write confirmation has been received. In at least one example, in response to writing a new e-commerce balance to the payment instrument 108, the reader device 106 sends a write confirmation (eg, via a proxy server 118) to a third-party server 114, or You can try to send. In some examples, write confirmations can be received by a third party server 114, in which process 700 is described above with reference to FIGS. 2-6 and is shown in block 706 as "success". You can proceed to the flow. However, in another example, the write confirmation may not be received by the third party server 114. In such an example, the merchant device 102 is unable to communicate with the proxy server 118, for example due to network connectivity issues, issues related to the proxy server 118 and / or the third party server 114, and so on. In some cases, and / or the proxy server 118 may not be able to communicate with the third party server 114. In some examples, write confirmation may fail due to an error associated with the dialogue between the reader device 106 and the payment instrument 108, or due to an error associated with the reader device 106. In some cases, write verification can fail for additional or alternative reasons.

Block 708 indicates determining if the problem is identifiable. In some examples, the third-party server 114 can detect problems that prevent it from receiving write confirmations. For example, in some examples, write confirmation is improper and / or improper between the payment instrument 108 and the reader device 106 such that the electronic money balance and / or payment data is not read from the payment instrument. Or it may not be sent (and therefore not received) due to errors resulting from a failed dialogue, read errors, etc. In such an example, as shown in block 710, the third party server 114 may send an instruction to the merchant device 102 to initiate the retouch flow. That is, the third party server 114 can send a command to the merchant device 102 to urge the customer to trigger another dialogue between the payment instrument 108 and the reader device 106. In some examples, as shown in block 712, the actions associated with blocks 704 to 710 can be repeated one or more times before the third party server 114 initiates the balance check flow, the number of times being set. It is possible.

If the problem is not identifiable, the third party server 114 may send a command to the merchant device 102 to initiate the result confirmation flow, as shown in block 714. For example, if the third-party server 114 has not received a write confirmation (or error notification), the third-party server 114 may not be able to identify the problem. In some examples, such issues may be related to network connectivity (eg, internet outages). In at least one example, the third party server 114 may send a command to the merchant device 102 prompting the POS application 104 to send an indication as to whether the payment was successful or not.

Block 716 indicates whether a successful response has been received. In at least one example, the POS application 104 comprises an indication of whether the payment was successful or unsuccessful, or that the POS application 104 does not know whether the payment was successful or unsuccessful (eg, unknown). Can send a response. In such an example, if the response indicates that the payment was successful, the third party server 114 can determine that a successful response has been received, and process 700 will "success" as shown in block 706. You can proceed to the flow.

In some examples, the merchant device 102 may send a request to the third party server 114 to determine if the third party server 114 has a correctly recorded payment. In such an example, the POS application 104 can send a result confirmation to the third party server 114 and wait for a response indicating that the payment was recorded correctly. The third-party server 114 can send a response to the payment reader 106 that may include an indication of the previous e-commerce balance and the current e-commerce balance associated with the payment instrument 108. In at least one example, the payment reader 106 can output an indication of whether the payment was successful (or not) and can transfer the indication to the POS application 104. In at least one example, process 700 can follow a success flow, as shown in block 706, at least in part based on receiving an indication that the payment was successful. If the indication indicates that the payment was unsuccessful, process 700 can proceed to block 718.

If the response indicates that the response failed, the third party server 114 can determine if the problem is identifiable, as shown in block 718. If the indication indicates that the write failed, the third party server 114 can determine that the problem is identifiable and can initiate a retouch flow, as shown in block 710. If no response is received or the response is associated with an unknown indication, the third party server 114 may determine in block 718 that the problem is indistinguishable, as shown in block 712. , You can start the balance check flow.

Block 712 indicates that the balance check flow is started. In at least one example, the third party server 114 (s) sends an instruction to the merchant device 102 (via the proxy server 118 (s)) to send instructions (s) to the merchant device 102 (s). The merchant device 102 can be instructed to urge the customer to trigger another dialogue between the payment instrument 108 and the reader device 106. In some examples, the instruction can be associated with a new e-commerce balance of payment instrument 108, as is known to the third party server 114. Further, the instruction can be associated with the amount of the transaction for which the payment instrument 108 is being bid, and the indication that the payment is associated with the error handling process. In at least one example, the POS application 104 can receive instructions and have the UI presented via the merchant device 102 to encourage such dialogue. In at least one example, the reader device 106 can read the payment data associated with the payment instrument 108, at least in part by encouraging the customer to provoke an additional dialogue. Further details related to the balance check flow are described below with reference to FIG.

In some examples, once the third-party server 114 initiates the balance check flow, any previous approval request (eg, the first request) can be canceled and the current e-commerce balance is the payment instrument 108. If the balance check flow indicates that it is equal to the previous e-commerce balance minus the amount bid for payment, the POS application 104 will generate a new approval request and send it to the third party server 114 to reprocess the transaction payment. can do. The new approval request can be associated with an indication that the payment is a reprocessed payment submitted as a result of an error. Further, in such an example, the server 116 can receive multiple requests that can be associated with the original and subsequent payments associated with the error handling process. In at least one example, the original request (eg, the request sent in connection with the original payment) can be associated with a failed indication.

FIG. 8 shows an exemplary process 800 related to the balance check flow, as described above.

Block 802 indicates that on the merchant device and at the first time, it receives an instruction to associate a new e-money balance with the payment instrument. As mentioned above, the third party server 114 can send a response to the approval request received from the merchant device 102. In at least one example, the approval response can be associated with an instruction for the reader device 106 to write a new e-commerce balance to the payment instrument 108 or otherwise associate it with the payment instrument 108. In at least one example, the new e-commerce balance can be at least partially based on the old e-commerce balance and the amount the payment instrument 108 has bid for payment. In at least one example, in response to receiving an approval response, the reader device 106 may write a new e-commerce balance to the payment instrument 108. That is, the reader device 106 can associate the new electronic commerce balance with the payment instrument 108.

Block 804 receives an instruction at a second time on the merchant device (s) to trigger a dialogue between the payment instrument and the reader device associated with the merchant device (s) 102. Is shown. In at least one example, the third party server 114 (s) sends an instruction to the merchant device 102 (via the proxy server 118 (s)) to send instructions (s) to the merchant device 102 (s). ) The merchant device 102 can be instructed to urge the customer to trigger another dialogue between the payment instrument 108 and the reader device 106. In some examples, the instruction can be associated with a new e-commerce balance of payment instrument 108, as is known to the third party server 114. Further, the instruction can be associated with the amount of the transaction for which the payment instrument 108 is being bid, and the indication that the payment is associated with the error handling process. In at least one example, as shown in block 806, the POS application 104 can receive instructions and have the UI presented via the merchant device 102 to encourage such dialogue. In at least one example, the reader device 106 can read the payment data associated with the payment instrument 108, at least in part by encouraging the customer to provoke an additional dialogue.

Block 808 indicates whether the current electronic commerce balance of the payment instrument is received from the reader device. In at least one example, the POS application 104 can determine if payment data that can be associated with the current electronic money balance of the payment instrument 108 is received from the reader device 106.

Block 810 indicates whether the current balance matches the previous balance of the payment instrument minus the amount of the transaction bid by the payment instrument for payment. In at least one example, the POS application 104 has an e-commerce balance received through additional dialogue (eg, the current e-commerce balance) and the amount of the transaction in which the payment instrument 108 has been bid (eg, the new e-commerce balance). ) Can be deducted to determine whether it matches the previous electronic commerce balance. In some examples, the new e-commerce balance may be provided by a third party server 114 (eg, in connection with an order to trigger an additional dialogue between the payment instrument 108 and the reader device 106). In some examples, the previous e-commerce balance and the amount of payment for which the payment instrument 108 has been bid may be provided by the third party server 114. In another example, the new e-commerce balance does not have to be provided by the third party server 114. In such an example, the POS application 104 can access the transaction data associated with the transaction to determine the previous e-commerce balance and the amount of the transaction for which the payment instrument 108 has been bid. In some examples, the POS application 104 can maintain transaction details and present at least some transaction details via the UI on the merchant device 102. For example, the POS application 104 can present the previous e-commerce balance and transaction amount via the UI while the payment for the transaction is being processed.

In at least one example, as shown in block 812, if the current e-commerce balance matches the new e-commerce balance, the POS application 104 determines that the new e-commerce balance has been written to the payment instrument 108 and confirms the write. Can be sent to the third party server 114. In some examples, instead of sending a write confirmation, the POS application 104 can initiate another transaction for processing. In such an example, the new transaction can be associated with an indication that the transaction is being generated from an error handling process resulting from a previous failure and / or error. Further, in at least one example, as shown in block 814, the POS application 104 can have the UI presented via the merchant device 102. In some examples, the UI can confirm that the transaction was successful and may include a new e-commerce balance associated with the payment instrument 108.

If the current balance does not match the previous balance of the payment instrument 108 minus the amount of the transaction bid by the payment instrument 108 for payment, the POS application 104 fails to pay, as shown in block 816. A UI indicating that the transaction has been made can be transmitted via the merchant device 102 to prompt the merchant to reprocess the payment for the transaction, as shown in block 818. In at least one example, as shown in block 820, the POS application 104 can send such an indication to a third party server 114 and / or server 116. The previous transaction may be canceled in response to the receipt of such an indication to the third party server 114 and / or the server 116. Upon receipt of a subsequent request to initiate payment for a transaction, the transaction and associated communications can be associated with an indication that the transaction has been reprocessed due to a previous failure and / or error.

In at least one example, if the current e-commerce balance is not received in block 808, the POS application 104 can prompt the merchant to take corrective action, as shown in block 822, and the process goes to block 806. You can go back. In at least one example, the corrective action can include attempting to reconnect to the network and / or reconnecting the reader device 106 and the merchant device 102. In some examples, the corrective action may be to power off the reader device 106. Additional or alternative corrective actions are within the scope of this disclosure.

In some examples, the merchant may retry payment for a transaction one or more times, and the number may be configurable. After the merchant fails one or more times and retries the payment, the POS application 104 can be made to present a UI that allows the merchant to cancel the transaction.

FIG. 9 shows an exemplary environment 900. Environment 900 is a server computing associated with a user device 906 (in some cases, a merchant device 908 (individually 908 (A) -908 (N))) and / or a third party service provider over network 904. Includes a server computing device 902 capable of communicating with device 910. The server computing device 902 can be associated with a service provider 912 capable of providing one or more services for the benefit of the user 914, as described below. Actions by the service provider 912 can be performed by the server computing device 902.

In at least one example, the merchant device 102 described above with reference to FIG. 1 can accommodate at least some of the user devices 906, and the server computing device 902 described above with reference to FIG. The server 116 can be accommodated and at least some of the server computing devices 910 associated with the third party service provider can accommodate the third party server 114 described above with reference to FIG. In at least one example, the exemplary environment 900 can include one or more proxy server computing devices 915 that can accommodate the proxy server 118 described above with reference to FIG. As previously described with reference to FIG. 1, the proxy server computing device 915 is between the user device 906, the server computing device 902, and / or the server computing device 910 associated with a third party service provider. Communication can be facilitated. In some examples, a proxy server computing device 915, a server computing device 910 associated with a third-party service provider, and one or more user devices 906 can be located in a first geolocation and are servers. The computing device 902 can be located at a different second geographic location.

The environment 900 can include a plurality of user devices 906 as described above. Each of the plurality of user devices 906 is a tablet computing device, smartphone or mobile communication device, laptop, netbook or other portable or semi-portable computer, desktop computing device, terminal computing device or other semi-stationary or It can be any type of computing device, such as stationary computing devices, dedicated devices, wearable computing devices or other body-mounted computing devices, augmented reality devices, virtual reality devices, IoT (Internet of Things) devices, etc. .. In some examples, individual user devices are operable by user 914. User 914 can be referred to as a customer, a buyer, a merchant, a seller, a borrower, an employee, an employer, a payer, a payee, a courier, and the like. The user 914 can interact with the user device 906 via the UI presented via the user device 906. In at least one example, the UI can be presented via a web browser or the like. In another example, the UI can be presented via an application, such as a mobile application or desktop application, which can be provided by service provider 912 or which can be a dedicated application in other cases. In some examples, an individual user device 906 may have an instance of an application or a versioned instance, which instance or versioned instance presents, for example, the UI described herein. Can be downloaded from the application store. In at least one example, the user 914 can interact with the UI via touch input, voice input, or any other type of input.

As mentioned above, in at least one example, the user 914 can include merchants 916 (individually, 916 (A)-916 (N)). In one example, the merchant 916 can operate each merchant device 908, which can be a user device 906 configured for use by the merchant 916. For this discussion, a "merchant" can be any entity that provides an item (eg, an entity or service) for a purchase or other means of acquisition (eg, rental, borrowing, barter, etc.). Merchant 916 can provide items for purchase or other acquisition means through physical stores, mobile stores (eg, pop-up shops, food trucks, etc.), online stores, and the combinations described above. In some examples, at least some of the merchants 916 can be associated with the same entity, but can have different merchant positions and / or have a franchise / franchisee relationship. In the additional or alternative example, the merchant 916 can be a different merchant. That is, in at least one example, the merchant 916 (A) is a different merchant than the merchant 916 (B) and / or the merchant 916 (C). In some examples, the merchant 916 can be located in different states, countries, etc.

For the purposes of this discussion, "different merchants" can therefore refer to two or more unrelated merchants. A "different merchant" can refer to two or more merchants who are different legal entities (eg, natural persons and / or legal entities) that do not share accounting, employees, branding, etc. "Different Merchant", as used herein, is a different name, employer identification number (EIN), business line (in some cases), inventory (or at least a portion thereof), and / or the same. Have one. Therefore, the use of the term "different merchant" does not refer to merchants with various merchant positions or franchise / franchisee relationships. Such merchants can be referred to as merchants with various merchant positions or franchise / franchisee relationships, with different merchant positions and / or different commercial trading channels.

Each merchant device 908 can store an instance of the POS application 918. The POS application 918 can correspond to the POS application 104 described above with reference to FIG. The POS application 918 can configure the merchant device 908 as a POS terminal, which allows the merchant 916 (A) to interact with one or more customers 920. As mentioned above, user 914 can include customers such as customer 920, which is shown to interact with merchant 916 (A). For the purposes of this discussion, a "customer" can be any entity that retrieves an item from a merchant. Although only two customers 920 are shown in FIG. 9, any number of customers 920 can interact with the merchant 916. Further, although FIG. 9 shows a customer 920 interacting with the merchant 916 (A), the customer 920 can interact with any of the merchants 916.

In at least one example, the dialogue between the customer 920 and the merchant 916, which involves the exchange of funds (from the customer 920) for the item (from the merchant 916), is referred to as a "POS transaction" and / or a "transaction". be able to. In at least one example, the POS application 918 can determine the transaction data associated with a POS transaction. The transaction data includes payment information, user authentication data, purchase amount information, purchase time information (eg, purchased item, purchase date, purchase time) that can be obtained from the reader device 922 associated with the merchant device 908 (A). Etc.) can be included. The POS application 918 can send transaction data to the server computing device 902. In at least one example described above, such transaction data can be sent to the server computing device 902 via the proxy server computing device 915. In at least one example, the POS application 918 can present a UI that allows the merchant 916 (A) to interact with the POS application 918 and / or the service provider 912 via the POS application 918.

In at least one example, the merchant device 908 (A) can be a special purpose computing device configured as a POS terminal (via execution of POS application 918). In at least one example, the POS terminal is connected to a reader device 922 that can accept various payment methods such as credit cards, debit cards, gift cards, short-range communication based payment methods, as described below. obtain. The reader device 922 can correspond to the reader device 106 described above with reference to FIG. In at least one example, the reader device 922 can be plugged into a port within the merchant device 908 (A), such as a microphone port, headphone port, audio jack, data port, or other suitable port. In an additional or alternative example, the reader device 922 can be connected to the merchant device 908 (A) via another wired or wireless connection, such as via Bluetooth®, BLE, or the like. Further details are described below with reference to FIG. In some examples, the reader device 922 can read information from alternative payment instruments, including, but not limited to, wristbands and the like.

In some examples, the reader device 922 is a magnetic stripe payment card, an EMV payment card, and / or short-range communication (eg, Near Field Communication (NFC), Radio Frequency Identification (RFID), Bluetooth®, Bluetooth. (Registered Trademarks) Low energy (BLE), etc.) Can physically interact with payment instruments such as payment instruments (eg, cards or devices configured for tapping). The POS terminal can provide a rich UI, communicate with the reader device 922, and, among other services, communicate with the server computing device 902, which can provide the payment processing service. The server computing device 902 associated with the service provider 912 can communicate with the server computing device 910 as described below. In some examples, such communication can be facilitated by a proxy server computing device 915. In at least one example, the POS terminal and reader device 922 can collectively process transactions between the merchant 916 and the customer 920. In some examples, the POS terminal and reader device can be configured with a one-to-one pairing. In another example, the POS terminal and reader device consist of many-to-one pairings (eg, one POS terminal coupled to multiple reader devices, or multiple POS terminals coupled to one reader device). can do. In some examples, a "secondary" terminal, for example, to allow information from a secondary terminal to be shared between a primary POS terminal and a secondary terminal, via short-range communication technology. There can be multiple POS terminals connected to some other device, such as back-of-house systems, printers, line-buster devices, POS readers, and so on. This type of configuration synchronizes data with another device (eg, primary terminal) when one device (eg, secondary terminal) continues to receive user input and the primary or secondary terminal switches to online mode. It can also work in offline-online scenarios to make it possible. In another example, such data synchronization can occur periodically or at randomly selected time intervals.

The POS terminal and reader device 922 of the POS system 924 are shown as separate devices, but in additional or alternative examples, the POS terminal and reader device 922 may be part of a single device. can. In some examples, the reader device 922 may have an integrated display unit therein for presenting information to the customer 920. In an additional or alternative example, the POS terminal may have a display unit incorporated therein for presenting information to the customer 920. POS systems such as the POS system 924 can be mobile so that POS terminals and reader devices can process transactions at different locations around the world. The point-of-sale system can be used to process card-present and non-card-present (CNP) transactions, as described above with reference to FIG.

The POS system 924, the server computing device 902, and / or the server computing device 910 can exchange payment information and transaction data to determine if a transaction is approved. For example, the POS system 924 may provide encrypted payment data, user authentication data, purchase amount information, purchase point information, etc. (collectively, transaction data) to the server computing device 902 via the network 904. can. The server computing device 902 can transmit transaction data to the server computing device 910. As mentioned above, in at least one example, the server computing device 910 includes an acquirer bank, an issuer, and / or a card payment network (eg, Mastercard®, VISA®, etc.). It can be associated with a third party service provider that provides payment services, not limited to these. In an additional or alternative example, the server computing device 910 can be associated with a third party service provider (eg, a third party payment processor) that provides payment services for processing electronic commerce payments, as described above.

For the purposes of this discussion, a "payment service provider" may acquire a bank ("acquirer"), issuing bank ("issuer"), card payment network, and the like. In one example, an acquirer is a bank or financial institution that processes payments (eg, credit or debit card payments) and can take risks on behalf of merchants. The acquirer may be a registered member of a card association (eg, Visa®, MasterCard®) or may be part of a card payment network. The acquirer (eg, the server computing device 910 associated with it) sends a transfer request to the server computing device of the card payment network (eg, Mastercard®, VISA®, etc.). It can be determined whether the transaction is approved or inadequate (incomplete). In at least one example, the service provider 912 can act as an acquirer and connect directly to the card payment network.

A card payment network (eg, a server computing device 910 associated with it) can forward a transfer request to the issuing bank (eg, "issuer"). An issuer is a bank or financial institution that provides a user with a financial account (eg, a credit or debit card account). The issuer can issue a payment card to the user and the issuing bank can pay the acquirer for purchases made by the cardholder who issued the payment card. The issuer (eg, the server computing device 910 associated with the issuer) can make a determination as to whether the customer has the ability to absorb the associated charges associated with the payment transaction. In at least one example, service provider 912 can act as an issuer and / or partner with an issuer. The transaction is approved or rejected by the issuer and / or the card payment network (eg, the server computing device 910 associated with it), and the payment approval message is sent via a path opposite to the one described above, or with an alternative path. The issuer communicates with the POS device via the issuer.

As mentioned above, the server computing device 910 that can be associated with the payment service provider approves the transaction based on the transaction data and information about the parties to the transaction (eg, customer 920 and / or merchant 916 (A)). It can be determined whether or not it is done. The server computing device 910 can send an approval notification to the server computing device 902 on the network 904, which approves the POS system 924 on the network 904 to indicate whether the transaction is approved. Notifications can be sent. The server computing device 902 can also send additional information, such as a transaction identifier, to the POS system 924. In one example, the server computing device 902 may include a merchant application and / or other functional components for communicating with the POS system 924 and / or the server computing device 910 to approve or reject the transaction.

Based on the approval notice received from the server computing device 902 by the POS system 924, the merchant 916 can indicate to the customer 920 whether the transaction has been approved. In some examples, approval may be shown on the POS system 924, eg, on the display of the POS system 924. In other examples, such as a smartphone or watch acting as a short-range communication payment instrument, information about the approved transaction may be provided to the short-range communication payment instrument for presentation via the display of the smartphone or watch. In some examples, additional or alternative information may be presented along with approved transaction notices, including but not limited to receipts, special offers, coupons, or loyalty program information.

As mentioned above, among the services, the service provider 912 includes payment processing services, inventory management services, catalog management services, business banking services, financial services, lending services, reservation management services, web development services, salary payment services, employees. It can provide personnel management services, appointment services, loyalty tracking services, restaurant management services, order management services, fulfillment services, peer-to-peer payment services, onboard services, identity verification (IDV) services, and the like. In some examples, user 914 can access all services of service provider 912. In another example, user 914 can have step-by-step access to the service, which can be based on risk tolerance, IDV output, subscription, and so on. In at least one example, access to such services is available to merchant 916 via the POS application 918. In the additional or alternative example, each service can be associated with its own access point (eg, application, web browser, etc.).

As mentioned above, the service provider 912 can provide a payment processing service for processing payments on behalf of the merchant 916. For example, the service provider 912, as described above, has payment processing software, payment processing hardware, and / / to allow the merchant 916 to receive payment from customer 920 when making a POS transaction with customer 920. Alternatively, a payment processing service can be provided to the merchant 916. For example, service provider 912 may allow merchant 916 to receive cash payments, payment card payments, and / or electronic payments from customer 920 for POS transactions, and service provider 912 may replace merchant 916. Can process transactions.

When Service Provider 912 processes a transaction on behalf of Merchant 916, Service Provider 912 may maintain Merchant 916's account or balance in one or more ledgers. For example, service provider 912 can analyze the transaction data received for a transaction to determine the amount of funds to be paid to merchant 916 (A) for the transaction. In at least one example, such amount may be the total purchase price minus the charges charged by the service provider 912 to provide the payment processing service. Based on determining the amount of funds to be paid to Merchant 916 (A), Service Provider 912 may deposit funds in the account of Merchant 916 (A). The account can have a stored balance that can be managed by service provider 912. At a minimum, the stored balances are managed by the service provider 912 ledger and the relevant funds are accessed through various withdrawal channels, including but not limited to scheduled deposits, same-day deposits, instant deposits, and linked payment instruments. The account can be different from a traditional bank account because it is possible.

A deposit is a merchant in which the service provider 912 holds the funds associated with the stored balance of the merchant 916 (A) in a bank or other financial institution (eg, associated with the server computing device 910). It can occur when transferring to a bank account of 916 (A). Scheduled deposits can be made at a predetermined time after the POS transaction is funded, which may be the business day after the POS transaction occurs, earlier or later. May be good. In some examples, the merchant 916 (A) has access to the funds prior to the scheduled deposit. For example, the merchant 916 (A) is a same day deposit (eg, the service provider 912 is linked to the merchant from the stored balance on the same day as the POS transaction, in some cases before the POS transaction is funded. Access to a bank account) or an immediate deposit (for example, the service provider 912 deposits funds from the stored balance to the merchant's linked bank account upon request, such as in response to a request). can do. Further, in at least one example, the merchant 916 (A) allows the merchant to access the funds without first transferring the funds from the account managed by the service provider 912 to the bank account of the merchant 916 (A). You can have a payment instrument linked to a stored balance that allows it.

In at least one example, service provider 912 can provide a warehouse management service. That is, service provider 912 can provide inventory tracking and reporting. The inventory management service may allow the merchant 916 (A) to access and manage a database that stores data related to the quantity (ie, inventory) of each item available to the merchant 916 (A). Further, in at least one example, the service provider 912 can provide a catalog management service that allows merchant 916 (A) to maintain the catalog, and the catalog is for acquisition by merchant 916 (A). It can be a database that stores the data associated with the items available to (ie, the catalog management service). In at least one example, the catalog may contain a plurality of data items, the data items of the plurality of data items may represent items available for acquisition by merchant 961 (A). Service provider 912 can provide recommendations for item pricing, item placement on the catalog, and multi-party fulfillment of inventory.

In at least one example, the service provider 912 deposits in the account of Merchant 916 (A) (from payment processing and / or other sources of funding), payroll from the account (eg, an employee of Merchant 916 (A)). Payments to other merchants directly from an account or from a linked debit card (eg, between companies), withdrawals made via scheduled deposits and / or immediate deposits, etc., Merchant 916 (A). ) Can provide business banking services that can be tracked. In addition, the business banking service allows merchant 916 (A) to obtain a customized payment instrument (eg, a credit card) and earn how much money (eg, through the presentation of available revenue balances). Check if, understand where their money is heading (eg, through a deposit report (which can include a breakdown of charges)), and (eg, scheduled deposits, instant deposits, linked payment instruments) Allows you to access / use the money you are earning (via, for example) and think you are in control of their money (eg, through the management of deposit schedules, deposit speeds, linked means, etc.) be able to. In addition, Business Banking Services allows merchants 916 to visualize their cash flow, track their financial health, set aside money for upcoming obligations (eg savings), and put money around goals. It can be possible to organize and so on.

In at least one example, service provider 912 may provide financial services and products via business loans, consumer loans, fixed term loans, flexible term loans and the like. In at least one example, the service provider 912 can utilize one or more risk signals to determine whether to extend the finance offer and / or the terms associated with such a finance offer.

In at least one example, the service provider 912 is, in some examples, a financial service for providing and / or lending a loan to a borrower, which is used to finance the borrower's short-term operational needs (eg, a capital loan). Can be provided. For example, a potential borrower who is a merchant can obtain a capital loan through a capital loan product to fund various operating costs (eg, rent, salary, inventory, etc.). In at least one example, service provider 912 may offer different types of capital loan products. For example, in at least one example, the service provider 912 may provide a daily repayment loan product, in which case the capital loan is, for example, from a portion of the transaction processed by the payment processing service on behalf of the borrower. Repayed daily. Additionally and / or alternatives, the service provider 912 may provide a monthly repayment loan product, in which case the capital loan is, for example, debited from a bank account linked to a payment processing service. It will be repaid monthly via (debit). A merchant's credit risk can be assessed using a risk model that takes into account factors such as payment volume, the credit risk of similarly positioned merchants, past transaction history, seasonality, and credit history.

Additionally or additionally, the service provider 912 is, in some examples, a funding service for providing and / or lending a loan to a borrower, which is used to fund the borrower's consumer purchases. (For example, a consumer loan) can be provided. In at least one example, the borrower may submit a loan request to allow the borrower to purchase an item from a merchant, which may be one of the merchants 916. Service provider 912 may generate a loan based, at least in part, on determining that the borrower has purchased or is about to purchase goods from a merchant. A loan can be associated with a balance based on the actual purchase price of the item (goods), and the borrower can repay the loan over time. In some examples, the borrower receives payments to be paid to the merchant from payments processed on behalf of the merchant, funds transferred to the merchant, etc. through funds managed and / or maintained by the service provider 912. You can repay the loan through a payable installment. The service provider 912 can provide a particular financial product, such as a payment instrument specifically tied to a loan product. For example, in one embodiment, the server provider 912 associates capital with a merchant or customer debit card, and the use of the debit card is defined by the terms of the loan. In some examples, merchants can only use debit cards to make certain purchases. In another example, the "installment" associated with the loan product is credited directly through the payment instrument. Therefore, the payment instrument is customized for the loan and / or the party associated with the loan.

Service Provider 912 provides web development services that enable users 914 unfamiliar with HTML, XML, JavaScript, CSS, or other web design tools to create and maintain professional and engaging websites. be able to. Some of these web page editing applications allow users to build and / or modify web pages (eg, modify, add, or remove content related to web pages). .. In addition to websites, web development services can create and maintain other online omni-channel presence, such as social media posts. In some examples, the resulting web page and / or other content item can be used to offer the item for sale via an online / e-commerce platform. That is, the resulting web page and / or other content item can be associated with an online store or offering by one or more merchants 916. In at least one example, service provider 912 may recommend and / or generate content items that complement the omni-channel presence of merchant 916. That is, if the merchant of merchant 916 has a web page, service provider 912 recommends additional content items presented via other channels such as social media, email transmission, etc., via web development or other services. And / or can be generated.

In addition, the service provider 912 may provide a payroll service to allow the employer to pay the employee for work performed on behalf of the employer. In at least one example, the service provider 912 was worked by an employee (eg, via an imported time card and / or POS dialogue), sales made by the employee, received by the employee. It is possible to receive data including chips and the like. Service provider 912 may pay employees on behalf of the employer via a payroll service based on such data. For example, service provider 912 can facilitate the transfer of the total amount paid out for employee salary payments from the employer's bank to the service provider 912's bank for employee salary payments. In at least one example, when funds are received at the bank of Service Provider 912, Service Provider 912 will often check or check, one day, one week or more after the work is actually done by the employee. It can be paid to employees by direct deposit. In an additional or alternative example, service provider 912 allows employees to receive payments on the same day or via immediate deposit, at least in part based on the risk and / or reliability analysis performed by service provider 912. Can be.

Further, in at least one example, service provider 912 may provide employee management services for managing employee schedules. Further, the service provider 912 can provide a reservation service to allow the user 914 to schedule and / or schedule the reservation.

In some examples, the service provider 912 allows the user 914 to make and / or manage reservations and to monitor front-of-house and / or back-of-house operations and the like. Can provide management services. In such an example, the merchant device 908 and / or the server computing device 902 may be configured to communicate with one or more other computing devices, which are front-of-house (eg, POS). Equipment) and / or can be located in the back of house (eg, Kitchen Display System (KDS)). In at least one example, the service provider 912 provides an order management service and / or a fulfillment service to allow the restaurant to manage open tickets, split tickets, etc., and / or the fulfillment service. Can be provided. In some examples, such services can be associated with restaurant merchants, as described above. In additional or alternative examples, such services can be of any type of merchant.

In at least one example, the service provider 912 can provide a fulfillment service that allows the courier to be used for delivery, the courier to provide delivery service, photography service, and the like. You can move between places. The courier can be a user 914 who can move between locations to perform services for the requesting user 914 (eg, deliver an item, capture an image, etc.). In some examples, the courier may receive compensation from service provider 912. Couriers can use one or more vehicles such as cars, bicycles, scooters, motorcycles, buses, planes, helicopters, boats, skateboards and the like. However, in another example, the courier can travel by foot or in other ways without a vehicle. Some of the examples described herein allow people to participate in a sort of crowdsource service economy as a courier. Here, in essence, any person with a mobile device can immediately become a courier or become a courier in a courier network that provides services as described herein. You can quit. In at least one example, the courier may be an unmanned aerial vehicle (eg, an unmanned aerial vehicle), an autonomous vehicle, or any other type of vehicle capable of receiving commands to move between positions. In some examples, the service provider 912 receives a request for the courier service, automatically assigns the request to the active courier, and presents a UI (eg, an application, web browser, etc.) through each device 906. Alternatively, the shipping order can be communicated to the courier via another access point).

In some examples, service provider 912 may provide omni-channel fulfillment services. For example, if a customer places an order with a merchant and the merchant cannot fulfill the order because one or more items are out of stock or otherwise unavailable, the service provider 912 may place the customer's order. Other merchants and / or sales channels that are part of the service provider 912 platform can be leveraged to fulfill. That is, another merchant may offer one or more items to satisfy a customer's order. In addition, in some examples, different sales channels (eg, online, brick and mortar, etc.) can be used to satisfy a customer's order.

In some examples, the service provider 912 can enable conversational commerce through the conversational commerce service, where the conversational commerce service uses one or more machine learning mechanisms to create two or more. The intention of the user 914 can be determined by analyzing the message exchanged between the users 914, the voice input to the virtual assistant, and the like. In some examples, the service provider 912 can use the determined intent to automate customer service, provide promotions, provide recommendations, or otherwise interact with customers in real time. .. In at least one example, service provider 912 integrates products and services, as well as payment mechanisms, into a communication platform (eg, messaging), where a customer calls, emails, or emails a merchant's web page or other channel. It can be possible to make a purchase or otherwise make a transaction without the need to visit. That is, conversational commerce reduces the need for customers to switch back and forth between conversations and web pages in order to collect and purchase information.

In at least one example, the service provider 912 can provide a peer-to-peer payment service that allows peer-to-peer payments between two or more users 914. In at least one example, service provider 912 can communicate with an instance of a payment application (or other access point) installed on device 906 configured to operate by user 914. In one example, an instance of a payment application running on a first device operated by a payer transfers a certain amount of money (eg, cryptocurrency) from the payer's account to the payee's account (eg, peer-to-peer payment). , Securities, and flat or non-flat currencies such as related assets) can be sent to the service provider 912. The service provider 912 can facilitate the transfer and notify that the transfer is in progress (or completed) of the payment application running on the second mobile device operated by the recipient. Can be sent to an instance. In some examples, the service provider 912 may send additional or alternative information (eg, low balance to payer, current balance to payer or payee, etc.) to an instance of the payment application. In some implementations, payers and / or payees may be automatically identified based on, for example, context, accessibility, previous transaction history, and so on. In another example, the payee can send a request for funds to the payer before the payer initiates the transfer of funds. The funds transferred can be associated with any digital currency type, including but not limited to cash, cryptocurrencies, and the like. In some embodiments, the service provider 912 funds the request to the payee on behalf of the payer, speeding up the transfer process and compensating for any delays that may result from the payer's financial network. ..

）、ポンド（￡）、ルピー（

）、円（￥）などを含むがこれらに限定されない様々な通貨に対応することができる。ドル通貨インジケータ（＄）の使用が本明細書で使用されるが、任意の通貨記号が等しく使用され得ることが理解されるべきである。ピアツーピアプロセスは、ユーザデバイス９０６上で実行される特定のアプリケーションを介して開始することができる。 In one implementation, the service provider 912 can trigger a peer-to-peer payment process through the identification of a "payment proxy" with a particular syntax. For example, the syntax includes a currency indicator prefixed with one or more alphanumers (eg, $ Cash). The currency indicator acts as a tagging mechanism that tells the computer system to treat the input as a request to transfer cash from the sender, and has a syntax (including one or more alphanumers tagged by the currency indicator). Detection triggers cash transfer. Currency indicators are dollar ($), euro (

), Pound (£), Rupee ()

), Yen (¥), etc., but not limited to these. Although the use of the dollar currency indicator ($) is used herein, it should be understood that any currency symbol can be used equally. The peer-to-peer process can be initiated via a particular application running on the user device 906.

In some embodiments, the peer-to-peer process can be implemented within the forum context. The term "forum" as used herein allows for user interaction and engagement through comments, posts, messages on electronic bulletin boards, messages on social networking platforms, and / or any other type of message. Refers to the media channel of the content provider (for example, social networking platform, microblogging, blogging, video sharing platform, music sharing platform, etc.). Forums can be used by content providers to allow users of the forum to interact with each other (eg, through composing messages, posting comments, etc.). In some embodiments, a "forum" can also refer to an application or web page of an e-commerce or retail organization that provides products and / or services. Such websites may provide online "forms" that are completed before or after a product or service is added to a virtual cart. The online form can include one or more fields for receiving user interaction and engagement. Examples include the user's name and other identification information, the user's shipping address, and so on. Some of these fields may be configured to receive payment information such as payment proxy instead of other types of payment mechanisms such as credit cards, debit cards, prepaid cards, gift cards, virtual wallets and the like. ..

In some embodiments, the peer-to-peer process can be implemented within a communication application context, such as a messaging application context. The term "messaging application" as used herein is arbitrary that allows communication between users (eg, the sender and receiver of a message) using a communication message over a wired or wireless communication network. Refers to the messaging application of. The messaging application can be used by service provider 912. For example, service provider 912 can provide a messaging service that provides a communication service to a user via a messaging application (eg, chat or messaging function). Messaging applications include, for example, text messaging applications for communication between phones (eg, traditional mobile phones or smartphones), or cross-platform instant messaging applications for smartphones and phones that use the Internet for communication. Can be done. The messaging application can be run on a user device 906 (eg, a mobile device or a traditional personal computer) based on instructions sent to and from the server computing device 902 (in such an example, in such an example). Can be called a "messaging server"). In some cases, the messaging application may include a payment application having a messaging function that allows users of the payment application to communicate with each other. In such cases, the payment application is based on instructions transmitted to and from the server computing device 902 (eg, the payment service described herein, or another payment service that supports payment transactions). It can be run on device 906.

In at least some embodiments, the peer-to-peer process can be implemented within the landing page context. As used herein, the term "landing page" is a virtual identified by a personalized location address that is dedicated to collecting payments on behalf of the recipient associated with the personalized location address. Point to a position. The personalized location address that identifies the landing page can include the payment proxy described above. Service provider 912 can generate a landing page to allow recipients to conveniently receive one or more payments from one or more senders. In some embodiments, the personalized location address that identifies the landing page is a uniform resource locator (URL) that incorporates a payment proxy. In such an embodiment, the landing page is a web page, eg, www. cash. It is me / $ cash.

In at least one example, a user 914 not registered with a service provider 912 is a user 914 to a service provider 912 (eg, subscribed to gain access to one or more services provided by the service provider). May be new. Service provider 912 can provide an onboarding service for registering potential users 914 with service provider 912. In some examples, onboarding involves presenting various questions, prompts, etc. to the potential user 914 in order to obtain information that can be used to generate a profile for the potential user 914. be able to. In at least one example, the service provider 912 may provide limited or short-term access to the service before or during onboarding (eg, users of peer-to-peer payment services are fully on). Funds can be transferred and / or received before boarding, merchants can process payments before they are fully onboarded, etc.). In at least one example, the potential user 914 can be onboarded to the service provider 912 in response to the potential user 914 providing all the necessary information. In such an example, any limited or short-term access to the service of service provider 912 shifts to more permissive (eg, less limited) or longer-term access to such service. Can be done.

The service provider 912 can be associated with the IDV service, which can be used by the service provider 912 for compliance purposes and / or, for example, a third party service provider (eg, associated with the server computing device 910). Can be provided as a service to. That is, the service provider 912 can provide IDV services and verify the identity of the user 914 who uses or intends to use those services. Identity verification requires a customer (or potential customer) to provide information that is used by the compliance department to prove that the information is associated with the identity of a real person or entity. In at least one example, the service provider 912 determines whether the identification information provided by user 914 accurately identifies the customer (or potential customer) (ie, is the customer they say is). It is possible to execute a service for determining.

Service provider 912 may provide additional or alternative services, the services described above being provided as a sampling of services. In at least one example, the service provider 912 can exchange data with the server computing device 910 associated with the third party service provider. Such a third-party service provider can provide information that allows the service provider 912 to provide such services as described above. In an additional or alternative example, such a third party service provider may have access to the services of service provider 912. That is, in some examples, the third-party service provider can be a subscriber and otherwise access the services of service provider 912.

The techniques described herein can be configured to operate in both real-time / online and offline modes. The "online" mode refers to a mode in which the device can communicate with the service provider 912 (eg, the server computing device 902) and / or the server computing device 910 over the network 904. In some examples, the merchant device 908 is unable to connect to the service provider 912 (eg, server computing device 902) and / or server computing device 910, for example due to network connectivity issues. In an additional or alternative example, the server computing device 902 is unable to communicate with the server computing device 910, for example due to network connectivity issues. In such an example, at least some payment data (eg, a merchant device) is available until connectivity is restored and payment data is sent to the server computing device 902 and / or the server computing device 910 for processing. When stored (908) and / or on the server computing device 902), the device may operate in "offline" mode.

In at least one example, the service provider 912 is an order hub, inventory hub, fulfillment hub that allows integration with one or more additional service providers (eg, associated with an additional server computing device 910). Can be associated with hubs such as. In some examples, such additional service providers may provide additional or alternative services, and the service provider 912 integrates the functionality of the service provider 912 into one or more additional service providers. It can provide an interface or other computer-readable instructions to do so.

The techniques described herein are services provided through a distributed system of user devices 906 communicating with one or more server computing devices 902 and / or proxy server computing devices 915 of service provider 912. Yes, and can be associated with the service provider 912. That is, the techniques described herein may be associated with one or more server computing devices 902 and / or service provider 912 of service provider 912 in order to perform various services, as described above. Possible Proxy Server Targets specific implementations or practical applications that utilize a distributed system of user devices 906 that communicate with computing devices 915. The non-traditional configuration of the distributed system described herein is that the server computing device 902 remotely located from the end user (eg, user 914) has aggregated data related to the end user, such as user 914 (eg, user 914). Allows you to intelligently deliver services based on multiple, different merchants and / or multiple, different buyer related data) in near real time. Accordingly, the techniques described herein are directed to a particular configuration of elements that provide technical improvements over conventional techniques for performing payment processing services and the like. Especially for small business owners, the business environment is typically fragmented and relies on irrelevant tools and programs to allow owners to manually integrate and view such data. Making it difficult. The techniques described herein are accounts within the control of Service Provider 912, and control of Service Provider 912, to track the merchant's business condition (debt, receivables, salaries, invoices, appointments, capital, etc.). Monitor different and separate merchant accounts, such as outside accounts, on a regular or regular basis. The techniques herein provide an integrated view of a merchant's cash flow, anticipate needs, preemptively provide recommendations or services such as capital, coupons, and / or disparate in a frictionless and transparent manner. Allows money to be transferred between accounts (merchant, another merchant, or even payment services).

As described herein, artificial intelligence, machine learning, etc. can be used to dynamically make decisions, recommendations, etc., thereby making payment processing services and / or as described herein. Add intelligence and context awareness to the otherwise uniform scheme for providing additional or alternative services. In some implementations, distributed systems can apply intelligence derived from an existing user base to new users, thereby providing a new user's onboarding experience when compared to traditional onboarding methods. Personalize and make it frictionless. Therefore, the techniques described herein improve existing technical processing.

As mentioned above, various graphical UIs (GUIs) can be presented to facilitate the techniques described herein. Some of the techniques described herein are directed to UI features presented via the GUI to improve the dialogue between the user 914 and the user device 906. Moreover, such features are dynamically modified based on the profile of the user interacting with the GUI. Therefore, the techniques described herein are intended to improve computing systems.

FIG. 10 shows an exemplary block diagram showing a system 1000 for performing the techniques described herein. The system 1000 includes networks 1006 (eg, internet, cable networks, cellular networks, cloud networks, wireless networks (eg Wi-Fi) and wired networks), as well as Bluetooth®, Bluetooth® Low Energy (BLE). ), Etc.), and the user device 1002 that communicates with the server computing device (for example, the server 1004). Although a single user device 1002 is shown, in additional or alternative examples, the system 1000 can have multiple user devices, as described above with reference to FIG.

In at least one example, the user device 1002 can correspond to the merchant device 102 described above with reference to FIG. The server 1004 can correspond to the server 116 described above with reference to FIG.

In at least one example, the user device 1002 can be any suitable type of computing device, eg, portable, semi-portable, semi-stationary, or stationary. Some examples of user device 1002 are tablet computing devices, smartphones or mobile communication devices, laptops, netbooks or other portable or semi-portable computers, desktop computing devices, terminal computing devices or other semi-stationary. It can also include, but is not limited to, stationary computing devices, dedicated devices, wearable computing devices or other body-mounted computing devices, augmented reality devices, virtual reality devices, Internet of Things (IoT) devices, and the like. That is, the user device 1002 can be any computing device capable of transmitting communications and performing functions according to the techniques described herein. The user device 1002 can include a device capable of accepting payments, such as a payment card reader, or a component, as described below.

In the illustrated example, the user device 1002 is one or more processors 1008, one or more computer readable media 1010, one or more communication interfaces 1012, one or more input / output (I / O) devices. Includes 1014, display unit 1016, and sensor 1018.

In at least one example, each processor 1008 can itself include one or more processors or processing cores. For example, processor 1008 is as one or more microprocessors, microcontrollers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and / or any device that manipulates signals based on operating instructions. Can be implemented. In some examples, the processor 1008 is with one or more hardware processors and / or logic circuits of any suitable type specifically programmed or configured to perform the algorithms and processes described herein. can do. The processor 1008 can be configured to fetch and execute a computer-readable processor executable instruction stored in the computer-readable medium 1010.

Depending on the configuration of the user device 1002, the computer readable medium 1010 can be an example of a tangible, non-temporary computer storage medium of computer readable processor executable instructions, data structures, program modules, or other data. It can include volatile and non-volatile memory and / or removable and non-removable media implemented in any type of technology for storing such information. Computer-readable media 1010 can include, but is not limited to, RAM, ROM, EEPROM, flash memory, solid-state storage, magnetic disk storage, optical storage, and / or other computer-readable media technology. Further, in some examples, the user device 1002 can be used to store a RADIUS storage system, storage array, network-attached storage, storage area network, cloud storage, or information, either directly by processor 1008 or by processor 1008. You can access external storage devices such as any other medium that can be accessed via another computing device or network. Therefore, the computer readable medium 1010 is a computer storage medium capable of storing instructions, modules or components that can be executed by the processor 1008. Further, when mentioned, non-temporary computer-readable media exclude media such as energy, carrier signals, electromagnetic waves, and the signal itself.

The computer-readable medium 1010 can be used to store and maintain any number of functional components that can be executed by the processor 1008. In some embodiments, these functional components are executable by the processor 1008, and when executed, an instruction or instruction or instruction that implements the operation logic for executing the operation and service belonging to the above on the user device 1002. Includes program. The functional components stored in the computer-readable medium 1010 include the POS application 104 described above with reference to FIG. 1 and / or the POS application 1020 capable of corresponding to the POS application 918 described above with reference to FIG. Can be done.

Depending on the type of user device 1002, the computer readable medium 1010 may optionally include modules and other functional components and data such as data 1022, which may include UIs, programs, drivers, etc., as well as by functional components. It can also contain data that is used or generated. As an example, modules and data can include a UI that allows the user to interact with the user device 1002, and thus the server 1004 and / or other networked devices. In at least one example, the UI can be presented via a web browser or the like. In another example, the UI can be presented via an application such as a mobile application or desktop application, which can be provided by the service provider 912 associated with the server 1004, otherwise it is a dedicated application. be able to. In at least one example, the user can interact with the UI via touch input, voice input, gestures, or any other type of input. The word "input" is also used to describe "context" inputs that may not be provided directly by the user via the UI. For example, the user's interaction with the UI can be analyzed, for example, using natural language processing techniques to determine the user's context or intent, which can be processed in a manner similar to "direct" user input.

Further, the computer-readable medium 1010 can also store data, data structures, etc. used by the functional components. Further, the user device 1002 can include many other logical, programmatic, and physical components, of which those described are merely examples related to the description herein.

In at least one example, the computer readable medium 1010 can include additional functional components such as an operating system 1024 that controls and manages various functions of the user device 1002 and enables basic user interaction.

The communication interface 1012 may include one or more interfaces and hardware components to allow communication with various other devices via or directly through the network 1006. For example, the communication interface 1012 allows communication over one or more networks 1006, which may include any type of network known in the art, such as a local area network such as the Internet or a wide area network. Can be a cellular network, a cloud network, a local wireless network such as Wi-Fi and / or short-range wireless communication, such as Bluetooth®, BLE, NFC, RFID, wired network, or any other. Such networks, or any combination thereof, can be included. Thus, the network 1006 can include both Bluetooth®, BLE, Wi-Fi and cellular communication technologies as well as wired and / or wireless communication technologies including wired or fiber optic technologies. The components used for such communication can be at least partially dependent on the type of network, the environment selected, or both. Protocols for communicating over such networks are well known and are not described in detail herein.

The embodiments of the present disclosure can be provided to users via a cloud computing infrastructure. Cloud computing refers to providing scalable computing resources as a service on a network, a shared pool of configurable computing resources that can be quickly provisioned and released with minimal administrative effort or service provider interaction. Allows convenient on-demand network access to. Therefore, cloud computing is a virtual computing resource (eg, for example) in the "cloud" regardless of the underlying physical systems (or the location of those systems) used by the user to provide the computing resources. Allows access to storage, data, applications, and fully virtualized computing systems.

The user device 1002 may further include one or more input / output (I / O) devices 1014. The I / O device 1014 can include speakers, microphones, cameras, various user controls (eg, buttons, joysticks, keyboards, keypads, etc.), tactile output devices, and the like. The I / O device 1014 may also include an attachment that utilizes accessories (audio jack, USB-C, Bluetooth, etc.) to connect to the user device 1002.

In at least one example, the user device 1002 may include a display unit 1016. Depending on the type of computing device used as the user device 1002, the display unit 1016 may use any suitable display technique. For example, the display unit 1016 may be a liquid crystal display, a plasma display, a light emitting diode display, an OLED (organic light emitting diode) display, an electronic paper display, or any other suitable type of display capable of presenting digital content on it. Can be. In at least one example, the display unit 1016 can be an augmented reality display, a virtual reality display, or any other display capable of presenting and / or projecting digital content. In some examples, the display unit 1016 has a touch sensor associated with the display unit 1016 to receive touch inputs to allow interaction with the graphic interface presented on the display unit 1016. A configured touch screen display can be provided. Therefore, the embodiments of the present specification are not limited to any particular display technique. Alternatively, in some examples, the user device 1002 may not include the display unit 1016 and the information may be presented by other means such as auditory, tactile and the like.

Further, the user device 1002 can include a sensor (s) 1018. The sensor (s) 1018 can include a GPS device capable of indicating location information. Further, the sensor 1018 can include, but is not limited to, an accelerometer, a gyroscope, a compass, a proximity sensor, a camera, a microphone, and / or a switch.

In some examples, GPS devices can be used to identify the user's location. In at least one example, the user's location may be used by the service provider 912 described above to provide one or more services. That is, in some examples, service provider 912 may implement geo-fencing to provide a particular service to the user. As an example, in a lending service, a location can be used to ensure that the defined purpose of a loan corresponds to evidence of use (eg, a user using a loan means that the user himself / herself). Consistent with what you said you would use). In addition, in some examples, positions can be used for payroll purposes. As an example, if the contractor completes the project, the contractor may provide a geotagged image (eg, tagged based on location information available by a GPS device). In some examples, the location sends a notification to the user 914 to facilitate peer-to-peer payments between nearby users 914 and / or regarding available reservations with merchants located close to the user 914. Can be used for. In at least one example, the location can be used to make a payment from a nearby customer when a nearby customer leaves the geofence, or the location is that the user 914 enters the merchant's physical store. It can be used to respond and initiate an action. Positions can also be used in additional or alternative ways.

In addition, the user device 1002 can include various other components (not shown), such as removable storage, power supplies such as storage batteries and power control units, bar code scanners, printers, cash withdrawals. Etc. are included.

Further, in some examples, the user device 1002 may include a reader device 1026 to read the payment instrument and / or identifier associated with the payment object and may or may not be able to connect to the reader device 1026. If not, it can be connected to the reader device 1026. In at least one example, the reader device 1026 can correspond to the reader device 106 described above with reference to FIG. 1 and / or the reader device 922 described above with reference to FIG. In some examples, as mentioned above, the reader device 1026 can be plugged into a port within the user device 1002, such as a microphone port, headphone port, audio jack, data port, or other suitable port. In an additional or alternative example, the reader device 1026 can be connected to the user device 1002 via another wired or wireless connection, such as via Bluetooth®, BLE, or the like. The reader device 1026 can include a read head for reading the magnetic strip of the payment card, and can further include an encryption technique for encrypting the information read from the magnetic strip. Additionally or additionally, the reader device 1026 can be, in some examples, an EMV payment reader that can be embedded in the user device 1002. Further, depending on the type and configuration of the user device 1002, many other types of readers can be used with the user device 1002 herein.

Reader device 1026 is a portable magnetic stripe card reader, optical scanner, smart card (card with embedded IC chip) reader (eg, EMV compliant card reader) configured to detect and retrieve data from any payment instrument. Alternatively, it may be a reader capable of short-distance communication), an RFID reader, or the like. Accordingly, the reader device 1026 may include hardware implementations such as slots, magnetic tracks, and rails with one or more sensors or electrical contacts to facilitate detection and acceptance of payment instruments. That is, the reader device 1026 is a swipe (ie, a card presentation transaction in which a customer slides a card with a magnetic strip through a payment reader that captures payment data contained in the magnetic strip), a dip (ie, a microchip in which the customer is embedded (ie, a customer-embedded microchip). That is, a card presentation transaction that first inserts a card with a chip) into a payment reader) or taps (ie, a customer taps or hoveres his or her electronic device, such as a smartphone running a payment application on the payment reader). Can include a hardware implementation that allows the reader device 1026 to interact with the payment instrument via a card-presenting transaction that can complete the transaction via short-range communication. Further, or optionally, the reader device 1026 receives and processes the biometric characteristics when the biometric characteristics are registered in the payment service environment 100 and is connected to a financial account having a bank server, and the payment means. It can also include a biometric sensor to be treated as.

The reader device 1026 can include a processing unit, a computer-readable medium, a reading chip, a trading chip, a timer, a clock, a network interface, a power supply, and the like. The processing unit of the reader device 1026 executes one or more modules and / or processes to provide the reader device 1026 with various functions as described above and further described in the disclosure below. Can be executed. In some examples, the processing unit can include a central processing unit, a graphics processing unit, a CPU and GPU, or a processing unit or component known in the art. In addition, each processing unit can have its own local memory that can also store program modules, program data, and / or one or more operating systems. Depending on the exact configuration and type of reader device 1026, the computer readable medium shall include volatile memory, non-volatile memory (ROM, flash memory, miniature hard drives, memory cards, etc.), or some combination thereof. Can be done. In at least one example, the computer-readable medium of the reader device 1026 may include at least one module for performing the various functions described herein.

The reading chip can perform functions that control the operation and processing of the reader device 1026. That is, the reading chip can perform functions to control payment interfaces (eg, non-contact interfaces, contact interfaces, etc.), wireless communication interfaces, wired interfaces, UIs (eg, signal state devices (FPGAs)), and the like. Further, the reading chip can perform a function of controlling a timer that can provide a timer signal indicating the amount of time elapsed following a particular event (eg, dialogue, power event, etc.). In addition, the reading chip may perform functions for controlling the clock, which may provide a clock signal indicating time. Further, the reading chip may perform a function of controlling the network interface, which may be interface-connected with the network 1006, as described below.

Further, the reading chip can perform a function of controlling the power supply. The power supply can include one or more power supplies, such as an AC power supply or a physical connection to a battery. The power supply may include a power conversion circuit for converting AC power and generating multiple DC voltages for use by the components of the reader device 1026. If the power supply includes a storage battery, the storage battery may be charged via a physical power connection, via inductive charging, or via any other suitable method.

The transaction chip can perform functions related to processing payment transactions, interface with payment instruments, encryption, and other payment-specific functions. That is, as described above, the transaction chip can access the payment data related to the payment means and provide the payment data to the POS terminal. Payment data includes the customer's name, customer's address, type of payment instrument (eg, credit, debit, etc.), number associated with the payment instrument, validation value associated with the payment instrument (eg, PIN verification key indicator (PVKI)). PIN verification value (PVV), card verification value (CVV), card verification code (CVC), etc.), expired data related to the payment method, primary account number (PAN) corresponding to the customer (number related to the payment method) It may or may not match), and may include, but is not limited to, restrictions on what type of charge / debt may be made. In addition, the transaction chip can encrypt the payment data upon receipt of the payment data.

In some examples, the reading chip may have its own processing unit and computer readable medium, and / or the trading chip may have its own processing unit and computer readable medium. Should be understood. In another example, the reading and trading chip functions can be embodied in a single chip or multiple chips, and each chip collectively performs the reading and trading chip functions described herein. To include any suitable combination of processing unit and computer readable medium.

The user device 1002, which can be a POS terminal, and the reader device 1026 are shown as separate devices, but in an additional or alternative example, the user device 1002 and the reader device 1026 are battery-powered devices. Can be part of a single device that can be. In such an example, both components of the user device 1002 and the reader device 1026 may be associated with a single device. In some examples, the reader device 1026 can have a display unit integrated with it, which can be added to (or an alternative to) the display unit 1016 associated with the user device 1002.

Server 1004 can include one or more servers or other types of computing devices that can be embodied in any number of ways. For example, in the server example, modules, other functional components, and data can be implemented in a single server, a cluster of servers, a server farm or data center, a cloud host computing service, a cloud host storage service, and so on. Yes, but other computer architectures can be used additionally or as an alternative.

Further, although the figure shows that the components and data of the server 1004 are in a single location, these components and data can be distributed in different ways to different computing devices and different locations. As a result, functionality can be achieved by one or more server computing devices, and the various functionality described above is distributed in different ways across different computing devices. The plurality of servers 1004 can be arranged together or separately, and can be organized as, for example, a virtual server, a server bank, and / or a server farm. The described functionality can be provided by a single merchant or enterprise server, or by multiple different customer or enterprise servers and / or services.

In the illustrated example, the server 1004 can include one or more processors 1028, one or more computer readable media 1030, one or more I / O devices 1032, and one or more communication interfaces 1034. Each processor 1028 can be a single processing unit or a plurality of processing units and can include a single or a plurality of computing units or a plurality of processing cores. Processor 1028 is implemented as one or more microprocessors, microcontrollers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and / or any device that manipulates signals based on operating instructions. be able to. For example, the processor (s) 1028 may include one or more hardware processors and / or logic circuits of any suitable type specifically programmed or configured to perform the algorithms and processes described herein. can do. Processor 1028 can be configured to fetch and execute computer-readable instructions stored on the computer-readable medium 1030, which can be configured to program processor 1028 to perform the functions described herein. can.

The computer-readable medium 1030 is a volatile and non-volatile memory and / or removable that is implemented in any type of technology for storing information, such as computer-readable instructions, data structures, program modules, or other data. And can include non-removable media. Such computer readable media 1030 is, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, optical storage, solid storage, magnetic tape, magnetic disk storage system, RADIUS storage system, storage. It may include arrays, network-attached storage devices, storage local area networks, cloud storage devices, or any other medium that can be used to store desired information and can be accessed by computing devices. can. Depending on the configuration of the server 1004, the computer readable medium 1030 can be a kind of computer readable storage medium and / or, if mentioned, a non-temporary computer readable medium can be energy, carrier signals, electromagnetic waves, etc. And as long as the medium such as the signal itself is excluded, it can be a tangible non-temporary medium.

The computer-readable medium 1030 can be used to store any number of functional components that can be executed by the processor 1028. In many embodiments, these functional components include instructions or programs that can be executed by processor 1028, such that when executed, the service provider 912 and / or the payment processing service performs the actions attributed to the above. Specifically, one or more processors 1028 are configured. Functional components stored on the computer-readable medium 1030 can optionally include a payment processing application 1036, a training application 1038, and one or more additional or alternative modules and data 1040.

The payment processing application 1036 can correspond to the payment processing application 122 described above with reference to FIG.

The training application 1038 can be configured to train the model using a machine learning mechanism. For example, a machine learning mechanism can analyze training data and train a data model that produces output that can be recommendations, scores, and / or other indications. Machine learning mechanisms include monitored learning algorithms (eg, artificial neural networks, Bayesian statistics, support vector machines, decision trees, classifiers, k-nearest neighbors, etc.), unsupervised learning algorithms (eg, artificial neural networks, association rules, etc.). It can include, but is not limited to, learning, hierarchical clustering, cluster analysis, etc.), semi-supervised learning algorithms, deep learning algorithms, etc.), statistical models, and so on. In at least one example, the machine-trained data model can be stored in a data store associated with user device 1002 and / or server 1004 for use after training (eg, at run time). ..

In addition, one or more other modules and data 1040 can include data used or generated by programs, drivers, etc., and functional components. Further, the server 1004 can include many other logical, program, and physical components, of which those described above are merely examples related to the description herein.

One or more "modules" referred to herein can be implemented as more or less modules, and the functionality described for the modules is redistributed according to the details of the implementation. be able to. As used herein, the term "module" refers to software, hardware, or firmware (or theirs) stored in non-temporary storage media (eg, volatile or non-volatile memory for computing devices). Any combination) Broadly refers to a module. Modules usually function to be able to generate useful data or other output using the specified inputs. The module may or may not be built-in. An application program (also referred to as an "application") can include one or more modules, or the modules can be accessed over the network or downloaded as software on the device. It can contain one or more application programs (eg, executable code that causes the device to perform an action). An application program (also referred to as an "application") can include one or more modules, and a module can include one or more application programs. In additional and / or alternative examples, the module is at least one to execute an instruction and configure the computing device described herein to perform the operations described herein. It can be implemented as computer readable instructions, various data structures, etc. via a processing unit.

In some examples, a module may include one or more application programming interfaces (APIs) to perform some or all of its functions (eg, operations). In at least one example, a software developer kit (SDK) is provided by a service provider to allow a third party developer to include service provider functionality and / or utilize service provider services in connection with their own third party application. Can be made possible. Further, or instead, in some examples, the service provider can leverage the SDK to integrate third-party service provider functionality into its application. That is, APIs or SDKs allow third-party developers to customize how each third-party application interacts with the service provider (or vice versa).

The computer readable medium 1030 may additionally include an operating system 1042 for controlling and managing various functions of the server 1004.

Communication interface 1034 can include one or more interfaces and hardware components to allow communication with various other devices, either via network 1006 or directly. For example, the communication interface 1034 can allow communication through one or more networks 1006, which is any type known in the art, such as a local area network such as the Internet or a wide area network. Networks can include cellular networks, Wi-Fi and / or local wireless networks such as short-range wireless communications, such as Bluetooth®, BLE, NFC, RFID, wired networks, or any of these. It can include wireless networks such as combinations. Thus, the network 1006 can include both Bluetooth®, BLE, Wi-Fi and cellular communication technologies as well as wired and / or wireless communication technologies including wired or fiber optic technologies. The components used for such communication can be at least partially dependent on the type of network, the environment selected, or both. Protocols for communicating over such networks are well known and are not described in detail herein.

Server 1004 can further include various I / O devices 1032. Such I / O devices 1032 can include displays, various UI controls, buttons, joysticks, keyboards, mice, touch screens, biometric or sensory input devices, etc.), audio speakers, connection ports, and the like.

In at least one example, the system 1000 can include a data store 1044 that can be configured to store accessible, manageable, and updatable data. In some examples, the data store 1044 can be integrated with the user device 1002 and / or the server 1004. In another example, as shown in FIG. 10, the data store 1044 can be located remotely from the server 1004 and can access the server 1004. Database store 1044 may include multiple databases and / or servers connected locally and / or remotely via network 1006.

In at least one example, the data store 1044 can store a user profile that can include a merchant profile, a customer profile, and so on.

The merchant profile can store or otherwise associate with the data associated with the merchant. For example, a merchant profile can be information about a merchant (eg, merchant's name, merchant's geographic location, employee information, etc.), merchant categorization (MCC), items provided by the merchant, hardware used by the merchant (eg,). For example, device type), transaction data related to the merchant (eg, transactions made by the merchant, payment data related to the transaction, items related to the transaction, description of the item related to the transaction, itemized expenditure for each transaction and / Or total spending, parties to the transaction, date, time, and / or location, etc., loan information related to the merchant (eg, previous loan made to the merchant, previous default of the loan, etc.), related to the merchant. Risk information (eg, risk indications, fraud, chargeback instances, etc.), appointment information (eg, previous appointment, next (scheduled) appointment, appointment timing, appointment length, etc.), salary information (Eg employee, salary frequency, salary amount, etc.), employee information, booking data (eg, previous booking, next (scheduled) booking, dialogue related to such booking, etc.), inventory data, Customer service data, etc. can be stored or otherwise associated. The merchant profile can securely store the bank account information provided by the merchant. Further, the merchant profile can store payment information related to the payment instrument linked to the merchant's storage balance, such as the storage balance maintained in the ledger by the service provider 912.

Customer profiles include customer information (eg, name, phone number, address, banking information, etc.), customer preferences (eg, learned or customer-specified), and purchase history data (eg, identifying one or more purchased items). A payment instrument used to purchase one or more items (and their respective item information), a payment instrument associated with one or more orders, and the status of one or more orders (eg, preparation, Packing, in transit, in transit, etc.), booking data (eg, previous booking, next (planned) booking, booking timing, booking length, booking length, etc.), salary data (eg, employment) Person, salary payment frequency, salary payment amount, etc.), reservation data (eg, previous reservation, next (planned) reservation, reservation period, dialogue related to such reservation, etc.), inventory data, customer service data. It is possible to store customer data including, but not limited to, such as.

Further, in at least one example, the data store 1044 can store an inventory database and / or a catalog database. As mentioned above, inventory can store data related to the quantity of each item (item) available to the merchant. In addition, the catalog can store data related to the items available for acquisition by the merchant. The data store 1044 can store additional or alternative types of data as described herein.

As described above with reference to FIGS. 1 and 9, the exemplary system 1000 corresponds to the proxy server 118 described above with reference to FIG. 1 and / or the proxy server 915 described above with reference to FIG. Can include a proxy server 1046.

Proxy server 1046 can include one or more servers or other types of computing devices that can be embodied in any number of ways. For example, in the server example, modules, other functional components, and data can be implemented in a single server, a cluster of servers, a server farm or data center, a cloud host computing service, a cloud host storage service, and so on. However, other computer architectures can be used additionally or as an alternative. As mentioned above, in some examples, the proxy server 1046 may be located in a different state, country, or other geographic region than the server 1004.

Further, although the figure shows that the components and data of proxy server 1046 are in a single location, these components and data can be distributed to different computing devices and different locations in different ways. can. As a result, functionality can be achieved by one or more server computing devices, and the various features described above are distributed in different ways across different computing devices. Multiple proxy servers 1046 can be placed together or separately and can be organized as, for example, virtual servers, server banks and / or server farms. The described functionality can be provided by a single merchant or enterprise server, or by multiple different customer or enterprise servers and / or services.

In the illustrated example, the proxy server 1046 can include one or more processors 1048, one or more computer readable media 1050, one or more I / O devices 1052, and one or more communication interfaces 1054. Each processor 1048 can be a single processing unit or a plurality of processing units and can include a single or a plurality of computing units or a plurality of processing cores. Processor 1048 is implemented as one or more microprocessors, microcontrollers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and / or any device that manipulates signals based on operating instructions. be able to. For example, the processor (s) 1048 may be any suitable type of hardware processor and / or configured specifically programmed or configured to perform the algorithms and processes described herein. It can be a logic circuit. Processor 1048 can be configured to fetch and execute computer-readable instructions stored in computer-readable media 1050, which can be configured to program processor 1048 to perform the functions described herein. can.

The computer-readable medium 1050 is a volatile and non-volatile memory and / or removable that is implemented in any type of technology for storing information, such as computer-readable instructions, data structures, program modules, or other data. And can include non-removable media. Such computer readable media 1050 is, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, optical storage, solid storage, magnetic tape, magnetic disk storage system, RADIUS storage system, storage array. , Network-attached storage, storage local area networks, cloud storage, or any other medium that can be used to store desired information and can be accessed by computing devices. .. Depending on the configuration of the proxy server 1046, the computer readable medium 1050 can be a kind of computer readable storage medium, and / or, if mentioned, a non-temporary computer readable medium can be energy, carrier signals, electromagnetic waves, etc. And as long as the medium such as the signal itself is excluded, it can be a tangible non-temporary medium.

The computer-readable medium 1050 can be used to store any number of functional components that can be executed by the processor 1048. In many embodiments, these functional components include instructions or programs that can be executed by processor 1048, such that when executed, the service provider 912 and / or the payment processing service performs the actions attributed to the above. Specifically, one or more processors 1048 are configured. The functional components stored in the computer readable medium 1050 can optionally include the communication application 1056 and one or more additional or alternative modules and data 1058. The communication application 1056 can correspond to the communication application 120 described above with reference to FIG. In addition, one or more other modules and data 1058 may include data used or generated by programs, drivers, etc., and functional components. Further, the proxy server 1046 can include many other logical, programmatic, and physical components, of which the above are merely examples related to the description herein.

One or more "modules" referred to herein can be implemented as more or less modules, and the features described for the modules are redistributed according to the details of the implementation. can do. As used herein, the term "module" refers to software, hardware, or firmware (or theirs) stored in non-temporary storage media (eg, volatile or non-volatile memory for computing devices). Any combination) Broadly refers to a module. Modules usually function to be able to generate useful data or other output using the specified inputs. The module may or may not be built-in. An application program (also referred to as an "application") can include one or more modules, or the modules can be accessed over the network or downloaded as software on the device. It can contain one or more application programs (eg, executable code that causes the device to perform an action). An application program (also referred to as an "application") can include one or more modules, and a module can include one or more application programs. In additional and / or alternative examples, the module is at least one to execute an instruction and configure the computing device described herein to perform the operations described herein. It can be implemented as computer readable instructions, various data structures, etc. via a processing unit.

In some examples, a module may include one or more application programming interfaces (APIs) to perform some or all of its functions (eg, operations). In at least one example, a software developer kit (SDK) is provided by a service provider to allow a third party developer to include service provider functionality and / or utilize service provider services in connection with their own third party application. Can be made possible. Further, or instead, in some examples, the service provider can leverage the SDK to integrate third-party service provider functionality into its application. That is, APIs or SDKs allow third-party developers to customize how each third-party application interacts with the service provider (or vice versa).

The computer readable medium 1030 may additionally include an operating system 1042 for controlling and managing various functions of the proxy server 1060.

The proxy server 1046 may further include various I / O devices 1052. Such I / O devices 1052 can include displays, various UI controls, buttons, joysticks, keyboards, mice, touch screens, biometric or sensory input devices, etc.), audio speakers, connection ports, and the like.

The communication interface 1054 can include one or more interfaces and hardware components to allow communication with various other devices, either via network 1006 or directly. For example, the communication interface 1054 can allow communication through one or more networks 1006, which is any type known in the art, such as a local area network such as the Internet or a wide area network. Networks can include cellular networks, Wi-Fi and / or local wireless networks such as short-range wireless communications, such as Bluetooth®, BLE, NFC, RFID, wired networks, or any of these. It can include wireless networks such as combinations. Thus, the network 1006 can include both Bluetooth®, BLE, Wi-Fi and cellular communication technologies as well as wired and / or wireless communication technologies including wired or fiber optic technologies. The components used for such communication can be at least partially dependent on the type of network, the environment selected, or both. Protocols for communicating over such networks are well known and are not described in detail herein.

Phrases such as "in some examples", "according to various examples", "in the examples shown", "in one example", "in other examples", "various examples", "some examples" In general, means a particular feature, structure, or property following a phrase, which is included in at least one example of the invention and may be included in two or more examples of the invention. Moreover, such terms do not necessarily refer to the same or different examples.

Where a component or property is described as "possible", "possible" or "may have a property" in the specification, that particular component or property is included. Or it is not required to have properties.

In addition, the aforementioned description is intended for devices and applications related to payment technology. However, it will be appreciated that the technology can be extended to any device and application. In addition, the techniques described herein can be configured to work regardless of the type of payment object reader, POS terminal, web application, mobile application, POS topology, payment card, computer network, and environment.

The various figures included herein are flowcharts illustrating exemplary methods, including the techniques described herein.

Further, the method described above is presented as a set of blocks in a logical flow graph representing a sequence of operations that can be implemented by hardware, software, or a combination thereof. In the context of software, it represents a computer-executable instruction stored on one or more computer-readable storage media that performs the described actions when the block is executed by the processor. In general, computer-executable instructions include routines, programs, objects, components, data structures, etc., performing specific functions or implementing specific abstract data types. The order in which the behavior is described is not intended to be construed as limiting, and any number of described blocks may be combined in any order and / or in parallel to implement the process. In some embodiments, one or more blocks of the process can be omitted altogether. Moreover, these methods can be combined in whole or in part with each other or with other methods.

Exemplary A: On a merchant device of a merchant associated with a payment processing service, receiving an indication of a transaction between the merchant and the customer, the customer receiving electronic money (to satisfy the payment of the transaction). e-money) Present the payment card, receive the above,
Sending an indication of the transaction from the merchant device to a third-party payment processor via a proxy server computing device associated with the payment processing service.
The merchant device receives instructions from the third party payment processor via the proxy server computing device to the reader device associated with the merchant device in preparation for reading payment data from the electronic commerce payment card. That is, the electronic money payment card is associated with the electronic money balance, and the merchant device sends, receives, and receives the command to the reader device.
Receiving the payment data associated with the e-commerce payment card in the merchant device through a dialogue between the e-commerce payment card and the reader device.
The merchant device may (i) send a first request to the third party payment processor via the proxy server computing device to approve the electronic money payment card for the cost of the transaction. ii) To ensure that a second request is sent to the server computing device associated with the payment processing service to record the transaction.
In response to having the merchant device send the first request to a third-party payment processor, the payment data is sent from the third-party payment processor via the proxy server computing device for the cost of the transaction. Receiving the first response that it is approved,
Allowing the merchant device to write a new e-commerce balance to the e-commerce payment card.
In the merchant device, the transaction is recorded by the payment processing service from the server computing device via the proxy server computing device in response to causing the second request to be sent to the server computing device. Receiving a second response that says
Presenting the UI indicating that the transaction has been completed and the new e-commerce balance associated with the e-commerce payment card via the display unit associated with the merchant device.
How to include.

B: The second request is at least one of an identifier associated with the merchant, an identifier associated with the customer, the total cost of the transaction, or one or more items associated with the transaction. The method of clause A associated with.

C: At least in part, further comprising sending a write confirmation to the third party payment processor via the proxy server computing device based on having the new e-commerce balance written to the e-commerce payment card. , Phrase A or B.

D: In response to the merchant device transmitting the indication of the transaction to the third party payment processor via the proxy server computing device, the proxy server computing device is the merchant device and the third party. The method of any of clauses A through C, wherein an identifier is associated with said transaction to track subsequent communication with a party payment processor.

E: It ’s a merchant device,
With one or more processors
When executed by the one or more processors, the merchant device.
Receiving an indication of a transaction between a merchant and a customer, said customer, electronic money (e-money) to meet payment for at least a portion of the cost of one or more items associated with the transaction. ) Presenting the payment instrument associated with the balance, said receiving and
Sending the indication of the transaction to a third-party payment processor,
Receiving instructions from the third-party payment processor associated with the dialogue between the payment instrument and the reader device associated with the merchant device.
Receiving payment data associated with the payment instrument via the reader device, and
(I) send a first request to the third-party payment processor, and (ii) send a second request to at least the server computing device associated with the payment processing service that processes the transaction on behalf of the merchant. When,
In response to sending the first request, receiving a first response from the third party payment processor indicating that the payment data is approved for payment.
To associate the new e-commerce balance with the payment instrument,
Receiving a second response to the second request, wherein the second response indicates that the transaction was recorded by the payment processing service.
To present information associated with a commercial transaction through a display associated with the merchant device.
One or more non-temporary computer-readable media containing instructions to perform an operation, including
A merchant device.

F: The merchant device according to clause E, wherein the reader device is communicably coupled to the merchant device via Bluetooth® or a Near Field Communication (NFC) network.

G: The merchant device according to phrase E or F, wherein the reader device is integrated with the merchant device.

H: The merchant device according to any of clauses E to G, wherein the reader device is coupled to the merchant device via a wired connection.

I: Further comprising sending a confirmation to the third party payment processor, at least in part based on associating the new e-commerce balance with the payment instrument, the second response to the third party payment processor. The merchant device according to any of clauses E to H, which is received at least in part on the basis of transmitting the confirmation.

J: The operation is (i) before sending the first request to the third-party payment processor and (ii) sending the second request to the server computing device associated with the payment processing service.
Compressing the data packet size of the first request and the second request,
To encrypt the first and second requirements, at least in part based on the compression.
The merchant device according to any one of phrases E to I, further comprising.

K: When executed by one or more processors, the one or more processors
On a merchant's merchant device associated with a payment processing service, receiving from a third-party payment processor the instructions associated with the interaction between the payment instrument associated with the customer and the reader device associated with said merchant device. That the payment instrument is associated with an electronic money (e-money) balance, said receiving and
Receiving payment data associated with the payment instrument in the merchant device via the reader device.
A third-party payment processor and one or more server computing devices associated with the payment processing service by the merchant device to process an electronic money payment for a transaction between the merchant and the customer. To send a communication to
One or more non-temporary computer-readable media that stores instructions that perform an operation, including.

L: The non-temporary computer-readable medium of clause K, wherein at least one of the communications is transmitted via one or more proxy server computing devices associated with the payment processing service.

M: The operation is performed before receiving the instruction from the third party payment processor.
Receiving an indication of the transaction on the merchant device,
Sending the indication of the transaction to the third party payment processor to initiate the transaction from the merchant device.
A non-temporary computer-readable medium according to phrase K or L, further comprising.

N: Sending the communication to the third party payment processor and one or more server computing devices
Sending a first request to the third party payment processor by the merchant device and
In response to the transmission of the first request, the merchant device receives a first response indicating whether the payment data is approved from the third party payment processor for the cost of the transaction. ,
A non-temporary computer-readable medium according to any one of phrases K to M, comprising.

O: Sending the communication to the third party payment processor and one or more server computing devices
Sending a second request to the one or more server computing devices by the merchant device.
In response to the transmission of the second request on the merchant device, comprising receiving a second response that the transaction was recorded by the payment processing service.
The non-temporary computer-readable medium of clause N, wherein the second response is received at least in part based on the first response indicating that the payment data is approved by the third party payment processor. ..

P: The first response indicates that the payment data is approved for the cost of the transaction, and the action is:
To allow the merchant device to associate a new e-commerce balance with the payment instrument.
The indication that the transaction has been completed in response to the receipt of the second response is presented via the display associated with the merchant device.
Including
The non-temporary computer-readable medium of clause O, wherein the indication comprises the new e-commerce balance.

Q: The first response indicates that the payment data has been approved by the third party payment processor, and the operation is:
Upon receiving the first order to associate the new e-commerce balance with the payment instrument on the merchant device.
In response to the failure to notify the third-party payment processor that the new e-commerce balance has been associated with the payment instrument, triggering another dialogue between the payment instrument and the reader device. Encouraging the customer to determine the current e-commerce balance of the payment instrument,
A non-temporary computer-readable medium according to phrase O or P, further comprising.

R: The above operation is
Determining that the current e-commerce balance matches the new e-commerce balance,
Presenting an indication confirming the successful payment of the e-commerce through the display associated with the merchant device.
The non-temporary computer-readable medium described in Clause Q, further comprising.

S: The operation is
Determining that the current electronic commerce balance does not match the new electronic commerce balance,
To present an indication that the payment of the electronic money has failed via the display associated with the merchant device.
The non-temporary computer-readable medium according to clause Q or R, further comprising: The indication urges the merchant to reprocess the payment for the transaction.

T: If the current balance is not acquired, the action performs a corrective action associated with at least one of the merchant device or the reader device via the display associated with the merchant device. To, and further comprising presenting an indication to trigger another dialogue between the payment instrument and the reader device to determine the current balance of the payment instrument, clauses Q to S. A non-temporary computer-readable medium described in any of.

Claims (17)

Receiving an indication of a transaction between the merchant and the customer on the merchant device of the merchant associated with the payment processing service, the customer paying electronic money (e-money) to satisfy the payment of the transaction. Present the card, receive the above, and
Sending an indication of the transaction from the merchant device to a third-party payment processor via a proxy server computing device associated with the payment processing service.
The merchant device receives instructions from the third party payment processor via the proxy server computing device to the reader device associated with the merchant device in preparation for reading payment data from the electronic commerce payment card. That is, the electronic money payment card is associated with the electronic money balance, and the merchant device sends, receives, and receives the command to the reader device.
Receiving the payment data associated with the e-commerce payment card in the merchant device through a dialogue between the e-commerce payment card and the reader device.
(I) allow the merchant device to send a first request to the third party payment processor via the proxy server computing device to approve the electronic money payment card for the cost of the transaction (i). ii) To ensure that a second request is sent to the server computing device associated with the payment processing service to record the transaction.
In the merchant device, the payment data is sent from the third party payment processor via the proxy server computing device in response to causing the first request to be sent to the third party payment processor. Receiving the first response that the transaction is approved for said cost and
Allowing the merchant device to write a new e-commerce balance to the e-commerce payment card.
Sending a confirmation to the third-party payment processor, at least in part, based on ensuring that the new e-commerce balance is written to the e-commerce payment card.
In the merchant device, the transaction is made via the proxy server computing device and the payment from the server computing device in response to causing the second request to be sent to the server computing device. Receiving a second response that was recorded by a processing service , said second response being received, at least in part, based on sending the confirmation to the third party payment processor. To receive and
Presenting the UI indicating that the transaction has been completed and the new e-commerce balance associated with the e-commerce payment card via the display unit associated with the merchant device.
How to include. The second request is associated with at least one of an identifier associated with the merchant, an identifier associated with the customer, the total cost of the transaction, or one or more items associated with the transaction. The method according to claim 1. Claiming, at least in part, further comprising sending a write confirmation to the third party payment processor via the proxy server computing device based on having the new e-commerce balance written to the e-commerce payment card. Item 1. The method according to Item 1. In response to the merchant device transmitting the indication of the transaction to the third party payment processor via the proxy server computing device, the proxy server computing device is the merchant device and the third party payment. The method of claim 1, wherein the transaction is associated with an identifier to track subsequent communication with the processor. It ’s a merchant device,
With one or more processors
When executed by the one or more processors, the merchant device.
Receiving an indication of a transaction between a merchant and a customer, said customer, electronic money (e-money) to meet payment for at least a portion of the cost of one or more items associated with the transaction. ) Presenting the payment instrument associated with the balance, said receiving and
Sending the indication of the transaction to a third-party payment processor,
Receiving instructions from the third-party payment processor associated with the dialogue between the payment instrument and the reader device associated with the merchant device.
Receiving payment data associated with the payment instrument via the reader device, and
(I) send a first request to the third-party payment processor, and (ii) send a second request to at least the server computing device associated with the payment processing service that processes the transaction on behalf of the merchant. When,
In response to sending the first request, receiving a first response from the third party payment processor indicating that the payment data is approved for payment.
By associating the new e-commerce balance with the payment method,
Sending a confirmation to the third-party payment processor, at least in part, based on associating the new e-commerce balance with the payment instrument.
Receiving a second response to the second request, the second response indicating that the transaction was recorded by the payment processing service, and the second response being the third. Receiving and receiving, at least in part, on sending the confirmation to a party payment processor .
To present information associated with a commercial transaction through a display associated with the merchant device.
One or more non-temporary computer-readable media containing instructions to perform an operation, including
A merchant device. The merchant device of claim 5, wherein the reader device is communicably coupled to the merchant device via Bluetooth® or a Near Field Communication (NFC) network. The merchant device according to claim 5, wherein the reader device is integrated with the merchant device. The merchant device of claim 5, wherein the reader device is coupled to the merchant device via a wired connection. The operation is (i) before sending the first request to the third-party payment processor and (ii) sending the second request to the server computing device associated with the payment processing service.
Compressing the data packet size of the first request and the second request,
To encrypt the first and second requirements, at least in part based on the compression.
5. The merchant device of claim 5. When executed by one or more processors, the one or more processors said.
On a merchant's merchant device associated with a payment processing service, receiving from a third-party payment processor the instructions associated with the interaction between the payment instrument associated with the customer and the reader device associated with said merchant device. That the payment instrument is associated with an electronic money (e-money) balance, said receiving and
Receiving payment data associated with the payment instrument in the merchant device via the reader device.
Sending a first request to the third-party payment processor by the merchant device to process an electronic money payment for a transaction between the merchant and the customer is associated with the payment processing service. Sending a second request to one or more server computing devices,
In response to the transmission of the first request, the merchant device receives a first response indicating whether the payment data is approved from the third party payment processor for the cost of the transaction. ,
To allow the merchant device to associate a new e-commerce balance with the payment instrument.
Sending a confirmation to the third-party payment processor, at least in part, based on associating the new e-commerce balance with the payment instrument.
In the merchant device, in response to the transmission of the second request, receiving a second response that the transaction was recorded by the payment processing service, the second response being said third. Receiving, at least in part, on sending the confirmation to a party payment processor.
One or more non-temporary computer-readable media that stores instructions that perform an operation, including. The one or more non-temporary computer-readable medium of claim 10 , wherein at least one of the requests is transmitted via one or more proxy server computing devices associated with the payment processing service. The operation is performed before receiving the instruction from the third party payment processor.
Receiving an indication of the transaction on the merchant device,
Sending the indication of the transaction to the third party payment processor to initiate the transaction from the merchant device.
One or more non-temporary computer-readable media according to claim 10 , further comprising. The first response indicates that the payment data is approved for the cost of the transaction, and the action is:
Presenting, through a display associated with the merchant device, an indication that the transaction has been completed in response to the receipt of the second response .
Including
The one or more non-temporary computer-readable medium of claim 10 , wherein the indication comprises the new e-commerce balance. The first response indicates that the payment data has been approved by the third party payment processor, and the operation is:
Upon receiving the first order to associate the new e-commerce balance with the payment instrument on the merchant device.
In response to the failure to notify the third-party payment processor that the new e-commerce balance has been associated with the payment instrument, triggering another dialogue between the payment instrument and the reader device. Encouraging the customer to determine the current e-commerce balance of the payment instrument,
One or more non-temporary computer-readable media according to claim 10 , further comprising. The above operation is
Determining that the current e-commerce balance matches the new e-commerce balance,
Presenting an indication confirming the successful payment of the e-commerce through the display associated with the merchant device.
One or more non-temporary computer-readable media according to claim 14 , further comprising. The above operation is
Determining that the current electronic commerce balance does not match the new electronic commerce balance,
To present an indication that the payment of the electronic money has failed via the display associated with the merchant device.
The indication is one or more non-temporary computer-readable media according to claim 14 , which urges the merchant to reprocess the payment for the transaction. If the current balance is not acquired, the action is to perform a corrective action associated with at least one of the merchant device or the reader device via the display associated with the merchant device. , And, further comprising presenting an indication to trigger another dialogue between the payment instrument and the reader device to determine the current balance of the payment instrument. One or more non-temporary computer-readable media.

Images