PAIRING ELECTRONIC WALLET WITH SPECIFIED MERCHANTS

Abstract

A system and method for facilitating use of a digital electronic wallet by a cardholder for cashless transactions. The method comprises receiving a selection by a first cardholder to pair a first digital wallet held by a first wallet holder with a first merchant, the first digital wallet having therein an electronic representation of at least one payment device usable to fund a cashless transaction, and verifying the cardholder's identity. Thereafter, facilitating a communication between the first cardholder and the first wallet holder to record consent by the first cardholder to share wallet information with the first merchant. The present disclosure further comprises receiving from the first wallet holder authorization to generate a wallet token usable for acquiring wallet information on behalf of the first merchant, using the first digital wallet as selected by the first cardholder, and preparing a merchant token corresponding to the wallet token. The merchant token is provided to the first merchant, for presentation to access wallet information, including payment card information on a cashless transaction.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is related to non-provisional U.S. Utility patent application Ser. No. 13/209,312 entitled “MULTI-COMMERCE CHANNEL WALLETS FOR AUTHENTICATED TRANSACTIONS”, and also International PCT Application Serial No. PCT/US2011/047678 having the same title, both filed 12 Aug. 2011, both of which in turn claim the priority benefit of U.S. Provisional Application Ser. No. 61/372,955 filed 12 Aug. 2010 and also of U.S. Provisional Application Ser. No. 61/468,847 filed 29 Mar. 2011.

This application is further related to U.S. Provisional Application Ser. No. 61/588,505 (Attorney Docket No. 1788-82P) entitled “SYSTEM TO ENABLE A NETWORK OF WALLETS”, filed 19 Jan. 2012.

This application is further related to U.S. Provisional Application Ser. No. 61/642,729 (Attorney Docket No. 1788-82P2), entitled “SYSTEM AND METHOD TO ENABLE A NETWORK OF DIGITAL WALLETS”, and filed on even date herewith.

The complete disclosures of all related applications cited above and any of their corresponding priority applications are hereby incorporated in their entirety for all purposes by this reference.

BACKGROUND

1. Field of the Disclosure

The present invention relates to cashless transactions for payment of goods/services and, more particularly, to an electronic interface protocol facilitating purchaser access to a network of electronic wallets from which the purchaser may choose.

2. Brief Discussion of Related Art

Electronic wallets are becoming a more prevalent counterpart to electronic forms of cashless payment for a wide variety of transactions. Generally speaking, an electronic wallet is a system by which a credit card, debit card, pre-paid card, etc., are stored where a single electronic application provides access to them, analogous to the way in which one might store corresponding physical payment cards in a tangible wallet.

The disclosure in the application entitled “MULTI-COMMERCE CHANNEL WALLETS FOR AUTHENTICATED TRANSACTIONS”, and also the related application entitled “SYSTEM AND METHOD TO ENABLE A NETWORK OF DIGITAL WALLETS”, includes a federated network of electronic wallets. The purchaser may select this network of wallets, which includes wallet partners who are members of the federation, each of whom provide electronic wallet services. One option presented to the purchaser may be the option to use an electronic wallet maintained and provided by the payment processing entity, e.g., MasterCard International, which is also operating the network of wallets.

A problem is presented to present the purchaser with a consistent and desirable or pleasing checkout experience using their chosen electronic wallet across multiple vendor websites, and multiple platforms (e.g., web, mobile, tablet, etc.). The present state of the art is therefore wanting.

SUMMARY

At least one benefit to be realized according to the present disclosure is that the user's shopping experience is improved by the merchant having access, during the shopping process, to user wallet data which would ordinarily be shared with the merchant only later in the process. For example, at the collection of payment by cashless means, which would ordinarily occur at the conclusion of the sale, the merchant would receive the user's wallet data.

Features of the disclosure will become apparent from the following detailed description considered in conjunction with the accompanying drawings. It is to be understood, however, that the drawings are designed as an illustration only and not as a definition of the limits of this disclosure.

The present disclosure is directed to a method of facilitating use of a digital electronic wallet by a cardholder for cashless transactions. The presently disclosed method comprises receiving a selection by a first cardholder to pair a first digital wallet held by a first wallet holder with a first merchant, the first digital wallet having therein an electronic representation of at least one payment device usable to fund a cashless transaction, and further may include other information to facilitate completing the transaction, including without limitation a shipping address, or loyalty account identifiers. Thereafter, facilitating a communication between the first cardholder and the first wallet holder to record consent by the first cardholder to discreetly share payment device, profile, shipping address, and rewards information with the first merchant. Upon consent, the present disclosure further facilities a communication between the first wallet holder and first merchant by providing a wallet token usable for accessing wallet information, including payment card information for acquiring payment on behalf of the first merchant from the first cardholder using the at least one payment device in the first digital wallet as selected by the first cardholder, and preparing a long lived merchant token corresponding to the provided wallet token. The merchant token is provided to the first merchant, for presentation to the network operator (e.g., the instant Applicant, under the trademark MASTERPASS) to access wallet information from the first wallet holder.

In still a further embodiment of the present disclosure, the merchant is provide, together with the merchant token, additional information associated with the first digital wallet, including as least one of a shipping address, a loyalty account, product-related preference (e.g., without limitation, airline seating preference) and a scope of cardholder consent.

The present disclosure further provides for a more particular method to include receiving, from the first wallet holder, a request to disable the previously received wallet token. Responsive to receipt from the first wallet holder to disable the token, corresponding merchant token provided to the first merchant is disabled. Optionally, the presently disclosed method provides for receiving postback data from the first merchant concerning any cashless transaction concluded using the merchant token.

Also provided according to the present disclosure are a system including a network-enabled processor for communication among at least a first merchant and a first wallet holder, and a machine-readable recording medium storing thereon a program of instructions which, when executed by a processor, cause the processor to carry out a method described above.

BRIEF DESCRIPTION OF THE DRAWINGS

In addition to the above aspects of the present disclosure, additional aspects, objects, features and advantages will be apparent from the embodiments presented in the following description and in connection with the accompanying drawings,

FIG. 1 is a schematic illustration of a representative cycle of transaction processing by a payment network of an electronic cashless sale;

FIG. 2 is a flow diagram representation of a communication flow for facilitating consumer use of their electronic wallet in remote electronic transactions according to a particular embodiment of the present disclosure;

FIG. 3 is a flow diagram representation of a communication flow for facilitating consumer use of their electronic wallet in remote electronic transactions according to an alternate embodiment of the present disclosure;

FIG. 4 is a flow diagram representation of a communication flow for facilitating consumer use of their electronic wallet in remote electronic transactions where a cardholder had already paired their electronic wallet credentials with a merchant, for example as depicted in either FIG. 2 or FIG. 3, according to a particular embodiment of the present disclosure;

FIG. 5 is a flow diagram representation of a communication flow for facilitating a cardholder unpairing their electronic wallet from any merchant with which they had previously consented to pairing, according to a particular embodiment of the present disclosure; and

FIG. 6 illustrates schematically a representative system operative to carry out the method described in accordance with the present disclosure.

DETAILED DESCRIPTION OF THE EMBODIMENTS

The following sections describe particular embodiments. It should be apparent to those skilled in the art that the described embodiments provided herein are illustrative only and not limiting, having been presented by way of example only. All features disclosed in this description may be replaced by alternative features serving the same or similar purpose, unless expressly stated otherwise. Therefore, numerous other embodiments of the modifications thereof are contemplated as falling within the scope of the present method and system as defined herein and equivalents thereto.

Throughout the description, where items are described as having, including, or comprising one or more specific components, or where methods are described as having, including, or comprising one or more specific steps, it is contemplated that, additionally, there are items of the present disclosure that consist essentially of, or consist of, the one or more recited components, and that there are methods according to the present disclosure that consist essentially of, or consist of, the one or more recited processing steps.

It should also be understood that the order of steps or order for performing certain actions is immaterial, as long as the method remains operable. Moreover, two or more steps or actions may be conducted simultaneously.

The term “transaction data” is used herein to refer to data associated with any recorded cashless transaction, including any transaction using a payment device, for example, a credit card, debit card, PIN debit card, ATM card, electronic funds transfer (EFT), near field communications (NFC) payments, smartphone wallet transactions, and so on, as well as those electronic payments using ACH and electronic wire. Transaction data may further include, without limitation, information identifying the source of funds for the transaction, the amount or value of the transaction, the parties to the transaction, their names, addresses, other identifying information, an identification of the purchaser derived from the payment device used in the transaction, among any other pieces of information as may be relevant to the transaction.

The term “payment network” generally refers to a payment network for handling cashless transactions and is often associated with a single payment card issuer, such as a credit card issuer. However, the term “payment network” as used herein can encompass both single card issuer networks and a network, such as a network of wallets that includes multiple card issuers.

The various methods of the present disclosure are preferably implemented as executable programs stored on a server device and executed by a processing device associated with the server device. Such server devices may be maintained and operated by a payment network operator, or by a third-party hosting operator. The flow of various embodiments of the method of the present disclosure for imputing a personal holiday date associated with a consumer from payment card transaction data into an individualized forecasting model is preferably directed by the hosted executable program code running on the server device or on any appropriate device known in the art for providing the embodiments of the methods of the present disclosure.

Referring to FIG. 1, in one embodiment of a typical cashless transaction a device holder 12 presents a payment instrument 14 to a merchant 16 for payment. Though the payment instrument is shown as a payment card, it can also be a transponder device, NFC-enabled smart phone, or any digital wallet selected for remote or on-line payment or provided as a mobile device app. In cases where the merchant 16 has an established merchant account with an acquiring bank (also called the acquirer) 20, the merchant communicates with the acquirer to secure payment on the transaction by sending a transaction request 21. An acquirer 20 is a party or entity, typically a bank, which is authorized by the network operator 22 to acquire network transactions on behalf of customers of the acquirer 20 (e.g., merchant 16). The merchant 16 may alternatively secure payment on a transaction through a third-party payment provider 18 authorized by the acquirer 20 and the network operator 22 to acquire payments on network transactions on behalf of the merchants. In this way, the merchant 16 can be authorized and able to accept the payment device 14 from a device holder 12, without having a merchant account with the acquirer 20.

The acquirer 20 typically populates and routes the transaction request 21 from the merchant to a network operating system (also referred to as “network operator”) 22 controlled by the network operations entity (for example, MasterCard International Incorporated, assignee of the instant application). The data included in the transaction request identifies the source of funds, or type of payment, used for the transaction. With this information, the network operator 22 routes the transaction to an issuer 24, typically a bank, which is authorized by the network operator 22 to issue payment devices 14 on behalf of its customers (e.g., device holder 12), for use in payment transactions within the payment network. The issuer 24 also typically funds the transaction that it approves. The issuer 24 may approve or authorize the transaction request based on criteria such as a device holder's credit limit, account balance, or in certain instances more detailed and particularized criteria including transaction amount, merchant classification and so on.

The issuer 24 decision to authorize or decline the transaction is routed through the network operator 22 and acquirer 20, and ultimately to the merchant 16 at the point of sale. This entire process is carried out by electronic communication, and under routine circumstances (i.e., valid device, adequate funds, etc.) can be completed in a matter of seconds. It permits the merchant 16 to engage in transactions with a device holder 12, and the device holder 12 to partake of the benefits of cashless electronic payment, while the merchant 16 can be assured that payment is secured.

The issuer 24 may also periodically generate a statement of the cashless transactions 25 for the benefit of the device holder 12 that lists all of the device holder's 12 purchases with the payment device 14 over a specified period of time.

The transaction request from the merchant, which includes details of the payment transaction for authorization, is generally further populated by the acquirer 20 with merchant information and then forwarded to the issuer. A central database, or data warehouse 26, is also associated with and maintained by the payment network for storing and augmenting this payment transaction data on a regular basis for use in marketing, macroeconomic reporting, and so on.

Each payment card transaction record that is stored in the data warehouse 26 is associated with a consumer, and includes at least a date and time of the transaction, an account number, cardholder ID, and/or other identifying data of the cardholder making the purchase, a merchant ID and/or merchant name, and, generally, other merchant location and/or identification information of the merchant associated with the transaction, along with additional details of the purchase. Such additional purchase information recorded in the transaction records typically includes the number, type, and cost of each good purchased. Accordingly, for any particular cardholder/consumer, a time-stamped listing of the consumer's purchasing activity can be obtained, including information on a type of good, number of each type of good purchased, and the cost of each good.

With the advent of the digital wallet, an additional party, a wallet holder 28 (see, e.g., FIG. 2) plays a part in the transaction. The wallet holder 28 stores a cardholder's 12 card credentials electronically, much as a physical wallet would hold a cardholder's 12 transaction devices 14 (e.g., payment cards).

Referring now to FIG. 2, illustrated is a communication flow, generally 100, for facilitating consumer use of their electronic wallet in remote electronic transactions. This method and communication flow will be applicable across any means of electronic interaction between the merchant 16 and their cardholder 12 customer, whether internet web-based e-commerce platforms, mobile device platforms, or app-based platforms, and the precise interface between the cardholder 12 and the merchant 16 will be considered as interchangeable for the purposes of the following discussion. At least one purpose of the interaction is to persistently associate a particular electronic wallet, and more particularly a payment card 14 therein, with a given merchant 16 to facilitate future uses of that wallet while completing a checkout for the current transaction.

The cardholder 12 will interact 102 with the merchant 16, for example via the merchant 16 website or the like. The merchant 16 will then, where possible, recognize 104 the cardholder 12. Among the means of recognition 104, the cardholder 12 may log into the merchant 16 site via credential established for that purpose. Alternately, the cardholder will have consented to a ‘cookie’ placed on their computer from a prior visit to the merchant 16 website which the merchant can use to recognize 104 the cardholder 12. Other methods of recognition are within the scope of this disclosure. During the course of the cardholder's 12 interaction with the merchant 16 the cardholder 12 will initiate a transaction 106 to purchase goods or services from the merchant, and will further choose to use their electronic wallet managed by the network operator 22 in order to pay for the transaction. Additionally the merchant also requests that persistent access be granted to the card holder's wallet data.

The merchant 16 redirects the wallet selection request 108 to the network operator 22. In some embodiments of the present disclosure, the network operator requests information 110 of the cardholder 12 to verify their location, as part of a security measure. The network operator 22 validates the cardholder's response 114 against known data, and presuming successful validation, displays to the cardholder their electronic wallet or wallets 116 available from which to choose. The cardholder 12 makes their selection of wallet 118 from among the available wallets presented 116 by the network operator 22. The network operator 22 at action 120 redirects the cardholder 12 selection of electronic wallet to the corresponding wallet holder 28.

It should be noted here that, consistent with Applicant's prior Network of Wallets filings referenced above and incorporated herein by reference, in certain instances, the network operator 22, or a related entity, will also perform the wallet holder 28. In other cases, the network operator 22 will host an electronic wallet on behalf of a wallet holder 28, for use by customers of that wallet holder 28. This case is also referred to as a “white label” wallet, which is branded by the wallet partner, but functionally operated by the network operator. The Network of Wallets framework further contemplates the wallet being hosted by a wallet holder 28 independent of the network operator. In any case, the communications described herein as with the wallet holder 28 are made with whichever entity is responsible for hosting the electronic wallet.

The wallet partner displays a login page 122 to the cardholder 12, who responds by logging into their wallet 124. The wallet partner validates the login 126, and at 128 presents a page to the cardholder 12 requesting, inter alia, consent to persistently share the consent to share the cardholder's 12 the electronic wallet particulars with the merchant 16. Also to be selected by the cardholder for the purposes of the current transaction is one card within the electronic wallet to be used for the current transaction 16, an address for shipment of goods, and any merchant-linked or other loyalty discounts cards or programs that the cardholder 12 wishes to provide to the particular merchant 16. In certain embodiments of the present disclosure, the provided information may include, without limitation, one or more of payment card information, shipping address information, loyalty account information, cardholder personal profile information and purchase preference information. Purchase preference information may be defined by the merchant, and the information shared may be limited to a particular merchant's needs, or may be more universal with cardholder consent. Merely one example of purchase preference information, taking for instance airline travel merchants, may be seat preference (aisle or window) or meal preference.

The cardholder's 12 selection 130 is provided to the wallet holder 28. The wallet holder 28 will record the cardholder's consent for persistent access by the merchant 132, the additional selections for the current transaction, and issue a confirmation notification 134 to the cardholder 12, for example via e-mail. For the current transaction, the wallet provider will generate a token and provide this token to the network operator. The wallet partner will also authorize the network operator to generate a long lived pairing token for persistent access at 136. A “token” in this context is a data file, and/or a reference to a specific data file, that securely represents the cardholder's 12 primary account number (PAN), or other confidential wallet account information. Optionally, the token is usable only by a particular merchant 16 to obtain funds on the account of a particular linked cardholder 12. The token is thus a data security measure.

For the current transaction, the network operator 22 thus receives at 136 from the wallet holder 28 a authorization to generate a wallet token and typically, though not necessarily, retrieval URI to access the token 12. The network operator then generates a token 138 and optionally a URI to be shared with the merchant 16. The network operator 22 sends the checkout package 140 to the merchant 16. A checkout package will include a merchant token the merchant can use to access payment consistent with the scope of the token. The merchant can respond by presenting the checkout retrieval token to the network operator 22 at 142. The network operator 22 then issues to the merchant 16 a checkout retrieval URI, 144, which the merchant can access to conclude the checkout. The merchant will then access the checkout retrieval URI, 146. The cardholder makes their final review of the transaction, and places their order by indication to the merchant 16 at 152. The merchant will send a postback 154 of the completed transaction to the network operator 22.

Based on the consent to grant the merchant persistent access to the cardholder's wallet information, the network operator provides a long lived access token to the merchant. The merchant will map this token to their identified consumer to be used to request cardholder information for a future transaction.

According to a further embodiment of the present disclosure, the pairing between a particular cardholder's 12 electronic wallet and a particular merchant 16 may provide for varying scope of authority to the merchant 16. This is to say that the token generated by the network operator 22 may be used by a specific merchant 16 to obtain payment on subsequent unspecified transactions, rather than a specific transaction involved in the pairing, as compared with a token that is linked to a particular transaction, transaction amount, and/or short timeframe. In this way, a more permissive scope token can be used by a merchant 16 to enable purchases by the cardholder 12 by executing only a single mouse click, using their pre-selected electronic wallet with no further authentication required.

As a result of the foregoing process, in addition to completing the transaction contemplated between the cardholder 12 and the merchant 16, one of the cardholder's electronic wallet(s) will be associated, or paired, with a particular merchant 16, during the checkout of a transaction. Additionally, as depicted in FIG. 3, and described below, the cardholder 12 may pair their card with the merchant directly, outside the context of a pending transaction.

The foregoing description with respect to FIG. 2 presumed the pairing between wallet and merchant was formed during the checkout of a transaction in which the cardholder 12 chose to both use their electronic wallet for payment and also form the pairing between wallet and merchant. Referring now to FIG. 3, illustrated is illustrated is a communication flow, generally 200, for facilitating consumer use of their electronic wallet in remote electronic transactions by pairing the wallet with the merchant in as part of steps deliberately undertaken for that purpose, as compared to accomplishing the pairing during the course of a transaction checkout using the electronic wallet. In view of the similarities with the foregoing communication flow 100 described in FIG. 2, the present description will not include each and every detail already mentioned above.

The cardholder 12 will interact 202 with the merchant 16, for example via the merchant 16 website or the like. The merchant 16 will then, where possible, recognize 204 the cardholder 12. The cardholder 16 will initiate a request 206 to pair their electronic wallet with the merchant 16. The merchant 16 redirects the wallet selection request 208 to the network operator 22.

In response, the network operator may request information 210 of the cardholder 12 to verify their location, as described above. The cardholder 12 responds 212 with the requested information. The network operator 22 validates the cardholder's response 214 against known data, and presuming successful validation, displays 216 to the cardholder their electronic wallet or wallets available from which the cardholder 12 may choose. The cardholder 12 makes their selection of wallet 218 from among the available wallets presented 216 by the network operator 22. The network operator 22 at action 220 redirects the cardholder 12 selection of electronic wallet to the corresponding wallet holder 28.

The wallet partner displays a login page 222 to the cardholder 12, who responds by logging into their wallet 224. The wallet partner validates the login 226, and at 228 presents a page to the cardholder 12 requesting, inter alia, consent to share the consent to share the cardholder's 12 the electronic wallet particulars with the merchant 16. The wallet holder 28 will record the cardholder's consent 232, and issues a confirmation notification 234 to the cardholder 12, for example via e-mail. The wallet partner will authorize the network operator to generate a wallet token

The network operator 22 thus provides a wallet token to the wallet holder The network operators then generates a token 238 to be shared with the merchant 16 at 240. The merchant 16 maps the merchant token to the cardholder ID at 250, for use in future purchases.

Referring then to FIG. 4, illustrated is a communication flow, generally 300, for facilitating consumer use of their electronic wallet in remote electronic transactions where, as depicted in either FIG. 2 or FIG. 3, the cardholder 12 had already paired their electronic wallet credentials with the merchant 16. Notably, the communication flow 300 is characterized by a greatly reduced need for information from the cardholder 12.

The cardholder 12 will interact 302 with the merchant 16, for example via the merchant 16 website or the like. The merchant 16 will then, where possible, recognize 304 the cardholder 12. The merchant will also retrieve a previously received merchant token 304 that is mapped to the recognized cardholder 12 from a previous pairing. The merchant 16 presents the corresponding merchant token to the network operator 22 along with the requested data at 306. The requested data can only be the same or a subset of the data previously consented by the cardholder. The network operator 22 at 308 validates the merchant token, and resolves the merchant token to the corresponding wallet holder and wallet token 28. The network operator then at 310 presents the wallet token to wallet holder 28. At 312, the wallet holder 28 validates the wallet token, retrieves the scope of prior cardholder 21 authorization with respect to the merchant 16. The wallet holder 28 sends to the network operator 22 at 314 the requested data. This is received by the network operator at 316. Concurrently, the wallet holder 28 may issue a confirmation notification 334 to the cardholder 12, for example via e-mail, confirming that the merchant has accessed the cardholder's 12 electronic wallet in accordance with a prior consent.

The network operator 22 sends the requested data (i.e. pre-checkout data) 340 to the merchant 16. The merchant then can display to the cardholder 350 the provided data on the merchant site/app, including available card(s), address(es), loyalty programs, cardholder personal profile information, etc along with the cardholder's default preferences. The cardholder 12 makes their selection (or accepts a prior default selection) and places their order 352, and the merchant 16 then in turn requests the payment particulars 354 (e.g., PAN) from the network operator 22 for the card selected by the cardholder 12.

The network operator 22 will then provide the merchant 16 with the PAN for the selected payment card 349. The merchant uses the supplied PAN to obtain payment for the transaction. Alternately, the network operator 22 will then request the PAN of the selected payment card from the wallet holder and redirects the cardholder to the previously paired wallet holder. The wallet partner displays a login page 222 to the cardholder 12, who responds by logging into their wallet. The wallet holder will provide the network operator with the selected PAN and the network operator will then provide the merchant 16 with the selected PAN 349. The merchant uses the supplied PAN to obtain payment for the transaction. In either case, the merchant 16 may also send a verification to the wallet operator 21 upon consummation of the transaction. The merchant 16 may send a postback 354 of the completed transaction to the network operator 22 as well.

Referring now to FIG. 5, illustrated is a communication flow, generally 500, by which a cardholder 12 may unpair their electronic wallet from any merchant 16 with which they had previously consented to pairing. In this example, the cardholder 12 logs into their electronic wallet 501 directly with the wallet provider 21. The wallet provider 21, having validated the login, displays 503 to the cardholder 12 wallet information, including payment cards, addresses, profile information, default preferences selected, inter alia, and at least a list of any connected merchants. The cardholder 12 selects an option 505 to review connected merchants. The wallet holder 28 then displays 507 to the cardholder 12 their connected merchants. The interface provided to the cardholder 12 may also include an ability to deselect a merchant connection, for example depicted as a toggle switch, or any other suitable graphic interface means. In some embodiments of the present disclosure, the user is given the opportunity to review a connection history.

The cardholder, using the provided interface, may deselect a merchant connection 509 for one or more connected merchants. The wallet holder 28 may optionally prompt the cardholder 12 for confirmation, which the cardholder 12 may confirm 513. The wallet holder 28 records the cardholder's 12 confirmed selection at 515, and will disable any previously provided token pairing the cardholder's 12 electronic wallet with the merchant 16. The wallet partner will optionally send a confirmation 517, e.g., by email, to the cardholder to confirm the unpairing operation by a separate communication channel. The wallet holder 28 communicates the disabling of the prior issued the wallet token 519 to the network operator 22. The network operator receives this communication 521, and in turn disables any corresponding merchant token.

Thereafter, on a subsequent visit to the merchant 16 site by the cardholder 12, at 523, the cardholder may likewise recognize the cardholder 12 at 525. The merchant 16 communicates with the network operator 22 at 527 by submitting a previously issued merchant token corresponding to the cardholder 12. The network operator 22 will validate the merchant token at 529, recognizing the unpairing. The network operator will thus communicate the unpairing 531 to the merchant 16.

The foregoing figures have contemplated interaction and/or pairing between a cardholder's 12 digital wallet and a particular merchant 16 providing goods or services. In still a further embodiment of the present disclosure, the cardholder 12 may wish to pair their digital wallet with an app, website or the like provided by the wallet holder 28. In this scenario, the cardholder 12 may use the wallet services interface to perform so-called CRUD functions, i.e., Create, Read, Update and Delete, using the app. This makes the digital wallet more usable to the cardholder 12, and also to the digital wallet operator.

In most respects, the interaction of the wallet services app provided by wallet partner 28 will be largely similar to that of a merchant 16 as described in the foregoing embodiments and communications diagrams. One key difference being that the scope of the authority granted by the cardholder and encoded into a corresponding token with one of administrative functionality (i.e., CRUD) with the electronic wallet, as compared with incurring charges for purchase of goods or services. In this way, the pairing process between wallet and will be seen to most resemble that of FIG. 3, describes above, and the unpairing process will most resemble that of FIG. 5. On an ongoing basis, administrative action undertaken once paired will resemble the communications depicted in FIG. 4, with reduced interaction required of the cardholder 12.

It will be appreciated by those skilled in the art that the methods as described above may be operated by a machine operator having a suitable interface mechanism, and/or more typically in an automated manner, for example by operation of a network-enabled computer system including a processor executing a system of instructions stored on a machine-readable medium, RAM, hard disk drive, or the like. The instructions will cause the processor maintained by the network operator 22 to operate in accordance with the present disclosure.

Turning then to FIG. 6, illustrated schematically is a representative computer 616 of the system, generally 600. The computer 616 includes at least a processor or CPU 622 which is operative to act on a program of instructions stored on a computer-readable medium 624. Execution of the program of instruction causes the processor 622 to carry out, for example, the methods described above according to the various embodiments. It may further or alternately be the case that the processor 622 comprises application-specific circuitry including the operative capability to execute the prescribed operations integrated therein. The computer 616 will in many cases include a network interface 626 for communication with an external network 612. Optionally or additionally, a data entry device 628 (e.g., keyboard, mouse, trackball, pointer, etc.) facilitates human interaction with the server, as does an optional display 630. In other embodiments, the display 630 and data entry device 628 are integrated, for example a touch-screen display having a GUI.

Variants of the above-disclosed and other features and functions, or alternatives thereof, may be desirably combined into many other different systems or applications. Various presently unforeseen or unanticipated alternatives, modifications, variations, or improvements therein may be subsequently made by those skilled in the art which are also intended to be encompassed by the following claims.

Claims

1. A method of facilitating use of a digital electronic wallet by a cardholder for cashless transactions, the method comprising:

receiving a selection by a first cardholder to pair a first digital wallet held by a first wallet holder with a first merchant, the first digital wallet having therein wallet information including an electronic representation of at least one payment device usable to fund a cashless transaction;

facilitating a communication between the first cardholder and the first wallet holder to record consent by the first cardholder to wallet information with the first merchant;

generating a wallet token usable for accessing the wallet information from the first wallet holder for the first digital wallet as selected by the first cardholder;

preparing a merchant token corresponding to the received wallet token; and

providing the merchant token to the first merchant, to access the wallet information.

2. The method according to claim 1, wherein the wallet information further comprises at least one of a shipping address, a loyalty account identifier, merchant-specified personal preferences, cardholder personal profile information, and a scope of cardholder consent.

3. The method according to claim 1, further comprising:

receiving from the first wallet holder a request to disable the previously generated wallet token;

responsive to receipt from the first wallet holder of a disabling token, disabling a corresponding merchant token provided to the first merchant.

4. The method according to claim 1, further comprising:

receiving from the first merchant postback data concerning any cashless transaction concluded using the merchant token.

5. The method according to claim 1, further comprising:

verifying a cardholder a cardholder location.

6. A system for facilitating use of a digital electronic wallet by a cardholder for cashless transactions, the system comprising a network-enabled processor for communication among at least a first merchant and a first wallet holder, and a machine-readable recording medium storing thereon a program of instructions which, when executed by a processor, cause the processor to carry out a method comprising:

receiving a selection by a first cardholder to pair a first digital wallet held by a first wallet holder with a first merchant, the first digital wallet having therein wallet information including an electronic representation of at least one payment device usable to fund a cashless transaction;

facilitating a communication between the first cardholder and the first wallet holder to record consent by the first cardholder to share wallet information, including payment device information, with the first merchant;

generating a wallet token usable for accessing the wallet information from the first wallet holder for the first digital wallet as selected by the first cardholder;

preparing a merchant token corresponding to the received wallet token; and

providing the merchant token to the first merchant, to access the wallet information.

7. The system according to claim 6, wherein the wallet information further comprises at least one of a shipping address, a loyalty account identifier, merchant-specified personal preferences, cardholder personal profile information, and a scope of cardholder consent.

8. The system according to claim 6, wherein the method further comprises:

receiving from the first wallet holder a request to disable the previously generated wallet token;

responsive to receipt from the first wallet holder of a disabling token, disabling a corresponding merchant token provided to the first merchant.

9. The system according to claim 6, wherein the method further comprises:

receiving from the first merchant postback data concerning any cashless transaction concluded using the merchant token.

10. The system according to claim 6, wherein the method further comprises:

verifying a cardholder location.