HK1214670B - Electronic wallet apparatus, method, and computer program product - Google Patents

Description

Electronic wallet device, method and computer program product

Cross-reference to related applications

This application is a non-provisional application of and claims the benefit of U.S. Provisional Patent Application No. 61/722,294, filed by David Pardo et al., entitled “ELECTRONIC WALLET APPARATUS, METHOD, AND COMPUTER PROGRAM PRODUCT,” filed on May 11, 2012. The entire disclosure of the aforementioned U.S. Provisional Patent Application No. 61/722,294 is expressly incorporated herein by reference in its entirety for all purposes.

Technical Field

The present invention relates generally to electronic commerce and, more particularly, to electronic payment systems.

Background Art

With the growth of Internet commerce, electronic wallets (e-wallets) (also known as digital wallets) have been developed. E-wallets provide consumers with a secure and convenient way to pay for purchases made from accepted online merchants. After registration, consumers can store their card, billing, and shipping information on a site hosted by an appropriate entity and access that information to conveniently and securely make payments across multiple participating merchants.

Summary of the Invention

The principles of the present invention provide techniques for electronic wallet devices, methods, and computer program products. An exemplary embodiment of a method according to one aspect of the present invention includes obtaining registration information for a plurality of consumers at an electronic wallet platform; providing a mechanism for integrating the electronic wallet platform with a plurality of merchants; and, via the electronic wallet platform, providing a given one of the consumers with the option to select from a plurality of methods for paying for transactions with a given one of the merchants. The plurality of methods is based at least in part on the registration information. At least one of the plurality of methods includes a virtual card number. Further steps include obtaining a selection of a virtual card number from the given one of the consumers for payment of the transaction; and providing the virtual card number to the given one of the merchants.

In another aspect, another exemplary method includes: obtaining registration information for a plurality of consumers at an electronic wallet platform; and making available to the consumers a secure application for their portable devices, the secure application offering the consumers the option of selecting from a plurality of methods for paying for transactions with merchants. The plurality of methods is based at least in part on the registration information. At least one of the plurality of methods includes a virtual card number. Another step includes intercepting an authorization request from a given merchant to credit an amount of the given person in the transaction to an expense of the given person in the virtual card number. The given person in the transaction includes the given person in the consumer presenting the given person in a portable device (having the secure application thereon) at a point-of-sale terminal of the given merchant. The virtual card number has been provided to the merchant by communication between the given person in the portable device and the point-of-sale terminal of the given merchant. Another step includes: translating the given person in the virtual card number so as not to provide the given person in the merchant with an actual card number; and transmitting the authorization request to an issuing entity, wherein the actual card number is included in the authorization request.

In another aspect, another exemplary method includes: obtaining, at an e-wallet server, product information in conjunction with an online shopping session between a consumer and an e-commerce retailer; dispatching, from the e-wallet server, delivery option information destined for the consumer, thereby providing at least two options for delivering an item associated with the product information from the e-commerce retailer to the consumer; and obtaining, at the e-wallet server, in conjunction with the online shopping session, an indication of a desired delivery form from the e-commerce retailer to the consumer, the indication being based on the delivery option information.

In yet another aspect, another exemplary method includes obtaining, via an electronic wallet platform, transaction data regarding a transaction between a consumer and a merchant for providing at least one of goods and services. The electronic wallet platform has at least first and second funding sources available. Another step includes assigning, from the electronic wallet platform, based on the transaction data, a first transaction cost scheme based on usage of the first of the funding sources and a second transaction cost scheme based on usage of the second of the funding sources. The first and second cost schemes are destined for the consumer. Another step includes obtaining, from the electronic wallet platform, a selection of the at least first and second funding sources based on the first and second cost schemes; and providing the merchant with an account associated with the selected funding source.

In yet another aspect, another exemplary method includes: obtaining, via an e-wallet mobile application, transaction data regarding a transaction between a consumer and a merchant for providing at least one of goods and services. The e-wallet mobile application has at least first and second funding sources available. Further steps include: determining, via the e-wallet mobile application, based on the transaction data, a first transaction cost scheme based on usage of a first of the funding sources and a second transaction cost scheme based on usage of a second of the funding sources; obtaining, via the e-wallet mobile application, a selection of the at least first and second funding sources based on the first and second cost schemes from the consumer; and providing the merchant with an account number associated with the selected funding source.

In yet another aspect, an exemplary wallet platform server device includes: a memory; and at least one processor coupled to the memory. The at least one processor is operable to: obtain registration information for a plurality of consumers; integrate with a plurality of merchants; and provide a given one of the consumers with an option to select from a plurality of methods for paying for a transaction with the given one of the merchants. The plurality of methods is based at least in part on the registration information. At least one of the plurality of methods includes a virtual card number. The at least one processor is operable to obtain, from the given one of the consumers, a selection of the virtual card number for payment for the transaction; and provide the virtual card number to the given one of the merchants.

Aspects of the present invention contemplate the performance of the methods described herein by one or more entities, as well as the facilitation of one or more method steps by the same or different entities. As used herein, "facilitating" an action encompasses performing the action, making the action easier, assisting in performing the action, or causing the action to be performed. Thus, by way of example and not limitation, instructions executed on one processor may facilitate an action performed by instructions executed on a remote processor by sending appropriate data or commands to cause or assist the action to be performed. For the avoidance of doubt, where an actor facilitates an action by a means other than performing the action, the action is still performed by some entity or combination of entities.

One or more embodiments of the present invention or its elements may be implemented in the form of a computer program product comprising a tangible computer-readable recordable storage medium, wherein computer-usable program code for performing the indicated method steps is stored in a non-transitory manner on the tangible computer-readable recordable storage medium. In addition, one or more embodiments of the present invention or its elements may be implemented in the form of a system (or device) comprising a memory and at least one processor, the processor being coupled to the memory and operable to perform the exemplary method steps. For example, when executed on one or more processors, the computer-readable program code creates platform 5497. In yet another aspect, one or more embodiments of the present invention or its elements may be implemented in the form of a component for implementing one or more of the method steps described herein; the component may include: (i) a dedicated hardware module; (ii) a software module that is stored in a non-transitory manner on a tangible computer-readable recordable storage medium (or multiple such media) and is executable on a hardware processor; (iii) or a combination of (i) and (ii); any of (i) to (iii) implements the specific techniques set forth herein. The component is defined to exclude the transmission medium itself or the intangible signal itself.

One or more embodiments of the present invention may provide a number of beneficial technical effects, for example, the beneficial technical effects include

● Create a process flow where delivery is provided between merchants and logistics providers

● Create one or more shipping features in the merchant account that allow merchants to select their preferred shipping options

● Create comparison functionality within the transaction flow that allows the consumer’s data to be compared with the merchant’s preferences

● Allowing small or medium-sized merchants to more accurately determine volume data about products to be shipped, thereby allowing, for example, more accurate estimates of shipping times and/or costs

Reduce the time and potential for error when determining which payment instrument offers the most favorable terms for a given transaction

• Allows for enhanced security of virtual card numbers while allowing consumers to gain the benefits of offers, discounts, and the like associated with real card numbers.

These and other features and advantages of the present invention will become apparent from the following detailed description of illustrative embodiments of the invention, which is to be read in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 shows a general example of a payment system, which is an exemplary context in which one or more embodiments of the present invention may be implemented;

FIG2 depicts an exemplary interrelationship between: (i) a payment network configured to facilitate transactions between multiple issuers and multiple acquirers; (ii) multiple users; (iii) multiple merchants; (iv) multiple acquirers; and (v) multiple issuers;

FIG3 is a schematic representation of a mobile phone based payment/authentication system according to aspects of the present invention;

FIG4 is a block diagram of a “smart” phone or tablet computer configured in accordance with aspects of the present invention;

FIG5 is a diagram of an exemplary software architecture;

FIG6 is a flow diagram illustrating an authentication system in which features of a merchant plug-in (MPI) and an access control server (ACS) are incorporated into a wallet server;

FIG7 is a block diagram of an exemplary system;

FIG8 is a block diagram of an exemplary computer system useful in one or more embodiments of the present invention;

FIG9 depicts an exemplary transaction using a prepaid card at an international merchant;

FIG10 depicts an exemplary transaction using a local funds card at an international merchant;

11 to 18 show exemplary screenshots of a payment process according to the prior art;

19-24 show exemplary screenshots of a payment process according to aspects of the present invention, wherein the e-wallet utilizes a virtual card number;

FIG25 is a data flow diagram of the process of FIG19 to 24;

26 to 31 show exemplary screenshots of a payment process according to the prior art;

32 through 39 show exemplary screen shots of a payment process according to aspects of the present invention, wherein the e-wallet utilizes a virtual card number;

40 to 46 show exemplary screenshots of cross-border online shopping according to the prior art;

47-51 show exemplary screenshots of cross-border online shopping according to aspects of the present invention;

FIG52 is a flow chart comparing the process of FIG40 to FIG46 and FIG47 to FIG51;

FIG53 is a data flow diagram of the process of FIG47 to 51; and

FIG54 is another exemplary software architecture diagram.

DETAILED DESCRIPTION

Attention should now be directed to FIG. 1 , which depicts an exemplary embodiment of a system 100 according to aspects of the present invention and includes various possible components of the system. In this aspect, one or more embodiments of the present invention relate to an operator of a payment network, for example, an entity such as MasterCard International Incorporated (which is the operator of the network) or Visa International Service Association (which is the operator of the network), among others. This should be kept in mind in conjunction with the description of FIG. 1 and FIG. 2 . It should be noted that some aspects of the present invention are directed to cardless Internet commerce, while other embodiments of the present invention relate to presenting (e.g., via near-field communication (NFC)) a payment device (e.g., a suitably configured "smart" cell phone) at a merchant's point-of-sale terminal.

System 100 may include one or more portable payment devices of different types. For example, one such device may be a contact device, such as card 102. Card 102 may include an integrated circuit (IC) chip 104 having a processor portion 106 and a memory portion 108. A plurality of electrical contacts 110 may be provided for communication purposes. In addition to or as an alternative to card 102, system 100 may also be designed to operate with a contactless device, such as card 112. Card 112 may include an IC chip 114 having a processor portion 116 and a memory portion 118. An antenna 120 may be provided for contactless communication, for example, using radio frequency (RF) electromagnetic waves. An oscillator or oscillators and/or additional appropriate circuitry for one or more of modulation, demodulation, down-conversion, and the like may be provided. Note that cards 102 and 112 are exemplary of various devices that may be used. The system itself may function with other types of devices, such as a conventional card 150 having a magnetic stripe 152, instead of or in addition to "smart" or "chip" cards 102, 112. Furthermore, in some cases, appropriately configured cellular telephone handsets, personal digital assistants (PDAs), and the like may be used to effectuate contactless payments.

ICs 104 and 114 may contain processing units 106 and 116 and memory units 108 and 118. Preferably, ICs 104 and 114 may also include one or more of control logic, timers, and input/output ports. Such components are well known in the field of IC technology and are therefore not separately described. One or both ICs 104 and 114 may also include a coprocessor, which is also well known and not separately described. The control logic may provide the necessary control to handle communications between memory units 108 and 118 and the input/output ports in conjunction with the processing units 106 and 116. The timers may provide timing reference signals from the processing units 106 and 116 and the control logic. The coprocessor may provide the ability to perform complex calculations (e.g., those required by encryption algorithms) in real time.

The memory portion or unit 108, 118 may include different types of memory, such as volatile memory, non-volatile memory, read-only memory, and programmable memory. The memory unit may store transaction card data (e.g., a user's primary account number ("PAN") and/or personal identification number ("PIN")). The memory portion or unit 108, 118 may store the operating system of the card 102, 112. The operating system loads and executes application programs and provides file management or other basic card services to the application programs. One operating system that may be used is an operating system licensed by MAOSCO Limited (MAOSCO Limited, St. Andrews House, The Links, Kelvin Close, Birchwood, Warrington, WA3 7PB, United Kingdom). Alternatively, a Java Card ^™ -based operating system based on Java Card ^™ technology (licensed by Sun Microsystems, Inc. (4150 Network Circle, Santa Clara, CA 95054, USA) or a proprietary operating system available from a number of vendors may be used. Preferably, the operating system is stored in read-only memory ("ROM") within memory portions 108, 118. Alternatively, flash memory or other non-volatile and/or volatile types of memory may be used in memory units 108, 118.

In addition to the basic services provided by the operating system, memory portions 108, 118 may also include one or more applications. Currently, one possible specification that such applications may conform to is the EMV Interoperable Payment Specification set forth by EMVCo, LLC (901 Metro Center Boulevard, Mailstop M3-3D, Foster City, CA 94404, USA). It will be appreciated that the applications may be configured in a variety of different ways.

As mentioned, cards 102, 112 are examples of various payment devices that can be used. The primary function of the payment device may not be payment; for example, the payment device may be a cell phone handset implementing aspects of the present invention. Such devices may include cards with conventional form factors, smaller or larger cards, cards with different shapes, key fobs, personal digital assistants (PDAs), appropriately configured cell phone handsets, or virtually any device capable of implementing aspects of the present invention. In some cases, the card or other payment device may include a body portion (e.g., the laminated plastic layer of a payment card, the cover or housing of a PDA or cell phone, a chip package, and the like), memory 108, 118 associated with the body portion, and a processor 106, 116 associated with the body portion and coupled to the memory. The memory 108, 118 may contain appropriate application programs. The processor 106, 116 is operable to facilitate the execution of one or more method steps. For example, the application may be an application identifier (AID) associated with software code plus data in the form of firmware in card memory, such as Electrically Erasable Programmable Read-Only Memory (EEPROM).

Many different types of terminals can be used with system 100. Such terminals may include: a contact terminal 122, configured to interface with a contact-type device 102; a wireless terminal 124, configured to interface with a wireless device 112; a magnetic stripe terminal 125, configured to interface with a magnetic stripe device 150; or a combination terminal 126. Combination terminal 126 is designed to interface with any type of device 102, 112, 150. Some terminals may be contact terminals with a plug-in contactless reader. Combination terminal 126 may include memory 128, a processor portion 130, a reader module 132, and (optionally) an item interface module (e.g., a barcode scanner 134 and/or a radio frequency identification (RFID) tag reader 136). Items 128, 132, 134, 136 may be coupled to processor 130. Note that the construction principles of terminal 126 are applicable to other types of terminals and are described in detail for illustrative purposes. The reader module 132 can generally be configured for contact communication with the card or device 102, contactless communication with the card or device 112, reading the magnetic stripe 152, or any combination of two or more of the above (different types of readers can be provided to interact with different types of cards (e.g., contact, magnetic stripe, or contactless cards)). The terminals 122, 124, 125, 126 can be connected to one or more processing centers 140, 142, 144 via a computer network 138. For example, the network 138 can include the Internet or a private network (e.g., a virtual private network (VPN), such as described below with respect to FIG. 2). More than one network can be used to connect the different elements of the system. For example, a local area network (LAN) can connect the terminal to a local server or another computer at a retail facility. The payment network can connect acquirers and issuers. Further details regarding a specific form of payment network will be provided below. For example, the processing centers 140, 142, 144 can include a host computer of the issuer of the payment device.

Many different retail or other facilities, represented by points of sale 146, 148, may be connected to network 138. Different types of portable payment devices, terminals, or other elements or components may be combined or "mixed and matched" with one or more features depicted on the exemplary device in FIG1. Likewise, some aspects of the present invention are directed to cardless Internet commerce, while other embodiments of the present invention involve presenting (e.g., via near field communication (NFC)) a payment device (e.g., a suitably configured "smart" cell phone) at a merchant's point of sale terminal.

A portable payment device can facilitate transactions conducted by a user using a terminal (e.g., 122, 124, 125, 126) of a system (e.g., system 100). This device may include a processor, such as processing units 106 and 116 discussed above. The device may also include a memory coupled to the processor, such as memory portions 108 and 118 discussed above. Furthermore, the device may include a communication module coupled to the processor and configured to interface with a terminal (e.g., one of terminals 122, 124, 125, 126). For example, the communication module may include contacts 110 or antenna 120 and appropriate circuitry (e.g., the oscillator or oscillators and associated circuitry mentioned above) to allow for contact-based or wireless communication with the terminal. The device's processor is operable to perform one or more of the steps described herein. The processor may perform such operations via hardware techniques and/or under the influence of program instructions (e.g., an application stored in one of the memory units).

The portable device may include a body portion, which may be, for example, a laminated plastic body in the case of a "smart" or "chip" card 102, 112 (as discussed above) or a handset chassis and body in the case of a cellular phone.

It will be understood that terminals 122, 124, 125, and 126 are examples of terminal devices for interacting with a user's payment device. The device may include a processor (e.g., processor 130); a memory (e.g., memory 128) coupled to the processor; and a communication module (e.g., 132) coupled to the processor and configured to interface with portable devices 102, 112, and 1420 (discussed below). Processor 130 is operable to communicate with the user's portable payment device via communication module 132. The terminal device may function via hardware technology in processor 130 or through program instructions stored in memory 128. This logic may optionally be provided from a central location (e.g., processor center 140) via network 138. The barcode scanner 134 and/or RFID tag reader 136 mentioned above may be provided and coupled to the processor to collect attribute data (e.g., product identification) from UPC codes or RFID tags on products to be purchased.

The devices 102, 112 described above may be contact cards or devices compliant with ISO 7816 or NFC (near field communication) or proximity cards or devices compliant with ISO 14443. In operation, the card 112 may be touched or tapped on the terminal 124 or 126 (or an associated reader), which then transmits electronic data in a contactless manner to a proximity IC chip in the card 112 or other wireless device.

One or more of the processing centers 140 , 142 , 144 may include a database, such as a data warehouse 154 .

Sometimes a dual-interface device 1302 is used. Device 1302 is shown larger than devices 101 and 112 for ease of illustration, but may have a similar form factor. Device 1302 includes an IC chip 1304 having a processor portion 1306 and a memory portion 1308. A plurality of electrical contacts 1310 (similar to contacts 110) and an antenna 1320 (similar to antenna 120) may be provided, as well as an oscillator or oscillators and/or additional appropriate circuitry for one or more of modulation, demodulation, downconversion, and the like, as described with respect to device 112. Appropriate firmware may be provided for managing the two available interfaces, with operation otherwise similar to devices 102 and 112.

In many embodiments, a suitably configured cellular telephone handset 1420 may also be used. Handset 1420 is depicted in semi-schematic form in FIG. 1 and may include one or more IC chips, such as chip 1440 including a processing unit 1460 and a memory unit 1480. Wireless communication with the terminal may be provided via antenna 1500 or using a second antenna 1800 similar to antenna 120 described above (i.e., the handset may have a second antenna for payment applications). Note that antenna 1800 is depicted schematically, but may be, for example, a loop antenna as used in typical "smart" cards. Handsets 1420 may each be equipped with a suitable display 1560. Furthermore, a suitable power supply 1620 may also be provided. For example, such a power supply may include a battery and appropriate circuitry. The display and power supply may be partially interconnected with the processor. Different types of portable payment devices may be combined or "mixed and matched" with one or more of the features depicted on the exemplary device in FIG. 1. A keypad 1680 and speaker 1740 may be provided. Many current devices omit the keypad 1680 and use a touch screen instead; a newer device of this type is depicted in FIG.

Descriptions of devices, elements or components 102 , 104 , 108 , 110 , 112 , 114 , 116 , 118 , 120 throughout this document are equally applicable to corresponding items in the dual interface card 1302 and cellular telephone handset 10 , 1420 .

Referring to FIG2 , an exemplary relationship between multiple entities is depicted. A number of different users (e.g., consumers) 2002, _U1 , _U2 , ...U _N) interact with a number of different merchants 2004, P1, P2, ... _PM . Merchants 2004 interact with a number of different acquirers 2006, _A1 , _A2 , ... _AI . Acquirers 2006 interact with a number of different issuers 2010, _I1 , _I2 , ... _IJ , through, for example, a single operator of a payment network configured to facilitate transactions between multiple issuers and multiple acquirers; the operator being, for example, MasterCard International Incorporated (the operator of the aforementioned network) or Visa International Service Association (the operator of the aforementioned network). In general, N, M, I, and J are integers that may or may not be equal.

In some cases, Network 2008 utilizes ISO 8583 messaging. ISO 8583, derived from the Financial Transaction Card Message Interchange Message Specification, is an International Organization for Standardization standard for systems that exchange electronic transactions conducted by cardholders using payment cards. ISO 8583 has three parts: Part 1: Messages, Data Elements, and Code Values; Part 2: Application and Registration Procedures for Institutional Identifier Codes (IICs); and Part 3: Maintenance Procedures for Messages, Data Elements, and Code Values, all of which are expressly incorporated herein by reference in their entirety for all purposes. Regardless, ISO 8583 will be familiar to those skilled in the art of payment processing.

During the conventional credit authorization process, cardholder 2002 pays for the purchase, and merchant 2004 submits the transaction to acquirer (acquiring bank) 2006. The acquirer verifies the card number, transaction type, and amount with issuer 2010 and reserves the amount from the cardholder's credit line for the merchant. At this point, authorization requests and responses are typically exchanged in real time. Authorized transactions are stored in "batches" that are sent to acquirer 2006. During subsequent clearing and settlement, the acquirer sends the batched transactions through the credit card associations, which debit the issuer 2010 and credit the acquirer 2006. Once acquirer 2006 has been paid, it pays merchant 2004.

It will be appreciated that the network 2008 shown in FIG. 2 is an example of a payment network configured to facilitate transactions between multiple issuers and multiple acquirers, which can be considered an "open" system. A variety of other types of payment networks can be used. For example, in some instances, a payment network configured to facilitate transactions between multiple issuers and a single acquirer can be used. Some embodiments of the present invention can be used with other types of payment networks, such as proprietary or closed payment networks with only a single issuer and acquirer; with mobile networks; and/or with various types of e-wallet services that incorporate a suitable payment network. In addition, one or more embodiments utilize a payment gateway, a payment service provider, and/or a payment facilitator.

As seen in FIG. 2 , in some cases, an owner or user of a smartphone 10, 1420, or similar device, configured in accordance with one or more embodiments of the present invention, accesses a payment network operator's 2008 website or the like to download a suitable e-wallet application 12 (see FIG. 4 ) to the phone 10, 1420, or similar device. This feature is optional. Note that the connection between the phone 10, 1420 and the payment network operator 2008 can be entirely indirect; for example, the payment network operator 2008 can provide a "gold copy" of the application 12 to a third party, and the phone 10, 1420 downloads it from the third party over the network. The link shown between the phone 10, 1420 and the payment network operator 2008 also represents the flow of data between the phone 10, 1420 and the payment network operator 2008, and can be direct or indirect; for example, via a cellular network, possibly using one or more intermediaries.

3 , a mobile phone 10 can be associated with a payment card (e.g., a credit card, debit card, or prepaid card). The mobile phone is preferably capable of storing and/or running a wallet application 12, which is preferably a browser-based mobile application that can store selected information (e.g., cardholder name, card alias, billing/shipping address, etc.) locally on the phone or in a cloud server. In a preferred embodiment, the mobile phone is a "smartphone" and the wallet application is stored in a memory device located in the phone. The arrangement of FIG3 enables payments across multiple commerce channels, such as POS payments 14 made through, for example, a MasterCard® terminal (a registered trademark of MasterCard International, Inc., Purchase, NY, USA), remote mobile payments 16 initiated by the mobile phone, and/or web-based payments 18.

As further described in FIG3 , some embodiments utilize various authentication tools, including an offline PIN 20, a security code PIN 22, and/or an online PIN 24. It will be appreciated that the aforementioned PINs are currently in use in the marketplace, and therefore, utilizing such existing PINs may facilitate implementation of the present system. Of course, it is contemplated herein that new, independent PINs (in addition to the aforementioned PINs) may be created specifically for use with one or more embodiments.

The offline PIN 20 preferably utilizes an offline personal identification number (PIN) verification process, whereby the PIN entered by the consumer is verified by a secure element located on the phone 10. In this process, the wallet acts as a "virtual terminal" by interacting with the secure element and, after verifying the PIN, passes a CHIP token (Authorization Request Password or ARQC) to the merchant for authorization. In this "virtual terminal," the secure element acts as a "card." For example, the offline PIN 20 can be used in conjunction with payment. Those skilled in the art will be familiar with the terminology used in the description of FIG. 3 , referring to the aforementioned EMV Interoperable Payment Specification. Versions 4.0 through 4.3 of the EMV Specification (including Volumes 1, 2, 3, and 4); Version 1 Supplemental Bulletin of the EMV Common Payment Application Specification (CPA); and Version 1.1 Supplemental Bulletin of the EMV Card Personalization Specification are expressly incorporated herein by reference in their entirety for all purposes. MasterCard is a non-limiting example of an EMV-compliant “contactless” payment feature based on the ISO/IEC 14443 standard, which provides cardholders with a simpler way to pay by tapping their payment card or another payment device (e.g., a phone or key fob) on a point-of-sale terminal reader rather than swiping or inserting the card.

The security code PIN 22 is the PIN associated with a card registered with the MasterCard system (a registered trademark of MasterCard International, Inc., Purchase, New York, USA). It is contemplated herein that the security code system may also utilize passwords and/or codes instead of a PIN.

The online PIN 24 is used in an online PIN verification process whereby the wallet application 12 acts as a "virtual terminal" to interact and encrypt the PIN for transmission to the merchant. Use of the online PIN verification process can provide greater flexibility in verifying transactions by, for example, allowing issuing banks to verify transactions associated with their cardholders without requiring the issuing bank to enroll/register its cardholders and/or implement new infrastructure.

A user can have different instances of the wallet application 12 on different phones. A synchronization service can keep the various instances synchronized with an online server (similar to how browser bookmarks can be stored offline in different instances of an Internet browser and synchronized between various machines). Merchants can add a code to their checkout button that invokes the wallet application. During checkout, the user selects a card and a shipping address (if required). A verification PIN is entered into the phone in response to a prompt from the mobile application. The wallet passes the information back to the merchant, who submits this information through existing channels (Internet gateway or payment processor) (i.e., no changes to existing processes or integrations are required).

In a non-limiting example, the wallet application can be a browser HTML 5 application (not a native application) that is automatically installed on a mobile phone or computer browser upon first use. In a non-limiting example, the wallet application is downloaded to a smartphone or the like from an "app store" or the like on a server.

In another aspect, the wallet application can securely store information on the phone (shipping address, card alias, security token (if used), virtual card number and/or real card number, etc.). This information can be used for many purposes; in some cases, it is used for authentication with a remote server. It also allows for offline transactions. The mobile application can preferably "talk" to a secure element on the phone (for example, it can be on the phone's Subscriber Identity Module (SIM card)). In this regard, the mobile application can act as a virtual POS terminal when initiating a card-present CHIP-plus-PIN transaction. On the other hand, in some cases, the smartphone or similar device is used only as the actual payment device at the POS.

In some cases, a consumer can use his or her phone or computer to shop at a web-based retailer. When the consumer is ready to check out, he or she will preferably have the option of clicking a checkout button associated with some aspects of the present system. Clicking the button prompts the consumer to provide his or her username and password to log in, and to confirm the payment card to be used and the shipping address to which the item is to be sent. Thereafter, the system will prompt the consumer to enter a verification PIN, and the transaction is completed. At this point, the consumer is preferably returned to the merchant's site. This is a non-limiting example. Some embodiments are directed to cardless Internet commerce using one or more virtual card numbers in an electronic wallet on a server, and some embodiments are directed to a downloadable electronic wallet application on a smartphone or the like for conducting transactions using the smartphone at a brick-and-mortar retailer.

One or more embodiments provide one or more benefits to consumers. Some embodiments provide easy and convenient checkout through form fill or pass-through functionality (which is preferably part of the wallet application 12). Some embodiments provide secure payment via a PIN or other biometric parameter (e.g., voiceprint or fingerprint). In this regard, smartphones may be equipped with biometric readers and/or analyzers. Some embodiments omit one, some, or all of these features.

One or more embodiments provide one or more benefits to merchants. Some embodiments include a potential shift of liability from merchants to authorizing banks for all wallet-based transactions. More specifically, using a verification process for remote transactions reduces the fraud risk associated with such transactions and can limit and/or reverse the shift of fraud liability from authorizing banks to merchants. Using a verification process can also provide merchants with more attractive economics by using a lower-cost structure (depending on the consumer verification method). One or more embodiments also provide limited integration impact by providing a simple wallet application programming interface (API) to pass card details, shipping information, and security tokens, and without requiring any new contractual relationships (i.e., existing card acquirers are leveraged). One or more embodiments are backwards compatible (i.e., provide native support for the technology), resulting in a better consumer experience and/or ergonomics. Again, these details are exemplary, optional, and non-limiting; some embodiments are directed to cardless Internet commerce using one or more virtual card numbers in an electronic wallet hosted on a server, and some embodiments are directed to a downloadable electronic wallet application on a smartphone or the like for conducting transactions using the smartphone at brick-and-mortar retailers.

The wallet application 12 described with respect to FIG. 3 provides a comprehensive solution for financial transactions conducted across multiple commerce channels. The wallet application 12 provides consumers with simple and persuasive recommendations and, in some cases, offers form-filling options. One or more embodiments may utilize existing payment networks 2008 and the like that are already accepted by merchants, thereby eliminating the need for extensive integration while providing increased security and better economics. One or more embodiments do not require issuing banks to implement new requirements because they can function using existing authorization technologies (e.g., technology, CHIP and PIN, and/or online PIN). Some embodiments anticipate a long-term convergence of the three commerce platforms (i.e., retail, e-commerce, and mobile) toward a mobile phone-centric system. As mentioned, other embodiments involve a server-based wallet and, optionally, a downloadable wallet application, and may omit some or all of the enhanced authorization features described herein.

Some aspects can be used in applications where the consumer has a "dumb phone." For example, in an application where the consumer is conducting an e-commerce transaction through his or her computer or has initiated a call to a call center and the consumer does not have a smartphone, the system in FIG3 can utilize existing SMS messaging or other messaging technology to contact the consumer's "dumb phone" and request entry of a PIN. After receiving the PIN from the "dumb phone," the transaction can be verified and completed. This feature is entirely optional and can be omitted in one or more embodiments.

FIG4 is a block diagram of an exemplary tablet computing device or smartphone 10 or the like. Unit 10 includes a suitable processor (e.g., microprocessor 402). A cellular transceiver module 404 coupled to processor 402 includes an antenna and appropriate circuitry to transmit and receive cellular telephone signals (e.g., 3G or 4G). A WiFi transceiver module 406 coupled to processor 402 includes an antenna and appropriate circuitry to allow unit 400 to connect to the Internet via a wireless network access point or hotspot. Those skilled in the art will appreciate that "Wi-Fi" is a trademark of the Wi-Fi Alliance and the brand name for products that use the IEEE 802.11 family of standards.

One or more embodiments include a wallet application 12 in memory 412 that, when executed, causes processor 402 to implement at least a portion of the functionality described herein. Operating system 427 coordinates the operation of unit 400. Apple Inc.'s iOS is a non-limiting example of a suitable operating system; other non-limiting examples include Linux-based systems (a registered trademark of Linus Torvald), Windows Phone (a registered trademark of Microsoft Corporation), and the like.

A touch screen 410 coupled to the processor 402 also generally indicates various input/output (I/O) devices (e.g., a keypad, another type of display, a mouse or other pointer device, etc.), which may or may not be present in one or more embodiments. An audio module 418 coupled to the processor 402 includes, for example, an audio codec/decoder (CODEC), a speaker, a headphone jack, a microphone, etc. A power management system 416 may include a battery charger, an interface to the battery, etc. Memory 412 is coupled to the processor 402. Memory 412 may include, for example, volatile memory (e.g., RAM) and non-volatile memory (e.g., ROM, flash memory), or any tangible computer-readable recordable storage medium that stores information in a non-transitory manner. The processor 402 will typically also have on-chip memory.

Quote 5994 is discussed below.

Thus, some embodiments may, for example, be implemented at least in part via an application running on a tablet or smartphone or the like and another application running on a remote server or the like.

FIG5 shows an exemplary software architecture diagram. The wallet platform 597 includes executable code stored in a non-transitory manner on a tangible, computer-readable, recordable storage medium. When loaded into the memory of one or more servers, the executable code causes one or more processors of the servers to implement at least a portion of the logic described herein. The database 1479 includes a suitable database program (e.g., Oracle DBMS, Access and SQL Server from Microsoft, DB2 from IBM, and the open source DBMS MySQL) stored in a non-transitory manner on a tangible, computer-readable, recordable storage medium and a permanent storage device to store records therein. The database program, when loaded into the memory of one or more servers, causes one or more processors of the servers to implement the database described herein (e.g., with pre-registered information). Various interface modules include executable code stored in a non-transitory manner on a tangible, computer-readable, recordable storage medium. When loaded into the memory of one or more servers, the executable code causes one or more processors of the servers to implement the interface functionality and communication processes described herein (including any required data translation between the wallet platform and external entities). GUI 1477 provides an interface to consumer 598; shipping merchant interface module 1475 provides an interface to shipping merchant 599; balance inquiry service interface module 1469 provides an interface to balance inquiry service 989; prepaid card issuer interface module 1471 provides an interface to prepaid card issuer 596; and e-commerce retailer interface module 1473 provides an interface to e-commerce retailer 895. Furthermore, registration and account maintenance module 1483 interfaces with consumer 598 via GUI 1477 to perform registration and maintenance functions; new data and/or updates may be stored in database 1479. In some cases, the local PAN comes from prepaid card issuer 596 via interface 1471; module 1481 determines for which countries the PAN is obtained based on relevant regulations.

Referring to FIG. 6 , in some embodiments, wallet 1989 detects checkout at merchant 1999 at step 1901. Wallet 1989 then authenticates the user (step 1902) and selects payment details (step 1903). Wallet server 1988 then determines that the bank is a wallet ACS (bank's authentication server) client and that no further authentication is required (step 1903). The wallet then fills in the payment details (including the AAV (Account Holder Verification Value)) on the merchant page 1999 form. The merchant then authorizes the transaction in the normal manner (authorization request with the AAV to merchant acquirer 990). The authorization request is passed to bank authorization system 2010 via payment network 987. Merchant acquirer 990 receives the necessary approval (authorization response) from system 2010 via network 987 and passes the approval (authorization response) back to page 1999. In some cases, network 987 is a network such as network 2008. System 2010 is typically operated by or on behalf of an issuing organization and, therefore, has received the same reference characters as issuing organization 2010 in FIG. 2 .

FIG7 relates to aspects of consumer offers. There are two different ways for consumers to register in the consumer registration database 1996. Automatic registration is possible, as in 1995, based on accounts maintained by, for example, a payment network operator (PNO) 2008; certain accounts may be segmented and enabled for participation. Alternatively, as in 1994, consumers may be given the opportunity to opt-in. This can be accomplished, for example, by having the PNO 2008 or some other entity analyze or review certain other consumer databases to conduct outreach and invite one or more consumers to participate. This can be selective (targeted) or open. In any case, consumer privacy should be respected, requiring the consumer to perform some action (registration, confirmation, or the like) before sharing any information or receiving any offers. In many cases, this can be accomplished online, via mobile messaging, or using a clickable link in an email. The consumer registration database 1996 manages all registered consumers. This is ultimately mapped back to an e-wallet account; for example, via a credit or debit card account or through the wallet account itself.

The offer registry 1997 typically involves business-to-business interactions. The rules for an offer are determined by whoever is providing the offer, whether it's a merchant, manufacturer, issuing bank, or the like. The appropriate entity provides the offer rules, the merchants to which they apply, the code range or some identification scheme used for the offer, and so on. Each person can receive an offer using a single identifier; serialized identifiers can be provided, and so on. This information is stored in the offer registry 1997.

The transaction qualification service 1998 applies the rules in real time based on the registration table 1997 and the database 1996. The service 1998 applies the rules quoted by the registration to the transaction information coming in for a given consumer and determines whether all information is qualified for qualification. The service 1998 then updates the registration and transaction records for the specific consumer.

The e-wallet platform 597 facilitates interaction between merchants and consumers 2002 regarding transactions to be qualified. The consumer 2002 goes to the merchant checkout page 1999 and when the consumer indicates that he or she wishes to pay using the e-wallet, he or she is rerouted to the e-wallet platform 597 and then passes the relevant transaction information provided by the merchant through the transaction qualification service 1998. If a promotion is applicable, this information is passed back to the e-wallet platform 597, and when the consumer completes the interaction with the e-wallet platform 597, the information is passed back to the merchant as part of the interface between the e-wallet platform 597 and the merchant. If the merchant wants to accept the e-wallet platform 597, there will be certain messages that the merchant will pass to the e-wallet platform 597 and certain messages that the merchant will receive back from the e-wallet platform 597.

FIG9 depicts an exemplary transaction at an international merchant using an existing prepaid card. At 901, consumer 598 responds affirmatively to a query regarding whether to proceed with checkout after being provided with the total landed cost. At 902, e-commerce retailer 895 initiates a call to e-wallet 597 to retrieve payment information and confirm shipping address information. At 903, e-wallet initiates a request to balance inquiry service 989 to generate a balance inquiry with prepaid card issuer 596 to determine the amount of funds remaining on the prepaid card. e-wallet 597 provides balance inquiry service 989 with the prepaid PAN associated with the e-commerce retailer's country.

At 904, the balance inquiry service formats a balance inquiry authorization request destined for the prepaid card issuer 596 and sends it to the authorization network 987 (e.g., network 2008). At 905, the authorization network forwards the balance inquiry to the prepaid card issuer. At 906, the prepaid card issuer sends an authorization response to the balance inquiry with the remaining funds on the prepaid card to the authorization network. At 907, the authorization network sends the authorization response to the balance inquiry service. At 908, the balance inquiry service provides the balance information to the e-wallet. At 909, the e-wallet generates a request to the funds purchase/payment transaction acquirer/processor 9999 to initiate a purchase to the default funds card associated with the consumer profile for the difference between the e-commerce purchase amount and the available funds on the prepaid card. The e-wallet 597 provides the funds card PAN information and the amount to entity 9999.

Note that "0100" and "0110" refer to the ISO 8583 messages "Authorization Request" and "Authorization Request Response".

At 910, entity 9999 formats a purchase authorization request destined for fund card issuer 986 and sends the purchase authorization request to authorization network 987. At 911, the authorization network forwards the purchase authorization request to fund card issuer 986. At 912, the fund card issuer provides an approval response to the authorization request to the authorization network. At 913, the authorization network forwards the authorization response to entity 9999. At 914, entity 9999 forwards the authorization response to wallet 597.

At 915, the e-wallet generates a request to entity 9999 to initiate a payment transaction to "charge" the prepaid card with the difference between the e-commerce purchase and the remaining funds on the prepaid card (this is the same purchase amount as the purchase amount approved by the fund card issuer 986). The e-wallet provides the prepaid PAN and the amount to entity 9999. The prepaid PAN is associated with the same country as the e-commerce retailer (e.g., a US e-commerce retailer, a US prepaid card). At 916, entity 9999 formats a payment transaction authorization request destined for the prepaid card issuer 596 and sends the payment transaction authorization request to the authorization network 987.

At 917, authorization network 987 forwards the payment transaction authorization request to the prepaid card issuer. At 918, prepaid card issuer 596 provides an approved response to the authorization request to authorization network 987. At 919, authorization network forwards the authorization response to entity 9999. At 920, entity 9999 provides a response to the e-wallet indicating that the top-up has been approved. Flows 921 and 922 illustrate the CVC 2 request and response between the e-wallet and the prepaid card issuer. In this regard, at the time of purchase, after approval has been obtained from the fund card issuer and the top-up has been successfully completed, it is necessary to provide the merchant with all the details required to approve the purchase. Therefore, the merchant will need CVC 2 data. CVC 2 data is typically requested by merchants to ensure that the person conducting an online transaction is actually in possession of the card. In one or more embodiments, CVC 2 data is not stored and must therefore be obtained from the prepaid card issuer. At 921 and 922, a CVC 2 value is obtained for a particular prepaid card to use in a purchase transaction. At 923, payment information including the prepaid card PAN, expiration date, and CVC 2 (if required) is provided by the wallet to the e-commerce retailer.

At 924, the e-commerce retailer 895 generates a request to its acquirer 990 to withdraw the prepaid card to perform the e-commerce purchase. At 925, the e-commerce retailer acquirer 990 formats a purchase authorization request destined for the prepaid card issuer and sends the purchase authorization request to the authorization network. At 926, the authorization network forwards the purchase authorization request to the prepaid card issuer 596. At 927, the prepaid card issuer 596 provides a response to the authorization request to the authorization network. At 928, the authorization network provides the authorization response to the e-commerce retailer acquirer. At 929, the e-commerce retailer acquirer 990 forwards the authorization response to the e-commerce retailer. At 930, the e-commerce retailer provides a purchase confirmation to the consumer 598.

The intended e-commerce retailer acquirer box 990 is a bank in the same jurisdiction as the e-commerce retailer, and a server operated by or on behalf of the bank, which can be located in any jurisdiction. The intended balance inquiry service box 989 is a server with appropriate software configured to send a balance inquiry to the prepaid card issuer to determine the amount remaining on the card; this server may be in the same jurisdiction as the e-wallet server, but can also be located elsewhere. The intended prepaid card issuer box 596 is a prepaid card issuer, which may, but not necessarily, be in the same jurisdiction as the e-commerce retailer, and a server with appropriate software operated by or on behalf of the prepaid card issuer, which can be located in any jurisdiction. The intended fund card issuer box 986 is a banking institution most likely located in the consumer's home country, and a server with appropriate software operated by or on behalf of the banking institution, which can be located in any jurisdiction. Authorized network 987 is typically a multinational network (e.g., the BANKNET or VISANET networks discussed above, or other carriers' payment processing networks). It is contemplated that the funds purchase/payment transaction acquirer/processor block 9999 is: (i) an acquirer, which handles purchases on cards in the shopper's home country and top-ups on prepaid cards in the jurisdiction where the e-commerce retailer is located; and (ii) a server, operated by or on behalf of the acquirer, with appropriate software. The server and acquirer may be located in any jurisdiction and may themselves be located in the same or different jurisdictions. In some cases, the functionality of block 9999 may be divided between two or more different entities.

Applicable legal and regulatory considerations and/or contractual obligations should be appropriately considered because, in some embodiments, the merchant will accept a card that is not technically the consumer's financial card and ship to an address that is not the consumer's actual shipping address; further, in some embodiments, there is no physical card (prepaid or otherwise) issued (it is virtual).

In those embodiments involving such considerations, due consideration should be given to addressing the potential reluctance of shipping merchant acquirers and prepaid card issuers to risk sending and/or approving transactions before settlement has occurred. In some embodiments, the shipping merchant will initiate a payment transaction authorization request before settlement has occurred in the case of a fund card purchase, and/or the prepaid card issuer will approve the e-commerce purchase before settlement has occurred in the case of a payment transaction.

In some cases, the prepaid card issuer will be able to restrict purchases on the prepaid card to only those made through the wallet—for example, ensuring that the billing and/or shipping address is the shipping merchant's warehouse. In other cases, an additional indicator will be required in the authorization request to indicate that the transaction was made through the electronic wallet. Other cases do not involve a separate prepaid card, and in such cases, these considerations are not an issue.

Figure 10 depicts an exemplary transaction at an international merchant using a local money card, where the merchant accepts foreign-issued cards. At 1001, the consumer 598 responds affirmatively to a query regarding whether to proceed with checkout. At 1002, the e-commerce retailer 895 initiates a call to the e-wallet to retrieve the payment method and confirm shipping address information. At 1003, the e-wallet 597 provides payment information to the e-commerce retailer 895, including the money card PAN and expiration date. In one or more embodiments, the e-wallet does not store the money card CVC2, so if the e-commerce retailer requires a CVC2, the consumer will need to populate these fields on the e-commerce retailer's website. At 1004, the e-commerce retailer generates a request to its acquirer 990 to withdraw the money card to execute the e-commerce purchase. At 1005, the e-commerce retailer acquirer 990 formats a purchase authorization request destined for the money card issuer 986 and sends the purchase authorization request to the authorization network 987. At 1006, the authorization network 987 forwards the purchase authorization request to the fund card issuer 986. At 1007, the fund card issuer provides an approved response to the authorization request to the authorization network. At 1008, the authorization network provides the authorization response to the e-commerce retailer acquirer 990. At 1009, the e-commerce retailer acquirer forwards the authorization response to the e-commerce retailer 895. At 1010, the e-commerce retailer provides a purchase confirmation to the consumer. At 1011, the e-commerce retailer generates a clearing message (e.g., message type indicator (MTI) 1240) for the e-commerce purchase to the clearing system 1081. At 1012, the clearing system sends the clearing message for the e-commerce purchase to the fund card issuer 986. It is contemplated that the clearing system block 1081 is a normal business clearing system and may be located, for example, in the United States or another jurisdiction. Likewise, some embodiments do not involve cross-jurisdictional aspects and/or local prepaid fund cards.

Some embodiments of the present invention relate to virtual card numbers for digital wallets. The following terms are used herein:

● Virtual Card Number - a unique number (16 digits at least in some cases) that is linked to the real card number (RCN) in the backend. The virtual card number can be set with several sets of rules, alerts and limits, which allows for strict yet flexible management of payments

Real Card Number (RCN) - the number written on the physical card (at least in some cases it is 16 digits)

Digital wallet - a host for a user's financial information (card number, address, etc.), facilitating transactions with only a few clicks or interactions

Card - credit, debit or prepaid card

● Consumers – the end users who visit a physical store or online store

Merchants – online or physical stores

● Remote Payment - Payments made using any suitable computing device: desktop, laptop, smartphone, tablet and similar using an internet connection

Proximity Payments – Payments made using Near Field Communication

Near Field Communication (NFC) - a set of rules for devices to communicate with each other using radio frequency by touching them together or bringing them into close proximity (usually no more than a few centimeters) (used herein for payment purposes)

Credit, debit, and prepaid cards contain a series of numbers that can be used to identify the issuing bank and the cardholder's bank account. A virtual card number (VCN) is a randomly generated number that contains no identifying information but is linked to a real card number (RCN).

A digital wallet is an electronic version of a physical wallet and holds various payment methods (e.g., credit, debit, and/or prepaid cards) and/or electronic cash in the form of stored value.

One of the benefits currently offered by digital wallets is hiding the consumer's RCN from merchants, thereby allowing consumers to purchase from merchants to whom they are not inclined to give their RCN. However, a consequence of hiding the consumer's RCN from merchants is that the merchant does not know which bank card is being used and any promotions associated with that particular bank card are forfeited.

By incorporating a VCN into a digital wallet, consumers are able to hide their account information while revealing the bank that issued the card, thereby enjoying the benefits of being able to purchase from merchants without giving out their RCN while enjoying all the promotions associated with using a specific bank card.

Existing payment options will now be described. A current technology involves paying merchants directly via credit cards, debit cards, or prepaid cards. As shown in Figure 11, consumers are asked for card information 8001, delivery address (here, store pickup 8002), and billing address 8003, and the like. With reference to Figure 12, during the review of payment, consumers typically review all the information they have entered in the previous page. Merchants are able to obtain information from consumers (including actual card number -RCN). This option is advantageous because it does not require any form of registration, consumers are entitled to any privileges granted by their card, merchants process transactions through standard procedures and receive their settlements in their bank accounts, and existing dispute resolution and/or refund processes are available. On the other hand, consumers face the risk of revealing their card number and security code to merchants, and the process is cumbersome because it requires consumers to fill in many information fields.

Another current technology involves indirect payments to merchants via digital wallets. As shown in Figure 13, the consumer is redirected to a wallet website (e.g., by selecting the wallet option "E-Wallet" 8004). In Figure 14, for example, the consumer logs into their wallet account using their email (or another username) and password. In Figure 15, the consumer reviews the card to be used for the purchase and clicks the "Continue" button 8005 to confirm the payment and be redirected to the merchant's site. In Figure 16, the consumer reviews their information. In this option, the RCN information is not passed to the merchant. The merchant only receives a payment token. This option is advantageous because the consumer only needs to log in instead of filling in information fields, and because the consumer's card number and security code are hidden from the merchant. On the other hand, the consumer gives up any privileges granted by their card, and the merchant receives the payment in their wallet account instead of their bank account, and the dispute resolution and refund process is difficult for the merchant.

Yet another current technique involves interacting directly with merchants via a virtual card number (also known as a virtual account number). Here, in FIG. 17 , a user logs in at 8006 using a user ID and password or the like and is provided with a virtual card number at 8007 . In FIG. 18 , the user then enters the virtual card information from 8007 into corresponding fields 8008 . Advantageously, the consumer's actual card number and security code are hidden from the merchant. On the other hand, this presents a relatively unintuitive user experience, requiring the consumer to leave the current transaction to go to their bank's website 8006 to generate a VCN 8007 (typically by switching between windows and browser tabs in their browser). Furthermore, as with the first current option, this is a cumbersome process requiring the consumer to fill out numerous information fields.

Referring now to FIG. 19 , an exemplary sequence of steps according to an embodiment of the present invention will now be described, in which a consumer makes a remote payment via a VCN-enabled digital wallet. At 8009 , the user selects a VCN-enabled digital wallet, "E-wallet," as a payment option. Consequently, the consumer is redirected from the merchant's website to the e-wallet website. At 8010 in FIG. 20 , the consumer logs in using their email address or similar, or registers an account if they don't already have one. At 8011 in FIG. 21 , the consumer is greeted by name and presented with a personal message of their choice. If both the name and personal message are correct, the consumer proceeds to enter their password. In FIG. 22 , the consumer can select an RCN or VCN already in their wallet, as at 8012; generate a VCN for a single transaction by clicking the "Use VCN" button 8013 next to their RCN; or add a new RCN or VCN to their wallet by clicking the "Add Card" button 8014. Optional functionality for adding and/or managing VCNs may be provided. If the consumer wishes to manage VCN rules, restrictions, and alerts, they can do so through the interface itself. In the right-hand column, various shipping address options may be provided, such as "Home (default)," "Vacation Home," and "Dad's House." FIG23 is a non-limiting example of such a management interface. As seen in FIG24 , after the consumer has selected the card they wish to use, they will click the "Review Your Order" button to be redirected to the merchant site to complete their transaction; at 8015, the merchant website displays the VCN but not the RCN.

Advantageously, in this embodiment, a consumer can generate a VCN to be used only for a specific transaction; a consumer can create multiple VCNs to be used for different purposes and can specify an expiration date or the number of times the VCN can be used; and/or a consumer can set controls over their VCN, such as requesting to be alerted or have a transaction declined if, for example, the transaction amount exceeds a specified limit, the amount spent on the VCN has reached its daily limit, and/or a specific category of spending has reached its limit.

In another aspect of the present invention, proximity payments are performed via an NFC wallet. In addition to remote payments via mobile payment technology, virtual card numbers can also be used for proximity payments. Consumers can use VCNs instead of loading a physical credit card into their wallet when they are wary of merchants. The advantages of this aspect are similar to those discussed above for remote payments.

FIG25 illustrates an exemplary transaction flow. During a one-time prerequisite and setup process 8017, one or more consumers 598 register with a digital wallet 597, as seen at 8020, and add card and shipping details to the wallet. Furthermore, as seen at 8021, a merchant 1999 integrates with the wallet 597 and places the wallet's payment token on the merchant's website 1999. Note that reference character 1999 is used in FIG25 to refer to both the merchant and the merchant's website. For example, steps 8020 and 8021 may be implemented using module 1483 or 5483.

In the payment phase 8018, as seen at 8022, the consumer 598 visits the merchant's website 1999 or one of their other applications and makes a purchase. At checkout, as seen at 8023, the consumer is redirected to the wallet 597. At step 8024, the consumer selects an existing VCN or creates a new one to use. At step 8025, the wallet 597 passes the VCN details back to the merchant 1999. At step 8026, the details are presented to the consumer 598 as part of the checkout review process. At step 8027, the consumer 598 reviews the details and confirms payment. At step 8028, the merchant passes all information to the acquirer 990, which sends the information to the issuer (not shown) via network 987. In step 8029, the operator of network 987 uses MasterCard PAN (primary account number) mapping functionality 8016 to access a table or the like to map the transaction's VCN to a corresponding RCN before passing the RCN to the issuer (a registered trademark of MasterCard International Incorporated, Purchase, New York, USA).

Other processes are shown at 8019. As seen at 8030, 8031, the settlement and refund and/or reversal processes may be conventional (ie, business as usual or "BAU").

In some cases, as discussed elsewhere herein, a suitable application 12 resides on a smartphone 1420, 10 or the like and presents the phone to a terminal 126 or the like at a physical location. The application 12 includes or has access to one or more locally stored VCNs and/or one or more locally stored quotes 5994.

Thus, one or more embodiments of the present invention are directed to and/or advantageously function in conjunction with electronic wallets (e-wallets) (also known as digital wallets). As mentioned, e-wallets provide consumers with a secure and convenient way to pay for purchases from accepted online merchants. After registration, consumers can store their card, billing, and shipping information on a site hosted by an appropriate entity (e.g., the operator of a payment network 2008) and access that information to conveniently and securely make payments across participating merchants. E-wallet platforms can provide additional security using "virtual" account numbers to mask the cardholder's actual information.

In some cases, for example, the use of "virtual" account numbers mentioned above (also known as PAN mapping) may be a network service provided by the operator of payment network 2008 (e.g., an entity such as Mastercard International Inc.) to issuers; in other cases, issuers may choose to use their own solution. The PAN mapping process involves taking the original primary account number (PAN) and issuing a pseudo-PAN (or virtual card number) in its place. This provides security against the potential disclosure of the original PAN. A non-limiting example of PAN mapping is the PAN mapping provided by the "One-time Use Number" feature of Mastercard International Inc.'s inControl ^™ payment solutions platform. Those skilled in the art will be familiar with various PAN mapping techniques and, given the techniques herein, will be able to adapt PAN mapping techniques for one or more embodiments of the present invention. For example, a payment network operator may create a translation table in which outward-facing instances of a number present a pseudo-PAN, while inward-facing instances present the actual PAN. In view of the teachings herein, commercially available PAN mapping solutions that may be suitable for embodiments of the present invention include the PAN mapping solution available from Orbiscom Ltd., Block 1, Blackrock Business Park, Carysfort Avenue, Blackrock, Co. Dublin, Ireland (now a division of MasterCard International Incorporated, Purchase, New York, USA); by way of example and not limitation, U.S. Patents 6,636,833 and 7,136,835 to Flitcroft et al., the complete disclosures of which are expressly incorporated herein by reference in their entirety for all purposes.

For the avoidance of doubt, it should be emphasized that Mastercard International Inc.'s inControl ^™ payment solutions platform is a non-limiting example and that many different techniques may be used to provide the “virtual numbers” described elsewhere herein, whether the PAN mapping is as described in the U.S. patent to Flitcroft et al. or elsewhere.

It should be noted that one of ordinary skill in the art will be familiar with electronic wallets themselves and, given the techniques herein, will be able to adapt electronic wallets to implement one or more embodiments of the present invention. Non-limiting examples of known electronic wallets include the PayPal service (a trademark of PayPal, a subsidiary of eBay, Inc. of San Jose, California, USA); the Checkout by Amazon service (a trademark of Amazon.com, Inc. of Seattle, Washington, USA); and the Google Checkout service (a trademark of Google Inc. of Mountain View, California, USA).

One or more embodiments advantageously utilize virtual card numbers within the convenient user experience provided by an electronic wallet. As discussed above, virtual card numbers advantageously provide increased security and consumer trust (particularly in cross-border usage scenarios where the consumer is unfamiliar with the merchant from whom the purchase is being made); the ability to implement alerts, restrictions (time, amount, and number of transactions, merchant categories, etc.); and/or risk management. On the other hand, virtual card numbers are inconvenient because they provide a cumbersome user experience in which the consumer needs to switch between their virtual card number generator (browser, desktop plug-in, etc.) and their payment experience (merchant site).

As discussed above, wallets offer the advantage that the consumer pays via a mouse click or the like without even having to pull his or her card out of his or her wallet (nor leaving the merchant's website); however, this is inconvenient because the consumer needs to trust the merchant in that the wallet application passes the card number to the merchant for processing; and the wallet may or may not provide a level of risk management that can provide a shift of liability to the merchant.

Advantageously, one or more embodiments integrate the virtual card number with the e-wallet. In one or more embodiments, the merchant does not need to change any integration to use the e-wallet with the virtual card number. Furthermore, in one or more embodiments, the difference between paying the merchant with the virtual card number and paying the merchant with the real card number is transparent to the merchant.

In one or more embodiments, a consumer can select when they want to use a VCN for a particular transaction during their payment experience using only a few mouse clicks or the like. Relevant use cases for one or more embodiments include situations where a consumer wants greater control over alerts and/or restrictions for specific card numbers or when they lack trust in the merchant or country they are purchasing from.

Now consider the current wallet payment experience. As shown in Figure 26, the consumer has several items in his or her shopping cart and is provided with the opportunity to select the desired delivery option and the desired payment method (e.g., regular checkout 8033 or e-wallet checkout 8034) at 8032. In Figure 27, at 8035, the user identifies himself or herself to the wallet using credentials, such as an email address or mobile phone number. In Figure 28, at 8036, the user enters his or her password. In Figure 29, the user selects from several different payment cards at 8037 and from several different delivery addresses at 8038. In the right column, various delivery address options are available, such as "Home (Default)", "Vacation Home", and "Dad's House". In Figure 30, the user returns to the merchant site and confirms the details. In Figure 31, the payment completion page is displayed to the user.

VCN payment experience embedded in the wallet

Attention is now directed to FIG. 32 . In a first step, the user is at a shopping cart, generally designated 8039 , with the option of selecting from several different shipping options presented at 8040 and also provided with payment method selection options 8041 (Convenience) and 8042 (E-Wallet). In FIG. 33 , at 8021 , the user identifies themselves to the wallet using credentials (e.g., an email address or mobile phone number). In FIG. 34 , at 8043 , the user enters their password. In FIG. 35 , the user selects from several different payment cards at 8044 and from several different shipping addresses at 8045. In FIG. 36 , the user selects to use a VCN for the given transaction, as seen at 8046 . At FIG37 , the user optionally changes the limits and/or alert parameters of the VCN using the MASTERCARD platform or the like (a division of Mastercard International, Inc., Purchase, NY, USA; functionality allows customers to establish customized spending management controls). As seen at 8047 , the user can set a dollar limit on a single transaction or on spending over a period of time, and can choose to decline transactions that exceed the limit or receive alerts about such transactions. As seen at 8048 , the user can set a dollar limit on spending for a category of spending over a period of time, and can choose to decline transactions that exceed the limit or receive alerts about such transactions. As seen in FIG38 , the user returns to the merchant site and confirms the details. In FIG39 , the payment completion page is displayed to the consumer. Note that, in general, some embodiments involve leaving the merchant site and returning to the merchant site, while other embodiments involve a seamless experience in which the wallet or the like is tightly integrated with the merchant site via an API or the like.

Cross-border delivery for digital wallets

[0011] In another aspect, one or more embodiments relate to cross-border delivery for digital wallets.

Many international consumers now have a strong desire to shop in the US and UK. The US and UK are perceived as offering more choices, better pricing, and a more enjoyable shopping experience. Many consumers travel from around the world to the US for their shopping spree.

Furthermore, broadband capacity has increased around the world, typically by 150% annually. There is also a growing middle class in rapidly developing countries such as Brazil, India, China, and Russia. Consumers from these jurisdictions are finding their way to merchant websites in the United States and the United Kingdom. Today, 19% of all browsing on U.S. e-commerce comes from consumers in other countries. However, most U.S. merchants do not accept foreign cards due to liability issues. About 40% accept foreign cards online; however, they only accept foreign cards from a small number of countries; for example, 10 to 30 countries. Even when they do accept foreign cards, they typically do not ship overseas. Therefore, there are acceptance and fulfillment barriers for foreigners who want to purchase from U.S. e-commerce.

Even for U.S. merchants that ship worldwide, there is a transparency issue with overseas shoppers because they have no way of knowing what taxes, duties, and the like will be charged when their order arrives in their particular country; in some cases, they don't even know the shipping costs.

As used in this discussion, a “domestic address” is a consumer’s address in his or her country of residence; an “overseas address” is a consumer’s address in the merchant’s country; a “domestic delivery” is a delivery from the merchant’s warehouse to the consumer’s overseas address; and an “overseas delivery” is a delivery from the consumer’s overseas address to a domestic address.

Low prices and availability of products are driving consumers online to buy products from overseas. However, the problem they often encounter is that merchants do not offer international shipping and usually only offer domestic shipping.

Currently, service providers such as Borderlinx (also known as logistics providers, logistics partners, or fulfillment merchants) offer a solution to this problem by providing consumers with an overseas address to which merchants can ship their purchased items. Items shipped to overseas addresses are stored free of charge for 30 days, allowing for the accumulation of items and the delivery of one large package rather than many small ones. Items can also be combined with items from family and friends to create larger packages. When a consumer requests a package be shipped from their overseas address to their domestic address, the total shipping cost (including taxes and duties) is calculated, and the consumer is able to make a full and final payment for the cross-border shipping service.

However, there are several limitations to this service:

●Consumers will not know the cost of overseas delivery when purchasing their products because this service is provided by a third party rather than the merchant.

• The consumer must wait several days to complete their transaction because the consumer must wait for their merchandise to arrive at their overseas address before they can arrange delivery to their domestic address.

• The consumer must access two different websites on two separate days to complete their transaction because they must deal with two parties (the merchant and the service provider).

Advantageously, one or more embodiments improve the consumer experience by integrating merchants with service providers. In at least some cases, exemplary embodiments of the e-wallet provide consumers with shipping costs at the time of purchase, using information from the merchant regarding the weight of the item and the size of the package, along with the service provider's shipping fees. Thus, consumers can arrange for international shipping without having to wait for their items to be delivered to their domestic address; furthermore, they only need to transact with one entity (i.e., the e-wallet).

Furthermore, in one or more embodiments, an e-wallet according to aspects of the present invention allows consumers to compare prices across several service providers in order to have their goods delivered at the lowest cost.

Still further, in one or more embodiments, the e-wallet is provided by an entity, such as the operator of payment network 2008; this entity in turn holds the added value features of the international shipping service provider (e.g., bundling goods or repackaging to reduce shipping costs).

Referring now to FIG40 , in the current method for shipping options (using an international shipping service provider), a consumer registers on the service provider's website and is given an address in the merchant's country 8049. As shown in FIG41 , the user enters their billing address. As shown in FIG42 , when the user selects a shipping option, they use their domestic address as their billing address and their assigned overseas address as their shipping address, as at 8050. In FIG43 , the consumer selects a domestic shipping method. Here, the consumer selects "Standard Ground." In FIG44 , the consumer selects a payment method (here, electronic wallet "E-Wal"). In FIG45 , the consumer reviews their order and confirms their purchase via the "Submit Order" button 8051. Then, in FIG46 , after the package arrives at the overseas address, the consumer selects their overseas shipping method and pays for the overseas shipping. Here, the user has selected 2-day shipping.

The current approach just discussed has the following advantages: consumers follow the same familiar purchasing process, can consolidate and ship one large package instead of many small ones, and can repack their packages to reduce shipping costs. On the other hand, with this current approach, consumers are unaware of international shipping costs at the time of purchase, must wait until the package arrives at their international address before arranging international shipping, and must independently transact with merchants and international shipping service providers.

Consider now an exemplary approach according to aspects of the present invention. Referring to FIG. 47 , using an e-wallet according to aspects of the present invention, a consumer selects "e-Wallet" as their payment method, as seen at 8052 . In FIG. 48 , the consumer is redirected to the "e-Wallet" website, where they log in using their credentials (e.g., using an email or mobile phone number as their ID at 8053 and then entering their password at 8054 ). If not registered, the consumer is given the option to register at 8055 . In FIG. 49 , the e-wallet determines whether the merchant will ship to the user's domestic address. If not, the e-wallet offers the consumer the option of using international shipping services provided by "American Express Logistics Provider," as seen at 8056 . In FIG. 50 , the e-wallet determines the cost of cross-border shipping and presents several options 8057 for the consumer to choose from. The first option is shipping speed. The second option is shipping fees from various international shipping providers and, if applicable, the merchant itself. The user can confirm their selection at 8058 . Optionally, if the consumer wishes to have their items consolidated, they also have the option of domestic delivery to their overseas address (e.g., warehouse) at 8059. In Figure 51, the consumer reviews the delivery charges before proceeding to review their order (button 8060) and making payment. A local delivery fee applies to local deliveries, while both a local delivery fee and an international delivery fee apply to international deliveries. In one or more embodiments, the domestic delivery fee is based on the consumer's selection on the merchant's website.

Advantageously, in this approach, consumers don't need to go through the hassle of filling in their billing address, shipping address, or credit card information, as their digital wallet already has this information. Furthermore, consumers know the total shipping cost before deciding whether to proceed with the purchase. As more international shipping services are added to the e-wallet, consumers will be able to compare shipping prices across various service providers. Consumers have the flexibility to complete the transaction immediately or consolidate the package at their overseas address.

Figure 52 compares the current technology 8071 with a sequence of steps 8072 according to an embodiment of the present invention. In step 8073, the consumer visits the merchant's website. In step 8074, the consumer adds items to their shopping cart. In step 8075, the consumer browses their shopping cart to proceed to checkout. These steps are common to both methods 8071 and 8072. In the current technology, at 8076, the user enters their billing and shipping addresses. At 8077, they select a domestic shipping method. At step 8078, they select a payment option. At step 8079, they review and confirm their order. At step 8080, the consumer typically must wait a certain number of days ("X") for the items to be delivered to the overseas address. At step 8081, the consumer receives a delivery notification from the logistics provider (e.g., American Express). At step 8082, they log in to the logistics provider's website. At step 8083, the consumer decides whether to deliver now or bundle it with other goods. At step 8084, the consumer confirms and pays.

In step sequence 8072 according to an embodiment of the present invention, at step 8085, the user selects a domestic delivery method. At step 8086, they select e-wallet as their payment option. At step 8087, the user logs into the e-wallet. At step 8088, the user selects a credit card to be used for payment and a delivery address. At step 8089, the user selects the delivery cost and speed (i.e., whether to ship now or bundle). At step 8090, the consumer reviews and confirms the order.

In FIG. 52 , it will be appreciated that steps 8073 to 8079 , 8085 and 8086 relate to the merchant's website; steps 8087 to 8090 relate to the e-wallet; and steps 8081 to 8084 relate to the logistics provider.

FIG53 illustrates an exemplary transaction flow. During a one-time prerequisite and setup process 8102, one or more consumers 598 register with the e-wallet 597, adding card and shipping details to the e-wallet, as seen at 8105. Furthermore, as seen at 8106, a merchant 1999 is integrated with the e-wallet 597. Note that reference character 1999 is used in FIG53 to refer to both the merchant and the merchant's website. In at least some cases, steps 8105 and 8106 can be performed using modules 1483, 5483, for example, with the assistance of GUIs 1477, 5477.

During the payment phase 8103, as seen at 8107, consumer 598 visits the merchant's website 1999 or some other merchant application and makes a purchase. At checkout, as seen at 8108, the consumer is redirected to wallet 597. In step 8109, wallet 597 obtains product details from merchant 1999. In step 8110, wallet 597 obtains shipping costs from logistics provider 8101. In step 8111, wallet 597 displays the product and shipping costs to consumer 598 for review. In step 8112, consumer 598 reviews the details and confirms payment. In step 8113, wallet 597 passes all information to acquirer 990 via network 987 for business as usual ("BAU") processing. In step 8114, wallet 597 passes the order to both merchant 1999 and logistics service provider 8101.

Other processes are shown at 8104, and as seen at 8115, 8116, the settlement and refund and/or reverse processes may be conventional (i.e., BAU).

In some cases, as discussed elsewhere herein, a suitable application 12 resides on a smartphone 1420, 10 or the like, and presents this phone to a terminal 126 or the like at a physical location. The application 12 includes or has access to one or more locally stored VCNs and/or one or more locally stored quotes 5994.

FIG54 shows an alternative exemplary software architecture diagram. Unless otherwise indicated, the elements therein have similar functionality to those in FIG5 (reference characters for corresponding portions of the wallet and database are incremented by 4000). Wallet platform 5497 includes executable code stored in a non-transitory manner on a tangible, computer-readable, recordable storage medium. When loaded into the memory of one or more servers, the executable code causes one or more processors of the server to implement at least a portion of the logic discussed herein. Database 5479 includes a suitable database program (e.g., Oracle DBMS, Access and SQL Server from Microsoft, DB2 from International Business Machines (IBM), and the open source DBMS MySQL) stored in a non-transitory manner on a tangible, computer-readable, recordable storage medium and a permanent storage device to store records therein. When loaded into the memory of one or more servers, the database program causes one or more processors of the server to implement the database described herein (e.g., with pre-registered information). The various interface modules include executable code stored in a tangible, computer-readable, recordable storage medium in a non-transitory manner that, when loaded into the memory of one or more servers, causes one or more processors of the servers to implement the interface functionality and communication processes described herein (including any required data translation between the wallet platform and external entities). The GUI 5477 provides an interface to consumers 598; the optional shipping merchant interface module 5475 provides an interface to shipping merchants 599; and the e-commerce retailer interface module 5473 provides an interface to e-commerce retailers 895. In addition, a registration module 5483 interfaces with consumers 598 via the GUI 5477 to perform registration and (optionally) maintenance functions; new data and/or updates can be stored in the database 5479.

API 5999 is exposed to e-commerce retailers to allow the retailer's 895 website to integrate with platform 5497. An optional PAN mapping engine 5998 (optional in the sense that a PAN mapping engine external to wallet 5497 may be used in some cases) converts between VCNs and RCNs (e.g., via the technology disclosed in the Flitcroft patent); an optional app store 5996 (optional in the sense that apps external to wallet 5497 may be used, and may be completely optional in embodiments that do not utilize a smartphone or the like) makes the app store 12 available for downloads (the term "store" does not necessarily imply a fee). A payment method engine 5997 allows the e-wallet platform 5497 to offer consumers the option of selecting from multiple methods for paying for transactions. The multiple methods (including one or more VCNs) are based at least in part on registration information. This information may be stored in database 5497 and accessed and selected by engine 5997. Optional delivery engine 5995 determines delivery options; for example, based on data in database 5497 and/or based on a real-time link with one or more delivery companies. Engine 5995 also optionally calculates the size and shape of the delivery goods and determines packaging requirements.

Comparative aspects

Some comparison embodiments offer price comparisons across several delivery services and merchants. For example, in some cases, the e-wallet offers consumers several options for domestic and cross-border delivery. For domestic delivery, consumers can choose between the merchant's delivery options and other domestic delivery services (e.g., the postal service). For international delivery, consumers have several delivery services (e.g., Borderlinx and Comgateway) to choose from. Based on these options, consumers can find a combination of price, speed, reliability, etc. that is as close to their ideal as possible.

In another aspect, offers and incentives may be available to encourage the use of specific funding sources. In some cases, the e-wallet aggregates various payment methods (e.g., credit cards and mobile phone bills). Within each payment method, there are also several options, such as credit cards from various issuers and payment service providers. The e-wallet applies any relevant promotions across and within funding sources; the display to the consumer determines which funding source in the consumer's wallet offers the lowest-priced option to the consumer. The consumer can also view prices using each of their funding sources that has an associated promotion, thereby generating price differences.

In yet another aspect, issuer promotions are delivered to consumers regardless of the PAN mapping technology used (e.g., VCN or virtual prepaid cards). In order for consumers to receive promotions offered by their credit card issuer, the virtual card needs to have the same Bank Identification Number (BIN) as the real card or be mapped to the real card. When using VCN or virtual prepaid cards, the e-wallet can provide this functionality.

In yet another aspect, where a virtual card number (VCN) is used in addition to or in lieu of a virtual prepaid card, the e-wallet can potentially use the VCN for both cross-border transactions and domestic transactions.

Furthermore, the consumer experience may be altered in several ways (e.g., having the e-wallet appear as a pop-up window), where the consumer completes the transaction on the merchant site, or where the consumer is redirected to the e-wallet site after checking out from the merchant site to complete the transaction on the wallet site.

In yet another aspect, some embodiments provide a "best offer card selector." In this aspect, a consumer registers credit cards (generally understood to also include debit cards, prepaid cards, and/or stored-value cards, in at least some cases) from various financial institutions into their e-wallet. Each credit card carries promotions applicable to selected merchants. When making a payment at each of these selected merchants, the consumer selects a credit card in their e-wallet and places their mobile phone over a proximity card reader. The e-wallet detects the merchant and checks all payment cards in the wallet for promotions associated with that merchant. If a better offer is found (in terms of paying the lowest price or other (e.g., points or rewards)), the transaction is paused and an alert is sent to the consumer, informing them of the better offer and providing the option to change the card used for payment. The consumer chooses to proceed with the current card or select a new card and place the mobile phone over the proximity card reader to complete the transaction.

Summary

In view of the discussion thus far, it will be understood that, generally speaking, exemplary methods according to aspects of the present invention include the step of obtaining registration information for a plurality of consumers 598 at an e-wallet platform 5497. For example, in at least some cases, this step can be performed using a registration module 5483 via a GUI 5477. Another step includes providing a mechanism for integrating the e-wallet platform with a plurality of merchants 1999 (e-merchant retailers 895 are non-limiting examples of merchants). For example, this step can be performed by exposing an API 5999 to the merchants.

Another step includes giving a given consumer, via the e-wallet platform 5497, the option to select from a plurality of methods for paying for transactions with a given merchant 1999. The plurality of methods is based, at least in part, on the registration information. At least one of the plurality of methods includes a virtual card number (VCN). As used herein and as mentioned above, a virtual card number (VCN) is a randomly generated number that does not contain any identifying information but is associated with a real card number (RCN). Confusion with the term "virtual card" should be avoided, as such a "virtual card" may be used in situations where an RCN is stored on some device and a transaction occurs without a physical card corresponding to the RCN, but where the RCN is provided to the merchant. For example, the steps discussed in this paragraph may be performed directly by the consumer via the GUI 5477, or through a merchant's intermediary using the e-commerce retailer interface module 5473; in either case, with the assistance of the payment method engine 5997. An example screen is shown in FIG. 35 .

Yet another step includes obtaining a selection from a given one of the consumers of a virtual card number for use in the payment transaction. For example, the steps discussed in this paragraph can be performed directly by the consumer via GUI 5477, or through a merchant's intermediary using e-commerce retailer interface module 5473; in either case, with the assistance of payment method engine 5997. An example screen is shown in FIG36 .

Yet another step includes providing the virtual card number to a given merchant. This step can be accomplished, for example, by disclosing API 5999 to the merchant. This facilitates the merchant receiving payment for the transaction. The virtual card number is provided to the given merchant, and the amount of the transaction is charged to a payment associated with the virtual card number, not the actual card number provided to the merchant.

Some embodiments further include intercepting a transaction request from a given merchant to charge a transaction amount to a payment made using a virtual card number; translating the virtual card number into an actual card number that is not provided to the merchant; and transmitting an authorization request to the issuer, wherein the actual card number is included in the authorization request. For example, these steps may be performed by an account mapping engine 5998 within a payment network (e.g., 2008).

In some cases, the transaction comprises an online transaction at a website of a given one of the merchants 1999; and a selection of a virtual card number is obtained at the e-wallet platform from a computing device of the given one of the consumers (e.g., a PC or laptop generally represented by system 300 in FIG. 8 ).

In some cases, another step includes providing a system. The system includes distinct software modules. Each of the distinct software modules is embodied on a non-transitory computer-readable storage medium. The distinct software modules include a registration module 5483, a user interface module 5477, an application program interface 5999, and a payment method engine module 5997. The steps are then performed or otherwise facilitated by the modules, as described above. In some cases, the distinct software modules further include an account mapping engine module 5998, and further steps include intercepting an authorization request from a given merchant to credit the amount of the transaction to the virtual card number by executing the account mapping engine module on at least one hardware processor; translating the virtual card number into an actual card number that is not provided to the merchant by executing the account mapping engine module on at least one hardware processor; and transmitting the authorization request to the issuer by executing the account mapping engine module on the at least one hardware processor, wherein the actual card number is included in the authorization request.

Notably, the wallet may pop up at the merchant's website or may redirect the consumer to an e-wallet site.

Thus, one or more embodiments contemplate a device (e.g., a server on which an e-wallet platform 5497 runs) comprising: memory; and at least one processor coupled to the memory and operable to perform any, some, or all of the method steps just described. In one or more embodiments, distinct software modules stored in a non-transitory storage medium, when loaded into the memory, configure the at least one processor to enable it to perform any, some, or all of the method steps just described. As mentioned, the modules may include a registration module 5483, a user interface module 5477, an application program interface 5999, a payment method engine 5997, and optionally, an account mapping engine module 5998 and/or an e-commerce retailer interface module 5473.

In some cases, the transaction involves a given consumer presenting a payment device (e.g., a "smart" phone 10) having an e-wallet application 12 thereon at a point-of-sale terminal 124, 126 of the given merchant, and providing the merchant with a virtual card number via communication between the payment device and the given merchant's point-of-sale terminal (e.g., via NFC). In such a scenario, an exemplary method includes the step of obtaining registration information for multiple consumers at the e-wallet platform. For example, registration can be performed using a registration module 5483 and a UI 5477. Another step includes providing the consumer with access to a secure application on the consumer's portable device, which provides the consumer with the option of selecting from multiple methods for paying for transactions with the merchant. The multiple methods are based at least in part on the registration information. At least one of the multiple methods includes a virtual card number. For example, this step can be performed using an application store 5996. The term "store" does not necessarily imply a fee for downloading the application. The VCN can be provided with the downloaded application or can be generated and downloaded at a later time.

It should be noted that a VCN is a payment method that is based at least in part on registration information, in the sense that the registration information allows for association with an actual card number. Of course, in at least some cases, the VCN itself may be dynamically created (i.e., the actual VCN may be dynamically created after the registration process). However, within this understanding, the VCN is still understood to be based at least in part on registration information.

Another step includes intercepting an authorization request from the merchant to have the amount of the transaction credited to the virtual card number. The transaction includes the consumer presenting the portable device with a secure application at the merchant's point-of-sale terminal. The virtual card number is provided via communication between the portable device and the merchant's point-of-sale terminal. This step can be performed, for example, using an account mapping engine 5998 within a payment network (e.g., 2008).

Still further steps include translating the given one of the virtual card numbers into an actual card number that is not provided to the given one of the merchants; and passing an authorization request to the issuer, wherein the actual card number is included in the authorization request. For example, these steps can be performed using an account mapping engine 5998 within a payment network (e.g., 2008).

In some cases, another step includes providing a system. The system includes distinct software modules. Each of the distinct modules is embodied on a non-transitory computer-readable recordable medium. The distinct software modules include a registration module 5483, a user interface module 5477, an application store module 5996, and an account mapping engine module 5998. The steps described above are then performed or otherwise facilitated by the modules.

Thus, one or more embodiments contemplate a device (e.g., a server on which an e-wallet platform 5497 runs) comprising: a memory; and at least one processor coupled to the memory and operable to perform any, some, or all of the method steps just described. In one or more embodiments, distinct software modules stored in a non-transitory storage medium, when loaded into the memory, configure the at least one processor to enable it to perform any, some, or all of the method steps just described. As mentioned, the modules may include a registration module 5483, a user interface module 5477, an application store module 5996, and an account mapping engine module 5998.

In view of the discussion thus far, it will be appreciated that, generally speaking, one or more embodiments contemplate an exemplary method of providing a secure online shopping experience at an e-commerce retailer located in a first country to a plurality of consumers located in at least one country different from the first country. The consumers have physical addresses (domestic addresses) in the at least one country different from the first country.

An optional step includes obtaining registration information from a plurality of consumers 598 at the e-wallet server 597. The registration information, in turn, includes at least name, physical address in at least one country different from the first country, and fund payment card account information. For example, the aforementioned optional registration step can be performed through interaction between the wallet platform 597 and consumers 598 facilitated by a suitable consumer interface, such as a graphical user interface (GUI) 1477. For example, the GUI 1477 may comprise HTML delivered from a server on which the platform 597 operates to a browser on the consumer's 598 machine. The registration information may be stored in a database 1479. Also involved in the registration (and account maintenance) process is a registration and account maintenance module 1483, which interfaces with the consumer via the GUI 1477. Optionally, the registration includes obtaining information via a browser using either Secure Sockets Layer (SSL) or Hypertext Transfer Protocol Secure (HTTP URI), and the registration information is stored in the database 1479 in an encrypted manner accessible to the e-wallet server but hidden from the e-commerce retailer.

Another step includes facilitating the assignment of a local delivery address (overseas address) in the first country to a plurality of consumers. For example, this step can be implemented by the delivery merchant interface module 1475.

Yet another step includes obtaining, at the e-wallet server, a request from the e-commerce retailer 895 to assign a local shipping address to the given one of the consumers in conjunction with the consumer's online shopping session at the e-commerce retailer; and yet another step includes providing the local shipping address to the e-commerce retailer in response to the e-commerce retailer's request. These steps may be performed, for example, by the e-commerce retailer interface module 1473 interfaced with the database 1479.

Yet another step includes obtaining, at the e-wallet server, product information and an indication of the desired delivery format (domestic delivery) from the e-commerce retailer to the corresponding local delivery address in conjunction with the online shopping session of a given one of the consumers at the e-commerce retailer. This step can be performed in various ways. In some cases, this information is provided to the wallet 597 from the e-commerce retailer 895, and the step is performed by the e-commerce retailer interface module 1473. In other cases, this information comes from the consumer 598 via a suitable consumer user interface (e.g., GUI 1477).

Another step includes obtaining, at the e-wallet server, an indication of the desired form of delivery (overseas delivery) from the counterpart at the local delivery address to the counterpart at the physical address in at least one country different from the first country, in conjunction with the given one of the consumers' online session at the e-commerce retailer. This step can also be performed in various ways. In some cases, this information is provided to the wallet 597 from the e-commerce retailer 895, and the step can be performed by the e-commerce retailer interface module 1473. However, in other cases, this information comes from the consumer 598 via a suitable consumer user interface (e.g., GUI 1477).

It's worth noting that, at this point, in some cases, the interaction between consumer 598 and retailer 895 is used to specify the desired delivery format from e-commerce retailer 895 to delivery merchant 599. Retailer 895 then provides this information to wallet 597. The total landed cost specifically includes the cost of delivery from merchant 895's warehouse to delivery merchant's warehouse 599, as well as the cost of delivery from delivery merchant's warehouse 599 to the consumer's physical address in their home country. However, retailer 895 typically doesn't care how delivery from delivery merchant's warehouse 599 to the consumer's physical address in their home country occurs. Therefore, in some cases, wallet 597 obtains product information and local delivery information from e-commerce retailer 895. In some cases, once it's known that the item has been delivered from retailer 895 to warehouse 599, the actual delivery from delivery merchant 599 to the consumer's physical address in their home country occurs. In some cases, the steps discussed immediately above provide an estimate of the delivery cost from delivery merchant 599 to the consumer's physical address in their home country, which is used to generate the estimated total landed cost. For the purpose of estimating the total delivery cost, in a non-limiting example, the consumer 598 interacts directly with the wallet 597 via the user interface 1477 or the like to indicate how he or she would like the goods to be delivered to his or her country from the shipping merchant 599. However, as mentioned, in some cases, the retailer 895 acts as an intermediary.

Yet another step includes dispatching, from the e-wallet server, an indication of an estimated total landed cost associated with the online shopping session destined for a given one of the consumers. The estimated total landed cost is based at least in part on the product information, an indication of a desired form of delivery from the e-commerce retailer to a counterpart at a local delivery address, and an indication of a desired form of delivery from the counterpart at the local delivery address to a counterpart at a physical address in at least one country different from the first country. For example, this step may be via user interface 1477 or the like (e.g., GUI 1477 distributes HTML code to the consumer's machine that causes another window to pop up on the consumer's machine); however, in some cases, the retailer 895 acts as an intermediary.

An additional step includes dispatching, from the e-wallet server 597, delivery option information destined for a given one of the consumers 598. The delivery option information provides at least two options for one or both of the deliveries (i.e., delivery from the e-commerce retailer to a counterpart at a local delivery address, and delivery from the counterpart at the local delivery address to a counterpart at a physical address in at least one country different from the first country).

An indication of the desired form of delivery from the e-commerce retailer to the counterpart at the local delivery address or an indication of the desired form of delivery from the counterpart at the local delivery address to the counterpart at a physical address in at least one country different from the first country or (as the case may be) both indications are responsive to the delivery option information.

In one or more embodiments, the delivery option information includes at least one of cost and speed information for each of the at least two options.

Cross-border delivery is currently inconvenient for both consumers and merchants. From the consumer's perspective, cross-border delivery involves having to individually transact with both the merchant and the cross-border delivery service, as the two entities have no relationship with each other. From the merchant's perspective, cross-border delivery is prohibitively expensive for small orders and is significantly more complex than domestic delivery due to varying regulations, taxes, insurance costs, and so on. One or more embodiments advantageously address this issue for both merchants and consumers by integrating with global delivery providers and negotiating affordable rates by aggregating orders from multiple merchants. Merchants can log in to their wallet account and select which countries their current logistics provider delivers to and which countries they would like to deliver to. When a consumer is redirected from the merchant's site to the wallet, the wallet compares the consumer's delivery address with the two lists to determine whether cross-border delivery services are required. If so, the wallet retrieves delivery options and rates from the cross-border delivery service and presents them to the consumer based on pre-set rules by the merchant, or sends the rates to the merchant if no pre-set rules are in place. Once the wallet receives confirmation from the merchant that the transaction was successful, the wallet passes the invoice and instructions on how to fulfill the order (shipping label, pickup time and location, etc.) from the logistics provider to the merchant.

One or more embodiments advantageously solve one or more of the following technical problems:

Create a process flow where the wallet acts as a pass-through between the merchant and the logistics provider;

● Create a shipping feature in the merchant account that allows merchants to select their preferred shipping preferences;

● Create a comparison function in the wallet transaction process that allows the wallet to compare the consumer's data with the merchant's preferences.

Given the discussion thus far, it will be appreciated that, generally speaking, yet another exemplary method includes obtaining product information at an e-wallet server 5497 in conjunction with an online shopping session between a consumer 598 and an e-commerce retailer 1999. This step may be performed, for example, using the e-commerce retailer interface module 5473. Another step 8111 includes dispatching, from the e-wallet server, shipping option information destined for the consumer, thereby providing at least two options for shipping the item associated with the product information from the e-commerce retailer to the consumer. This step may be performed, for example, using the e-commerce retailer interface module 5473 and the shipping engine module 5995. Yet another step 8112 includes obtaining, at the e-wallet server, an indication of a desired shipping format from the e-commerce retailer to the consumer in conjunction with the online shopping session. The indication is based on the shipping option information. This step may be performed, for example, using the e-commerce retailer interface module 5473 and/or the GUI 5477.

In some embodiments, a third party offers alternative delivery methods to those available to the merchant. This includes both domestic and cross-border scenarios. In situations where the merchant outsources delivery, some merchant integration may be appropriate. Domestic delivery options may be offered, either because the entire transaction is within a single country or for the first (domestic) portion of an international transaction. If only delivery from the merchant 599 to the consumer is selected, merchant integration with the retailer 895 is generally not required. The third party may be the delivery merchant 5999, the operator of the platform 5497 (e.g., the operator of the payment network 2008), and the like.

Likewise, in one or more embodiments, the delivery option information includes at least one of cost and speed information for each of the at least two options.

In some cases, additional steps include providing a system, wherein the system includes distinct software modules. Each of the distinct software modules is embodied on a non-transitory computer-readable storage medium. The distinct software modules include at least an e-commerce retailer interface module 5473 and a delivery engine module 5995. The steps are then performed or otherwise facilitated by the modules, as set forth above.

The wallet interface may pop up at the merchant website or may redirect the consumer to the e-wallet site; thus, the last step may be implemented through the interface module 5473 or GUI 5477.

Thus, one or more embodiments contemplate a device (e.g., a server on which an e-wallet platform 5497 runs) comprising: a memory; and at least one processor coupled to the memory and operable to perform any, some, or all of the method steps just described. In one or more embodiments, distinct software modules stored in a non-transitory storage medium, when loaded into the memory, configure the at least one processor to enable it to perform any, some, or all of the method steps just described. As mentioned, the modules may include an e-commerce retailer interface module 5473, a delivery engine module 5995, and (optionally) a GUI module 5477.

In addition, regarding domestic delivery for merchants, consider the following scenarios:

1. The merchant has not hired a logistics company (for example, a merchant in the early stages of a business);

2. The merchant's logistics company provides limited coverage in the country;

3. Logistics partners associated with e-wallets, payment network operators, or similar entities provide value-added services that the merchant’s logistics company does not provide.

In one or more embodiments, when the consumer is redirected to the wallet, the merchant indicates whether it offers domestic delivery and whether there are cities or states that it currently cannot deliver to. Along with this information, the merchant also provides the wallet with an estimate of the package size and weight.

When a wallet receives a customer from a merchant site that doesn't ship domestically, it calculates rates for different shipping options and presents them to the merchant. The merchant can then modify the rates before passing them back to the wallet for presentation to the customer. Alternatively, the merchant can log into the merchant's wallet account and set pricing rules (e.g., use a standard rate for a specific country or add an x% surcharge on top of the carrier's rate). After the customer has selected their preferred shipping option, they proceed to pay for the merchant's merchandise and the shipping costs. After the wallet receives confirmation from the merchant that the transaction was successful, it passes the invoice and instructions on how to fulfill the order (shipping label, pickup time and location, etc.) from the carrier to the merchant.

When the wallet receives a consumer from a merchant site with limited domestic delivery coverage, it will compare the consumer's delivery address with the merchant's list of uncovered areas. If the merchant cannot deliver to the consumer's address, the same process is initiated as when the merchant does not have domestic delivery.

If a merchant already has domestic delivery but wants to use wallet-based delivery due to lower prices or value-added services (e.g., insurance or pickup services), the merchant can select under what circumstances they want to use the wallet delivery service by logging into their merchant account in the wallet. Examples of such circumstances might be when the item to be delivered is fragile or when the value of the item exceeds a certain amount. In integrating these settings, in one or more embodiments, the wallet will initiate domestic delivery when any of these conditions are met.

During the payment process, merchants typically don't share the weight and size of their packages with other parties. Large merchants have their own inventory management systems, and small or medium-sized merchants set their own delivery fees or check the rates of delivery services. In order for merchants (especially small and medium-sized merchants) to send volume data, they must come up with their own internal system for estimating the volume size of the package required for the products a consumer has ordered. This is relatively straightforward when the products are the same or very similar in size (for example, an order for multiple t-shirts). However, when different types of products are involved (for example, belts, shoes, jeans, and t-shirts), accurately estimating the volume size of the package becomes more challenging and is often overestimated.

One or more embodiments address this problem by providing merchants with such a system.

In light of the discussion thus far, and with reference to FIG. 7 , it will be appreciated that, generally speaking, yet another exemplary method includes the step of obtaining, via an e-wallet platform 597, transaction data regarding a transaction between a consumer 2002 and a merchant 1999 providing at least one of goods and services. For example, the transaction data may include a PAN and/or another account number and/or other identifying indicia of the cardholder; data regarding the merchant (e.g., a merchant category code or MCC), the transaction amount, the time and/or location of the transaction; and, where applicable, item-level data from a scanner 134 . The e-wallet platform has at least first and second funding sources available. For example, this step may be implemented using an e-commerce retailer interface module 5473 . Another step includes assigning, from the e-wallet platform 597 , based on the transaction data, a first transaction cost scheme based on the use of a first funding source and a second transaction cost scheme based on the use of a second funding source. The first and second cost schemes are designated for the consumer 2002 . For example, this step may be implemented using an offer comparison module; a non-limiting example of an offer comparison module is the offer comparison module formed by elements 1997 and 1998 in FIG. 7 . Another step includes obtaining, at the e-wallet platform 597, a selection from the consumer 2002 of at least first and second funding sources based on the first and second cost schemes. This step may be performed, for example, using the e-commerce retailer interface module 5473 and/or the GUI 5477. Yet another step includes providing the merchant with an account number associated with the selected funding source. This step may be performed, for example, using the API 5999.

For example, one funding source may generate thirty frequent flyer points; another funding source may generate a 1% discount. This aspect may be server-based or implemented via a smartphone application, for example. In the latter case, after the consumer chooses to download the offers to his or her phone, the database (e.g., offers 5994 in memory 412) stores the discounts locally on the phone—in some cases, all representative offers are stored in a central location (e.g., registry 1997), all representative offers are displayed to the consumer, and the consumer selects which ones he or she wants to store locally on his or her smartphone or the like.

In some cases, the first and second cost scenarios are determined based on different promotions available when using at least the first and second funding sources (e.g., one card in the wallet offers a promotion and the other does not; or both cards offer a promotion but the promotions are different).

In some cases, at least one of the payment options includes a virtual card number; the consumer selects the virtual card number; provides the merchant with the virtual card number; and sends an authorization message for the transaction amount to the issuer, without providing the merchant with the actual card number. In such cases, one or more embodiments determine the correlation of at least one of the first and second cost schemes based on the actual card number, advantageously allowing the consumer to receive promotions or other benefits from the RCN while only revealing the VCN to the merchant. The notation "at least one of the first and second cost schemes is correlated" allows for situations where one cost scheme is based on the VCN and the other is based on the RCN, so any associated quotes are known, as well as situations where both cost schemes involve the VCN.

Point-of-sale (POS) devices are typically designed to read only one card at a time. Therefore, mobile wallets typically require consumers to activate the card they wish to use before presenting their mobile phone to the POS. To compare discounts across several cards, the POS must first detect inactive cards on the mobile wallet and then use the mobile wallet to transfer discounts for those inactive cards. Another current issue is the time it takes to complete the process of comparing inactive cards. As more and more cards are added to the wallet, the time it takes to compare increases. Because transactions must be completed within a fixed amount of time, this limits the number of cards that can be compared within that timeframe. Ultimately, transferring data for all discounts on the cards stored in a consumer's wallet can be error-prone because so much information is being transferred.

In some cases, the cards being compared are cards of the same brand, such as MasterCard. In some cases, the wallet addresses this issue by creating a quote database and causing quotes for the cards stored in the consumer's wallet to be downloaded to the consumer's mobile phone, as seen at 5994; for example, each time one of the consumers adds a card. In at least some instances, periodic updates occur automatically or manually at the consumer's request. Of course, in alternative embodiments, this information can be retrieved from an external database.

In some cases, the first eight digits of a virtual card number often need to match the real card number in order for the merchant to detect what type of card is being used. However, virtual card numbers are often randomly generated, making it impossible for the merchant to identify the card's issuer. In some cases, the wallet addresses this issue by using a quote database. When passing the transaction to the issuer for authorization, the wallet compares the real card number to the quote database and applies any applicable discounts. After the issuer authorizes the transaction, the wallet sends the updated amount to the issuer along with details of the applied discount.

In some cases, additional steps include providing a system, wherein the system includes distinct software modules. Each of the distinct software modules is embodied on a non-transitory computer-readable storage medium. The distinct software modules include at least an e-commerce retailer interface module 5473 and a quote comparison module (e.g., 1997, 1998) and an application program interface 5999. The steps are then performed or otherwise facilitated by the modules, as set forth above.

Thus, one or more embodiments contemplate a device (e.g., a server on which an e-wallet platform 5497 runs) comprising: a memory; and at least one processor coupled to the memory and operable to perform any, some, or all of the method steps just described. In one or more embodiments, distinct software modules stored in a non-transitory storage medium, when loaded into the memory, configure the at least one processor to enable it to perform any, some, or all of the method steps just described. As mentioned, the modules may include an e-commerce retailer interface module 5473 and an offer comparison module (e.g., 1997, 1998), an application program interface 5999, and (optionally) a GUI module 5477.

In yet another aspect, a method includes the step of obtaining, via an e-wallet mobile application 12, transaction data regarding a transaction between a consumer and a merchant for providing at least one of goods and services (non-limiting examples of transaction data are provided above). The e-wallet mobile application has at least first and second funding sources available. Another step includes determining, via the e-wallet mobile application, a first transaction cost scheme based on the use of the first funding source and a second transaction cost scheme based on the use of the second funding source based on the transaction data (e.g., by comparing quotes 5994 downloaded to memory 412). Yet another step includes obtaining, from the consumer, a selection of at least first and second funding sources based on the first and second cost schemes (e.g., via interaction with screen 410). Yet another step includes providing the merchant with an account number associated with the selected funding source (e.g., via antenna 1800). In some cases, another optional step includes downloading at least the first and second quotes 5994 to the e-wallet mobile application. The first and second cost schemes are based on the first and second quotes.

"Cost scheme" should be understood broadly to include direct total cost comparisons, the possibility of receiving a free gift in one scheme but not in another; the possibility of different free gifts being available in different schemes, the possibility of promotional coupons being available in some schemes but not others; the possibility of different promotional coupons being offered in different schemes, etc.

From the perspective of one or more servers, the steps include downloading the application, VCN and quote to a smartphone or similar, and intercepting the VCN's "authorization" request and converting the VCN to an RCN.

Thus, one or more embodiments contemplate a device (e.g., mobile phone 10) comprising: a memory; and at least one processor coupled to the memory and operable to perform any, some, or all of the method steps just described. In one or more embodiments, distinct software modules stored in a non-transitory storage medium, when loaded into the memory, configure the at least one processor to enable it to perform any, some, or all of the method steps just described. As mentioned, the modules may include a wallet application 12.

As mentioned, one or more embodiments of the present invention or its elements can be implemented in the form of a system (or device) comprising: a memory; and at least one processor coupled to the memory and operable to perform or otherwise facilitate the exemplary method steps. Examples include server 300 or smartphone 10 or the like.

System and product details

Embodiments of the present invention may utilize hardware and/or hardware and software aspects. Systems include, but are not limited to, firmware, resident software, microcode, and the like. For example, software may be used in conjunction with one or more of terminals 122, 124, 125, and 126; readers 132; payment devices (e.g., cards 102 and 112); hosts, servers, and/or processing centers 140, 142, and 144 (optionally with data repositories) of merchants, issuers, and acquirers, or operators of networks 2008 operating according to payment system standards (and/or specifications); smartphones 10; wallet servers running wallet platforms 597 or 5497; or other servers. For example, firmware may be used in conjunction with payment devices (e.g., cards 102 and 112 and reader 132). Firmware provides many basic functions (e.g., display, print, accept buttons) that do not themselves provide an end use but are building blocks; software connects the building blocks together to deliver a usable solution.

FIG8 is a block diagram of a system 300 that may implement part or all of one or more aspects or processes of the present invention. As shown in FIG8 , memory 330 configures processor 320 (which may correspond, for example, to processor options 106, 116, 130; a processor of a remote host in hubs 140, 142, 144; a processor of a server implementing the wallet platform or other blocks shown in the figure, and the like) to implement one or more aspects of the methods, steps, and functions disclosed herein (collectively shown as process 380 in FIG8 ). Different method steps may be performed by different processors. Processor 330 may be distributed or local, and processor 320 may be distributed or single. Memory 330 may be implemented as electronic, magnetic, or optical memory, or any combination of these or other types of storage devices (including the memory portions described above with respect to cards 102 and 112); for example, memory 412 of smartphone 10 may be similar. Note that if distributed processors are used, each distributed processor comprising processor 320 generally contains its own addressable memory space. It should also be noted that some or all of computer system 300 may be incorporated into a dedicated or general purpose integrated circuit. For example, one or more method steps may be implemented in hardware in an ASIC rather than using firmware. Display 340 represents various possible input/output devices (e.g., a display, mouse, keyboard, and the like).

The notation "to/from network" indicates various possible network interface devices.

As is known in the art, some or all of one or more aspects of the methods and apparatus discussed herein may be distributed as an article of manufacture, which itself includes a tangible computer-readable recordable storage medium having computer-readable code means embodied thereon. The computer-readable program code means may be used in conjunction with a computer system operating to perform all or some of the steps described to execute the method or produce the apparatus discussed herein. Generally, the computer-usable medium may be a recordable medium (e.g., a floppy disk, hard drive, compact disc, EEPROM, or memory card) or a transmission medium (e.g., a network including optical fiber, the World Wide Web, cable, or a wireless channel using time division multiple access, code division multiple access, or other radio frequency channels). Any known or developed medium suitable for use with a computer system that can store information may be used. The computer-readable code means is any mechanism for allowing a computer to read instructions and data (e.g., magnetic variations on magnetic media or height variations on the surface of a compact disc). The media may be distributed across multiple physical devices (or even multiple networks). For example, one device may be a physical storage medium associated with a terminal and another device may be a physical storage medium associated with a processing center. As used herein, tangible computer-readable recordable storage media is defined to include non-transitory recordable media (examples of which are set forth above) but not transmission media or intangible signals.

The computer systems and servers discussed herein each contain memory that configures the associated processor to implement the methods, steps, and functions disclosed herein. By way of example and not limitation, such methods, steps, and functions may be implemented by processing power on elements 140, 142, 144, 5497 (i.e., the physical machines on which the e-wallet platform and its associated interfaces and/or database modules run), 2004, 2006, 2008, 2010; processor 402; or by any combination thereof. The memory may be distributed or local, and the processor may be distributed or single. The memory may be implemented as electronic, magnetic, or optical memory, or any combination of these or other types of storage devices. Furthermore, the term "memory" should be interpreted broadly enough to encompass any information that can be read from or written to an address in a searchable space accessible by the associated processor. Under this definition, information on a network remains in memory because the associated processor can retrieve the information from the network.

Thus, the elements of one or more embodiments of the present invention can utilize computer technology with appropriate instructions to implement the method steps described herein as being performed by one or more processors. For example, various platforms can be implemented using one or more servers comprising a memory and at least one processor coupled to the memory. The processor can load appropriate software. The processor can be operated to perform one or more method steps discussed herein or otherwise facilitate their performance.

Thus, it will be understood that one or more embodiments of the present invention may include a computer program comprising computer program code means adapted to perform one or all of the steps of any method or claim when such software is run on a computer, and such program may be embodied on a computer-readable medium. Furthermore, one or more embodiments of the present invention may include a computer comprising code adapted to cause a computer to perform one or more steps of the method or claim recited herein, and one or more apparatus elements or features as depicted and described herein.

As used herein, including in the claims, a "server" includes a physical data processing system (e.g., system 300 shown in FIG8 ) that runs a server program. It will be understood that this physical server may or may not include a display, keyboard, or other input/output components. A "host" includes a physical data processing system (e.g., system 300 shown in FIG8 ) that runs appropriate software. It will be understood that this host may or may not include a display, keyboard, or other input/output components.

Furthermore, it should be noted that any of the methods described herein may include the additional step of providing a system of distinct software modules embodied on one or more tangible computer-readable storage media. For example, all of the modules (or any subset thereof) may reside on the same media or may each reside on a different media. The modules may include any or all of the components shown in the figures. In one or more embodiments, the modules include modules for implementing the functional blocks shown in Figures 5 and/or 54; application 12; and the like. The blocks may be implemented by software modules along with corresponding memory and one or more processors. For example, the modules may run on one or more hardware processors of one or more e-wallet servers; generally, all modules may run on the same server, each module may run on a separate server, and so on. In some cases, blocks 1478 and 5479 may run on one or more database servers. In a preferred, but non-limiting manner, elements 597 and 5497 comprise a software platform, while the interface modules comprise code for implementing the indicated functionality and any required translation functionality for interfacing with external systems. The method steps may then be performed using the distinct software modules of the system as described above executed on one or more hardware processors. In addition, a computer program product may include a tangible computer-readable recordable storage medium having code suitable for performing one or more method steps described herein, including providing the distinct software modules to the system.

For example, the computers discussed herein may be interconnected by one or more of network 138, 987, 2008, another virtual private network (VPN), the Internet, a local area network and/or a wide area network (LAN and/or WAN), via an EDI layer, etc. For example, the computers may be programmed with one or more of compiled, interpreted, object-oriented, assembled, and/or machine languages, such as C, C++, Java, Visual Basic, JavaScript, or other ECMAScript-based scripting languages, and the like (an exemplary and non-limiting list), and may also utilize, for example, Extensible Markup Language (XML), JSON, name/value pairs, known applications, such as relational database applications, spreadsheets, and the like. The computers may be programmed to implement the logic depicted in the flow charts and other figures. In at least some cases, at least some of the messages may be in accordance with ISO 8583.

Although illustrative embodiments of the present invention have been described herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments and that various other changes and modifications may be made by those skilled in the art without departing from the scope or spirit of the invention.

Claims (12)

1. A method for operating an e-wallet platform running on a server, the method comprising the following steps: The registration information of multiple consumers is obtained through the e-wallet platform, wherein the registration information includes the actual card number; The interface module of the e-wallet platform is made available to multiple merchants. The interface module includes executable code stored on a non-transitory computer-readable storage medium. When the code is loaded into the memory of the server, it causes one or more processors of the server to translate data between the wallet platform and the merchant. Through the e-wallet platform, a given consumer is given the option to choose from multiple methods to pay for transactions with a given merchant, said multiple methods being at least partially based on the registration information, and at least one of said multiple methods including a virtual card number associated with the actual card number, wherein said actual card number is different from said virtual card number; The selection of a virtual card number for payment of the transaction is obtained from a given consumer through the e-wallet platform, wherein the virtual card number needs to be mapped to the physical card number to complete the transaction; and The virtual card number is provided to the given party in the merchant through the interface module of the e-wallet platform, but the actual card number is not provided. The virtual card number facilitates the payment related to the transaction only based on the mapping to the actual card number. 2. The method according to claim 1, further comprising: The authorization request to record the transaction amount into the virtual card number is intercepted from the given party among the merchants; The virtual card number is translated into the actual card number, which is not provided to the merchant; and The authorization request is transmitted to the issuing institution, wherein the actual card number is included in the authorization request. 3. The method according to claim 2, wherein: The transactions include online transactions on the website of the given party among the merchants; and The selection of the virtual card number is obtained from the computing device of the given person among the consumers at the electronic wallet platform via Internet communication. 4. The method of claim 1, further comprising providing a system, wherein the system includes dissimilar software modules, each of which is embodied on a non-transitory computer-readable storage medium, and wherein the dissimilar software modules include a registration module, a user interface module, the interface module, and a payment method engine module. in: The acquisition of the registration information is performed by the registration module and the user interface module, which are executed on at least one hardware processor; The option given to the giver among the consumers is implemented by the payment method engine module and the user interface module, which execute on the at least one hardware processor; and The selection of the virtual card number for payment of the transaction from the given consumer is performed by the payment method engine module and the user interface module, which are executed on the at least one hardware processor. 5. The method according to claim 4, wherein the dissimilar software module further includes an account mapping engine module, and the method further includes: By executing the account mapping engine module on the at least one hardware processor, an authorization request to credit the transaction amount to the virtual card number is intercepted from the given party among the merchants; By executing the account mapping engine module on the at least one hardware processor, the virtual card number is translated into the actual card number not provided to the merchant; and The authorization request is transmitted to the issuing authority by executing the account mapping engine module on the at least one hardware processor, wherein the actual card number is included in the authorization request. 6. An electronic wallet platform server device, comprising: Memory; and At least one processor coupled to the memory, the at least one processor being operable to: Obtain registration information from multiple consumers, wherein the registration information includes actual card numbers; The interface module of the wallet platform server device is made available to multiple merchants. The interface module includes executable code stored on a non-transitory computer-readable storage medium. When the code is loaded into the memory of the server, it causes the at least one processor to perform data translation between the wallet platform and the merchant. A given consumer is given the option to choose from multiple methods to pay for a transaction with a given merchant, said multiple methods being at least partially based on the registration information, and at least one of said multiple methods including a virtual card number associated with the actual card number, wherein said actual card number is different from said virtual card number; The selection of a virtual card number for payment of the transaction is obtained from the given consumer, wherein the virtual card number needs to be mapped to the physical card number to complete the transaction; and The virtual card number is provided to the given party in the merchant through the interface module, but the actual card number is not provided. The virtual card number facilitates the payment related to the transaction only based on the mapping to the actual card number. 7. The e-wallet platform server device according to claim 6, wherein the at least one processor is further operable to: The authorization request to record the transaction amount into the virtual card number is intercepted from the given party among the merchants; Translate the virtual card number into the actual card number that is not provided to the merchant; and The authorization request is passed to the issuing structure, wherein the actual card number is included in the authorization request. 8. The e-wallet platform server device according to claim 7, wherein: The transactions include online transactions on the website of the given party among the merchants; and The selection of the virtual card number is obtained from the computing device of the given person among the consumers at the electronic wallet platform via Internet communication. 9. The e-wallet platform server device according to claim 6, further comprising a plurality of dissimilar software modules embodied on the non-transitory computer-readable storage medium, wherein the dissimilar software modules include a registration module, a user interface module, the interface module, and a payment method engine module, and wherein: When the registration module and the user interface module are loaded into the memory, the at least one processor is configured to operate to obtain the registration information of the plurality of consumers; When the payment method engine module and the user interface module are loaded into the memory, the at least one processor is configured to operate to provide the options to the giver among the consumers; When the payment method engine module and the user interface module are loaded into the memory, the at least one processor is configured to operate to obtain the selection of the virtual card number from the given consumer; and When disclosing to the merchant, the interface module allows the at least one processor to send the virtual card number to the given person in the merchant. 10. The e-wallet platform server device of claim 9, wherein the dissimilar software module further includes an account mapping engine module, and wherein the account mapping engine module, when loaded into the memory, configures the at least one processor to further operate to: The authorization request to record the transaction amount into the virtual card number is intercepted from the given party among the merchants; The virtual card number is translated into the actual card number that is not provided to the merchant; and The authorization request is transmitted to the issuing institution, wherein the actual card number is included in the authorization request. 11. An electronic wallet platform server device, comprising: A component for obtaining registration information of multiple consumers at an e-wallet platform, wherein the registration information includes actual card numbers; A component for making the interface module of the e-wallet platform available to multiple merchants, the interface module including executable code stored on a non-transitory computer-readable storage medium, the code, when loaded into the server's memory, causing one or more processors of the server to translate data between the wallet platform and the merchant; Components for providing a given consumer with options to choose from multiple methods to pay for a transaction with a given merchant via the e-wallet platform, the multiple methods being at least partially based on the registration information, at least one of the multiple methods including a virtual card number associated with the actual card number, wherein the actual card number is different from the virtual card number; A component for selecting a virtual card number from the given consumer for paying the transaction, wherein the virtual card number needs to be mapped to the actual card number to complete the transaction; and A component for providing the virtual card number to the given party in the merchant but not the actual card number through the interface module of the e-wallet platform, the virtual card number facilitating payment related to the transaction solely based on the mapping to the actual card number. 12. A non-transitory computer-readable and recordable storage medium having instructions stored thereon, wherein the instructions, when executed by a processor, cause the processor to perform the following operations: Obtain registration information from multiple consumers, wherein the registration information includes actual card numbers; The interface module of the wallet platform is made available to multiple merchants. The interface module includes at least a portion of the instructions, which, when executed by the processor, cause the processor to translate data between the wallet platform and the merchant. A given consumer is given the option to choose from multiple methods to pay for a transaction with a given merchant, said multiple methods being at least partially based on the registration information, and at least one of said multiple methods including a virtual card number associated with the actual card number, wherein said actual card number is different from said virtual card number; The selection of a virtual card number for payment of the transaction is obtained from the given consumer, wherein the virtual card number needs to be mapped to the physical card number to complete the transaction; and The virtual card number is provided to the given party in the merchant through the interface module of the wallet platform, but the actual card number is not provided. The virtual card number facilitates the payment related to the transaction only based on the mapping to the actual card number.