EP3053118A1 - Système et procédé de gestion d'interactions entre marchands et consommateurs - Google Patents

Système et procédé de gestion d'interactions entre marchands et consommateurs

Info

Publication number
EP3053118A1
EP3053118A1 EP14851165.2A EP14851165A EP3053118A1 EP 3053118 A1 EP3053118 A1 EP 3053118A1 EP 14851165 A EP14851165 A EP 14851165A EP 3053118 A1 EP3053118 A1 EP 3053118A1
Authority
EP
European Patent Office
Prior art keywords
consumer
merchant
payment
transaction
offer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP14851165.2A
Other languages
German (de)
English (en)
Other versions
EP3053118A4 (fr
Inventor
Gregory W. Harvey
Samuel N. Brown
David S. Sink
Aaron Wilkinson
Michael Menefee
Mark S. Saum
Colm Bergin
Bruce Parker
Ralf Erich Schulz
Jon Buell
Jason Fisher
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ModoPayments LLC
Original Assignee
ModoPayments LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US14/046,792 external-priority patent/US20140040001A1/en
Application filed by ModoPayments LLC filed Critical ModoPayments LLC
Priority to EP19205018.5A priority Critical patent/EP3667592A1/fr
Publication of EP3053118A1 publication Critical patent/EP3053118A1/fr
Publication of EP3053118A4 publication Critical patent/EP3053118A4/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices

Definitions

  • the present invention relates to electronic payment processing and offer systems, and more specifically to a system and method for making and redeeming offers in conjunction with a secure, mobile, electronic payment processing system.
  • Payment cards including credit, debit, prepaid of both an association of bank issuers (e.g. VISA) and private or proprietary brand (e.g. Target), have become one of the most common forms of payment for payment transactions.
  • Payment cards are used to purchase nearly 4 trillion dollars worth of goods and services annually. This represents roughly one-fourth of the total U.S. economy. Almost 90% of online consumer transactions in the United States were made using a payment card. Payment cards have eclipsed other traditional methods of payment (notably checks and cash), and now are moving quickly to a dominant share of payments volume. Payment cards have a magnetic stripe which has been affixed to a piece of plastic, and is used at the payments terminal to "swipe" the payment credentials into the payments terminal. This is the predominant method by which these payments are conducted. Despite this widespread use in the United States, there are still a large number of problems to overcome in regard to payment card security, identification of consumers usage of payment cards, and the management of the data associated with payments cards transactions.
  • chip cards also known as smartcard or EMV enabled cards, and NFC enabled cards
  • a chip card is similar to a standard payment card
  • the chip uses electronic cash which transfers from the consumers' card to the sellers' device.
  • a popular smartcard initiative is the VISA Smartcard. Using the VISA Smartcard you can transfer electronic cash to your card from your bank account, and you can then use your card at various retailers and on the internet.
  • Another popular NFC card initiative is the PayPass system from MasterCard which allows an enabled card to simply be "dipped" near the payments terminal to initiate the exchange of payments credentials.
  • FIG. 1(a) the current state of the art for payment processing using payment cards or chip cards is shown.
  • a buyer 11 decides to initiate a transaction 10 to buy goods and/or services from a merchant 12
  • the merchant 12 will transfer these goods and services 13 to the buyer 11 and the buyer 11 will transfer payment in the form of payment credential information 14 (such as a magnetic card swipe, or chip card dip, or a more manual conveyance of the payment card account information) or cash back to the merchant 12.
  • payment credential information 14 such as a magnetic card swipe, or chip card dip, or a more manual conveyance of the payment card account information
  • a cash transaction cash moves from the buyer 11 to the merchant 12 via face to face exchanges.
  • the buyer 11 will transfer the payment information 14 to the merchant 12, adjusting the appropriate accounts of the seller and buyer.
  • the merchant 12 generally uses a different bank or acquirer 15 from the buyer's bank or issuer 11, and in all cases, does not have direct access to the buyer's bank, so a payment card network 17 operates between the merchant bank 15 and the buyer bank 16 in order to move funds between the appropriate accounts.
  • the payment card network can be an association open to all bank issuers and acquirers (e.g. VISA, MasterCard), an association available only to certain banks (e.g. Discover, American Express), or a proprietary network available only to certain merchants (e.g. Target, Starbucks).
  • FIG. 1(b) a similar transaction using an intermediary, such a PayPal, is shown.
  • the buyer 11 and merchant 12 have the ability to conduct a payment transaction 20 using the intermediary instead of presenting a physical payment card transaction process shown in Figure 1.
  • the buyer account information 22 is transferred along with the order.
  • the intermediary transaction the intermediary 21 holds funds received from buyer's bank 16.
  • the intermediary 21 Upon receipt of instructions from the buyer 11 and merchant 12, the intermediary 21, transfers funds from the buyer's account to an account held by the merchant at the intermediary, potentially using the payment card network 17. From there the merchant 12 can have the funds transferred to the merchant's bank 15.
  • Each of the payment methods above can classified as prepaid, pay-now or pay- later systems based on the nature of the funding of the transaction.
  • pre-paid systems such as those operated as stored value cards
  • the buyer/consumer pays before the transaction, i.e. the consumer funds the account with some form of payment and uses the prepaid account to pay for her transactions.
  • Pay-now systems mean that the consumer's account is checked and debited at the same time when the transaction takes place, e.g. the process that occurs when debit cards linked to a bank account are used for payment.
  • pay-later (credit-based) systems the consumer pays after the transaction, e.g. a consumer using a credit card for a purchase, and then paying the credit card at a later date (typically 30 days later) from funds in a bank account.
  • both merchants and buyers also interact through loyalty, award, coupon and/or offer programs.
  • Loyalty and award programs are used by merchants to reward repeat consumers and to incentivize consumers to frequent the merchant.
  • the merchant may award points that can be redeemed for goods or services or may provide members of the programs special discounts not available to non-members.
  • the programs also allow the merchant to track the purchasing habits of the program members and to engage in targeted marketing based on those buying habits.
  • Offer programs such as group discount programs
  • the most notable example of group offer programs is Groupon. Groupon works as an assurance contract using its web platform. Generally, if a certain number of people sign up for an offer made by a merchant through Groupon, then the offer, or deal, becomes available to all. If the predetermined minimum is not met, no one gets the offer. This reduces risk for merchants, who can treat the offers/coupons as quantity discounts, as well as sales promotion tools. Groupon makes money by keeping approximately half the money the consumer pays for the coupon. So, for example, an $80 massage could be purchased by the consumer for $40 and then Groupon and the merchant would split the $40.
  • the merchant provides a massage valued at $80 and gets approximately
  • Groupon collects personal information from willing consumers and then contacts only those consumers, primarily by a daily email, who may possibly be interested in a particular product or service.
  • What is needed is a secure payment processing system that is integrated with a merchant's award programs and/or offers, and uses a reliable mechanism to identify consumers.
  • the concepts described herein relate to a system and service that simplifies the processes whereby consumers interact electronically with merchants, to pay for purchases, and/or to receive relevant offers, receive rebates or refunds and track receipts.
  • the service also increases the relevance of merchant-consumer interactions, allowing the merchant to target offers to the consumer as the consumer is shopping.
  • the system and service described herein uses virtual personal account numbers (VPANs) representing stored value payment cards to process transactions.
  • VPANs virtual personal account numbers
  • the system and service provide for a portion of the VP AN, referred to as the checkout code, to be sent to the consumer after initiating a visit at a merchant, and another portion of the account number to the merchant referred to as the merchant code.
  • the merchant code forms the prefix while the checkout code form the suffix of the account number.
  • a method for allowing a consumer to complete a payment transaction with a merchant includes sending a checkout code to the consumer when the consumer initiates a visit to the merchant, the checkout code forming a portion of a virtual payment account number, and combining the checkout code with a merchant code, the merchant code provided to the merchant prior to the payment transaction, wherein the combined checkout code and merchant code form the virtual payment account number.
  • the method further includes processing the payment transaction using the virtual payment account number as the mechanism for payment using the merchant's existing payment processing system.
  • a virtual payment account number used to complete a payment transaction with a merchant includes a checkout code provided to a consumer and associated with a particular visit to a particular merchant and a merchant code provided to a merchant.
  • the checkout code and the merchant code are combined to create the virtual payment account number, the virtual payment account number being prefunded with sufficient funds to cover the payment transaction between the consumer and merchant using the merchant's existing payment processing system.
  • a method for incorporating an offer with a payment method includes generating an offer by an offer provider, the offer associated with an offer account having funds to cover the offer and splitting a virtual payment account number which can be used to make a payment into a checkout code and a merchant code.
  • the method then describes associating an offer with a checkout code, sending the checkout code to a consumer, and applying the offer value to the payment transaction by using the virtual payment account number to make the transaction payment and to withdraw funds from the offer account to cover the offer.
  • a system for combining a payment mechanism with an offer to a consumer includes a virtual payment account number generation engine to generate virtual payment account numbers that can be used by a consumer in a payment transaction at a ⁇ the virtual payment account number generation service also operable to take a portion of the virtual payment account number and send it as a checkout code to a consumer using the consumer's mobile device, and an offer generation engine used to set rules for an offer to be sent to consumers, create a fund for the offer, and determine individual consumer's eligibility for the offer.
  • the offer is associated with the checkout code such that the offer is processed as part of the payment during the payment transaction using the virtual payment account number.
  • FIG. 1(a) is a diagram of prior art electronic payment systems for electronic payments such as credit cards;
  • FIG 1(b) is a diagram of prior art electronic payment systems using an intermediary
  • FIG. 2(a) is a diagram showing a traditional credit card account number
  • FIG 2(b) is a diagram showing an embodiment of a virtual personal account number in accordance with the concepts described herein;
  • FIG 2(c) is a diagram showing an alternate embodiment of a virtual personal account number in accordance with the concepts described herein;
  • FIG. 3 is a network and flow diagram showing an embodiment of a method for processing a transaction according to the concepts described herein and the interaction between various elements of the transaction;
  • FIG. 4 is a network diagram showing the relationship between various elements of an embodiment of a system according to the concepts described herein;
  • FIG. 5 is a block diagram of an embodiment of a system implementing the service and method described herein;
  • FIG. 6 is a workflow diagram of an embodiment of a workflow implementing the service and method described herein for a transaction without an offer component
  • FIG. 7 is a workflow diagram of an embodiment of a workflow implementing the service and method described herein for a transaction with an offer component
  • FIG. 8 is a block diagram of an embodiment of an offer engine implementing the offer generation component of the service and method described herein;
  • FIG. 9 is a block diagram of an embodiment of an offer sequence using the offer engine of Figure 8.
  • FIG. 10 is a block diagram of an embodiment of an offer lifecycle according to the concepts described herein;
  • FIG. 11 is a block diagram of an embodiment of a merchant-consumer interaction
  • FIG. 12 is a diagram of an embodiment of a gift giving and usage sequence
  • FIG. 13 is a diagram of several embodiments of app screenshots used for payments
  • FIG. 14 is a diagram of the coin characteristics
  • FIG. 15 is a block diagram of coin based payment operations. BEST MODES FOR CARRYING OUT THE INVENTION
  • the concepts described herein relate to a system and service that simplifies the processes whereby consumers interact electronically with merchants, to pay for purchases, and/or to receive and redeem relevant offers, receive and redeem rebates or refunds and track receipts.
  • the service also increases the relevance of merchant-consumer interactions, allowing the merchant to target offers to the consumer as the consumer is shopping as well as associate historical purchase transaction data with a particular consumer.
  • the system and service described herein uses virtual personal account numbers (ANs) representing stored value payment cards to process transactions.
  • ANs virtual personal account numbers
  • the system and service provides a portion of the WAN to the consumer (the coin/consumer token/checkout token/checkout code), and another portion of the account number to the merchant (the lane token/merchant code).
  • the merchant code forms the prefix while the checkout code forms the suffix of the account number.
  • FIG. 2(a) shows a typical payment card account number used by the Visa/Mastercard processing systems.
  • an account number 20 is 16 digits long and is formed by a leading six digit issuer identifier (BIN) 21 that identifies the bank or financial institution that issued the card. While a 16 digit number is shown, any number of digits can be used to create a VP AN according to the concepts described herein.
  • the BIN 21 is followed by a nine digit account number 22 for the particular consumer/card and a one digit LUHN check value 23 that allows the processor to verify that the account number is valid.
  • FIG. 2(b) shows one embodiment of a VP AN according to the concepts described herein.
  • the WAN in this embodiment is a sixteen digit account number 25 processable by existing payment card payment processing systems found at most merchants.
  • the WAN is formed from two parts.
  • the first portion, or prefix 26, is the merchant code and can be 10 digits formed from the six digit BIN 28 and a four digit system number 29 assigned by the present system.
  • the second portion, or suffix 27 is the checkout code and is formed by a five digit number plus a LUHN check value 30.
  • the prefix and suffix are combined at the time of a transaction to form a payment card account number usable by the merchant to process the transaction.
  • Figure 2(c) shows an alternate embodiment of a WAN according to the concepts described herein.
  • WAN 32 is formed by a six digit prefix 33 consisting of the BIN 35 and a 10 suffix 34 that is the consumer token also referred to as the checkout code and LUHN value 36.
  • Figures 2(b) and 2(c) show two embodiments of a VPAN, one skilled in the art will understand that there are any number of ways to form a VPAN where a portion of the VPAN is given to the merchant and the remainder of the VPAN is given to the consumer, where the VPAN is formed by combining the merchant portion with the consumer portion in some manner. Further, the VPAN may represent a stored value account that is particular to this merchant or is in some other fashion unique.
  • the method 40 preferably begins by registering new consumers) 41 before the consumers) can enter into transactions using the system, as shown by step 42.
  • the new consumer 41 creates an account and supplies information such as name, address, phone and other identifying information.
  • the consumer 41 can agree to terms and conditions for use of the system and service and register a payment card as shown in step 43 used to fund the consumer portion of transactions.
  • the payment card may be validated by the system and may be checked for availability of funds.
  • the system 49 which is connected to persistent storage 50, requires prior to use that merchants 52 who desire to use the system also register.
  • the merchant provides their physical address, trade name, and business name, as well as a phone number and other merchant-specific information.
  • the information provided by the merchant can also be verified through other sources such as a Google search as well as a physical GPS location provided by an independent source. The verification methods would help prevent fraudulent merchant accounts.
  • the merchant then can create an offer account by which the merchant can fund offers that the system herein presents to consumers and that are fulfilled at their stores resulting in the specific location receiving funds from both the consumer and from the offer account.
  • the offer account contains the merchant's funds, that are accessible by the service to fulfill transactions.
  • the offer methodology and process will be described in greater detail with respect to Figures 8 through 10.
  • banks or other funding sources or intermediary services such as PayPal can be used for merchant accounts.
  • the merchant 52 then provides information used by the system to create and load funds onto VPANs. In preferred embodiments, the system knows the average sale amount, the number of transactions per week/month, the frequency of visits, and the gross margin of a typical visit in order to best serve the merchant.
  • the system then sends the merchant 52 the payment prefix(es), or merchant codes(s), which are based on the range of the VPANs used for this merchant for transactions at that merchant and which must be combined with the payment suffix(es), or checkout codes in order to create a complete VP AN that then is presented on the behalf of the consumer for payment authorization.
  • the system may then be used to allow the consumer 41 to pay for goods or services or may also be used to present offers to the consumer which may be redeemed through a transaction using the system.
  • the consumer checks in or is detected in a participating merchant location. This can be accomplished by any known or future mechanism, such as by having the consumer send a text or SMS message to the system, having the user activate an app on a smart phone that reads a bar code or Quick Response (QR) code at the merchant location, using a geo location or geo fencing feature or a phone or other mobile device that detects the consumer's location, social networking, or any other mechanism to alert, detect and/or verify the consumer's location.
  • QR Quick Response
  • This location can be set in any number of ways.
  • the service while not limited thereto, includes embodiments of three ways.
  • the checkout code can be requested for a merchant by the subscriber, for an imminent visit.
  • a checkout code may be automatically sent to a subscriber device once the device is "detected" entering a location.
  • a hybrid of these two approaches is possible, where a subscriber has already entered an establishment and desires repeat business. The person can then request an additional checkout code for a device where context or location awareness is already established. To accommodate transaction inquiries or to facilitate
  • the checkout code and mobile phone number may be submitted in the context of the location to retrieve the transaction details.
  • the system then prepares for a potential purchase by the consumer 41, as shown in step 45.
  • the system can, preferably, take a number of actions.
  • the system selects a consumer checkout code to send to the consumer 51 to be used should the consumer 41 make a purchase at the merchant 52.
  • the checkout code when combined with the merchant code, forms a complete VP AN that can be used to electronically pay for a purchase.
  • the VP AN corresponds to a stored value card number that has been loaded with an amount deemed sufficient to complete a transaction at the merchant.
  • the amount can be a multiple of the average value of a transaction at that merchant, can be set based on the consumer's purchasing history, can be selected by the consumer or merchant or can be set using any other manner consistent with the concepts described herein. Additionally, the value can be transferred to the stored value card at the time of the consumer's check in at the merchant, can be preloaded at some predetermined time, or can be loaded to the card according to some other methodology. If the card is preloaded, the checkout code can be selected based on the amount loaded in that stored value card account. In addition, the consumer's payment account can be authorized for some amount the system determines for the specific location.
  • the system 49 can determine if there is an offer available for the consumer at that merchant.
  • the offer can come from the merchant, or a related vendor, manufacturer, franchisor, another consumer (gift(s)), etc. any or all of whom are considered offer providers. If an offer or offers are available for the consumer, one or more are selected and presented to the consumer with the checkout code.
  • the offer may have conditions or require that certain triggers be met for the consumer to take advantage of the offer. For example, the consumer may be required to spend a minimum amount or to purchase particular goods or services to receive the benefit of the offer. Any conditions or triggers may be included in the offer while remaining within the scope of the concepts described herein.
  • the system can be used to track whether the conditions or triggers are met using the checkout code, or the merchant modify the point of sale system in order to verify, via automated or manual means, the triggers at the time the transaction is completed at check out.
  • the offer provider's payment account may be authorized for the specific amount of the offer that the consumer is qualified to receive.
  • the consumer provides the merchant with the checkout code that was sent to them during check-in which may be a 6 digit
  • suffix/checkout code may have the implication of setting a value limit for the transaction since the stored value card account associated with the checkout code may be pre-loaded with a value before check out.
  • the checkout codes are preferably set for a reasonable upper limit of what the consumer is likely to spend at this merchant.
  • the system may include a function for the consumer to request more value (e.g. increase the amount they can spend on this VISIT), or to request that the system lower their value (perhaps for budget management reasons).
  • the merchant's cashier 53 enters the prefix/merchant code provided to the merchant by the system, plus the consumer's six digit suffix/checkout code. Expiration date, and any other information required for processing, may be provided to the merchant with the merchant code.
  • the transaction is routed to the preloaded stored value card that was prepared previously, such as at check-in or at the beginning of the business day, and authorized by existing payment processing systems. Settlement will similarly be managed by existing payment processing systems in a known fashion.
  • a process for combining the merchant code and checkout code includes, in response to a request by the cashier for payment, providing the checkout token to the cashier verbally, in writing, by use of a code on a smart phone app, through wireless communications between a smart phone and or by any other means.
  • the cashier then combines the consumer checkout code with the merchant code and enters it as a "card number" in the register or on the card "swipe" terminal or via other means.
  • the actual entry of the number can be manual or can be through plug in application at the card terminal or merchant register. This results in the register/terminal processing as if a physical card had been presented (though without the card-swipe), or through the actual swipe of a card that has been programmed with the VPAN.
  • the system 49 receives a notification (advice) that an authorization (which includes capture/completion) has been released for a given card number, and amount.
  • the system 49 will then send a receipt to the consumer for that amount.
  • the system of the present invention, or the merchant can then compare the amount of the transaction to any applicable offers that were associated with this checkout code. If an offer associated with the checkout code was activated and the conditions for the offer are fulfilled, then the amount of the offer is preferably requested from the merchant's offer account or alternatively another funding account for which the offer provider is responsible.
  • the amount of the offer funds requested from the merchant's account may be grossed up by an amount representing a fee for use of the system.
  • the system then performs a capture transaction for the total amount minus the offer amount and deducts that amount from the stored value card account based on the authorization performed earlier, as shown in step 47.
  • the consumer's payment card account, loyalty account, reward account, or any other funding source is charged for the total sale minus the offer, which is charged against the offer provider's account.
  • step 48 post transaction analysis is conducted.
  • the system will allow the merchant 52 to manage their offers account based on the amount of funding they provide for offers and the responses that they get. Merchants can use information collected about the purchase and the response to offers to create offers based on the responsiveness of consumers to prior offers. When the merchant decides to make additional offers, the merchant simply adds the value corresponding to the offer to the merchant funding account. Similarly, other offer providers may access transaction analysis data in order to provide additional offer funding.
  • the payment process using the VP AN according to the present method follows a typical payment card scenario with respect to the stored value card account that was selected for this transaction, except for potential variations attributable to the use of the system. For example, any customer service interaction from a chargeback exception dispute or fraud perspective initiates with the present system instead of either the issuer of the VP AN (if different than the present system), or with the consumer's payment card issuer. Also, the system, in addition to or instead of the merchant, will create a proof of authorization that is retained as evidence of the transaction including location, mobile device, payment transaction details, and purchase receipt data.
  • checkout code is intended to be a single use account number active only for the merchant visit to which it is associated.
  • the checkout code provides credentials for access to the system for a payments authorization, and serves as a longer term reference number for a transaction by a consumer, specific to a particular location.
  • a checkout code may be used to lookup a transaction after it has been completed, given the checkout code and some other details such as the timeframe in which the transaction occurred, the location, or the registered mobile phone number associated with the transaction.
  • the checkout code can also be programmed to be active only for a certain period of time while the consumer is in the merchant location. Generally, this will be on the order of the third or fourth deviation from the average visit length to the merchant, but can be set to any value desired by the system, merchant and/or offer provider. For example, if a coffee shop has a mean visit time of 15 min, but a standard deviation of 3 minutes, the checkout code should be active for at least 25 min.
  • a checkout code Once a checkout code is has been activated, or used, it may not be re-used for a substantial period of time. Generally, the period of time between re-use of a particular checkout code should be on the order of a time frame measured in years, with a time frame of at least seven years being preferable. With respect to the actual number generated as the checkout code, the generation of the checkout code itself should not be "anticipatable", and therefore should not be susceptible to fraudulent use via guessing or other means of providing an otherwise valid VP AN at the specific merchant location.
  • a preferred mechanism to secure these transactions would be a confirmation number.
  • the checkout code In combination with the merchant code and possibly the date and time of the transaction, the checkout code would uniquely identify a visit by a consumer to a merchant at a specific date and time.
  • a subscriber Once the transaction is completed and processed, a subscriber will also be able to recall past transaction details via their mobile device or internet connection using an app or web browser.
  • the checkout code will have a time-to-live, or valid time frame in which to use it.
  • the checkout code will not be stored on the service platform in its native form, to prevent unauthorized use and to enhance physical security of the database.
  • Yet another alternative prevents a checkout code from being re-used for the same merchant, using any other device, for a given time period.
  • System, or generation engine, 60 communicates with external components 61.
  • External components include web browser 62, issuer API 63, scheduler 64, SMS gateway 65, and acquirer API 66.
  • Other external components may be included as required for system 60 to perform as described herein.
  • Web browser 62 provides the interface for consumers, merchants and others to interact with system 60. Web browser 62 allows consumers and merchants to register and see account data, such as transaction history and personal data. Merchants, as well as other offer providers, can also use web browser 62 to create, edit, and manage offers.
  • Issuer API 63 is the interface to the VP AN issuers computer systems. Issuer API 63 is used to manage, fund and defund the stored value card accounts associated with the WANs used by system 60. Scheduler 64 manages the timing of the interactions between the various actions of system 60. SMS gateway 65 provides the interface between system 60 and SMS communications and/or mobile applications used by consumers and merchants. Acquirer API 66 provides the interface between system 60 and the entity managing consumer and merchant accounts. Acquirer API 66 is used to claim funds from the merchant's offeror account and to charge the consumer payment method.
  • External components 61 communicate with system 60 over the backbone 67.
  • Backbone 67 includes interface 68 that manages communications to and from external components 61.
  • Framework 69 and execution engine 70 provide the platform to run the various applications that comprise system 60.
  • Backbone 67 communicates with database object 71 which provides the interface between database 72 and the rest of system 60.
  • Database 72 stores all of the information related to the operation of system 60 including consumer and merchant profiles, transaction histories, VP AN history and status and all accounting data.
  • SMS Controller 73, site controller 74, and issuer controller 75 provide the objects in system 60 that interact with their corresponding external components.
  • SMS controller 73 provides the interface in system 60 with mobile communications, such as SMS text messages and the like, from consumers and merchants.
  • Site controller 74 provides an interface using the web browser 62 to allow merchants to view, edit, and control offers and their merchant account at the acquirer. Issuer controller 75 manages the interaction of system 60 with the issuer of the VP AN accounts through issuer API 63, allowing system 60 to control which VPANs are active and the funding state of each VP AN in the system.
  • Utilities 76 provide utilities, applications, and objects that are used by the rest of system 60 in its operation.
  • Backends 77 includes methods and objects that allow system 60 to provide instructions to the acquirer and issuer during transactions and account management.
  • Website 78 is the public website for system 60 and is the portal through which consumers, merchants and third parties interact with the system over the internet using web browser 62.
  • system 60 various interactions between external components 61 and the elements of system 60 during typical operations will be described.
  • a consumer will view the website 78 using web browser 62 with the interactions between web browser 62 and website 78 being controlled by backbone 67, including interface 68 of backbone 67 which can be implemented using a program like the open source Apache web server program.
  • Backbone 67 communicates with database objects 71, which makes sure the appropriate changes are made to database 72 to reflect the new consumer registration and preferences.
  • Database object 71 may also call utilities 76 as required to perform necessary operations.
  • a merchant is added to the system over the web interface and the merchant is creating offers.
  • Merchant uses web browser 62 to interact with the system 60 over backbone 67.
  • Site controller 74 instructs database objects 70 to update the database 72 while backends 77 issues instructions to create and fund the merchant account at acquirer over acquirer API 66 that will be used to fund the merchant's offers.
  • a consumer checkout is occurring.
  • Scheduler 64 requests that backbone 67 check the VP AN account to see if the funds have been withdrawn as part of the checkout process using issuer API 63.
  • Backbone 67 then uses the issuer controller to update database 72 using database objects 72.
  • Backends 77 is then instructed to charge the consumer payment method and the merchant account as required for the funds spent by the consumer during checkout.
  • the system and method include a device to detect the entry of a registered user at a retail location. As before, once the consumer is known to be at a particular merchant, the system notifies the consumer of the most current, relevant offers from the merchant. Using his mobile phone and the secure authentication features of the service, the consumer can apply available gift card balances toward his purchases and ensure that applicable loyalty program balances are updated, all without the need to use gift cards, store cards or other tokens.
  • the service can be set up to detect the consumer's mobile phone (if it is present and powered on), identifies the consumer and sends a welcome message to the consumer's phone, using, for example, an SMS message, a push notification, if enabled by the consumer, or other similar mechanism.
  • the welcome message informs the consumer of any relevant offers or of any account credit balances applicable to the location (e.g. merchant store card balances, loyalty program points).
  • the message can also provide the consumer a checkout code that may be used for a limited time to authenticate the consumer to the service.
  • the checkout code can be a 6-digit number generated by the service, though other numbers, strings, identifiers, symbols, or any other suitable identifier can be used as a checkout code in the same manner as described herein.
  • the consumer may authenticate himself to the service by entering his phone number and the 6 digit token at the POS terminal.
  • the consumer may use the POS terminal to apply available loyalty points toward the purchase, and/or to pay for the purchase using an available store card balance, or other payment type registered with the service.
  • the device securely stores a record of the transaction receipt.
  • the consumer can use the POS terminal to request a copy of the receipt, which the service transmits securely to the consumer's mobile phone or email account or which can be accessed via a web browser or app.
  • POS point-of-sale
  • An alternative embodiment of the service registers with the merchant acquirer software that drives the POS terminal, when the device initializes.
  • the terminal driving software can present an option to the consumer at the terminal to use the present system to pay. On selecting this option, the consumer is prompted to enter his phone number and the 6-digit checkout code provided on entering the premises.
  • An alternative embodiment resulting in a 16-digit string resulting from the concatenation of phone number and checkout code may be made compatible in format with the existing payments infrastructure, and may be routed by the terminal driving software to the Service in order to authenticate the user. If the system successfully authenticates the phone number / checkout code combination, the consumer details together with the rest of the transaction details may be used to check whether the consumer has any applicable loyalty accounts, what other payment methods are available, or whether any offers or discounts are applicable to the transaction. As a result, the consumer may be prompted to select whether he wishes to apply available loyalty points toward the purchase, and/or to pay for the purchase using an available store card balance, and will be notified if any discounts have been applied.
  • the service may prompt the consumer to select one of the payment accounts he has registered with the service.
  • the Service will supply the payment account details to the merchant acquirer software, which will then process the payment in the normal way.
  • the service obtains an electronic copy of the receipt. This may be accomplished by communication with the terminal driving software or intercepting the receipt details being sent to the terminal printer.
  • the service securely stores a record of the transaction receipt for future reference by the consumer or the merchant.
  • the consumer may also request a copy of the receipt at the point of sale.
  • the service securely transmits a copy of the receipt to the consumer's mobile phone in a format suitable for viewing on the specific device the consumer is carrying.
  • any of these parties may change or stay the same depending on what specifically is being purchased.
  • Each of these parties produce and consume information and services in their own domain and in relation to their own domain with little to no regard to how it may or may not be valuable to a party in a different domain.
  • Embodiments of the system described herein track, maintain, relate, and provide access to consumer specific retail data and retail services in a consolidated, centralized fashion and present it to the various interested parties in a way that they understand with a mind toward security, privacy, and value.
  • Information and services may include but not be limited to: messages, reminders, entertainment, targeted advertisement, event notices, sale notices, receipt data, gift account access, loyalty data, payment, individualized offers, warrantee access, rebate process, etc.
  • This system can integrate within the existing retail infrastructure, complying to various established interfaces and protocols in order to collect the information from and provide services to the various domains. It can provide web-services or services similar to web-services to present and provide the information and services that is pertinent to each of the given parties.
  • this system will provide an abstraction layer of business logic 54 that will stand between system access and the various parties interested in system access. For instance a consumer may wish to look at their recent purchase receipt. This information might be access via several methodologies. A few being: a text message interface, a web-site, a mobile web-site, or a mobile "app". Each of these interfaces would access the business logic 54 in the same way via a service adapter.
  • Business logic 54 is connected to user data/service manager 55.
  • Direct interactions are generally more efficient because they involve personal service in response to a real-world event.
  • a dialog at the return desk happens because a consumer walks up to it with a previously purchased item. Sales personnel offer help because a consumer enters their aisle. The merchant's customer support staff give aid because a consumer calls a service desk phone number.
  • the weakness of direct interaction is that it relies on sales staff who are costly, time limited, and who cannot generally retain pertinent details about consumers from visit to visit.
  • Virtual interactions on the other hand are generally cheap (on a per-interaction basis), but also inefficient, relying on mass mailings, signs, advertisements, etc. to generate a response in a very small fraction of consumers on the receiving end. This is because virtual interaction is blindly active. That is, it is initiated solely by the retailer caused by no real- world event and usually very impersonal. As such, consumers risk virtual interaction fatigue resulting in ignored signs, unredeemed coupons, and deleted e- mails. Consumers place no value on the interaction because it has no connection to their current real- world activities.
  • the service utilizes an interface that achieves the benefits of direct interaction with the mass market appeal of virtual interactions.
  • the service can include the ability to personalize interaction with the consumer to the extent the interface system has information about a particular consumer. This is done by making use of the consumer's mobile phone as both a locater as well as a message transceiver.
  • the device can trigger a system that intelligently interacts with the owner of the phone based on the real-world characteristics of the phone (e.g.
  • a virtual (personalized) interaction in the sense that the interaction is with a single person
  • the interaction can then become a conversation where the consumer takes on the role of the inquirer and the system becomes a responder.
  • This can take place over any sort of mobile phone based interactive medium such as text messages, mobile web, or even phone conversation.
  • mobile phone based interactive medium such as text messages, mobile web, or even phone conversation.
  • it could be done via the existing mobile phone network or directly to the phone from the detection device.
  • the applications of this system are manifold from both the perspective of the retailer as well as the consumer including but not limited to: welcome messages, farewell messages, reminders, promotional games / entertainment, targeted advertisement, event notices, sale notices, receipt access, gift account access, loyalty balance access, payments, offer matching, warrantee access, rebate process, shopping lists, surveys, gift registrations lists, consumer feedback, etc.
  • Workflow 90 shows the process and message flow between the different entities utilized by the system. These entities include the consumer 91, the system 92, the virtual prepaid account issuer 93, the merchant, the merchant's acquirer 95, the system's acquirer 96, and the consumer's issuer 97.
  • the merchant's acquirer and the system's acquirer are the institutions used by those entities to process electronic payments.
  • the consumer's issuer is the payment mechanism used by the consumer to fund transactions, such as the consumer's credit card, debit card, bank account, PayPal account or any other payment system that could be used by the consumer to fund their purchases.
  • Workflow 90 begins with the consumer 91 sending a check in notice 98 to system
  • system 92 sends a request 99 for a new VP AN to virtual prepaid account issuer 93.
  • system 92 sends a hold request 100 for the consumer's expected or predicted spend to its acquirer 96, and acquirer 96 passes that hold request 101 to the consumer's issuer 97.
  • Hold responses 102 and 103 are sent to system acquirer 96 and system 92, respectively, confirming the hold.
  • system 92 then funds 104 the VP AN at issuer 93 with the expected or predicted spend amount, and the checkout code 105 is sent to the consumer 91.
  • consumer 91 presents the checkout code 106 to the merchant 94, and merchant 94 combines the merchant code (the prefix, as described with reference to Figures 2b and 2c) with the consumer's checkout code (the suffix) to create the VP AN to be used in the transaction.
  • the merchant then enters the VP AN as the payment mechanism for the transaction 107 which is sent to the merchant's acquirer 95.
  • the merchant's acquirer 95 sends a capture request 108 to the virtual prepaid account issuer 93 which sends back a capture response 109 and sends a transaction advice 110 with the actual transaction amount to the system 92.
  • the system 92 sends a capture request 111 to the system acquirer 96 for the actual amount to the transaction and the system acquirer sends a capture request 112 to the consumer issuer 97.
  • a capture response 113 is sent by the consumer issuer 97 to the system acquirer 96, which is passed along 114 to system 92.
  • System 92 can then issue an electronic receipt 115 to the consumer 91 to complete the transaction.
  • FIG. 7 an embodiment of a payment workflow 120 for a system according to the concepts described herein is shown.
  • the embodiment of the workflow 120 shown in Figure 7 does include an offer to the consumer.
  • the entities are the same as were described with respect to Figure 6, except that an offer provider 121 is added to the transaction.
  • the offer provider may be any third party or may be the merchant 94 or even the system 92.
  • a gift provider may be used in place of or in addition to the offer provider 121.
  • Functionality of providing a gift is substantially similar to the functionality of providing an offer.
  • system 92 issues an additional hold request 122 and 123 to the offer provider 121 for the amount of the offer.
  • the offer provider 121 then provides the hold responses 124 and 125 for the amount of the offer. If a gift provider is present an additional hold request may be issued to the gift provider with corresponding hold request from the gift provider.
  • system 92 issues the checkout code 126 with the offer details and funds the VP AN 127 with the expected spend plus the offer.
  • the rest of the workflow is again the same as the non-offer workflow except that an additional capture request 128 to the offer provider 121, with the capture request 112 to the consumer's issuer 97, is sent by the system acquirer 96.
  • the offer provider 121 then sends the capture response 129 for the offer amount alongside the capture response 113 from the consumer's issuer. If a gift provider is present, the offer provider steps may be repeated for the gift provider.
  • an embodiment of an offer engine for use with the system of the present invention is described.
  • the offer engine includes both a global offer component 141 and a user specific offer component 142.
  • the global offer component 141 includes one or more funding sources 143.
  • the funding source can be any funding source, including the merchant, a product manufacturer, a service provider, a franchisor, a marketing company, another individual consumer or any other entity desiring to make an offer on a product or service or at a merchant, particular merchant locations, or group of merchants.
  • the funding source supplies a fixed or variable funding pool that can be drawn against as consumers accept and use the offers. This approach results in funding for offers occurring in real time for precisely the amount of the actual redemption at the moment of checkout and is a critical component of this system.
  • the global offer component 141 includes one or more global offers 144.
  • the global offers 144 are abstract, non-specific offers associated with a particular funding source 143.
  • the global offers include information and rules regarding start date, expiration, qualification, award, messages and any other information or rule that can be used to control an offer.
  • the location for the global offers can be determined in the rules and may target any merchant, location, group of merchants, or group of locations.
  • the rules may take into account geographic information, local nuances, local regulation or laws, or other merchant, product, service, or location specific information.
  • the offer engine 141 can then make user specific offers using the user specific offer component 142.
  • Offer engine 140 take the global offer rules 144 and then applies them to the circumstances, demographics, and consumer specific information of each user.
  • Each of the offers may have both qualification rules and award rules.
  • Qualification rules determine whether each user is eligible for an offer under the particular offer rules.
  • Award rules determine the exact offer that is presented to a particular user or consumer. This allows the offer engine to present selected users 145, 146, 147, 148 and 149 with user specific offers 150, 151, 152, 153 and 154 that are specific to their specific circumstances and information.
  • the offers themselves may be any type of offer that an offer provider wishes to make to a consumer.
  • the offer may be for a discount on a transaction, product or service, may be a percentage of this particular transaction, may be a percentage of an average spend over a series of transactions, may be a bonus, additional product or any other type of offer.
  • Alternative embodiments permit data as distinct as line item information and ordinality of product selection to determine redemption of the offer.
  • offer engine 140 is used to provide a specific offer from an offer provider providing a funding pool 143 and a global offer 143.
  • global offer 143 provides global offer rules which can be applied to specific consumers, such as consumers 145-149 through an offer evaluation process 171.
  • the application of the offer rules results in either an invitation, or offer, 155, 156, and 158 being made to an applicable consumer, or results in a consumer being disqualified for a particular reason, such as disqualification for reason "X” 157, or disqualification for reason "Y” 159 where "X" and "Y” are specific disqualifying decisions that a specific consumer fails to pass.
  • the invitations themselves can be the same for all offer recipients or can be different based on the individual user attributes.
  • Offer engine 140 again includes funding pool 143 and global offer 144 containing the rules and eligibility requirements. Based on program start dates and requirements of the global offer, generated offers are created and may or may not be made available on the web for consumer to see. Once a consumer checks in at a participating merchant, he or she is presented with an active offer(s) 162 from the generated offers 161. The consumer can see the offer(s) from a message(s) sent to the consumer after he or she has checked in, or he or she may go to a website to view the offer(s) or further offer details.
  • an offer 162 can then either be used 163 or can be canceled 164.
  • a used offer 163 is redeemed for value by the consumer according to the concepts described herein and the consumer can see the transaction history, including the offer value in association with their account information or receipt. If the consumer fails to meet the offer requirements or chooses not to make a purchase, the active offer 162 is canceled. Active offers can have preset time limits that allow the offer to be canceled and the funding returned to the funding pool 143 if not used. Offers generated 161, but not used within the offer time frame set out by the global offer requirements 144 are considered expired 165. As with canceled offers, any funds for an expired offer which had been reserved can be returned to the pool. Offers can be processed as batches or can be processed in real time. Information 166 relating to the state of the offers is sent back to the offer engine to allow for critical tracking and accounting to take place to ensure that the offers are being made and redeemed according to the global offer rules 144 and to ensure that the funding pool is not exceeded.
  • Third-parties may also desire to give a gift to certain users. Gifts may be given to users in a substantially similar fashion to the way offers are given as described above.
  • While certain embodiments described above may include splitting a VP AN into 2 parts, certain other embodiments may transmit the complete VP AN, an encrypted version of the VP AN, or any other identifier that may be later correlated by the backend to a VP AN for payment.
  • Certain embodiments may also utilize special devices for interaction with the system.
  • the devices may be placed at merchants locations in order to facilitate use of the system.
  • One or more devices may be used to aid in detection of user devices and to aid in processing payments at the POS.
  • Multiple technologies may be used by the devices to detect the user device and aid in completion of the transaction. For example, any one or more of WiFi, Bluetooth(traditional and/or LE), NFC (SE and/or NDEF), barcodes, acoustic, and geo fencing may be used by the devices.
  • Figure 11 is a block diagram of an embodiment of a merchant-consumer interaction 1100.
  • User device 1105 may interact with a detection device 1110 upon entering a service area of a merchant.
  • the user device 1105 may be actively searching for detection device 1110, while in other embodiments, the detection device 1110 may be actively searching for user device 1105. While only one user device 1105 and detection device 1110 are depicted, it should be understood that any number of user devices 1105 and any number of detection devices 1110 may be present in the service area of the merchant.
  • Detection device 1110 may be capable of detecting the presence of user device 1105 using various technologies, some examples of the detection technologies include WiFi, Bluetooth, NFC, geofencing, or any combination of these technologies or any other technology that may be used to detect the presence of user device 1105.
  • detection device 1110 may inform backend 1115 of the presence of the device at the service area of the merchant.
  • Backend 1115 may determine whether or not the user device 1105 is registered with the payment/offer service. If user device 1105 is registered with the payment/offer service, backend 1115 delivers a push notice to user device 1105. Responsive to push notice 1120, app popup 1130 may be displayed on user device 1105 to a user. App popup 1130 may display offers for the merchant or other information relevant to transactions with the merchant.
  • Backend 1115 may determine the forms of payment accepted by the merchant and generate an appropriate VP AN or other payment code for use during transactions between the consumer and merchant. Backend 1115 may make this determination based upon a previous agreement with the merchant, or based upon devices installed in the merchant service area.
  • Bluetooth checkout module 1135 may be used to detect the user device 1105 based upon a
  • the user device 1105 may be used to transmit payment information via Bluetooth MAC 1165 to checkout device 1185, which in turn may provide payment information, for example a VP AN, to POS 1190.
  • a Bluetooth transmitter in the checkout device 1185 may be attenuated in order to reduce the transmission area of the Bluetooth signal.
  • detection device 1110 and checkout device 1185 may be housed in a single apparatus, in others, they may be housed in separate apparatuses.
  • backend 1115 provides an encoded VP AN 1150 to app 1160.
  • App 1160 presents the encoded VP AN 1150, or some other payment code, to the checkout device 1185 via one of NFC NDEF 1175, barcode 1 175, or SMS 1180.
  • Checkout device 1185 may contain one or more of a NFC communication device, a barcode reader, and an input device for entering a payment number.
  • the payment number may be a VP AN, an encoded VP AN 1150 or some other payment code that may be correlated by the checkout device 1185 via the backend 11 15 to a VPAN.
  • Checkout device 1185 may also contain a module to decode and/or verify an encoded VPAN 1150. This may be accomplished using a hash function or other techniques used for encryption/decryption.
  • the merchant's existing POS equipment and network process the VPAN or payment indicator similarly to the processing of more traditional credit card payments and the like.
  • the system interacts with, secures, and accounts for all of the related payment transactions between the VPAN, the consumer's form of funding, the offer or gift forms of funding, and the merchant's agreed forms of payments via the coin.
  • the payment workflows of Figure 6 and Figure 7 may perform a portion of the consumer-merchant interaction of Figure 11.
  • the checkout code described in Figure 6 and Figure 7 may be a partial VP AN, the complete VP AN, an encoded VP AN, a coin, or some other indicator that may be associated with the COIN and/or VP AN by the backend.
  • Figure 12 is a diagram of an embodiment of a gift giving and usage sequence
  • Developer 1205 may develop an app related to certain merchants or payment services. Developer 1205 may register the app with a system for managing merchant- consumer interactions.
  • a user, Friend 1210 may download the app and register a payment card or some other method of payment with the app and send a gift with a certain value to another user, shopper 1215.
  • the gift may be a dollar value to spend at a merchant 1220 or may be for a specific item available from merchant 1220.
  • Merchant 1220 may need to agree to terms and conditions of use of the app prior to accepting payment via the app.
  • Shopper 1215 may visit merchant 1220 and make a purchase using the app. Friend 1210 may then be notified via the app or some other form of messaging that shopper 1215 has redeemed the gift.
  • Figure 13 is a diagram of several embodiments of app screenshots used for payments 1300.
  • Login screen 1310 is from an app that may be used to access the payment system.
  • a user may select from login screen 1310 whether payment is to be made in a store or online. If an online payment is desired, pay online screen 1350 may be displayed.
  • the user may have been shopping online at a merchant that utilizes the payment system.
  • the merchant may display a bar code or other indicator to allow payment of the online purchase via the app as shown in online shopping screen 1360.
  • the app may allow the user to scan or otherwise enter the bar code or other indicator into the app.
  • the app may then transmit information to the payment system which may then communicate with the online merchant for payment. If an in-store payment is desired the user may select that option from login screen 1310.
  • Snap payment screen 1320 may be used by a merchant equipped with a barcode reader.
  • Tag payment screen 1330 may be used by a merchant equipped with a NFC device, attenuated Bluetooth,
  • Tell payment screen 1340 may be used at merchants that don't have the wireless payment equipment or a bar code reader, or if snap payment screen 1320 or tag payment screen 1330 are not working with merchant's equipment. Tell payment screen 1340 may display a payment code that the user will provide to the merchant for entry into a POS or other payment system.
  • FIG 14 is a diagram of the coin characteristics 1400.
  • a coin is a unique or nearly unique identifier that is used to associate together a series of operations into a complete transaction.
  • the coin may be specific to a set of participants using a payment system associated with the coin.
  • the coin may also be specific to a certain time and/or location, for example the coin may only be valid for the 30 minutes after a user enters a store.
  • the coin may be flexible based upon rules and event driven designs that may be configured to support multiple use cases. Further the coin may contractually bind together one or more of participants, merchants, locations, and funding accounts.
  • a coin may be generated.
  • Coin generation may include one or more of the following: registering participants that may use the coin, validating funding accounts that may be used to fund the coin, establishing rules for a transaction associated with the coin, generating invites for usage of the coin, and notifying recipients of the coin.
  • a coin user may visit a merchant.
  • a VP AN may be created and issued for use with the coin; transaction rules of the merchant and payee may be validated; the VP AN may be funded from the previously associated funding accounts; and the user may be presented with a checkout code.
  • a user checks out using coin or a VP AN associated with the coin for payment. The checkout may be conducted as a typical POS transaction.
  • the VP AN associated with the coin may be transmitted wirelessly, scanned by a bar code reader, or verbally given to a cashier or other salesperson at the POS. Participants in the transaction may be notified via message of the transaction, and the recipient may be notified of receipt of payment.
  • the coin transaction is settled. As part of settlement, funds may be acquired from the participants in the transaction.
  • the VP AN associated with the coin may be reset, and transaction data associated with the transaction may be stored.
  • FIG. 15 is a block diagram of coin based payment operations 1500.
  • a coin 1505 may be created.
  • Payment instructions 1530 may be received at an application programming interface (API) 1535.
  • An operations list 1510 may be associated with coin 1505.
  • API 1535 may interact with coin 1505 and operations list 1510.
  • Operations list 1510 may comprise one or more payment operations that are required in order to complete the payment instructions 1530.
  • Each payment operation is associated with a payment conduit 1515. There may be 1 to n payment operations each corresponding to a payment conduit 1515.
  • a first payment conduit may be related to a consumer requesting funds from the consumer's issuer.
  • a second payment conduit may be related to an offer from an offer provider.
  • a third payment conduit may be related to a gift provided from a third party to the consumer via a gift card provider.
  • a fourth payment conduit may be related to the merchant's acquirer for receiving payment.
  • Log/ledger/workflow 1525 tracks the completion of payment operations in the operations list 1510.
  • Processing engine 1520 may monitor or cause payment operations to execute. At the completion of all the payment operations in the operations list 1510, the coin will be balanced from an accounting standpoint.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Finance (AREA)
  • Cash Registers Or Receiving Machines (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un système permettant de combiner un mécanisme de paiement avec une promotion pour un consommateur. Le système comporte un moteur de génération de numéro de compte de paiement virtuel pour générer des numéros de compte de paiement virtuel qui peut être utilisé par un consommateur au cours d'une transaction de paiement chez un marchand, le service de génération de numéro de compte de paiement virtuel étant aussi utilisable pour extraire une partie du numéro de compte de paiement virtuel et l'envoyer comme code de paiement à un consommateur en utilisant le dispositif mobile du consommateur, et un moteur de génération de promotion utilisé pour définir des règles pour une promotion devant être envoyée aux consommateurs, pour créer un fonds pour la promotion, et pour déterminer l'éligibilité des consommateurs pour la promotion. La promotion est associée au code de paiement de sorte que la promotion est traitée comme partie du paiement pendant la transaction de paiement utilisant le numéro de compte de paiement virtuel.
EP14851165.2A 2013-10-04 2014-10-06 Système et procédé de gestion d'interactions entre marchands et consommateurs Ceased EP3053118A4 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP19205018.5A EP3667592A1 (fr) 2013-10-04 2014-10-06 Système et procédé de gestion d'interactions entre marchands et consommateurs

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/046,792 US20140040001A1 (en) 2010-10-26 2013-10-04 System and Method for Managing Merchant-Consumer Interactions
PCT/US2014/059274 WO2015051361A1 (fr) 2013-10-04 2014-10-06 Système et procédé de gestion d'interactions entre marchands et consommateurs

Related Child Applications (1)

Application Number Title Priority Date Filing Date
EP19205018.5A Division EP3667592A1 (fr) 2013-10-04 2014-10-06 Système et procédé de gestion d'interactions entre marchands et consommateurs

Publications (2)

Publication Number Publication Date
EP3053118A1 true EP3053118A1 (fr) 2016-08-10
EP3053118A4 EP3053118A4 (fr) 2016-09-21

Family

ID=52779224

Family Applications (2)

Application Number Title Priority Date Filing Date
EP14851165.2A Ceased EP3053118A4 (fr) 2013-10-04 2014-10-06 Système et procédé de gestion d'interactions entre marchands et consommateurs
EP19205018.5A Withdrawn EP3667592A1 (fr) 2013-10-04 2014-10-06 Système et procédé de gestion d'interactions entre marchands et consommateurs

Family Applications After (1)

Application Number Title Priority Date Filing Date
EP19205018.5A Withdrawn EP3667592A1 (fr) 2013-10-04 2014-10-06 Système et procédé de gestion d'interactions entre marchands et consommateurs

Country Status (3)

Country Link
EP (2) EP3053118A4 (fr)
CA (1) CA2926469A1 (fr)
WO (1) WO2015051361A1 (fr)

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6393325B2 (ja) 2013-10-30 2018-09-19 アップル インコーポレイテッドＡｐｐｌｅ Ｉｎｃ． 関連するユーザインターフェースオブジェクトの表示
US10482461B2 (en) 2014-05-29 2019-11-19 Apple Inc. User interface for payments
WO2016036552A1 (fr) 2014-09-02 2016-03-10 Apple Inc. Interactions utilisateur pour une application de cartographie
US20160224973A1 (en) 2015-02-01 2016-08-04 Apple Inc. User interface for payments
US9574896B2 (en) 2015-02-13 2017-02-21 Apple Inc. Navigation user interface
US20160358133A1 (en) 2015-06-05 2016-12-08 Apple Inc. User interface for loyalty accounts and private label accounts for a wearable device
US9940637B2 (en) * 2015-06-05 2018-04-10 Apple Inc. User interface for loyalty accounts and private label accounts
DK179186B1 (en) 2016-05-19 2018-01-15 Apple Inc REMOTE AUTHORIZATION TO CONTINUE WITH AN ACTION
US10621581B2 (en) 2016-06-11 2020-04-14 Apple Inc. User interface for transactions
CN114693289A (zh) 2016-06-11 2022-07-01 苹果公司 用于交易的用户界面
DK201670622A1 (en) 2016-06-12 2018-02-12 Apple Inc User interfaces for transactions
US11580608B2 (en) 2016-06-12 2023-02-14 Apple Inc. Managing contact information for communication applications
US20180068313A1 (en) 2016-09-06 2018-03-08 Apple Inc. User interfaces for stored-value accounts
US11216805B2 (en) * 2016-09-08 2022-01-04 Modopayments, Llc COIN operated digital payments hub
US10860199B2 (en) 2016-09-23 2020-12-08 Apple Inc. Dynamically adjusting touch hysteresis based on contextual data
KR102185854B1 (ko) 2017-09-09 2020-12-02 애플 인크. 생체측정 인증의 구현
JP6736686B1 (ja) 2017-09-09 2020-08-05 アップル インコーポレイテッドＡｐｐｌｅ Ｉｎｃ． 生体認証の実施
DK201870378A1 (en) 2018-05-07 2020-01-13 Apple Inc. DISPLAYING USER INTERFACES ASSOCIATED WITH PHYSICAL ACTIVITIES
CN112561537A (zh) 2018-06-03 2021-03-26 苹果公司 用于转账账户的用户界面
US11100498B2 (en) 2018-06-03 2021-08-24 Apple Inc. User interfaces for transfer accounts
US12125054B2 (en) 2018-09-25 2024-10-22 Valideck International Corporation System, devices, and methods for acquiring and verifying online information
US11328352B2 (en) 2019-03-24 2022-05-10 Apple Inc. User interfaces for managing an account
DK201970530A1 (en) 2019-05-06 2021-01-28 Apple Inc Avatar integration with multiple applications
US11477609B2 (en) 2019-06-01 2022-10-18 Apple Inc. User interfaces for location-related communications
US11481094B2 (en) 2019-06-01 2022-10-25 Apple Inc. User interfaces for location-related communications
AU2020356269B2 (en) 2019-09-29 2023-04-06 Apple Inc. Account management user interfaces
US11169830B2 (en) 2019-09-29 2021-11-09 Apple Inc. Account management user interfaces

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6754636B1 (en) * 1996-09-04 2004-06-22 Walker Digital, Llc Purchasing systems and methods wherein a buyer takes possession at a retailer of a product purchased using a communication network
US20020082986A1 (en) * 2000-12-26 2002-06-27 Hsi-Peng Lu Method for payment in exchange
US20060020542A1 (en) * 2004-07-21 2006-01-26 Litle Thomas J Method and system for processing financial transactions
US9881297B2 (en) * 2008-11-14 2018-01-30 Mastercard International Incorporated Methods and systems for secure mobile device initiated payments using generated image data
US8606638B2 (en) * 2009-03-02 2013-12-10 First Data Corporation Systems, methods and apparatus for facilitating transactions using a mobile device
US20110166992A1 (en) * 2010-01-06 2011-07-07 Firethorn Holdings, Llc System and method for creating and managing a stored value account associated with a client unique identifier
US20120136796A1 (en) * 2010-09-21 2012-05-31 Ayman Hammad Device Enrollment System and Method
CA2815362C (fr) 2010-10-26 2018-07-17 Modopayments, Llc Systeme et procede de gestion d'interactions commercant-consommateur

Also Published As

Publication number Publication date
CA2926469A1 (fr) 2015-04-09
WO2015051361A1 (fr) 2015-04-09
EP3053118A4 (fr) 2016-09-21
EP3667592A1 (fr) 2020-06-17

Similar Documents

Publication Publication Date Title
US11270301B2 (en) System and method for managing merchant-consumer interactions
EP3667592A1 (fr) Système et procédé de gestion d'interactions entre marchands et consommateurs
US20140040001A1 (en) System and Method for Managing Merchant-Consumer Interactions
AU2019200882B2 (en) System and method of registering stored-value cards into electronic wallets
JP7404154B2 (ja) 電子財布を経た支払いのためのシステム
US11049130B2 (en) Integrating custom benefits into an in-use communication transmission exchange
US20180053157A1 (en) Systems and methods for consumer modifiable payment card transactions
CA2834156C (fr) Procedes et systemes de verification et de remboursement d'offres et de cadeaux dynamiques
US8768834B2 (en) Digital exchange and mobile wallet for digital currency
JP6523272B2 (ja) 還元ポイントを用いるモバイル支払システム
US8751298B1 (en) Event-driven coupon processor alert
US20220027881A1 (en) Payment Processing Using Electronic Benefit Transfer (EBT) System
US20150019313A1 (en) Method, apparatus, and computer program product for facilitating promotions with an e-wallet
US20140081729A1 (en) Systems and Methods for Providing Consumer Discounts
US20210166260A1 (en) Systems and methods for providing a merchant offer
KR20100049602A (ko) 복수-벤더 복수-로얄티 통화 프로그램
US20150154587A1 (en) System and method for applying credits from third parties for redemption at member retailers
CN106462838B (zh) 使用通信网络在多个单独计算系统当中协调处理的系统及方法
US20180165704A1 (en) System, methods, and devices for real-time rewards accumulation and redemption
US9892419B1 (en) Coupon deposit account fraud protection system
US20240020685A1 (en) Method, apparatus, and computer readable medium for providing management of stored balance cards

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20160404

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

RIN1 Information on inventor provided before grant (corrected)

Inventor name: BUELL, JON

Inventor name: HARVEY, GREGORY, W.

Inventor name: BERGIN, COLM

Inventor name: WILKINSON, AARON

Inventor name: BROWN, SAMUEL, N.

Inventor name: SCHULZ, RALF, ERICH

Inventor name: FISHER, JASON

Inventor name: MENEFEE, MICHAEL

Inventor name: PARKER, BRUCE

Inventor name: SINK, DAVID, S.

Inventor name: SAUM, MARK, S.

A4 Supplementary search report drawn up and despatched

Effective date: 20160823

RIC1 Information provided on ipc code assigned before grant

Ipc: G06Q 20/32 20120101AFI20160817BHEP

Ipc: G06Q 20/38 20120101ALI20160817BHEP

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20180227

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20191230