JP5957524B2 - Payment selection and approval by mobile devices - Google Patents

Description

  Many merchants allow customers to pay with credit cards, debit cards, and other types of bank cards or electronic accounts (eg, gift cards). When a customer uses these types of payment methods and satisfies a payment request, the merchant typically performs a verification process. The verification process often occurs electronically after the identifier is read from the card (eg, via a swipe card reader, a radio frequency identifier (RFID) reader, a microchip reader, etc.). The verification process often contacts the card issuer or the issuer's agent to determine whether to approve the requested purchase amount.

  Some payment schemes use a personal identification number (PIN) or other encryption to protect against unauthorized use of the payment scheme. For example, in a point-of-sale information management system (POS), a user may use a swipe card reader to swipe the user's debit card and then enter a PIN associated with the card reader's keyboard. Card readers and keyboards are usually bare and visible to other people, including store clerk, and can therefore jeopardize the confidentiality of the PIN. In some cases, such as an automated teller machine, the keyboard is at least partially covered by a hood to block or limit keyboard visibility by other users.

  People often have multiple payment methods, such as a group of credit cards, debit cards, gift cards, and other cards or payment methods. It can be inconvenient to carry multiple cards in your wallet. In addition, carrying multiple cards at the same time exposes individuals to great risk and / or inconvenience if a group of cards is lost, misplaced, or stolen.

  This PCT application claims priority to US Patent Application No. 13 / 170,144, filed June 27, 2011, entitled “Payment Selection and Authorization by a Mobile Device”. US patent application Ser. No. 13 / 170,144 is hereby incorporated by reference in its entirety.

  This PCT application claims priority to US Patent Application No. 13 / 170,121, filed June 27, 2011, entitled “Payment Selection and Authorization”. US patent application Ser. No. 13 / 170,121 is hereby incorporated by reference in its entirety.

The detailed description is described with reference to the accompanying figures. In the figure, the leftmost digit (s) of a reference number identifies the figure in which the reference number first appears. The same reference numbers in different figures indicate similar or identical items.
1 is a schematic diagram of an exemplary computing environment that provides mobile payment selection and authorization. FIG. FIG. 2 is a block diagram of an exemplary computing architecture of various components included in the computing environment of FIG. FIG. 2 is a block diagram of an exemplary computing architecture of various components included in the computing environment of FIG. FIG. 2 is a block diagram of an exemplary computing architecture of various components included in the computing environment of FIG. FIG. 4 is a flow diagram of an example process for authorizing payments in a mobile device application. FIG. 2 is an exemplary process flow diagram illustrating the interaction between various parties from the computing environment shown in FIG. FIG. 5 is a flow diagram of an exemplary process for selecting an electronic payment method during payment authorization. FIG. 6 is a flow diagram of an exemplary process for initiating a gentle rejection of a payment request. FIG. 5 is a flow diagram of an example process for selecting an approval scheme for use by a mobile device application. 2 is an exemplary user interface (UI) that enables payment selection and approval. FIG. 4 is an exemplary UI that enables management of acknowledgment messages from hosts. FIG.

  The present disclosure provides techniques and systems that increase safety, confidentiality, and convenience when using electronic payment schemes such as credit cards, debit cards, gift cards, or other types of electronic payments. When making a payment with an electronic payment method, the user can provide additional verification of ownership through communication with the user's mobile computing device (eg, cell phone, tablet computer, etc.). For example, the user may insert or swipe the user's credit card at the retailer's retail store (directly or online). The merchant may then process the credit card information through a gateway that verifies whether the card is valid, has sufficient funds, and / or for other reasons. The gateway may forward the request to the issuer (“host”). According to various embodiments, the host may send a request to the user via a mobile application running on the mobile computing device and may ask the user to approve or reject the purchase request. . In various embodiments, the host request may require the user to enter personal and / or authentication information (eg, PIN, password, biometric, etc.) via a mobile application that approves the request.

  In some embodiments, the host may manage a group of users' electronic payment schemes. The host may allow the user to divide or distribute payment amounts across various electronic payment schemes available to the user from the host via the mobile application during the approval process. For example, the user may receive a request from the host, select a card that is different from the card originally provided to the merchant, and then accept the payment request. From the merchant's point of view, payments may be processed using the payment method received by the merchant and initiated this process. However, the host may provide the actual payment to the merchant using the payment method (s) selected by the user via the mobile application.

  The techniques and systems described herein may be practiced in many ways. Illustrative practices are provided below with reference to the following figures.

  FIG. 1 is a schematic diagram of an exemplary computing environment 100 that provides for mobile payment selection and authorization. The environment 100 includes a user 102 that interacts with a merchant 104. The merchant 104 may have a conventional physical store location and / or an electronic market that is accessible to the user 102 via one or more network (s) 106. For example, the electronic marketplace may be a website that allows the user 102 to purchase goods and / or services, or sold, rented, rented, otherwise or otherwise merchant It may be a catalog service that allows a user to browse items that are available from 104.

  The merchant 104 may approve payments from the user 102 using an electronic payment method (EPT) 108 and may accept other payment methods (eg, cash, personal checks, money orders, etc.). EPT 108 is a payment method that may include credit and debit cards and bank cards such as gift cards, stored value cards, or any other type of electronic payment. The EPT 108 may be processed through a series of events described below that allow the user 102 to authorize the use of the EPT 108 using the mobile computing device 110 (“user device”). User device 110 includes connectivity to network (s) 106 and allows user input, mobile phone, smartphone, tablet computer, laptop computer, netbook, personal digital assistant (PDA), gaming device, It may be a media player or any other mobile computing device.

  After receiving the EPT 108 from the user 102 via the point of sale information management system (POS) 112 and / or the merchant server 114 of the merchant 104, the merchant may send a request 116 for approval to the gateway 118. The gateway 118 may be a financial institution on behalf of the merchant 104 and / or a routing party that issued the EPT 108 to the user 102 and / or a relationship that manages the EPT 108 account for the user. The request 116 from the merchant is routed to the host 120, who is the seller.

  According to one or more embodiments, the host 120 includes a host server 122 that can receive the request 116, process the request, and then send the modified request 124 to the user device 110 associated with the user 102. During processing, host server 122 may retrieve information regarding EPT 108 from account data 126 maintained by host 120. Account data 126 includes rules for generating modified request 124, options for user 102, electronic payment methods available to the user, stored user preferences, and other data related to EPT 108 and / or user 102. And may be used to generate a modified request 124.

  The user device 110 may typically receive a modified request 124 immediately after the merchant 104 receives the identifier of the EPT 108. The modified request may be received by user device 110 using a communication path that is different from the communication path used to send EPT 108 to merchant 104. The modified request 124 may be processed by a payment application running on the user device 110, which uses the user interface 128 to allow the user 102 to receive information from among other possible options, and Allows the modified request 124 to be accepted or rejected. The payment application generates an extended answer 130 (ie, a response) that is sent back to the host server 122 using a different communication path than that used to send the EPT 108 to the merchant 104 again. May be. The expanded answer 130 may include acceptance, special codes (eg, personal identification number (PIN), password, or other personal information), and options related to the electronic payment method specified (eg, EPT modified). Selection to be used to satisfy request 124). The host 120 may verify the extended answer 130 information, such as verifying whether the PIN is correct and the user accepts the request 116. The host server 122 may then send the answer 132 to the gateway 118, which may be forwarded to the merchant server 114 and / or the POS system 112 of the merchant 104 after a relatively short amount of time. Unlike the extended answer 130, the answer 132 includes less information and may be primarily related to accepting or rejecting the payment request 116 rather than including a special code or other information directed to the host 120. .

  By using EPT in conjunction with user device 110, user 102 can experience greater safety against EPT misuse. For example, if EPT 108 (or an identifier of EPT 108) is stolen and used to purchase items from merchant 104 or other merchants using the techniques described above, user 102 may request purchase to protect against fraudulent purchases. Can simply be rejected. In situations where the modified request requires a PIN or other special code, the user 102 is protected against unauthorized use even when a thief (or other unauthorized person) holds the user device 110. Is possible. In addition, by using the user device 110 to enter a security code, such as when interacting with an automated teller machine where the user is susceptible to fraud (eg, card skimming, fake PIN pads, etc.) Code theft can be more difficult.

  In some embodiments, the merchant 104 may communicate directly with the host 120 and / or the host 120 may perform some or all operations of the gateway 118. Thus, in some embodiments, environment 100 may not include gateway 118 as long as it does not affect the techniques described herein.

  The network (s) 106 may include wired and / or wireless networks that allow high-speed communication between the various computing devices described in the environment 100. In some embodiments, the network (s) are optionally combined with each other to facilitate communication between various computing devices (ie, merchant server 114, host server 122, and user device 110). It may include local area networks (LANs), wide area networks (WANs), cellular phone networks (MTNs), and other types of networks that are used. The computing device is described in further detail with reference to the following figures.

  2a-2c illustrate an exemplary computing architecture for various computing devices included in the computing environment of FIG.

  FIG. 2a shows an exemplary computing architecture of merchant server 114, POS system 112, or both. This architecture may include a processor 202 and memory 204. Memory 204 may store various modules, applications, programs, or other data. Memory 204 may include instructions that, when executed by processor 202, cause the processor to perform the operations described herein on merchant 104. In some embodiments, the memory 204 may store a transaction manager 206 and an authorization module 208 that is part of the transaction manager or separate from the transaction manager. Transaction manager 206 may process transactions with user 102 and receive EPT 108. The approval module 208 may approve the EPT 108 via the gateway 118 or directly through the host 120 as described above to determine whether the EPT is approved as indicated by the answer 132. In some embodiments, transaction manager 206, approval module 208, or respective portions may be distributed across multiple computing systems, such as POS system 112 and merchant server 114.

  FIG. 2 b shows an exemplary computing architecture of the host server 122. This architecture may include processor (s) 210 and memory 212. The memory 212 may store various modules, applications, programs, or other data. Memory 212 may include instructions that, when executed by processor (s) 210, cause the processor to perform operations described herein on host 120. In some embodiments, the memory 212 may store an account manager 214 and an authorization manager 216. Account manager 214 may manage account data 126 that stores various rules, settings, EPTs, and other data for each user having an account with host 120. The authorization manager 216 may optionally accept the payment request from the merchant 104 via the gateway 118 to either accept or reject the payment request based at least in part on the user's interaction with the user device 110. Communication may be processed.

  FIG. 2 c shows an exemplary computing architecture of user device 110. This architecture may include processor (s) 218 and memory 220. Memory 220 may store various modules, applications, programs, or other data. Memory 220 may include instructions that, when executed by processor (s) 218, cause the processor to perform the operations described herein for user 102. In some embodiments, the memory 220 may store a payment application 222 that may interact with the authorization manager 216 and / or the account manager 214 of the host server 122. The payment application 222 may further include a validation module 224, a condition module 226, and a selection module 228. Each module is listed in turn.

  According to various embodiments, the validation module 224 determines whether to generate a security code request (eg, UI) for authorization based on the modified request 124 received from the authorization manager 216 of the host server 122. May be determined. When requested by the host server 122 (or possibly by the payment application 222), the verification module 224 may request a PIN, password, to accept a payment request originating from the merchant 104 and transmitted through the host server 122. The user may be asked to enter a security code, such as biometric data or other personal information.

  The condition module 226 provides information regarding the user device 110, applies conditions to the use of the security code, and / or automatically approves the payment request 124 or other types of information related to other types of information. You may refuse. For example, the authorization manager 216 may request the location of the user device 110 and may be provided using a global positioning system (GPS), triangulation, or other information. If this information matches the merchant's location, a known location of user 102 (eg, home, workplace, etc.), or another designated or learned location, authorization manager 216 may request payment (eg, security). The response required by the user may be adjusted, such as removing code requirements).

  The selection module 228 may allow the user 102 to select and distribute payments between other EPTs that are available to the user and stored in the account data 126. For example, account data 126 may include relationships between EPTs of many different types of users and may be accessible when any one of the EPTs is presented to merchant 104. The host may then satisfy the payment request 116 by the merchant 104 using one of the EPTs selected via the selection module 228. User 102 may allocate funds among multiple EPTs based on ratios, payments, or other allocations.

  FIG. 3 is a flow diagram of an example process 300 for authorizing payments at an application on a mobile device. Process 300 is shown as a group of blocks in a logical flow graph that represents a series of operations that may be implemented in hardware, software, or a combination thereof. This group of blocks is organized under each party that can perform the various operations described in the block. In the software context, a block represents computer-executable instructions that are stored in one or more computer-readable storage media that perform the operations described when executed by one or more processors. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform particular functions or implement particular abstract data types. The order in which the operations are described is not to be construed as limiting, and any number of the described blocks can be combined in any order and / or in parallel to practice the process. In addition to process 300, other processes described throughout this disclosure should be construed accordingly.

  Process 300 is described with reference to environment 100 and may be performed by user device 110 in cooperation with any one or more of host server 122, POS system 112, and / or merchant server 114. Of course, the process 300 (and other processes described herein) may be performed in other similar and / or different environments.

  At 302, user 102 may provide payment to merchant 104 using EPT 108. For example, the user 102 may interact with a merchant 104 at a conventional physical store location and submit an EPT directly to the merchant 104. The user may also interact with merchant 104 through an electronic market accessible using network (s) 106. In some cases, the user may transfer the EPT 108 via a browser or application using the user device 110.

  At 304, user device 110 may receive a request to approve a purchase using payment application 222 (ie, modified request 124) from merchant server 114 through gateway 118 and / or host server 122. May be routed to reach the user device 110. Payment application 222 may be different from an application that may be used to transfer EPT 108 to a merchant (eg, via a browser or the like). This request may include additional information such as requirements for the code, available electronic payment methods, request details such as the amount to be paid, and items included in the transaction.

  At 306, payment application 222 may determine whether to approve or reject the payment based at least in part on input from user 102 provided using user device 110. If the user 102 decides to decline the payment, at 308 (according to the “No” path), the payment application 222 may send a response to the host server 122 to decline the payment. However, if the user decides to approve the payment request (according to the “yes” path from decision operation 306), process 300 may continue at 310.

  At 310, payment application 222 may generate a response (or answer) to the request. The response may include a selection of one or more EPTs (including or different from the EPT used in operation 302) and may be collected and / or processed by the selection module 228. The response also includes a code such as a PIN, password, biometric data, or other personal information that can be collected and / or processed by the verification module 224. In some cases, the response may include a reject command when the user 102 wishes to reject the payment request. The response may also include condition information, such as the location of the user device 110, and may be collected and / or processed by the condition module 226.

  At 312, the payment application may send the response and related information to the host server 122 of the host 120. The host server 122 may then relay the response to the gateway 118 and / or merchant 104 when the response is correct, such as when the response meets the code and / or condition requirements included in the request from the host 120. .

  FIG. 4 is a flow diagram of an exemplary process 400 illustrating the interaction between various parties from the environment 100 shown in FIG. The operations shown in process 400 are shown under the parties that can perform the respective operations, but in other configurations, the operations may be performed at least partially by other parties. For example, some or all of the operations specified under merchant server 114 may be performed by POS system 112. The operation may include encryption / decryption of data with respect to the security of information transmitted between the respective parties.

  At 402, merchant server 114 may receive payment from user 102 via EPT 108.

  At 404, merchant server 114 may request authorization for the payment received at operation 402 for verifying funds, authenticating an electronic payment scheme, or for other reasons.

  At 406, the gateway 118, which may be a financial institution on behalf of the merchant 104 or another party, may identify an issuer (ie, host 120) that approves payment.

  At 408, the host server 122 via the account manager 214 may determine the user 102 associated with the approval message and payment from the operations 404 and 406. The host server 122 may match the identification number of the EPT 108 with the user 102 via the account data 126.

  At 410, the host server 122 may determine an approval parameter. Approval parameters can be automatically approved purchases (eg, whitelisted, less than a predetermined amount) or specific requirements for authorization to process payment requests (eg, security in addition to consent) It may be based on rules for approval, such as whether a code is required.

  At 412, the host server 122 may determine whether the user is eligible to use the EPT 108. For example, the host server 122 may determine whether the user's account has the necessary funds to complete the payment and / or the host server may determine whether the request should be rejected due to fraud risk. Various fraud checks may be performed to determine If the host server 122 determines that the user is eligible to use an EPT or other EPT and / or the fraud risk is acceptable (eg, less than a threshold score), processing may continue at 414.

  At 414, when approval is required, the host server 122 via the approval manager 216 may send a modified request (eg, the modified request 124) to the user device 110 associated with the user 102. In some cases, the user 102 may entrust approval or purchase (use of EPT) to another person, such as a family member, business partner, colleague, friend, or the like. Therefore, the user 102 who operates the user device 110 is not necessarily a user who presents the EPT 108 to the merchant 104.

  At 416, the user device 110 via the payment application 222 may process an approval message that includes an approval parameter. For example, the payment application 222 determines whether to request a code via the verification module 224, uses the condition module 226 to determine a condition (eg, the location of the user device), or to the user 102 Other possible operations may be performed before or during the presentation of the request. In addition, the user device 110 via the payment application 222 may allow the user 102 to select other or additional EPTs that satisfy the purchase initiated at operation 402 using the selection module 228.

  At 418, the user device 110 may send a response (answer) back to the host server 122. The response may include at least one or more of accept or reject, code, specified EPT (s), and condition information.

  At 420, the host server 420 via the authorization module 216 may verify the response when the user accepts the payment. For example, the authorization module 216 may verify that the code is correct, the condition is met, etc., and may be performed using the account data 126.

  At 422, the approval module 216 determines whether the response is approved (ie, accepted and correct), whether the user 102 has sufficient funds for payment, and whether the payment can be fraudulent. May be determined. When the response is approved by the user and the information (eg, code, condition, etc.) is correct, or when approval is not required from the decision operation 414, and sufficient funds are available or the risk of fraud is low (eg, The acceptance response may be sent to the merchant server 114 at 424 and forwarded via the gateway at 426. If the response is rejected by the user 102, the user lacks sufficient funds, and / or the fraud risk is high, a rejection (rejection) response may be sent to the merchant server 114 at 428 via the gateway at 430. May be forwarded. Payment also hosts that the user's account lacks sufficient funds and / or the payment may be fraudulent based on predetermined factors prior to communication for approval from user 102 via user device 110. Once the server 122 decides, it may be rejected from the decision operation 414 according to the route “No”.

  FIG. 5 is a flow diagram of an example process 500 for selecting an EPT during payment authorization. The process 500 is described as being performed by the user device 110 via the payment application 222 in the description below, but the process 500 may also be selected when a decision is selected based on rules stored in the account data 126, etc. This may be done in part or in whole by the host server 122 via the account manager 214.

  At 502, payment application 222 may receive an approval message. The approval message may include the amount to be paid, conditions, code requirements, and / or other information.

  At 504, the selection module 228 of the payment application 222 may provide an EPT for selection by the user 102 and may be different from the EPT 108 (eg, at operation 302) provided to the merchant 104.

  At 506, the selection module 228 may receive an EPT selection that satisfies at least a portion of the amount to be paid.

  At 508, the selection module 228 may receive an amount (or percentage, etc.) associated with the EPT selected at operation 506.

  At 510, the selection module 228 may determine whether additional EPT should be used or selected by the user 102. For example, if the amount to be paid is still intact after selection at operation 508, user 102 may be prompted to enter another EPT and / or another amount, and operation 506 following the “yes” path (or The process may be instructed to return to operation 508).

  If no other EPT should be used and following the “No” path from operation 510, payment application 222 may send an approval to the host at 512 to satisfy the approval message from operation 502.

  In various embodiments, payment application 222 may request financial information (eg, balance information, etc.) from host server 122 and attempt to prevent overdraft or EPT credit limits being exceeded. Once the payment application 222 determines that overdraft can occur or is possible, the payment application may prompt the user and / or request the use of another EPT in the decision operation 510.

  In some embodiments, account data 126 may include specific rules for selecting an EPT for the user. For example, account data 126 may include rules that use a specific EPT for a designated merchant. A particular EPT may be a credit card that includes additional rewards (points, miles, etc.) for a designated merchant. These rules may be generated by the user, retrieved from the user's 102 past transactions, or otherwise generated for the user. In some embodiments, the preferred EPT (or possibly multiple EPTs) is subject to user confirmation via the payment application 222, such as through a pre-selection process and a pre-selection process by the account manager 214. It may be.

  FIG. 6 is a flow diagram of an example process 600 for initiating a mild refusal of a payment request. A gentle rejection may be used when requested during a time when the approval process is stopped (eg, late at night) and / or when the user 102 does not respond to the request. Process 600 may be performed by host server 122, but may be used by other parties or computing devices to practice the process.

  At 602, the host server 122 receives a request to approve a purchase that originates from the merchant 104 and may optionally be relayed through the gateway 118.

  At 604, the host server 122 via the authorization manager 216 may determine whether there is a rule that allows an automatic reply to a purchase request without communicating to the user 102 via the user device 110. For example, the authorization manager 216 may use the information provided by the account manager 214 to determine the settings or rules stored in the account data 126 that determines whether to automatically reply to the request. The rules may indicate that some purchase amounts are automatically approved (eg, categories, merchants only, or less than a threshold, etc.) and may be communicated with user 102 via user device 110. May lead to automatic consent without interaction. The rules may also blacklist some purchases and may result in automatic rejection without interaction with the user 102 via the user device 110. When the request is not eligible for automatic reply, processing may continue at 606 as determined by decision operation 604.

  At 606, the authorization manager 216 may determine whether a request can be sent to the user 102 via the user device 110 according to rules or settings optionally stored in the account data 126. For example, the user 102 may decide to stop receiving an approval message at some time, such as from midnight to early morning (or other day, other time, etc.). If the approval manager 216 determines that it is a suspended time, the approval manager may issue a gentle rejection at 608 and may act as a temporary rejection for the request received at 602. In this case, the host server 122 may delay at 610 and may determine again whether the stop time has elapsed (after the delay).

  If there is no stop at 606 (according to the “No” route), processing may continue at 612. At 612, the host server 122 via the authorization manager 216 may send a request to the user 102 via the user device 110 to the payment application 222.

  At 614, the host server 122 may determine whether a response has been received from the user 102 within a predetermined amount of time. If a response is received within a predetermined amount of time, the response is received at 616 (which may precede the decision of operation 614) and then forwarded to merchant 104 (possibly via gateway 118).

  However, if a response is not received within a predetermined amount of time at 614 (following the “No” path), then the host server 122 via the authorization manager 216 determines 620 whether to attempt to contact the user again at 622. Rule (s) may apply. For example, rules may instruct host 120 to approve payment requests from approved merchants up to a predetermined amount and / or based on other criteria. Similarly, the rules may also instruct host 120 to refuse payment for various reasons set forth in the rules. The rule may also indicate some attempts to host 120 before deciding not to try again in decision operation 622. When authorization manager 216 tries again at decision operation 622, processing resumes at operation 608 by issuing a gentle rejection, and then processing proceeds due to the delay of operation 610 as described above and shown in FIG. Good.

  When the limit of operation 622 should not be retried, such as when the limit is reached or exceeded by the rule, or for other reasons included in the rule, the authorization manager 216 satisfies the payment request or rejects the payment request. A response that is either may be determined using the rules from operation 620. The response may then be forwarded to the merchant at 618, possibly via the gateway 118.

  FIG. 7 is a flow diagram of an example process 700 for selecting an approval scheme for use by a mobile device application. Process 700 may be performed by host server 122, but may be used by other parties or computing devices to practice the process. Process 700 may operate in conjunction with payment application 222 conditions module 226 at user device 110. As described below, process 700 is described with reference to conditions associated with the location of user device 110, although other conditions may be practiced using process 700.

  At 702, the host server 122 may receive a request to approve purchases.

  At 704, the host server 122 may determine whether the approval is subject to conditions such as the location of the user device 110 relative to the merchant 104 location. If approval is subject to the conditions of the decision operation 704, processing may continue at 706 along a “yes” path.

  At 706, the host server 122 may request the location of the user device 110 via the condition module 226, and obtain the location (or other information) via the GPS receiver of the user device 110 or the like. .

  After receiving the condition information from the user device 110, at 708, the host server 122 changes the location of the user device 110 to the location of the merchant 104 or a known location associated with the user 102 (eg, the user's home, office, frequent Compared to places visited in At 710, the host server 122 may determine based on a comparison of whether the device location matches the merchant location or a known location. Although a mismatch may be recorded at 712, a match may be recorded at 714.

  At 716, the host server 122 via the approval manager 216 may determine approval requirements. In some embodiments, this approval may be based on the results (ie, operations 712 and 714). This determination may include other related factors. For example, relevant factors may include whether payment is for a remote transaction (eg, online, by phone, etc.) or a distance transaction within reach of a traditional physical store location. In the latter situation, matching the user device location to the merchant location (operation 714) may result in a reduced approval process (simplified or none). In the former situation (remote transaction), the location of the user device 110 may be compared to a known and / or frequent location (home, workplace, school, etc.) and then used to select an approval process. Also good. For example, a more difficult approval process (eg, including a request for a code) may be used when the user device 110 is located in an unknown location (eg, not at home).

  At 718, the host server 122 via the approval manager 216 may send an approval message to the user device.

  At 720, the host server 122 via the authorization manager 216 may receive and verify the response. When the response is approved at 722 and is correct (eg, the correct code is received (if requested)) (according to the “yes” path), the host server 122 may optionally approve at 724 via the gateway 118. It may be sent to the merchant. When the response is rejected, or possibly the code is incorrect, or after an excessive delay (eg, operation 620 of FIG. 6) at 722 (according to the “No” path), the host server 122 may optionally be gateway 118. A rejection may be sent to the merchant at 726 via.

  In some embodiments, the location information determined from operations 708-714 may be used as another checkpoint by host server 122 that determines whether to satisfy a payment request. For example, process 700 may include sending an approval message 718 to user device 110 before or at the same time as the request for location information. Operation 720 may use information from operations 712-714 that determine whether to overturn the user's decision to approve payment. For example, if the host server 122 determines that the location is different at 712 and fraud may occur (eg, someone has stolen the user device 110), the host server 122 may have a user whose authorization message is intended to approve payment. Payment may be refused even when received from device 110 and includes the correct code (if required).

  FIG. 8 is an exemplary user interface (UI) 800 that enables payment selection and approval. The UI 800 may be presented to the user 102 via a payment application 222 that runs on the user device 110. The UI 800 may include an information section 802, a payment selection section 804, a code section 806, a decision section 808, or any combination thereof. Each section is listed in turn.

  The information section 802 may provide a description of the payment transaction, such as the amount 810 to be paid, and possibly a merchant identifier 812 and / or description 814, and may display items / services or other details of the payment transaction. Also good. In some embodiments, the description may include links to more information.

  The payment selection section 804 may be preconfigured in part by the selection module 228 and may include options in accordance with the process 500 shown in FIG. The payment selection section 804 may include an EPT 816 that is available to the user based at least in part on information in the account data 126 that is accessible to the host server 122. In addition, the payment selection section 804 may include a selection of amounts to include for each of the EPTs 816, such as a percentage of the purchase amount 818 and / or an amount 820 to be paid. Exemplary data showing input of 100% of the purchase amount for the first EPT is shown in FIG. In some embodiments, this may be preset by the selection module 228 as a default input for the user 102 for convenience. The selection module 228 creates rules that are stored in account data that generate specific EPT preferences for some merchants or product categories, such as to allow users to obtain special rewards from their respective EPTs, etc. A default input based on such a rule may be generated.

  The code section 806 may include one or more options for entering a code when required by an approval message. In some cases, multiple options may be included in a code section as shown in FIG. However, in some cases, code section 806 may only allow certain types of codes, such as PIN 822, biometric 824, pattern 826, or other types of codes.

  Decision section 808 may include a reject command 828 that rejects the payment request and an accept command 830 that accepts the payment request. In some embodiments, the code section 806 may be omitted and grayed out when no code is needed, otherwise it may not be utilized. In this situation, the user may only need to select an accept command 830 to approve the requested payment.

  The UI 800 may also include additional information. For example, this is the user who initiates payment when the user is not the user 102 receiving the message via the UI 800 (eg, using EPT on behalf of the user 102 authorized by the agent). Personal messages (by text, audio, video, etc.).

  FIG. 9 is an exemplary UI 900 that enables management of approval messages from hosts. The UI 900 may be presented to the user 102 via an account manager 214 that is supplied by the host server 122 and accessible via the user device (eg, the user device 110 or another computing device). The UI 900 may include a recent activity section 902, a rules section 904, a menu section 906, or any combination thereof. Each section is listed in turn.

  Recent activity section 902 may include previous transactions that may allow user 102 to easily create rules for future transaction occurrences or similar transactions. Recent activity section 902 may include a transaction entity specifier 908 and a date 910. For each transaction, the recent activity section 902 may include a whitelist option 912 that automatically approves approval messages from interested parties, categories, domains, etc., for a specified transaction amount (eg, Up to $ 50 per week, $ 100 per transaction, etc.). The options may also include a blacklist option 914 that automatically rejects approval messages for parties, categories, areas, etc. In addition, the recent activity section 902 may allow the user 102 to select an approval type 916 for the parties, categories, and / or areas. In some embodiments, recent activity selections may also use the EPT selector 918 to allow the user 102 to associate EPTs with parties, categories, and / or areas.

  Rules section 904 may allow user 102 to generate rules that can be applied to automatically accept or reject an approval message. The rules may include a description 920, an allowance 922, and / or an approval type 924. For example, the allowable amount 922 may include a period. Rules section 904 may include an “add more” command 926 to add additional rules. The user may also be able to delete rules or otherwise manage the rules via the UI 900.

  Menu section 906 may include commands that allow a user to operate UI 900. The commands may include a close command 928, a help command 930, and / or a save command 932 that saves information obtained by the UI 900 in the account data 126 for use by the host server 122.

Supplementary notes 1. A method of authorizing payment using a mobile device,
Receiving a request to approve payment using a bank card having an associated bank card identifier from a host via the mobile device under control of the mobile device comprising executable instructions, the bank card identifier Is sent to the merchant electronically through a communication path that is different from the communication path used at the merchant location or to receive the request;
Presenting the mobile device user with a description of the request, including at least the merchant name and payment amount
Receiving a response to the request from the user, the response including a security code entered by the user;
Sending a response including a security code to the host upon request, the response requesting the host to approve payment to a merchant with a bank card when the security code is correct; Method.

  2. Determining at least location information including the location of the mobile device, wherein the location is compared with the authorized location, operating a request for a security code from the user, or identifying fraud risk of the transaction The method according to appendix 1, used for one.

  3. The method of claim 1, wherein presenting further comprises presenting a merchant name and a description of an item or service included in the transaction associated with the payment.

  4). Receiving a selection of an electronic payment method from a user as a substitute for a bank card provided to the merchant, the electronic payment method further comprising establishing a payment to the merchant, and sending the response is electronic The method of claim 1, comprising sending a payment method to the host.

  5. Further comprising receiving from the user a selection of one or more of the additional electronic payment methods including or excluding the bank card that establishes payment to the merchant, and sending the response includes the additional electronic payment method The method of claim 1, comprising sending to a host.

6. When executed on one or more processors,
Receiving a request from a host via a mobile device to approve a payment resulting from the presentation of payment to the merchant using a communication path that is different from the processing path of the bank card used to receive the request. When,
Presenting a description of the request including at least the payment amount to the user of the mobile device;
Receiving a response to the request from a user, the response including at least an acceptance or rejection of the request;
Sending a response to the host as an answer to the request, wherein the answer is to approve or deny payment to the merchant resulting from the presentation of the payment; One or more computer-readable storage media for storing.

  7). The request includes a request for a unique identifier selected based at least in part on the merchant or payment amount, and the unique identifier includes a code that should be accurately entered by the user to authorize the payment. One or more computer-readable media according to claim 1.

8). The act is
Determining the location of the mobile device,
The one or more computer-readable media of claim 6, further comprising: transmitting the mobile device location to the host, wherein the request is based at least in part on the location of the mobile device relative to the merchant location.

  9. The one or more computer-readable media of claim 8, wherein determining the location of the mobile device is performed using a global positioning system (GPS) or triangulation.

  10. The one or more computer-readable media of claim 6, wherein presenting further comprises presenting a merchant identifier and an item or service description included in the transaction associated with the payment.

  11. The request is a second request and the act further includes receiving the first request before the second request, and the mobile device does not respond to the first request before the threshold amount of time. The one or more computer-readable media of claim 6, wherein the one or more computer-readable media provide a gentle refusal of payment prior to receipt of the second request.

  12 The one or more computer-readable media of claim 6, wherein the act further comprises presenting an additional electronic payment method for selection to the user to finalize the payment.

  13. Appendix 12 wherein one of the additional electronic payment methods is preselected for the user based on rules that at least partially associate each electronic payment method with a merchant to obtain a reward associated with the electronic payment method. One or more computer-readable media according to claim 1.

  14 The act further includes receiving a selection of an additional electronic payment method from the user to satisfy the response to the purchase, and sending the response includes transmitting the additional electronic payment method to the host. One or more computer-readable media according to claim 1.

  15. The presentation of payment is associated with an initial electronic payment method, and the act further includes receiving an allocation of funds for each electronic payment method that collectively establishes payment to the merchant when processed. One or more computer-readable media according to appendix 14.

  16. The act of appendix 6, wherein the act further includes receiving a selection of a different electronic payment method from the user instead of the electronic payment method associated with the presentation of the payment, wherein the different electronic payment method establishes the payment to the merchant. One or more computer-readable media as described.

  17. The presentation of payment is associated with an initial electronic payment method, and the act further includes selecting an additional electronic payment method that includes or excludes the initial electronic payment method that establishes the payment to the merchant. One or more computer-readable media as described.

18.
Receiving a request to approve an electronic payment provided by a user to a merchant at a mobile device under control of the mobile device having executable instructions, wherein the electronic payment is used to receive the request Being provided to the merchant using a different communication path than the bank card processing path,
Receiving a response to the request from a user, the response including at least an acceptance or rejection of the request;
Sending a response to the host as an answer to the request, the answer including authorizing or rejecting the merchant payment resulting from the presentation of the payment.

  19. The method of claim 18 further comprising presenting a description of the request including at least a payment amount and a merchant indication to a user of the mobile device.

  20. The method of clause 18 wherein the request includes a request for a security code to be accurately entered by a user to authorize payment.

21.
Receiving a request to approve a payment from a merchant under the control of one or more servers having executable instructions, wherein the payment is provided to the merchant by the user using a bank card and the closing of the transaction. The request includes at least a payment identifier and an amount;
Identifying the user's mobile device associated with the payment identifier;
Determining authorization requirements to be imposed on users based at least in part on the amount,
Sending an approval message containing approval requirements to the mobile device, which allows the user to accept or reject the request to approve the payment;
A payment application that receives a user response from a user via a mobile device, based at least in part on sending an authorization message, wherein the response is different from the application used to send the payment to the merchant Being received from
Determining whether approval requirements are met, based at least in part on user response;
Sending a response to the merchant that includes one of accepting or rejecting the merchant's payment, where the acceptance depends on meeting approval requirements;
Transferring the payment amount on behalf of the user to the merchant's account.

  22. The method of claim 21, wherein the approval message includes a request for at least one of a personal identification number (PIN) or biometric data that satisfies the approval requirements.

  23. The user response includes a selection of an electronic payment method other than a bank card having a payment identifier, wherein the electronic payment method is used to satisfy at least a portion of the amount to be paid to the merchant for the transaction. the method of.

  24. The method of claim 21, further comprising applying at least one rule for determining approval requirements.

  25. The method of claim 24, wherein the at least one rule is generated based at least in part on input from a user.

26.
Under the control of one or more servers having executable instructions,
Receiving a request to approve a payment from the merchant, wherein the payment is provided to the merchant by the user upon completion of the transaction, and the request includes at least a payment identifier and an amount;
Identifying the user's mobile device associated with the payment identifier;
Determining authorization requirements to be imposed on users based at least in part on the amount,
Sending an approval message containing approval requirements to the mobile device, which allows the user to accept or reject the request to approve the payment;
Receiving a user response from a user via a mobile device based at least in part on sending an approval message;
Determining whether approval requirements are met, based at least in part on user response;
To the merchant,
Accepting payment to the merchant when authorization requirements are met and the user accepts the request to approve the payment,
Or sending a response including one of the refusals to pay the merchant.

  27. 27. The method of clause 26, further comprising transferring the payment amount on behalf of the user to the merchant account.

  28. 27. The method of clause 26, wherein receiving the response from the user is done in communication with a payment application different from the application used to send the payment to the merchant.

  29. 27. The method of clause 26, wherein the user request includes at least one of a personal identification number (PIN) or biometric data to satisfy the approval requirement.

  30. 27. The method of clause 26, further comprising generating at least one rule for determining approval requirements, wherein the at least one rule is generated based at least in part on user input from a user.

  31. The method of claim 30, wherein the rules include at least one of a whitelisted or blacklisted merchant, category, or field associated with a threshold payment amount for a specified period of time.

32.
Requesting the user's mobile device location;
Receiving a location of the mobile device; and
27. The method of clause 26, wherein the location information is used to determine authorization requirements or fraud risk associated with merchant payment.

  33. 27. The user response includes a selection of an electronic payment method other than a payment method having a payment identifier, wherein the electronic payment method is used to satisfy at least a portion of the amount to be paid to the merchant for the transaction. the method of.

34. The approval message is the second approval message, and the action is
Sending the first approval message to the user prior to the second approval message;
27. The method of clause 26, further comprising: sending a gentle rejection notice to the merchant that at least temporarily rejects the payment prior to sending the second approval message to the user.

35.
Determining whether the user is unable to receive an approval message at the current time based at least in part on predetermined rules;
The user further comprising: delaying transmission of the approval message to the user when the user is unable to receive the approval message at the current time based at least in part on a predetermined rule. Method.

36. When executed on one or more processors,
Receiving a request to approve payment from a merchant, the request including at least a payment identifier and an amount;
Identifying the user associated with the payment identifier;
Determining authorization requirements to be imposed on users based at least in part on the amount,
Sending an approval message to the user, wherein the approval message includes at least an amount and the approval requirement allows the user to accept or reject the request to approve the payment;
Receiving a user response from a user via a mobile device based at least in part on sending an approval message;
Determining whether approval requirements are met, based at least in part on user response;
Sending a response to the merchant that includes one of accepting or rejecting the merchant's payment, wherein the acceptance depends on meeting the approval requirements, One or more computer-readable storage media for storing.

37. The approval message is the second approval message, and the action is
Sending the first approval message to the user prior to the second approval message;
37. The one or more computer-readable media of claim 36, further comprising: sending a gentle rejection notice to the merchant that at least temporarily rejects the payment prior to sending the second approval message to the user. .

38. The act is
Determining whether the user is unable to receive an approval message at the current time based at least in part on predetermined rules;
37. The appendix 36, further comprising: delaying transmission of the approval message to the user when the user is unable to receive the approval message at the current time based at least in part on a predetermined rule. One or more computer readable media.

  39. The user response includes a selection of a second electronic payment method that is different from the initial electronic payment method associated with the payment identifier, and the act is to make a payment to the merchant using the second electronic payment method. The one or more computer readable media of claim 36, further comprising:

  40. The authorization requirement is based on rules that select an authentication process based at least in part on the payment amount and merchant, and the selection of at least one of the authentication processes provides the user with a personal identification number (PIN) in a user response. 37. One or more computer readable media of clause 36, including requesting.

Conclusion Although the subject matter has been described in language specific to structural features and / or methodological acts, it is understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. It should be. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claims.

Claims (9)

Under the control of one or more servers having executable instructions,
From the merchant, the method comprising: receiving a request to authorize payment, the payment is provided to the merchant in the establishment of transactions by a user, wherein the request includes at least the payment identifier and amount, and the step,
Identifying a mobile device of the user associated with the payment identifier,
Determining the authorization requirements imposed on the user based at least in part on the amount,
And transmitting an approval message including the authorization requirements to the mobile device, wherein the authorization message, the user makes it possible to accept the request to approve the payment, the approval message, the user Including details of the request presented with a payment authorization code prompt at the mobile device, wherein the payment authorization code is pre-determined from a plurality of payment authorization codes based at least in part on the merchant identifier or the merchant category. Selected , based at least in part on a predetermined rule, to determine whether the mobile device can receive the approval message at a current time and can receive the approval message at the current time. If determined, the approval message is Serial Ru is received by the mobile device, the steps,
Based at least in part on the transmission of the acknowledgment message, and receiving a user response from the user via the mobile device, the user response is the correct input of the at least partially the payment authorization code Indicating acceptance of said request based on , and
Determining whether at least partly based on the user response, the approval requirements are met,
Sending to the merchant a response including acceptance of the payment to the merchant when the approval requirements are met and the user accepts the request to approve the payment ;
A method characterized by comprising : Receiving the response from the user A method according to claim 1, characterized in that it is made to communicate with different payment applications and applications that are used to transmit the payment to the merchant. The method of claim 1 wherein the user response, characterized in that it comprises at least one of a personal identification number (PIN) or biometric data to meet the approval requirements. Further comprising the step of generating at least one rule to determine the authorization requirements, said at least one rule, to claim 1, characterized in that it is generated based on user input from at least in part on the user The method described. A step of requesting the location of the mobile device of the user,
Receiving the location of the mobile device ;
Further comprising, said location method according to claim 1, characterized in that it is used for determining the said authorization requirements or fraud risk associated with payments to the merchants. The user response includes a selection of an electronic payment method other than a payment method having the payment identifier, and the electronic payment method is used to satisfy at least a portion of the amount to be paid to the merchant for the transaction. the method according to claim 1, characterized in that that. The approval message is a second approval message, and the method includes:
Transmitting a first acknowledgment message before the second authorization message to the user,
Sending a gentle rejection notice to the merchant that at least temporarily rejects the payment before sending the second approval message to the user ;
The method of claim 1, further comprising a. Whether it is determined that the approval message cannot be received at the current time, delays reception of the approval message by the mobile device, and can be received again at the mobile device after the delay the method according to claim 1, characterized in that that will be determined. Computer readable storage medium comprising the computer executable instructions for performing the method according to any one of claims 1 to 8.