WO2013166507A1 - Portefeuille électronique à plateformes multiples convergentes - Google Patents

Portefeuille électronique à plateformes multiples convergentes Download PDF

Info

Publication number
WO2013166507A1
WO2013166507A1 PCT/US2013/039753 US2013039753W WO2013166507A1 WO 2013166507 A1 WO2013166507 A1 WO 2013166507A1 US 2013039753 W US2013039753 W US 2013039753W WO 2013166507 A1 WO2013166507 A1 WO 2013166507A1
Authority
WO
WIPO (PCT)
Prior art keywords
wallet
consumer
wallets
digital
transaction
Prior art date
Application number
PCT/US2013/039753
Other languages
English (en)
Inventor
Mehmet PASA
Michael J. FRIEDMAN
Ngassam NGNOUMEN
Celine Martig
Shoshana C. ROSENFIELD
Rupa SUBRAMANIAN
Zavida MANGARU
John F. CACIOPPA
Scott Moser
Amyn DHALA
Original Assignee
Mastercard International Incorporated
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 US13/746,904 external-priority patent/US9799027B2/en
Application filed by Mastercard International Incorporated filed Critical Mastercard International Incorporated
Priority to CA2864747A priority Critical patent/CA2864747C/fr
Priority to EP13784810.7A priority patent/EP2815365A4/fr
Priority to AU2013256017A priority patent/AU2013256017B2/en
Publication of WO2013166507A1 publication Critical patent/WO2013166507A1/fr
Priority to HK15104948.8A priority patent/HK1204381A1/xx

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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/027—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] involving a payment switch or gateway
    • 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/22—Payment schemes or models
    • G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
    • 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/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices
    • 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user

Definitions

  • the present disclosure relates to electronic cashless transaction payments, and more particularly, to a system and method for enabling a consumer to have cross- platform access to a converged network of digital wallets.
  • the present invention provides a system for enabling a network of digital wallets which includes a common link to an acceptance network for authorizing a digital wallet purchase that allows multiple consumer interfaces via merchant landing pages and integration with various wallet providers.
  • the acceptance network is preferably accessed through an acceptance mark button on a graphical interface provided to consumers on merchant landing pages. Selection of the acceptance mark provides access to various digital wallet services and providers for initiating a purchase. Accordingly, multiple merchant web sites can be linked through a single digital wallet acceptance mark, which provides access to a switch through which a wallet of choice is accessed by the consumer for payment at a remote location or at point-of-sale.
  • the system to enable a network of digital wallets also provides the features and functionality required to decouple the acceptance network from each digital wallet consumer interface.
  • the present invention also provides a method for authorizing a digital wallet transaction initiated by a consumer from a merchant web site. The method provides for payment using one of a plurality of digital wallets in the acceptance network.
  • a method for authorizing a digital wallet transaction initiated by a consumer from a merchant web site or app includes providing an acceptance mark on a merchant landing page associated with the merchant web site or app for initiating the digital wallet transaction.
  • the acceptance mark comprises a link to a host server for accessing an acceptance network for authorizing payment.
  • the acceptance network comprises a plurality of digital wallets.
  • a digital wallet is selected and purchase details including a payment card and a shipping address are selected for the transaction.
  • An Access Token and a checkout resource URL associated with the digital wallet are generated by the host server, and the merchant web site or app sends the Access Token to the checkout URL to retrieve the purchase details for authorizing and completing the digital wallet transaction using the selected digital wallet.
  • a method for authorizing a digital wallet transaction initiated by a consumer from a merchant web site or app includes providing an acceptance mark on a merchant landing page associated with the merchant web site or app for initiating the digital wallet transaction, the acceptance mark comprising a link to a host server accessing an acceptance network for authorizing payment, the acceptance network comprising a plurality of digital wallets; routing the transaction to a digital wallet selected by the consumer from the plurality of digital wallets, the selected digital wallet capturing and validating the log-in credentials, the selected digital wallet capturing a payment card and a shipping address selected by the consumer for the digital wallet transaction; routing the transaction to the host server with purchase details including the payment card and the shipping address, the host server generating a postback merchant URL associated with the merchant web site or app, an Access Token and a checkout resource URL associated with the selected digital wallet for retrieving the purchase details; and redirecting the transaction back to the merchant web site or app using the postback merchant URL, the merchant web site or app sending the Access Token to the checkout resource URL
  • the selected digital wallet is a default wallet, the default wallet being selected prior to the consumer selecting the acceptance mark.
  • the method further comprises displaying an interstitial page associated with the default wallet in response to the consumer selecting the acceptance button.
  • Additional aspects of the method wherein the selected digital wallet is the default wallet can include the consumer establishing a default payment card and a default shipping address associated with the default digital wallet prior to selecting the acceptance mark, and providing an express checkout button associated with the default wallet, the default payment card and the default shipping address being captured for the transaction in response to the consumer selecting the express checkout button.
  • the default wallet corresponds to one of the plurality of digital wallets most recently accessed by the consumer.
  • the selected digital wallet is a partner-hosted wallet
  • the method further comprising storing the purchase details including the selected payment card and shipping address in a temporary store associated with the checkout URL on the host server, and purging the temporary store in response to the merchant web site or app retrieving the purchase details for authorizing the digital wallet transaction.
  • the method can further comprise associating a coupon or offer with each of the plurality of digital wallets and displaying the coupon or offer associated with one of the plurality of digital wallets displayed on the wallet selector switch.
  • the coupon or offer may be displayed, in one aspect, in response to the consumer hovering a pointer over the one of the plurality of digital wallets displayed.
  • Additional aspects of the method may include communicating the coupon or offer associated with the one of the plurality of digital wallets to the merchant web site or app prior to completing the digital wallet transaction, wherein the one of the plurality of digital wallets is the digital wallet selected from the plurality of digital wallets for the transaction.
  • Additional aspects of the method of the present disclosure can include associating a status with each of the plurality of digital wallets and displaying a graphical indicator of the status on the wallet selector switch.
  • the status can be associated with a capability to complete a pending transaction using the associated digital wallet, based on at least one of an amount of funds required for the transaction, a balance of available funds in the associated digital wallet, a class or merchant, a type of goods or service being transacted, an expiration of one or more card associated with the digital wallet, and whether a prior transaction using the digital wallet had failed.
  • the host server displays a shopping order confirmation page prior to redirecting the transaction back to the merchant web site or app.
  • the shopping order confirmation page includes the purchase details, the purchase details including shipping charges, taxes, and a surcharge rate and charge associated with the digital wallet selected.
  • the methods include dynamically updating the shopping order confirmation page in response to the consumer selecting a different one of the plurality of digital wallets for the digital wallet.
  • a history toggle can be provided on an interstitial page, the history toggle providing access to the historical purchase data of a recognized consumer of the network of wallets, the historical purchase data including data associated with each payment card registered to the consumer within the acceptance network.
  • the method includes returning a Request Token generated by the host server in response to the consumer selecting the acceptance mark, the host server generating a verifier associated with the Access Token, and the merchant web site or app capturing the checkout resource URL and the verifier after the transaction is redirected back to the merchant web site or app, the merchant web site or app using the Request Token and verifier to retrieve the Access Token from the host server for sending to the checkout resource URL and retrieving the purchase details.
  • the method can include displaying an interstitial page comprising a wallet selector switch and a wallet log-in menu in response to the consumer selecting the acceptance mark, the consumer entering log-in credentials in the wallet log-in menu associated with a digital wallet selected from the plurality of digital wallets for the transaction.
  • the selected digital wallet can be a federated co-branded wallet, the interstitial page being displayed and hosted by the host server, the interstitial page comprising a wallet log-in menu, wherein the log-in credentials entered by the consumer in the log-in menu are captured and validated by a partner server against a partner database, the method comprising framing the log-in menu in a widget for accessing the partner server.
  • These aspects can further include federating the captured log-in credentials to the selected wallet in response to the consumer being recognized by the partner server as an authorized user of another partner-hosted product.
  • aspects can include the partner server sending a SAML token and provisioning details of payment cards and shipping addresses associated with the consumer to the federated co-branded wallet displayed on the host server in response to validating the log-in credentials.
  • additional aspects can include the partner server automatically updating the details of the payment cards in the federated co-branded wallet associated with the consumer in response to the consumer selecting the federated co-branded wallet for the transaction, the details including consumer contact information, payment cards, and shipping addresses.
  • the method can include automatically creating a new digital wallet account associated with the federated co-branded wallet for the consumer using the captured log-in credentials.
  • a method is also provided for authorizing a digital wallet transaction initiated by a consumer from a merchant web site or app, the method including: providing an acceptance mark on a merchant landing page associated with the merchant web site or app for initiating the digital wallet transaction, the acceptance mark comprising a link to a host server accessing an acceptance network for authorizing payment, the acceptance network comprising a plurality of digital wallets, the plurality of digital wallets including a federated co-branded wallet; displaying an interstitial page in response to a consumer selecting the acceptance mark, wherein the consumer is a registered user of the acceptance network, the interstitial page displaying a wallet interface to the federated co-branded wallet, the wallet interface being hosted on the host server, the wallet interface comprising a wallet log-in menu framed
  • FIG. 1 is a block diagram representation of an embodiment of a system of the present disclosure for enabling a network of digital wallets.
  • FIG. 2 is a block diagram representation of an embodiment of a method for enabling a network of digital wallets.
  • FIG. 3A is a representation of an embodiment of a user log-in interface and switch for accessing the network of digital wallets in accordance with the present disclosure.
  • FIG. 3B is a representation of another embodiment of a user interface and another embodiment of a switch for displaying and accessing the digital wallets in accordance with the present disclosure.
  • FIG. 4A is a system flow representation of a checkout transaction with a partner-hosted wallet in accordance with an embodiment of a system and method of the present disclosure.
  • FIG. 4B is a sequence diagram for the method of FIG. 4A for completing a digital wallet transaction in accordance with the present disclosure.
  • FIG. 5A is a system flow representation of a checkout transaction with partner login and direct provisioning in accordance with another embodiment of a method of the present disclosure.
  • FIG. 5B is a sequence diagram for the method of FIG. 5A for completing a digital wallet transaction in accordance with the present disclosure.
  • FIG. 6 is a representation of a flow sequence on checkout with in-wallet dynamic update of shopping order details in accordance with an embodiment of a method of the present disclosure.
  • FIG. 7 is a representation of a flow sequence for real-time wallet creation in accordance with an embodiment of a method of the present disclosure.
  • Fig. 8 is a representation of the multiple consumer interface pathways to a converged electronic wallet.
  • a "digital wallet” is known in the art and can be used by a consumer associated with the digital wallet for making an electronic transaction.
  • the digital wallet has a data or information component associated with the consumer and transaction data, including payment methods, shipping addresses, billing address and other information.
  • the information component is associated with a consumer interface for the consumer accessing the digital wallet to input necessary information for the transaction.
  • the digital wallet is also associated with a software or services component for authorizing and completing the electronic transaction, including security and encryption for the customer's personal information and for the actual electronic transaction.
  • the system and method of the present disclosure provide the functionality and services required to connect multiple consumer interfaces to a single acceptance network for payment which supports a plurality of digital wallets.
  • NFC Near Field Communication
  • smartphones mobile applications for web- enabled smartphones
  • remote on-line systems for traditional electronic commerce.
  • certain mobile electronic devices are provisioned with NFC capability, allowing them to function and substitute for existing IC based technology provided in certain payment card devices (e.g., EMV or the like).
  • consumer interface platforms include a mobile-device enabled system disclosed in the commonly assigned U.S. Provisional Patent Application Serial No. 61/711,901 (Applicant Reference No. P00927-US-PROV; Attorney Docket No.
  • the aforementioned application discloses a payment system styled as "PoW3", and concerns a method of mobile-device based e-commerce (or “m- commerce”).
  • the merchant will present a scanable code (e.g., bar code, QR code or the like) or otherwise interact with the user's mobile device (via e.g., Wi-Fi, Bluetooth, SMS, without limitation).
  • This transaction event (code scan, communication, etc.) will trigger the user's mobile device to establish a connection with a payment gateway.
  • the payment gateway will synchronize the contents of the transaction with the user's mobile device, and provide access to the user's electronic wallet for payment. From their mobile device, the user may select a wallet and/or payment device to fund the transaction, or in some cases, a default wallet or payment device will have been previously selected.
  • the present disclosure converges the various consumer interface platforms, in this case merging the functions of both remote and NFC payment, among other interface platforms, giving the purchaser access to a single electronic wallet for online E-commerce and a variety of mCommerce scenarios, some including brick and mortar, face-to-face (F2F), and/or point-of-sale (POS) transaction payments.
  • the network of wallets has a network operator intermediating payment transactions between merchants and wallet providers.
  • Wallet providers represented generally reflect a co-branded or 'white label' wallet 80, a hero wallet 70, that is one operated by the same entity operating the network of wallets, or a partner-hosted wallet 60 operated by a partner participating in the federated network of wallets.
  • the parallel consumer interface platforms such as remote platform enabling e- commerce payments, an NFC platform, and/or others, into a single converged payment platform that is usable in either or both transaction settings.
  • the plurality of digital wallets can include any digital wallet suitable for remote or on-line purchases, including those digital wallets offered as a mobile app, particularly, a mobile phone app.
  • An "app” is used herein as that term is known, to refer to an application for a mobile device.
  • An app, or mobile app is a software application designed to run on, for example, smartphones, tablet computers, and other mobile devices.
  • a merchant page or merchant landing page is a consumer-facing graphical interface accessed from a merchant web site, or app.
  • the acceptance network is preferably accessed by a consumer by selecting an acceptance mark provided on the merchant page.
  • a partner is a bank, retailer, or other third-party seeking to integrate its proprietary wallet solution into the acceptance network of digital wallets, providing its users with access to the network of wallets services.
  • a Request Token is used as that term is known in the art and is a request for authorized access to a service using, for example, an industry standard security OAuth, which allows third party web sites to share user data without requiring additional credentials.
  • OAuth industry standard security
  • the network of digital wallets preferably uses this method for securing transactions to and from the host network of wallets' services. Additional tokens are used, such as an Access Token, to provide a location or URL (Uniform Resource Locator) from which data can be accessed, and a Verifier Token, to verify a party requesting access to data.
  • OpenAPI is an industry standard for enabling services to be easily shared across third party providers.
  • the digital wallets preferably use this standard to interconnect the host network of wallets services with partner services.
  • the various services and applications referred to herein are executable programs running on a host (network of digital wallets or "NoW") server, and/or on a partner server, as indicated, according to the type of digital wallet.
  • NoW network of digital wallets
  • the flow of a method for completing a purchase initiated from a merchant page, from a merchant web site or app, is directed by the hosted program code to switch between wallets and to direct the flow between a merchant and a digital wallet for completing a purchase.
  • a processing device associated with the merchant web site or app executes the back- end services required to interact with the host server and digital wallets to complete the purchase and authorize a transaction with the digital wallet.
  • the corresponding method steps for completing a purchase are preferably stored in memory associated with the host server and with the particular digital wallet, and executed by a processing device.
  • cardholder shipping and other details necessary to complete a transaction are stored in a database associated with a partner server hosting a partner wallet, or in a database associated with the host server.
  • an embodiment of a system to enable a network of digital wallets 10 includes a host ("Now") server 15 with secure databases 16 for storing cardholder, card and shipping data associated with various wallets offered within the network of digital wallets.
  • the server 15 includes services for facilitating and monitoring connectivity between merchants 20 and an acceptance network 25 for authorizing a purchase.
  • the acceptance network includes a plurality of digital wallets.
  • Services and resources offered from the host server 15 to wallet providers and merchants participating in the network of wallets preferably include application programming interfaces (API's) for shared services for integrating wallet providers and merchants into the network of wallets, standards for consumer authentication, and the availability of, and ability to select from, multiple consumer interfaces, depending on the type of digital wallet a wallet provider (partner) chooses to offer.
  • API's application programming interfaces
  • the services, applications, and executable programming steps for performing the methods of the present disclosure are preferably stored in memory 18 associated with the host server 15 and executed by a processing device 19.
  • digital wallet options include a partner-hosted (“partner") wallet 60, which maintains all consumer details and purchase data and consumer log-in credentials in the partner's own secure database 62 and is hosted by a partner server 64 providing the partner wallet web site 60.
  • Additional options include a hero/retail wallet 70 hosted on the NoW server 15, which maintains all consumer details, purchase data, and consumer login credentials in the host's databases 16, and variations of a white-label wallet 80, having a mix of control shared between the partner and host.
  • the white-label wallets can include a federated and non-federated white-label wallet, embodiments of which are described further herein.
  • an icon or acceptance mark 100 is preferably provided as a link on a merchant landing page 110 to a switch 125 for routing the consumer to any digital wallet in the acceptance network 25.
  • the purchaser selects the icon or acceptance mark 100 representing the network of wallets displayed on a merchant's shopping cart landing page 110.
  • the purchaser is brought to an interstitial landing page 120 to facilitate interaction with the network of wallets.
  • the interstitial page 120 includes a wallet selector 125 for switching between the wallets available to the purchaser.
  • the switch capability is provided by selection of the appropriate tab displaying the desired wallet.
  • Each tab of the wallet selector is associated with a hyperlink to a particular URL associated with the digital wallet, so that selection of a particular tab displays the associated digital wallet landing page.
  • the consumer selects one of the wallets and the payment process proceeds along one of the paths 85, in accordance with the type of digital wallet selected.
  • the different types of digital wallets can include hero/retail NoW-hosted wallets 70; federated or non-federated co- branded or white- label wallets 80; and partner-hosted wallets 60.
  • the consumer is an unrecognized user.
  • An unrecognized user includes a consumer who logs in for the first time, not yet registered with the network of wallets.
  • An unrecognized user also includes a consumer who has cleared cookies previously stored on the user' s device to allow identification.
  • the unrecognized user upon selection of the acceptance button 100, is directed to an embodiment of the interstitial landing page 120 which allows the unrecognized user to create a wallet, and/or to select a wallet for payment.
  • the page is hosted by the network of wallets host server. It also includes a wallet selector 125 for selecting and signing in to different wallets.
  • an option for creating a hero wallet account 105 is also provided so that a new account can be created by a first time user of NoW directly through a menu 105 on the landing page 120.
  • selecting the acceptance mark 100 automatically routes the payment process through the switch to a default digital wallet web site, displaying the default digital wallet to the consumer.
  • the default wallet can be, for example, the last wallet the consumer used, or one pre- selected as the default by the consumer.
  • a consumer is referred to as a recognized user of the network of wallets, if recognized, for example, by a cookie or a fingerprint or MAC address of the machine from which they are browsing, and is further recognized by the network of wallets as having login credentials associated with one of the digital wallets in the network of wallets.
  • the interstitial landing page that is displayed with an open wallet regardless of whether it is a default or user-selected wallet, will preferably still include the digital wallet selector 125, along with the wallet branding and sign-in menu for the user's default or user-selected wallet. Accordingly, an option to access (or create) alternate (or additional) digital wallets remains available to the consumer until completion of the checkout and purchase process.
  • the interstitial landing page 120 can offer a consumer a selection of his or her country of residence. Depending on the country selected, a different menu of digital wallets available to the consumer can be displayed.
  • the tabulated menu shown in FIGS. 2 and 3 A is one non-limiting embodiment of a wallet selector of the present invention.
  • a wallet selector of the present invention can be any number of variations of wallet selectors for accessing one of the digital wallets available in the network, including a revolving pane design and a daisy wheel.
  • the wallet selector can additionally include functionality to allow a consumer to compare different advantages of the various wallets prior to completing the purchase and checkout process.
  • various embodiments of the switch 125 can include displaying information such as specific offers or coupons associated with each wallet choice in the switch 125.
  • a coupon or offer is displayed to the purchaser, for example, as a pop-up, when a pointer is hovered over the associated wallet.
  • These offers or coupons can be communicated to the merchant upon selection of the wallet, and are applied during the checkout process.
  • a daisy wheel 122 is used to display all wallet options available to a particular user after selection of the acceptance mark 100.
  • a last-used wallet prong 124 of the daisy wheel (assuming a recognized purchaser), or other preferred wallet prong, can be highlighted, for example, by displaying the prong more prominently than the other available wallets.
  • An "additional wallets" prong 126 can provide a link to an additional wallet selector showing more digital wallets.
  • hovering a pointer over any one of the prongs highlights that selection, and can simultaneously display the interstitial page 120 for a particular digital wallet, in addition to various coupons and offers associated with a purchaser's use of that wallet for the purchase. Incentives to create a digital wallet to unrecognized users of that particular digital wallet can likewise be displayed.
  • the purchaser may choose from among the available digital wallets, which can include a Hero wallet 70, a wallet operated and maintained by the provider or host 15 of the network of wallets, in this example, by assignee MasterCard®.
  • the digital wallets can also include a white-label or co-branded wallet 80 that is maintained and operated by the provider or host 15 of the network of wallets, but which carries the branding of a partner entity in the network of wallets.
  • the purchaser may also choose a partner wallet 60, one which is maintained and operated by a partner entity.
  • the consumer enters login credentials on the selected wallet page, which can be hosted on the network-of- wallets host server or on the selected partner server.
  • the interstitial landing page 120 captures the login credentials for a consumer, for example, a User ID, such as an email address, along with an associated password.
  • the payment process continues by validating the log-in credentials of the purchaser and encrypting the fields with a key issued by the wallet owner of the selected digital wallet to insure the login credential integrity. This process will differ depending on the type of wallet selected.
  • the host validates against its own database 230, while for a partner-hosted wallet 60, the partner validates 240 against its own database.
  • the login credentials can be validated against the partner's database 240, or against the host database, where the host database maintains the partner's customer database.
  • a payment card and shipping address selection page 255 is displayed so that the consumer can choose a payment method.
  • the choice of wallet will determine from which database the page 255 will be retrieved, e.g., from a partner database or from a host (NoW) database, and how this page is presented to the consumer.
  • a co-branded wallet 80 is hosted by the network of wallets
  • the validation and shipping selection information is preferably aggregated and transmitted to the merchant through application programming interfaces (API's) 260 integrated on the merchant web site.
  • API's application programming interfaces
  • the merchant retrieves the consumer data provided and displays an order confirmation page to the consumer 270.
  • the system and method to enable a network of digital wallets of the present disclosure is a token mediation driven process connecting a merchant network 20 to a network of digital wallet providers 25.
  • a system flow diagram of a checkout transaction is provided in FIG. 4A using a partner-hosted wallet 60 in a network of digital wallets hosted by MASTERCARD® under its PAYPASSTM trademark, and a hero (“PayPass") wallet 402 provided by the network of wallets host ( "PayPass” services).
  • a corresponding sequence diagram is provided in FIG. 4B.
  • the partner maintains all control and responsibility for maintaining consumer login details and validation, storing consumer login and account management data and other consumer data in its own secure database.
  • the partner designs and hosts the partner wallet web site landing pages.
  • a Checkout Initialization defines what happens when the user chooses to make a payment with a particular wallet, in this case, one that is partner hosted.
  • the Checkout Authorization process continues after the user selects the card and shipping options and is ready to complete the checkout. It is invoked, in this case, by the partner-hosted wallet to authorize the merchant to access consumer's checkout data, and is hosted by the network of wallets' host
  • the Address Verification Service can be used at various times to determine if a given merchant provides shipping to a given set of locations.
  • a merchant landing page is displayed which includes an acceptance mark 100 (in this example, PAYPASSTM).
  • the consumer selects the acceptance button 310 to access the network of wallets service.
  • Programming applications running on a processing device in the back-end (server) 290 of the merchant web site or app retrieve a checkout identifier, consumer key and developer private key from local storage 320.
  • the consumer key and developer private key are sent to the host (PAYPASSTM) server 300 hosting the network of wallets service to get a Request Token and Authorize Wallet URL 330 from an open API.
  • the Request Token and Authorize Wallet URL are generated and returned 340 to the merchant 290 and forwarded to the merchant web site along with various merchant data, such as the merchant's accepted card types, International Shipping Boolean, and a Checkout Identifier 350, for redirecting the consumer to an interstitial landing page 355 for sign-in to the network of wallets and wallet selection.
  • the interstitial landing page which includes a sign-in menu for capturing login credentials and a wallet selector, is preferably displayed 360 with the merchant's branding from a network-of-wallets hosted (PAYPASSTM) checkout site 362.
  • the fields on the login page for capturing credentials are preferably encrypted with a key issued by the wallet owner.
  • the wallet selector includes those digital wallets that are available in the network of wallets and accepted by the merchant.
  • the consumer selects a partner wallet 364 from the wallet selector, the consumer is directed to a partner site which hosts and maintains the partner digital wallet.
  • the PayPass Wallet Services 300 executes a Checkout Initialization transaction with the partner hosted wallet selected 366 to start the sign in process.
  • the partner wallet presents an interface to the user for logging in 368, selecting a payment method 370 and a shipping address (if applicable) 372 and confirming the order 374.
  • An Address Verification Service (see FIG. 4B) 332 is invoked during the Checkout Initialization, either before or after selecting the shipping address 372, to confirm that the Merchant is willing to ship to each shipping address listed (or selected).
  • the user wallet and payment credential experience is controlled by the partner for a partner- hosted wallet. The consumer can review the order 374 before selecting an
  • “AuthorizeOrder” option 334 for example, to initiate the Checkout Authorization process to continue with the checkout.
  • the partner site sends the flow back to the PayPass Wallet Services 300 for executing the Checkout Authorization transaction through an open API, passing in the Request Token, payment method, shipping address and details, and preferably a transaction ID 334.
  • the Request Token is authenticated, and the payment method selected and any details of the purchase including shipping address, consumer contact information, and merchantID from the consumer's digital wallet are passed from the partner site to the PayPass server 300, where it is stored in a temporary store or database, referred to herein as "Temp Store,” as a unique record in a relational database object.
  • the Temp Store database preferably stores all checkout details from the partner wallet for that consumer required to complete the purchase, including a payment method, shipping address, contact, a network of wallets' provider ID, and a merchant ID, for example.
  • the PayPass server 300 generates a network of wallets (PayPass) Checkout Resource URL and verifier for obtaining an Access Token in order to retrieve the information temporarily persisted or stored in the Temp Store, and a Merchant Postback URL 378, the site to which the browser or app will redirect control back to the merchant and passes the URL and verifier back to the merchant using the Merchant Postback URL 380.
  • PaymentPass a network of wallets
  • the process continues by directing flow back to the Merchant from the partner wallet using the Merchant Postback URL 380 provided by the PayPass server 300.
  • control is passed back to the merchant web site, which captures the Checkout Resource URL and verifier 382, and uses the Request Token and verifier together to obtain the Access Token from the PayPass server 384.
  • the PayPass server generates and returns the Access Token 386 to the merchant 290 (for the purpose of obtaining access to the payment details), which then sends the Access Token to the partner-hosted Checkout Resource URL to retrieve the payment method and details, including shipping address, from the Temp Store 388.
  • the data is retrieved from Temp Store 390 and a response with details from Temp Store is returned to the merchant 392 and used in the submission of a financial payment transaction from the merchant.
  • Temp Store is purged either when it expires (assuming it was not retrieved) within minutes, or immediately after the data is accessed by the merchant.
  • the merchant 285 can then display an order confirmation page 394. At this point, control is back to the merchant and any desired additional checkout options can be presented to the consumer prior to submitting the transaction details to a payment gateway 396 for finalizing and confirming completion of the purchase 398.
  • FIG. 4A also shows the flow of a transaction initiated after a purchaser selects 400 a wallet, which is a hero or host wallet (PayPass Wallet), from the wallet selector.
  • a wallet which is a hero or host wallet (PayPass Wallet)
  • the Request Token is authenticated, as it was for the partner wallet, the authentication service binding the Request Token to the transaction 406 and generating and returning the Verifier to the applicable wallet 408, in this case, to the hero wallet 402.
  • a Checkout Resource URL is generated 412 and the Checkout Resource URL and Verifier to the applicable (hero) wallet are returned to the merchant using a postback Merchant URL.
  • partner wallets in the network of wallets are possible offering varying levels of control by the partner and various integration points into the acceptance network of wallets, referred to as co-branded wallets.
  • co-branded wallets For example, a non- federated co-branded "White Label" option allows the partner wallet to be hosted, controlled, and maintained by the host (MASTERCARD® or PAYPASSTM) server. The consumer selects and logs into the partner wallet site, which is hyperlinked to the PayPass-hosted White Label partner wallet. All consumer data and login credentials are preferably bulk-uploaded and stored in secure containers maintained by the host for the partner or provisioned to the cloud. The partner provides a bulk upload of consumer and card data to the PayPass database, or provisions the cloud for use in the network of wallets.
  • the process flow including the Checkout Initialization and Checkout Authorization, to complete a purchase order through the network of wallets acceptance button on a merchant page is essentially a clone of the hero wallet shown in FIG. 4A.
  • Control never leaves the host, except that the partner wallet's brand is displayed in the wallet selector landing page and subsequent landing pages after selection of the co-branded partner wallet.
  • the partner creates the "skin" with its brand for the landing pages, including login and shipping pages, and provides the skins to the host which can be stored in a partner container in the host database.
  • the co-branded landing page is displayed to the consumer after selection of the co- branded partner wallet, and while hosted on the PayPass server, appears to the consumer to be a partner hosted wallet.
  • the login credentials and card are validated by the PayPass server and the partner is responsible for providing updates.
  • another co-branded digital wallet option available to partners in the network of wallets is a federated, skinned White Label partner wallet that uses partner login credentials by framing the login and password prompts in a widget for accessing the wallet owner (partner) site, while the interstitial landing page 120 is a user interface hosted by the network of wallets host.
  • the consumer's login credentials 123 are captured and validated by the partner and are federated to the network of wallets. No wallet creation and setup is required if the customer's login credentials already exist for one of the wallet owner cards.
  • the consumer interacts with the White Label wallet without requiring an additional login sequence.
  • the partner supplies the user experience and functionality to support authentication and password recovery within their own hosted web/mobile property. All other data and services are hosted by the network of wallets.
  • a customer when ready to initiate a purchase on a merchant site, a customer selects the acceptance button and is directed to the federated White Label wallet via the selector interstitial page.
  • the consumer logs in to the partner wallet site from the landing page and login access and validation is handled at the partner site.
  • the credentials are then passed to the host network of wallets service in a single login seamless to the customer.
  • the federated single sign-on capability is preferably provided by SAML integration of the partner with the network of wallets host services.
  • the partner controls access to their White Label Wallet and passes federated credentials via SAML 2.0, for example, to PayPass online hosting services for access.
  • the partner sends a SAML token to the host network of wallets services, and a security assertion data logs the customer into the network of wallets.
  • the token contains customer data attributes to setup the wallet and to insert cards into the wallet automatically.
  • This digital wallet option also allows direct partner provisioning.
  • the partner feeds existing consumer data dynamically into a wallet.
  • This data includes profile information, payment cards and addresses.
  • the data is encrypted, supplied as an extension to the SAML token exchange and refreshed with each consumer login.
  • FIG. 5A depicts the flow of the checkout process when the consumer is leveraging a federated White Label Partner wallet with partner login credentials.
  • the browser will remember the last wallet selected, minimizing the number of steps in the consumer sign-in process.
  • the consumer will be presented with a NoW (PayPass) hosted page listing of wallet providers allowing the consumer to select a wallet and sign-in.
  • the partner provides and maintains the consumer experience and services to authenticate the consumer, in turn providing assertion of identity for the consumer to NoW.
  • the partner also provides consumer cardholder and profile data for the purposes of registering and refreshing a consumer's data, and captures email addresses and mobile telephone numbers for cardholders, which are passed to the network of wallets server to create a wallet account for the user.
  • the wallet is displayed for log-in 432 and the consumer enters sign-on credentials (login and password) 434 through the partner-hosted widget for capture of login credentials directly by a partner identity provider 436.
  • the partner authenticates the user 442 and if a new wallet is being created (the user has not yet opted in to the co-branded wallet 440), requires the user to accept terms and conditions 444, and creates SAML assertion and, optionally, secure attributes 446, and passes the SAML assertion to the network of wallets' co-branded wallet services.
  • the NoW validates the SAML assertion 448 and determines if the consumer identity exists in the NoW 450.
  • the consumer data is provisioned from the partner and updated to the NoW before proceeding. If a profile of the consumer does not exist (not a previously registered user), a new consumer profile and identity is created 454, and additional details as required to complete a purchase, such as payment method and shipping address, are requested and entered by the consumer 456 before redirecting flow to the merchant 458 to complete the checkout process.
  • an express checkout option is available to a consumer after opting to make a purchase through the network of wallets, which avoids the extra step of selecting a shipping address in addition to a payment card.
  • This express checkout option is also applicable to other digital wallet options, not only those provided within a network of wallets.
  • a consumer registers for at least one of the digital wallets available in the network of wallets, and establishes a default card and shipping address. The consumer selects an acceptance mark 100 available from a merchant page (e.g., PAYPASSTM) to access the network of wallets after a consumer places their items in a merchant's shopping cart. Because a consumer has previously established and accessed a wallet, the consumer is brought to the default wallet page.
  • Recognition can be through cookies or device
  • the username is pre- populated and the default wallet is highlighted and receives hero placement. If the consumer opts to use a different wallet, other wallet options can be chosen from a wallet selector provided on the wallet page.
  • the consumer enters his/her password and selects an Express Checkout Button, so that the consumer is not brought to a card and shipping address page. Instead, the consumer's default card and address are automatically used and the consumer is not required to review them.
  • the consumer is brought back to the merchant page, which displays the card and address details that were passed directly to the merchant via an API.
  • an interstitial page is provided by the selected (default) wallet for confirming the details of the credit card, which is preferably referred to by a previously established nickname or by the last 4 digits of the card. The consumer clicks on a button to confirm the order and details and is then brought back to the merchant page.
  • Various additional embodiments of the system and method of the present disclosure are directed to in- wallet checkout enhancements available before control is redirected back to the merchant web page.
  • a consumer logs in to a wallet or credit card from a merchant's checkout page.
  • the wallet stores credit card and the associated billing address and shipping addresses, which can be used to populate address fields.
  • the consumer logs into the wallet, and selects a credit card and shipping address.
  • a shipping option selection and order review which includes shipping and tax charges, is only available to the consumer after leaving the wallet services pages, including shipping and card information, and arriving on the merchant site. No transaction history or spend tracking is available.
  • services are provided to enable a digital wallet to dynamically update the shopping order total with particular details, such as surcharge, shipping cost and tax.
  • Such selections can be offered within the wallet interface, based on consumer selection of the credit card and shipping address. Additional details such as shipping options and costs associated therewith can also be provided.
  • such details can be displayed dynamically when a consumer uses a mouse to hover over a particular wallet available in the network of wallets. Or, as shown in FIG. 6, the details can be displayed and updated dynamically in a frame 560 with each combination of card and shipping details entered 570. Accordingly, the consumer is made aware of the charges that apply to the purchase within a particular wallet and can exercise several choices before placing the order 580 and exiting the wallet services. Such choices include which card to use based on which has a lower surcharge, or which location to ship to, based on shipping charges, or which shipping option to choose based on need and cost.
  • This enhancement of the user's checkout experience provides a capability not currently available to consumers in choosing a particular credit card to use in a sales transaction.
  • surcharge is a charge imposed by merchants for accepting credit cards which is then passed on to the consumers. Merchants have the ability to set these rates on credit cards, some of which carry higher rates.
  • the proposed enhancement allows the wallet service to dynamically display the surcharge rate and charge associated with the card the consumer has selected, so that the consumer can make a choice within the wallet service of selecting a different card with a lower surcharge.
  • the information is aggregated and transmitted to the merchant through application programming interfaces (API's) 590.
  • the merchant retrieves the consumer data provided and displays an order confirmation page 575 to the consumer.
  • a history of a consumer' s spending using a particular wallet can also be provided, so that the consumer does not have to look at multiple statements from multiple payment cards to track one's spending.
  • the 'History' section of the wallet preferably includes stored details of purchases made with each payment card within the network of wallets, and tracks purchases made. Such details can include date, merchant, card used, and shipping address.
  • FIG. 7 is a schematic representation of a real-time interstitial electronic wallet creation process, depicted using a mobile phone-based payment/authentication system.
  • FIG. 7 illustrated is an exemplary process by which a credentialed user may create an electronic wallet in real time.
  • the purchaser has selected certain goods or services to be purchased from a participating merchant, and arrives at either a checkout page or a shopping cart page, represented at 1020.
  • the purchaser is offered the option or opportunity to complete the purchase using the network of wallets which is represented by an icon 1040.
  • the network of wallets is operated under the name "PayPass Online”, PAYPASS being a trademark of MasterCard International Incorporated, the assignee of the instant application.
  • the purchaser is presented with an interstitial page 2020 which prompts the purchaser to select the provider of their chosen wallet from among the partners participating in the network of wallets and displayed at 2040, including optional page select function 2060 or equivalent (rotating panes, daisy- wheel, etc., as described elsewhere herein).
  • a partner wallet provider for example ABC Bank.
  • selection may be highlighted among the display of partners 2040, and/or optionally displayed again, as at 2070.
  • the purchaser is further prompted to enter a login username and password credentials 2080 associated with their selected partner wallet provider.
  • the case contemplated here is applicable to only a subset of all purchasers. Namely, the purchaser will have previously established identity credentials (e.g., login ID and password) with the partner provider they select at 2040. The purchaser can therefore be verified by the respective partner, but does not have an established electronic wallet with a particular partner. It may be the case that a purchaser has established demand deposit account (DDA, e.g., checking or savings) with the banking institution that includes online banking service, and a login/password pair to access them, but does not have an established electronic wallet with that partner.
  • DDA demand deposit account
  • That purchaser may simply be unaware of the wallet service offered by the banking partner, and may have clicked/selected the network of wallets checkout icon 1040 inadvertently, or out of curiosity.
  • the banking partner may selectively offer electronic wallet services to less than all of their customers, as an incentive or service enhancement.
  • the subset of purchasers to whom the present method is applicable is still narrower, as determined by their eligibility to create an electronic wallet with the selected partner banking institution.
  • the purchaser is presented with the opportunity to establish a wallet with the partner immediately, which the purchaser may accept or decline at 3040.
  • a purchaser who is authenticated using their established credentials with the banking partner, but is ineligible to create an electronic wallet with that partner for whatever reason, and/or declines to create an electronic wallet, may be returned to either the network of wallets interstitial login screen 2020, for example to select another wallet provider, or alternately to the merchant checkout page 1020.
  • the purchaser's wallet details are pre-populated based upon information known to the partner about the purchaser associated with the existing credentials and presented to the purchaser for verification 4020.
  • the wallet details include the relevant payment card numbers 4040, a billing address associated with the payment card 4060, and a shipping address 4080 where goods may be delivered. The purchaser must then confirm the pre-populated details 4100 to proceed with the transaction.
  • the necessary transaction details e.g., card number details, billing and shipping addresses, etc.
  • the merchant contemporaneously transmitted the necessary transaction details, e.g., card number details, billing and shipping addresses, etc. to the merchant, which are again presented to the purchaser from the merchant's page 5020.
  • the purchaser then has only to confirm the order by selecting the corresponding option at 5040.
  • the purchaser will then have established a partner wallet in the federated network of wallets.
  • their existing wallet may be recognized.
  • the purchaser may consent to a software cookie to be stored on the purchaser's system, which can be used to auto-identify the purchaser, at least in part.
  • a software cookie to be stored on the purchaser's system, which can be used to auto-identify the purchaser, at least in part.
  • their existing wallet may be recognized, and that wallet provider pre-selected.
  • the purchaser then has only to enter the appropriate username and password, thereby streamlining the checkout process.
  • the need to create a new wallet with respect to that same partner as described herein is obviated.
  • FIG. 8 illustrated is a representation of the multiple consumer interface pathways to a converged electronic wallet.
  • a consumer may use an internet pathway via, as example only personal computer 802 or mobile device 804 to establish and manage their one or more consumer wallet accounts.
  • Interaction between personal computer 802 or mobile device 804 on the one hand and a NoW cloud database 806 is via proprietary web services interface.
  • the consumer securely enters and verifies payment data via this web-based user interface A.
  • a registration user interface displayed on the consumer's mobile device 804 can be optimized for mobile screen form factor.
  • a third party wallet provider 808 can automate creation of consumer wallet account, for example via systematic provisioning of consumer payment data via secure, proprietary web services interface (G).
  • Interface (B) enables secure provision of consumer payment data to a merchant 814a, 814b, with whom the consumer is transacting.
  • the NoW checkout user interface as displayed on consumer mobile device 812 may be optimized for mobile screen form factor.
  • NoW cloud database 806 maintains consumer wallet profile centrally for hosted wallets (i.e., 70, 80), and/or serves as the gateway to partner-hosted wallets 60. Each connected device has access to central consumer wallet profile and the same group of electronic wallets regardless of the interface platform, ensuring consistent access to payment data across all enabled consumer devices.
  • a provisioning system 818 securely stores payment device data into local storage on consumer mobile phone 818 via a secure
  • Provisioning occurs either "over the air” or via direct connect to consumer (or other) computer.
  • the consumer initiates "tap-to-pay" mobile NFC transaction by bringing their mobile device 818 in proximity with an NFC-enabled POS terminal 820.
  • the consumer uses their mobile device 818 to choose payment details, or will have previously selected a default setting. In certain cases, including without limitation certain high-value transactions, the consumer may be asked to verify their identity, e.g., by PIN or the like.
  • the mobile device 818 securely transmits payment details to POS terminal 820 via contactless payment protocol. If other data is required to complete the purchase transaction (e.g., shipping address, loyalty account, promotional offer, etc.), the consumer mobile phone 820 acquires this data from cloud database 806 via proprietary web services interface (C), prior to transmission to POS 820 via contactless payment protocol.
  • C proprietary web services interface
  • Still another consumer interface pathway enables remote or F2F transactions via NoW.
  • a provisioning system 822 securely stores payment device data into local storage on consumer mobile phone 824 via secure provisioning interface (F). Provisioning occurs either "over the air", or via direct connect to consumer (or other) device.
  • a consumer initiates payment in this case by engaging in a "trigger event" 826.
  • a Trigger event may include, without limitation, QR read via phone camera, barcode read via phone camera, display QR/bar code on phone screen, Wi-Fi, Bluetooth, among others.
  • An app provided on a consumer mobile device 824 may be used to initiate payment interface with merchant, authenticates the consumer identity, and transmit payment data to merchant.
  • the consumer mobile device 824 acquires data required to complete the purchase (e.g., shipping address, loyalty account, promotional offer, etc. from the NoW cloud database 806 via proprietary web services interface (E) prior to transmission to the merchant via secure, proprietary interface.
  • E proprietary web services interface
  • Still another consumer interface platform can be implemented by the merchant choosing to provide a native, "in app” checkout experience for mCommerce transactions.
  • this interface platform the entire payment user experience is controlled by a merchant app on the user mobile device 828.
  • the merchant app acquires consumer payment data from the NoW server 806 securely via secure, proprietary web services interface (H).
  • An optional additional feature of the user interface for access to the Network of Wallets and/or the wallet selector page is what can be referred to as a "health check" of available wallets.
  • an electronic wallet may be provided with one or more debit or credit accounts, and/or one or more pre-paid cards or accounts.
  • a debit or credit account may be limited in balance by the available account balance in a demand deposit account associated with a given debit card, the available credit limit of a credit account associated with a given credit card. Additionally, the balance on a given pre-paid card or account may be limited or exhausted.
  • a listing or other graphic or textural device indicating a choice of wallets may include information regarding the state of health for a given wallet. For example, reference may be made to the amount of the merchant transaction that precipitated the network of wallets login, as compared to available balance in the wallet. Other limiting factors besides available balance that would prevent a transaction from being completed may be the class of merchant with regard to restriction placed upon one or more payment sources stored in a given electronic wallet, effective reducing the available balance for that transaction. In other cases, the card or cards associated with a given wallet may be expired. In still others, a prior attempt to transact on a particular wallet may have failed for unknown reasons.
  • the health check information may be conveyed, for example, by selecting an order of listing available wallets. More specifically, any that do not have the capacity to complete a transaction may be ordered lower in the selection listing than another available wallet having ability to complete the transaction.
  • a graphical representation such as the switch, flip (rotating pane) or daisy wheel described herein elsewhere (and without limitation to those graphical devices)
  • an 'unhealthy' wallet with reference to the instant transaction may be positioned less conveniently than others, may be showing in a different shade or color (e.g., gray tone), or may simply be hidden altogether. Some combination of indications may be used as well.
  • the user may identified by cookies placed on the user's access device from a prior use of an electronic wallet associated with the network of wallets.
  • the state of health of a wallet may be indicated even before the user logs into the network, and may aid the user in selecting a wallet partner via which they choose to login.
  • the user experience be enhanced by including an identifiable link or graphic icon which the user may associate with the network of wallets, even or especially while interacting with one of the federated partners in the network of wallets.
  • the link or graphic icon which we will refer to as a "pin" is preferably small and unobtrusive, yet visible and
  • the pin may, for example, expand when hovered upon by a user- selection device (e.g., mouse pointer). Such hovering over and/or selection of the pin by a user will transfer the user from the partner site to the network of wallets site, for example to select a different wallet or wallet provider. Alternately or additionally, the user may be presented with a selection of partner wallets to transfer directly to.
  • a user- selection device e.g., mouse pointer
  • An additional feature which may be integrated into the network of wallets checkout experience is a shopping cart.
  • the network of wallets as described herein can be entered from the merchant's checkout page, for example, via a clickable icon.
  • Data concerning the pending transaction (seller, description, quantity, price, terms, etc.) are passed to network operator in the course of processing the checkout transaction.
  • this information may be made available to the user during the course of their interactions with the network of wallets (e.g., login, wallet selection, etc.).
  • the shopping cart is integrated with the pin described above. Hovering over the pin initiates an expansion of the pin graphic into a selection of data or alternate destinations for the user.
  • Among these may include the shopping cart, showing a precis of pertinent data to the pending transaction (e.g., seller, description, quantity, price, terms, etc.). Furthermore, it may be convenient to permit the user to select the shopping cart, or items in it, and be returned to the merchant site to append or change the transaction.
  • a precis of pertinent data to the pending transaction e.g., seller, description, quantity, price, terms, etc.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Finance (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • User Interface Of Digital Computer (AREA)

Abstract

Selon l'invention, diverses plateformes d'interface consommateur sont mises en convergence afin de faciliter un accès d'un utilisateur à un réseau de portefeuilles électroniques. Les fonctions de paiement à distance et NFC (communication en champ proche), parmi d'autres plateformes d'interface, donnent à l'acheteur accès à un unique portefeuille électronique pour du commerce électronique en ligne et divers scénarios de commerce mobile, certains comprenant des paiements de transaction physique (« briques et mortier »), face à face (F2F) et/ou par point de vente (POS). Le réseau de portefeuilles comprend un opérateur de réseau servant d'intermédiaire de transactions de paiement entre des marchands et des fournisseurs de portefeuille. De cette manière, les plateformes d'interface consommateur parallèles, telles qu'une plateforme à distance permettant des paiements de commerce électronique, une plateforme NFC et/ou d'autres plateformes, sont mises en convergence en une seule plateforme de paiement convergente qui est utilisable dans l'une ou l'autre des configurations de transaction ou toutes.
PCT/US2013/039753 2012-05-04 2013-05-06 Portefeuille électronique à plateformes multiples convergentes WO2013166507A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CA2864747A CA2864747C (fr) 2012-05-04 2013-05-06 Portefeuille electronique a plateformes multiples convergentes
EP13784810.7A EP2815365A4 (fr) 2012-05-04 2013-05-06 Portefeuille électronique à plateformes multiples convergentes
AU2013256017A AU2013256017B2 (en) 2012-05-04 2013-05-06 Converged cross-platform electronic wallet
HK15104948.8A HK1204381A1 (en) 2012-05-04 2015-05-26 Converged crossplatform electronic wallet

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
US201261642799P 2012-05-04 2012-05-04
US201261642925P 2012-05-04 2012-05-04
US201261642792P 2012-05-04 2012-05-04
US201261642729P 2012-05-04 2012-05-04
US61/642,729 2012-05-04
US61/642,925 2012-05-04
US61/642,792 2012-05-04
US61/642,799 2012-05-04
US13/746,904 US9799027B2 (en) 2012-01-19 2013-01-22 System and method to enable a network of digital wallets
US13/746,904 2013-01-22

Publications (1)

Publication Number Publication Date
WO2013166507A1 true WO2013166507A1 (fr) 2013-11-07

Family

ID=49514947

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2013/039753 WO2013166507A1 (fr) 2012-05-04 2013-05-06 Portefeuille électronique à plateformes multiples convergentes

Country Status (5)

Country Link
EP (1) EP2815365A4 (fr)
AU (1) AU2013256017B2 (fr)
CA (1) CA2864747C (fr)
HK (1) HK1204381A1 (fr)
WO (1) WO2013166507A1 (fr)

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103761655A (zh) * 2014-01-07 2014-04-30 张诗悦 一种基于近场通信技术的转让方法、防伪装置和防伪系统
US9355391B2 (en) 2010-12-17 2016-05-31 Google Inc. Digital wallet
CN107278313A (zh) * 2015-02-27 2017-10-20 三星电子株式会社 支付手段操作支持方法和用于支持该方法的电子设备
EP3262584A4 (fr) * 2016-02-04 2018-01-03 Samsung Electronics Co., Ltd. Dispositif électronique fournissant une fonction de paiement électronique et son procédé de fonctionnement
US10650374B1 (en) 2015-10-22 2020-05-12 Amdocs Development Limited System, method, and computer program for implementing high performance digital wallets
WO2021062165A1 (fr) * 2019-09-27 2021-04-01 Openedge Payments Llc Systèmes et procédés de transactions uniformes inter-plateformes
US11107047B2 (en) 2015-02-27 2021-08-31 Samsung Electronics Co., Ltd. Electronic device providing electronic payment function and operating method thereof
US20210334783A1 (en) * 2017-12-21 2021-10-28 Paypal, Inc. Systems and methods employing a router for electronic transactions
US11182769B2 (en) 2015-02-12 2021-11-23 Samsung Electronics Co., Ltd. Payment processing method and electronic device supporting the same
US11443316B2 (en) * 2013-10-14 2022-09-13 Equifax Inc. Providing identification information to mobile commerce applications
US11449630B2 (en) 2017-12-14 2022-09-20 Equifax Inc. Embedded third-party application programming interface to prevent transmission of sensitive data
US11463450B2 (en) 2017-04-13 2022-10-04 Equifax Inc. Location-based detection of unauthorized use of interactive computing environment functions
US20230112305A1 (en) * 2021-10-08 2023-04-13 Comcast Cable Communications, Llc Diverse pathway integration
US20230162188A1 (en) * 2021-11-01 2023-05-25 Pyxelchain Technology Corporation Blockchain transaction approval using offline private encryption keys
US11966887B1 (en) * 2022-10-27 2024-04-23 Chime Financial, Inc. Bridging network transaction platforms to unify cross-platform transfers
US12052155B2 (en) 2022-12-14 2024-07-30 Comcast Cable Communications, Llc Methods, apparatuses, and systems for network accessibility

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108256846A (zh) * 2016-12-28 2018-07-06 航天信息股份有限公司 一种集成支付的方法及系统
US12026457B2 (en) * 2022-11-07 2024-07-02 Microsoft Technology Licensing, Llc Utilizing dynamic interface elements to improve user interfaces

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020042776A1 (en) * 2000-09-19 2002-04-11 Woo Kevin K.M. System and method for unifying electronic payment mechanisms
JP2002109435A (ja) * 2000-09-28 2002-04-12 Japan Total Design Communication Co Ltd 決済プログラムおよび決済システム
KR100846460B1 (ko) * 2007-02-02 2008-07-16 주식회사 퍼스트포켓 통합전자지갑 서비스를 제공하는 방법 및 서버
JP2009230626A (ja) * 2008-03-25 2009-10-08 Nec Computertechno Ltd 電子マネーの付加サービス情報提供装置及び電子マネー決済端末装置
US20100211501A1 (en) * 2009-02-13 2010-08-19 Toshiba Tec Kabushiki Kaisha Electronic settlement apparatus ans control method for the apparatus

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7505941B2 (en) * 1999-08-31 2009-03-17 American Express Travel Related Services Company, Inc. Methods and apparatus for conducting electronic transactions using biometrics
TR200201280T2 (tr) * 1999-08-31 2002-08-21 American Express Travel Related Services Company, Inc. Elektronik işlemler yürütmek için yöntemler ve cihazlar.
US20090048887A1 (en) * 1999-11-05 2009-02-19 American Express Travel Related Services Company, Inc. Systems and Methods for Facilitating Transactions Involving an Intermediary
US7966259B1 (en) * 1999-12-09 2011-06-21 Amazon.Com, Inc. System and methods for facilitating transactions on, and personalizing web pages of, third party web sites
WO2001061659A1 (fr) * 2000-02-16 2001-08-23 Mastercard International Incorporated Systeme et procede de conduite d'une transaction electronique avec un serveur portefeuille distant
GB2364482B (en) * 2000-06-30 2002-10-09 Motorola Inc Server-based electronic wallet system
JP5348711B2 (ja) * 2000-07-11 2013-11-20 ペイパル， インコーポレイテッド サードパーティ支払い処理のシステムおよび方法
US20020128977A1 (en) * 2000-09-12 2002-09-12 Anant Nambiar Microchip-enabled online transaction system
US7337144B1 (en) * 2000-09-28 2008-02-26 Microsoft Corporation Method and system for restricting the usage of payment accounts
US7784684B2 (en) * 2002-08-08 2010-08-31 Fujitsu Limited Wireless computer wallet for physical point of sale (POS) transactions
US20040143550A1 (en) * 2002-12-19 2004-07-22 International Business Machines Corporation Cellular electronic wallet device and method
US9147210B2 (en) * 2009-07-29 2015-09-29 Paypal, Inc. System and a machine-readable medium for processing an on-line payment without authenticating the user

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020042776A1 (en) * 2000-09-19 2002-04-11 Woo Kevin K.M. System and method for unifying electronic payment mechanisms
JP2002109435A (ja) * 2000-09-28 2002-04-12 Japan Total Design Communication Co Ltd 決済プログラムおよび決済システム
KR100846460B1 (ko) * 2007-02-02 2008-07-16 주식회사 퍼스트포켓 통합전자지갑 서비스를 제공하는 방법 및 서버
JP2009230626A (ja) * 2008-03-25 2009-10-08 Nec Computertechno Ltd 電子マネーの付加サービス情報提供装置及び電子マネー決済端末装置
US20100211501A1 (en) * 2009-02-13 2010-08-19 Toshiba Tec Kabushiki Kaisha Electronic settlement apparatus ans control method for the apparatus

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2815365A4 *

Cited By (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11507944B2 (en) 2010-12-17 2022-11-22 Google Llc Digital wallet
US9355391B2 (en) 2010-12-17 2016-05-31 Google Inc. Digital wallet
US9691055B2 (en) 2010-12-17 2017-06-27 Google Inc. Digital wallet
US11443316B2 (en) * 2013-10-14 2022-09-13 Equifax Inc. Providing identification information to mobile commerce applications
CN103761655B (zh) * 2014-01-07 2017-12-19 张诗悦 一种基于近场通信技术的转让方法、防伪装置和防伪系统
CN103761655A (zh) * 2014-01-07 2014-04-30 张诗悦 一种基于近场通信技术的转让方法、防伪装置和防伪系统
US11182769B2 (en) 2015-02-12 2021-11-23 Samsung Electronics Co., Ltd. Payment processing method and electronic device supporting the same
CN107278313A (zh) * 2015-02-27 2017-10-20 三星电子株式会社 支付手段操作支持方法和用于支持该方法的电子设备
US11107047B2 (en) 2015-02-27 2021-08-31 Samsung Electronics Co., Ltd. Electronic device providing electronic payment function and operating method thereof
US11129018B2 (en) 2015-02-27 2021-09-21 Samsung Electronics Co., Ltd. Payment means operation supporting method and electronic device for supporting the same
US20170337542A1 (en) * 2015-02-27 2017-11-23 Samsung Electronics Co., Ltd. Payment means operation supporting method and electronic device for supporting the same
CN107278313B (zh) * 2015-02-27 2022-06-24 三星电子株式会社 支付手段操作支持方法和用于支持该方法的电子设备
US10650374B1 (en) 2015-10-22 2020-05-12 Amdocs Development Limited System, method, and computer program for implementing high performance digital wallets
EP3262584A4 (fr) * 2016-02-04 2018-01-03 Samsung Electronics Co., Ltd. Dispositif électronique fournissant une fonction de paiement électronique et son procédé de fonctionnement
US11463450B2 (en) 2017-04-13 2022-10-04 Equifax Inc. Location-based detection of unauthorized use of interactive computing environment functions
US11449630B2 (en) 2017-12-14 2022-09-20 Equifax Inc. Embedded third-party application programming interface to prevent transmission of sensitive data
US20210334783A1 (en) * 2017-12-21 2021-10-28 Paypal, Inc. Systems and methods employing a router for electronic transactions
US11681999B2 (en) * 2017-12-21 2023-06-20 Paypal, Inc. Systems and methods employing a router for electronic transactions
US20230351363A1 (en) * 2017-12-21 2023-11-02 Paypal, Inc. Systems and methods employing a router for electronic transactions
WO2021062165A1 (fr) * 2019-09-27 2021-04-01 Openedge Payments Llc Systèmes et procédés de transactions uniformes inter-plateformes
US20230112305A1 (en) * 2021-10-08 2023-04-13 Comcast Cable Communications, Llc Diverse pathway integration
US20230162188A1 (en) * 2021-11-01 2023-05-25 Pyxelchain Technology Corporation Blockchain transaction approval using offline private encryption keys
US11966887B1 (en) * 2022-10-27 2024-04-23 Chime Financial, Inc. Bridging network transaction platforms to unify cross-platform transfers
US12052155B2 (en) 2022-12-14 2024-07-30 Comcast Cable Communications, Llc Methods, apparatuses, and systems for network accessibility

Also Published As

Publication number Publication date
AU2013256017B2 (en) 2016-05-05
HK1204381A1 (en) 2015-11-13
EP2815365A1 (fr) 2014-12-24
EP2815365A4 (fr) 2015-11-18
AU2013256017A1 (en) 2014-09-04
CA2864747A1 (fr) 2013-11-07
CA2864747C (fr) 2017-08-29

Similar Documents

Publication Publication Date Title
US9799027B2 (en) System and method to enable a network of digital wallets
AU2013256017B2 (en) Converged cross-platform electronic wallet
US20130254115A1 (en) Converged cross-platform electronic wallet
US20220058619A1 (en) Electronic wallet apparatus, method, and computer program product
US20200250648A1 (en) Systems and methods for facilitating bill payment functionality in mobile commerce
CN108141368B (zh) 即时令牌发行系统
US20170116596A1 (en) Mobile Communication Device with Proximity Based Communication Circuitry
US8762210B2 (en) Alternative payment implementation for electronic retailers
US20140081783A1 (en) Push Payment Processor
US20130346302A1 (en) Remote Portal Bill Payment Platform Apparatuses, Methods and Systems
US20170344981A1 (en) Increasing Efficiency of Transaction Network
US20130159087A1 (en) Method and system for enabling use of loyalty program points as form of payment
JP6159840B1 (ja) 決済認証システム、方法、及びプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13784810

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2864747

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2013784810

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2013256017

Country of ref document: AU

Date of ref document: 20130506

Kind code of ref document: A

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112014022325

Country of ref document: BR

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 112014022325

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20140909