ELECTRONIC WALLET APPARATUS, METHOD, AND COMPUTER PROGRAM PRODUCT
Registration information for a plurality of consumers is obtained at an electronic wallet platform. A mechanism is provided to integrate the electronic wallet platform with a plurality of merchants. Via the electronic wallet platform, a given one of the consumers is afforded an option to select from multiple methods to pay for a transaction with a given one of the merchants. 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. Further steps include obtaining, from the given one of the consumers, a selection of the virtual card number for payment for the transaction; and providing the given one of the merchants with the virtual card number.
This patent application is a divisional of U.S. patent application Ser. No. 13/836,326, filed Mar. 15, 2013, entitled ELECTRONIC WALLET APPARATUS, METHOD, AND COMPUTER PROGRAM PRODUCT, which in turn claims the benefit of U.S. Provisional Patent Application Ser. No. 61/722,294, filed Nov. 5, 2012, entitled ELECTRONIC WALLET APPARATUS, METHOD, AND COMPUTER PROGRAM PRODUCT. The complete disclosures of the aforementioned patent application Ser. No. 13/836,326 and Provisional Patent Application Ser. No. 61/722,294 are expressly incorporated herein by reference in their entireties for all purposes.
FIELD OF THE INVENTIONThe present invention relates generally to electronic commerce, and, more particularly, to electronic payment systems.
BACKGROUND OF THE INVENTIONWith the growth of Internet commerce, the electronic wallet (e-wallet), also known as a digital wallet, has been developed. An e-wallet provides consumers with a secure and convenient way to pay for purchases from accepting on-line merchants. Upon registration, consumers may store their card, billing and shipping information on a site hosted by a suitable entity, and may access that information to pay conveniently and securely across participating merchants.
SUMMARY OF THE INVENTIONPrinciples of the present invention provide techniques for an electronic wallet apparatus, method, and computer program product. An exemplary embodiment of a method, according to one aspect of the invention, includes obtaining, at an electronic wallet platform, registration information for a plurality of consumers; providing a mechanism to integrate the electronic wallet platform with a plurality of merchants; and, via the electronic wallet platform, affording a given one of the consumers an option to select from multiple methods to pay for a transaction with a given one of the merchants. 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. Further steps include obtaining, from the given one of the consumers, a selection of the virtual card number for payment for the transaction; and providing the given one of the merchants with the virtual card number.
In another aspect, another exemplary method includes obtaining, at an electronic wallet platform, registration information for a plurality of consumers; and making available to the consumers a secure application for portable devices of the consumers which affords the consumers an option to select from multiple methods to pay for transactions with merchants. 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. A further step includes intercepting an authorization request, from a given one of the merchants, for an amount of a given one of the transactions to be charged against a given one of the virtual card numbers. The given one of the transactions includes a given one of the consumers presenting a given one of the portable devices, having the secure application thereon, at a point-of-sale terminal of the given one of the merchants. The virtual card number had been provided to the merchant via communication between the given one of the portable devices and the point-of-sale terminal of the given one of the merchants. Further steps include translating the given one of the virtual card numbers into an actual card number which is not provided to the given one of the merchants; and passing the authorization request to an issuer, with the actual card number therein.
In a further aspect, another exemplary method includes obtaining, at an electronic wallet server, product information in connection with an on-line shopping session of a consumer with an e-commerce retailer; dispatching, from the electronic wallet server, shipping option information, destined for the consumer, providing at least two options for shipping goods, associated with the product information, from the e-commerce retailer to the consumer; and obtaining, at the electronic wallet server, in connection with the on-line shopping session, an indication of a desired form of shipping from the e-commerce retailer to the consumer, the indication being based on the shipping option information.
In a still further aspect, another exemplary method includes obtaining, by an electronic wallet platform, transaction data pertaining to a transaction between a consumer and a merchant for provision of at least one of goods and services. The electronic wallet platform has at least first and second funding sources available. A further step includes dispatching, from the electronic wallet platform, based on the transaction data, a first cost scenario for the transaction based on use of the first one of the funding sources and a second cost scenario for the transaction based on use of the second one of the funding sources. The first and second cost scenarios are destined for the consumer. Further steps include obtaining, at the electronic wallet platform, from the consumer, a selection, from among the at least first and second funding sources, based on the first and second cost scenarios; and providing the merchant an account number associated with the selected funding source.
In an even further aspect, another exemplary method includes obtaining, by an electronic wallet mobile application, transaction data pertaining to a transaction between a consumer and a merchant for provision of at least one of goods and services. The electronic wallet mobile application has at least first and second funding sources available. Further steps include determining, by the electronic wallet mobile application, based on the transaction data, a first cost scenario for the transaction based on use of the first one of the funding sources and a second cost scenario for the transaction based on use of the second one of the funding sources; obtaining, at the electronic wallet mobile application, from the consumer, a selection, from among the at least first and second funding sources, based on the first and second cost scenarios; and providing the merchant an account number associated with the selected funding source.
In yet a further aspect, an exemplary wallet platform server apparatus includes a memory; and at least one processor, coupled to said memory. Said at least one processor is operative to: obtain registration information for a plurality of consumers; integrate with a plurality of merchants; and afford a given one of said consumers an option to select from multiple methods to pay for a transaction with a given one of said merchants. Said multiple methods are based, at least in part, on said registration information. At least one of said multiple methods comprises a virtual card number. Said at least one processor is operative to obtain, from said given one of said consumers, a selection of said virtual card number for payment for said transaction; and provide said given one of said merchants with said virtual card number.
Aspects of the invention contemplate the method(s) performed by one or more entities herein, as well as facilitating of one or more method steps by the same or different entities. As used herein, “facilitating” an action includes performing the action, making the action easier, helping to carry the action out, or causing the action to be performed. Thus, by way of example and not limitation, instructions executing on one processor might facilitate an action carried out by instructions executing on a remote processor, by sending appropriate data or commands to cause or aid the action to be performed. For the avoidance of doubt, where an actor facilitates an action by other than performing the action, the action is nevertheless performed by some entity or combination of entities.
One or more embodiments of the invention or elements thereof can be implemented in the form of a computer program product including a tangible computer readable recordable storage medium with computer usable program code for performing the method steps indicated stored thereon in a non-transitory manner. Furthermore, one or more embodiments of the invention or elements thereof can be implemented in the form of a system (or apparatus) including a memory and at least one processor that is coupled to the memory and operative to perform exemplary method steps. For example, the computer readable program code, when executed on one or more processors, cerates the platform 5497. Yet further, in another aspect, one or more embodiments of the invention or elements thereof can be implemented in the form of means for carrying out one or more of the method steps described herein; the means can include (i) specialized hardware module(s), (ii) software module(s) stored in a non-transitory manner in a tangible computer-readable recordable storage medium (or multiple such media) and implemented on a hardware processor, or (iii) a combination of (i) and (ii); any of (i)-(iii) implement the specific techniques set forth herein. The means are defined to exclude a transmission medium per se or a disembodied signal per se.
One or more embodiments of the invention can provide substantial beneficial technical effects, including, for example,
-
- Creating a process flow wherein a pass-through is provided between the merchant and logistics provider
- Creating one or more shipping functions in a merchant account that allow merchants to select their preferences
- Creating a comparison function in a transaction flow that permits comparison of the consumer's data with the merchant's preferences
- Allowing small or medium-sized merchants to more accurately determine volumetric data regarding products to be shipped, to thereby allow, for example, more accurate estimation of shipping times and/or costs
- Reducing time expended and/or likelihood of errors in determining which payment vehicle offers the best terms for a given transaction
- Permit enhanced security of a virtual card number while allowing consumer to obtain benefit of offers, discounts, and the like linked to a real card number.
These and other features and advantages of the present invention will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings.
Attention should now be given to
System 100 can include one or more different types of portable payment devices. For example, one such device can be a contact device such as card 102. Card 102 can include an integrated circuit (IC) chip 104 having a processor portion 106 and a memory portion 108. A plurality of electrical contacts 110 can be provided for communication purposes. In addition to or instead of card 102, system 100 can also be designed to work with a contactless device such as card 112. Card 112 can include an IC chip 114 having a processor portion 116 and a memory portion 118. An antenna 120 can be provided for contactless communication, such as, for example, using radio frequency (RF) electromagnetic waves. An oscillator or oscillators, and/or additional appropriate circuitry for one or more of modulation, demodulation, downconversion, and the like can be provided. Note that cards 102, 112 are exemplary of a variety of devices that can be employed. The system per se may function with other types of devices in lieu of or in addition to “smart” or “chip” cards 102, 112; for example, a conventional card 150 having a magnetic stripe 152. Furthermore, an appropriately configured cellular telephone handset, personal digital assistant (PDA), and the like can be used to carry out contactless payments in some instances.
The ICs 104, 114 can contain processing units 106, 116 and memory units 108, 118. Preferably, the ICs 104, 114 can also include one or more of control logic, a timer, and input/output ports. Such elements are well known in the IC art and are not separately illustrated. One or both of the ICs 104, 114 can also include a co-processor, again, well-known and not separately illustrated. The control logic can provide, in conjunction with processing units 106, 116, the control necessary to handle communications between memory unit 108, 118 and the input/output ports. The timer can provide a timing reference signal from processing units 106, 116 and the control logic. The co-processor could provide the ability to perform complex computations in real time, such as those required by cryptographic algorithms.
The memory portions or units 108, 118 may include different types of memory, such as volatile and non-volatile memory and read-only and programmable memory. The memory units can store transaction card data such as, e.g., a user's primary account number (“PAN”) and/or personal identification number (“PIN”). The memory portions or units 108, 118 can store the operating system of the cards 102, 112. The operating system loads and executes applications and provides file management or other basic card services to the applications. One operating system that can be used is the MULTOS® operating system licensed by MAOSCO Limited. (MAOSCO Limited, St. Andrews House, The Links, Kelvin Close, Birchwood, Warrington, WA3 7PB, United Kingdom) Alternatively, JAVA CARD™-based operating systems, based on JAVA CARD™ technology (licensed by Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, Calif. 95054 USA), or proprietary operating systems available from a number of vendors, could be employed. Preferably, the operating system is stored in read-only memory (“ROM”) within memory portion 108, 118. In an alternate approach, flash memory or other non-volatile and/or volatile types of memory may also be used in the 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. At present, one possible specification to which such applications may conform is the EMV interoperable payments specification set forth by EMVCo, LLC (901 Metro Center Boulevard, Mailstop M3-3D, Foster City, Calif., 94404, USA). It will be appreciated that applications can be configured in a variety of different ways.
As noted, cards 102, 112 are examples of a variety of payment devices that can be employed. The primary function of the payment devices may not be payment, for example, they may be cellular phone handsets that implement aspects of the invention. Such devices could include cards having a conventional form factor, smaller or larger cards, cards of different shape, key fobs, personal digital assistants (PDAs), appropriately configured cell phone handsets, or indeed any device with the capabilities to implement aspects of the invention. In some cases, the cards, or other payment devices, can include body portions (e.g., laminated plastic layers of a payment card, case or cabinet of a PDA or cellular phone, chip packaging, and the like), memories 108, 118 associated with the body portions, and processors 106, 116 associated with the body portions and coupled to the memories. The memories 108, 118 can contain appropriate applications. The processors 106, 116 can be operative to facilitate execution of one or more method steps. The applications can be, for example, application identifiers (AIDs) linked to software code in the form of firmware plus data in a card memory such as an electrically erasable programmable read-only memory (EEPROM).
A number of different types of terminals can be employed with system 100. Such terminals can include a contact terminal 122 configured to interface with contact-type device 102, a wireless terminal 124 configured to interface with wireless device 112, a magnetic stripe terminal 125 configured to interface with a magnetic stripe device 150, or a combined terminal 126. Combined terminal 126 is designed to interface with any type of device 102, 112, 150. Some terminals can be contact terminals with plug-in contactless readers. Combined terminal 126 can include a memory 128, a processor portion 130, a reader module 132, and optionally an item interface module such as a bar code scanner 134 and/or a radio frequency identification (RFID) tag reader 136. Items 128, 132, 134, 136 can be coupled to the processor 130. Note that the principles of construction of terminal 126 are applicable to other types of terminals and are described in detail for illustrative purposes. Reader module 132 can, in general, be configured for contact communication with card or device 102, contactless communication with card or device 112, reading of magnetic stripe 152, or a combination of any two or more of the foregoing (different types of readers can be provided to interact with different types of cards e.g., contacted, magnetic stripe, or contactless). Terminals 122, 124, 125, 126 can be connected to one or more processing centers 140, 142, 144 via a computer network 138. Network 138 could include, for example, the Internet, or a proprietary network (e.g., a virtual private network (VPN) such as is described with respect to
Many different retail or other establishments, represented by points-of-sale 146, 148, can be connected to network 138. Different types of portable payment devices, terminals, or other elements or components can combine or “mix and match” one or more features depicted on the exemplary devices in
Portable payment devices can facilitate transactions by a user with a terminal, such as 122, 124, 125, 126, of a system such as system 100. Such a device can include a processor, for example, the processing units 106, 116 discussed above. The device can also include a memory, such as memory portions 108, 118 discussed above, that is coupled to the processor. Further, the device can include a communications module that is coupled to the processor and configured to interface with a terminal such as one of the terminals 122, 124, 125, 126. The communications module can include, for example, the contacts 110 or antennas 120 together with appropriate circuitry (such as the aforementioned oscillator or oscillators and related circuitry) that permits interfacing with the terminals via contact or wireless communication. The processor of the apparatus can be operable to perform one or more steps described herein. The processor can perform such operations via hardware techniques, and/or under the influence of program instructions, such as an application, stored in one of the memory units.
The portable device can include a body portion. For example, this could be a laminated plastic body (as discussed above) in the case of “smart” or “chip” cards 102, 112, or the handset chassis and body in the case of a cellular telephone.
It will be appreciated that the terminals 122, 124, 125, 126 are examples of terminal apparatuses for interacting with a payment device of a holder. The apparatus can include a processor such as processor 130, a memory such as memory 128 that is coupled to the processor, and a communications module such as 132 that is coupled to the processor and configured to interface with the portable apparatuses 102, 112, 1420 (discussed below). The processor 130 can be operable to communicate with portable payment devices of a user via the communications module 132. The terminal apparatuses can function via hardware techniques in processor 130, or by program instructions stored in memory 128. Such logic could optionally be provided from a central location such as processing center 140 over network 138. The aforementioned bar code scanner 134 and/or RFID tag reader 136 can be provided, and can be coupled to the processor, to gather attribute data, such as a product identification, from a UPC code or RFID tag on a product to be purchased.
The above-described devices 102, 112 can be ISO 7816-compliant contact cards or devices or NFC (Near Field Communications) or ISO 14443-compliant proximity cards or devices. In operation, card 112 can be touched or tapped on the terminal 124 or 128 (or an associated reader), which then contactlessly transmits the electronic data to the proximity IC chip in the card 112 or other wireless device.
One or more of the processing centers 140, 142, 144 can include a database such as a data warehouse 154.
A dual-interface device 1302 is sometimes employed. Device 1302 is shown larger than devices 102, 112 for illustrative convenience but can 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, can be provided, as well as an antenna 1320 similar to antenna 120, together with an oscillator or oscillators, and/or additional appropriate circuitry for one or more of modulation, demodulation, downconversion, and the like, as described with regard to device 112. Appropriate firmware to manage the two available interfaces can be provided, with operation otherwise being similar to devices 102, 112.
An appropriately configured cellular telephone handset 1420 can also be employed in a number of embodiments. Handset 1420 is depicted in semi-schematic form in
The description of devices, elements, or components 102, 104, 106, 108, 110, 112, 114, 116, 118, 120 throughout this document are equally applicable to the corresponding items in the dual interface card 1302 and cellular telephone handsets 10, 1420.
With reference to
In some cases, network 2008 uses ISO 8583 messaging. ISO 8583, Financial transaction card originated messages—Interchange message specifications, is the International Organization for Standardization standard for systems that exchange electronic transactions made by cardholders using payment cards. It has three parts: Part 1: Messages, data elements and code values; Part 2: Application and registration procedures for Institution Identification Codes (IIC); 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. The skilled artisan in the payments processing field will be thoroughly familiar with ISO 8583 in any case.
During a conventional credit authorization process, the cardholder 2002 pays for the purchase and the merchant 2004 submits the transaction to the acquirer (acquiring bank) 2006. The acquirer verifies the card number, the transaction type and the amount with the issuer 2010 and reserves that amount of the cardholder's credit limit for the merchant. At this point, the authorization request and response have been exchanged, typically in real time. Authorized transactions are stored in “batches,” which are sent to the acquirer 2006. During subsequent clearing and settlement, the acquirer sends the batch transactions through the credit card association, which debits the issuers 2010 for payment and credits the acquirer 2006. Once the acquirer 2006 has been paid, the acquirer 2006 pays the merchant 2004.
It will be appreciated that the network 2008 shown in
As seen in
Referring now to
As further described in
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 phone 10. In this process, the wallet plays the role of a “virtual terminal,” interacting with the secure element, and upon verification of the PIN, passes the CHIP token (Authorization Request Cryptogram or ARQC) to the merchant for authorization. In this “virtual terminal”, the secure element serves the role as the “card.” Offline PIN 20 can, for example, be used in connection with a PayPass® payment. The skilled artisan will be familiar with the terminology used in the description of
Secure Code PIN 22 is a PIN associated with a card enrolled in the MasterCard SecureCode® system (registered mark of MasterCard International Incorporated, Purchase, N.Y., USA). It is contemplated herein that the SecureCode system could also utilize a password and/or code, rather than a PIN.
Online PIN 24 is used in an online PIN verification process whereby the wallet application 12 plays the role of a “virtual terminal,” interacting to encrypt the PIN for transmission to the merchant. The use of an online PIN verification process may provide greater flexibility in authenticating transactions by, for example, allowing an issuing bank to authenticate the transactions associated with its cardholders without the need for the issuing bank to enroll/register its cardholders and/or adopt new infrastructure.
Users may have different instances of wallet application 12 on different phones. A sync service can maintain 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 can be synchronized between various machines.) Merchants can add a piece of code to their checkout button that invokes the wallet application. During checkout, users select card and shipping address (if needed). The authentication PIN is entered into the phone in response to a prompt from the mobile application. The wallet passes back the information to the merchant who submits this information through existing channels (internet gateway or payment processor), i.e., no changes are required to existing processes or integration.
In a non-limiting example, the wallet application may be a browser HTML 5 application (not a native application) that self-installs in the mobile phone or computer browser on the first use. In a non-limiting example, the wallet application is downloaded to the smart phone 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, secure token if used, virtual and/or real card number(s), etc.). This information can be used for a number of purposes; in some cases, to authenticate to the remote server. This also enables offline transactions. The mobile application can preferably “talk” to the secure element on the phone (which may be on the subscriber identity module (SIM card) of the phone, for example). In this regard, the mobile application could play the role of a virtual POS terminal in initiating card present CHIP plus PIN transactions. On the other hand, in some cases, the smart phone or the like is only used as an actual payment device at a POS.
In some instances, a consumer may 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 both 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 the authenticating PIN, and the transaction is then completed. At that point, the consumer is preferably returned to the merchant's site. This is a non-limiting example. Some embodiments are directed to card-not-present Internet commerce with 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 smart phone or the like for use in transactions with the smart phone at brick and mortar retailers.
One or more embodiments provide one or more benefits to the consumer. Some embodiments provide easy and convenient checkout through a form fill or pass through function, which is preferably part of the wallet application 12. Some embodiments provide secure payments via a PIN, or other biometric parameters such as a voice print or fingerprint. In this regard, the smart phone may be provided with a biometric reader and/or analyzer. Some embodiments omit one, some, or all of these features.
One or more embodiments provide one or more benefits to the merchant. Some embodiments include a potential liability shift from the merchant to the authorizing bank for all wallet-based transactions. More particularly, the use of an authentication process for remote transactions reduces the risk of fraud associated with such transactions, and may limit and/or reverse the shifting of fraud liability from the authorizing bank to the merchant. The use of the authentication process may also provide more attractive economics to the merchant through access to lower fee structures, depending on the consumer authentication method. One or more embodiments also provide limited integration impact in that a simple wallet application program interface (API) is provided to pass card details, shipping information and security tokens, and does not require any new contractual relationships (i.e., existing card acceptance is leveraged). One or more embodiments are backwards compatible, (i.e., native support is provided for SecureCode® technology) thus resulting in better consumer experience and/or ergonomics. Again, these details are exemplary, optional, and non-limiting; some embodiments are directed to card-not-present Internet commerce with 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 smart phone or the like for use in transactions with the smart phone at brick and mortar retailers.
The wallet application 12 as described with respect to
Some aspects can be employed in applications where the consumer owns a “dumb phone.” For example, in applications 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 own a smart phone, the system in
One or more embodiments include a wallet application 12 in memory 412 which when executed causes the processor 402 to implement at least a portion of the functionality described herein. Operating system 427 orchestrates the operation of unit 400. Apple's iOS is a non-limiting example of a suitable operating system; other non-limiting examples include Linux-based systems (registered mark of Linus Torvalds), Windows Phone (registered mark of Microsoft Corporation), and the like.
Touch screen 410 coupled to processor 402 is also generally indicative of a variety of input/output (I/O) devices such as a keypad, another type of display, a mouse or other pointing device, and so on, all of which may or may not be present in one or more embodiments. Audio module 418 coupled to processor 402 includes, for example, an audio coder/decoder (codec), speaker, headphone jack, microphone, and so on. Power management system 416 can include a battery charger, an interface to a battery, and so on. Memory 412 is coupled to processor 402. Memory 412 can include, for example, volatile memory such as RAM, and non-volatile memory such as ROM, flash, or any tangible computer-readable recordable storage medium which stores information in a non-transitory manner. Processor 402 will typically also have on-chip memory.
Offers 5994 are discussed below.
Thus, some embodiments may be implemented, for example, at least in part via an application that runs on a tablet or smart phone or the like and another application that runs on a remote server or the like.
Referring to
Offers registry 1997 typically involves business-to-business interaction. The rules of the offer are determined by whoever provides the offer, whether a merchant, manufacturer, issuing bank, and so on. The appropriate entity provides the rules of the offer, the merchants at which the rules apply, a code range or some kind of identification scheme for the offer, and so on. A single identifier could be used for everyone to receive the offer; serialized identifiers could be provided, and so on. This information is stored in the offers registry 1997.
Transaction qualification service 1998 applies the rules in real time, based on registry 1997 and database 1996. Service 1998 applies the rules of the registered offer to transaction information coming through for the given consumer and determines if all the pieces are in place to qualify. Service 1998 then updates that particular consumer's registration and transaction records.
E-wallet platform 597 provides the interaction between the merchant and the consumer 2002 as to the transaction that is to be qualified. Consumer 2002 goes to merchant checkout page 1999 and when the consumer indicates that he or she wishes to pay with the e-wallet, he or she is re-routed to the e-wallet platform 597 and pertinent transaction information provided by the merchant is then run through the transaction qualification service 1998. If a promotion is applicable, this information is passed back to e-wallet platform 597, and when the consumer completes interaction with e-wallet platform 597, that information passes back to the merchant, as part of the interface between e-wallet platform 597 and the merchant. If the merchant wants to accept e-wallet platform 597, there will be certain messages the merchant will pass to e-wallet platform 597 and certain messages the merchant will receive back from e-wallet platform 597.
At 904, the balance inquiry service formats and sends a balance inquiry authorization request to the authorization network 987 (for example, network 2008) that is destined for the prepaid card issuer 596. At 905, the authorization network forwards the balance inquiry to the prepaid card issuer. At 906, the prepaid card issuer sends an authorization response for the balance inquiry with the amount of funds remaining 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 funding purchase/payment transaction acquirer/processor 9999 to initiate a purchase against the default funding card associated with the consumer's profile for the amount that is the difference between the e-commerce purchase amount and the available amount on the prepaid card. E-wallet 597 provides the entity 9999 with the funding card PAN information and the amount.
Note that “0100” and “0110” refer to ISO 8583 messages “authorization request” and “authorization request response.”
At 910, the entity 9999 formats and sends a purchase authorization request to the Authorization Network 987 that is destined for the funding card issuer 986. At 911, the authorization network forwards the purchase authorization request to the funding card issuer 986. At 912, the funding card issuer provides an approved response to the authorization request to the authorization network. At 913, the authorization network forwards the authorization response to the entity 9999. At 914, the entity 9999 forwards the authorization response to the wallet 597.
At 915, the e-wallet generates a request to the entity 9999 to initiate a payment transaction to “top up” funds to the prepaid card in the amount of the difference between the e-commerce purchase and remaining funds on the prepaid card (this is the same purchase amount that was approved by the funding card issuer 986). The e-wallet provides the entity 9999 with the prepaid PAN and the amount. The prepaid PAN is associated with the same country as the e-commerce retailer (e.g. US e-commerce retailer, US prepaid card). At 916, the entity 9999 formats and sends a payment transaction authorization request to the authorization network 987, that is destined for the prepaid card issuer 596.
At 917, the authorization network 987 forwards the payment transaction authorization request to the prepaid card issuer. At 918, the prepaid card issuer 596 provides an approved response to the authorization request to the authorization network 987. At 919, the authorization network forwards the authorization response to the entity 9999. At 920, the entity 9999 provides a response to the e-wallet indicating that the top-up was approved. Flows 921 and 922 show the CVC 2 request and response between the wallet and prepaid card issuer. In this regard, at the time of the purchase, once approval has been obtained from the funding card issuer, and top-up has been successfully accomplished, to make the purchase successful it is necessary to provide the merchant with all the details needed to move an authorization through. Thus, the merchant will need the CVC2 data. CVC2 data is often requested by the merchant to ensure that the person making an on-line transaction really has the card in his or her possession. In one or more embodiments, CVC2 data is not stored and so must be obtained from the prepaid card issuer. At 921 and 922, the CVC2 value is obtained for the specific prepaid card to be used in the 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 perform the e-commerce purchase against the prepaid card. At 925, the e-commerce retailer acquirer 990 formats and sends a purchase authorization request to the authorization network that is destined for the prepaid card issuer. At 926, the authorization network forwards the purchase authorization request to the prepaid card issuer 596. At 927, the prepaid card issuer 596 provides an approved response to the authorization request to the authorization network. At 928, the authorization network forwards 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 purchase confirmation to the consumer 598.
The e-commerce retailer acquirer block 990 contemplates a bank in the same jurisdiction as the e-commerce retailer, as well as a server operated by or on behalf of the bank which may be located in any jurisdiction. The balance inquiry service block 989 contemplates a server with appropriate software which is configured to send a balance inquiry to the prepaid card issuer to determine how much is left on the card; such server is likely to be in the same jurisdiction as the e-wallet server, but could also be elsewhere. The prepaid card issuer block 596 contemplates a prepaid card issuer which is likely, but not necessarily, in the same jurisdiction as the e-commerce retailer, as well as a server run by or on behalf of the prepaid card issuer, with suitable software, which could be located in any jurisdiction. The funding card issuer block 986 contemplates a banking institution, most likely in the home country of the consumer, as well as a server run by or on behalf of such banking institution, with suitable software, which could be located in any jurisdiction. The authorization network 987 is typically a multinational network such as the BANKNET or VISANET networks discussed elsewhere, or payment processing networks of other operators. The funding purchase/payment transaction acquirer/processor block 9999 contemplates (i) an acquirer that handles the purchase on the card in the shopper's native country, as well as the top-up of the pre-paid card in the jurisdiction where the e-commerce retailer is located, as well as (ii) a server run by or on behalf of such acquirer, with suitable software. The server and acquirer could be in any jurisdiction(s) and could themselves be in the same or different jurisdictions. In some cases, the functionality of block 9999 could be split between two or more entities.
Due consideration of applicable legal and regulatory considerations and/or contractual obligations should be had, inasmuch as, in some embodiments, the merchant will be accepting a card and shipping to an address that are not technically the consumer's funding card and actual shipping address; furthermore, in some embodiments, there also is not a physical (prepaid or other) card being issued (it is virtual).
In those embodiments where such considerations are pertinent, due consideration should be given to addressing concerns of the shipping merchant acquirer and prepaid card issuer, with respect to their willingness to take on the risk of sending and/or approving a transaction before settlement has occurred. In some embodiments, the shipping merchant will initiate a payment transaction authorization request before settlement has occurred on the funding card purchase, and/or the prepaid card issuer will approve the e-commerce purchase before settlement has occurred on payment transaction.
In some cases, the prepaid card issuer will be able to restrict purchases on the prepaid card to only those occurring through the wallet—for example, will ensure 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 generated via the e-wallet. Other cases do not involve a separate prepaid card and in such cases, these considerations are not a concern.
Some embodiments of the invention pertain to virtual card numbers for digital wallets. The following terminology is employed herein:
-
- Virtual card number—a unique number (in at least some instances, 16 digits) that is linked in the back end to a Real Card Number (RCN). It can be set up with sets of rules, alerts and limits which allows tight and flexible management of payments
- Real Card Number (RCN)—number (in at least some instances, 16 digits) written on a physical card
- Digital wallet—host of the financial information (card numbers, addresses, etc.)
of users to facilitate transactions with just a few clicks or interactions
-
- Card—A credit, debit or prepaid card
- Consumer—The end user who patronizes physical or online stores
- Merchant—An online or physical store
- Remote payments—Payments made using an internet connection using any suitable coming device: desktop, laptop, smart phone, tablet, and the like
- Proximity payments—Payments made using Near Field Communication
- Near field communication (NFC)—sets of standards for devices to use radio communication with each other by touching devices together or bringing them into close proximity, usually no more than a few centimeters (used herein for payment purposes)
Credit, debit and prepaid cards include a series of numbers which can be used to identify the issuing bank and the cardholder's bank account. A virtual card number (VCN) is a randomly generated series of numbers which does not contain any identifying information but is linked to a real card number (RCN).
A digital wallet is an electronic form of a physical wallet and houses various payment methods such as credit, debit and/or prepaid cards and/or electronic cash in the form of stored value.
One of the benefits currently being offered by digital wallets is concealing the consumer's RCN from merchants, thereby allowing consumers to make purchases from merchants that they would not be inclined to give their RCNs to. However, the consequence of hiding the consumer's RCN from the merchant is that the merchant does not know which bank's card is being used and any promotions associated with that particular bank's card are forgone.
By incorporating a VCN into a digital wallet, consumers are able to conceal their account information while revealing the bank that issued the card, thereby enjoying both the benefits of being able to purchase from merchants without giving them their RCNs while enjoying all promotions associated with using a particular bank's card.
Existing payment options will now be described. One current technique involves direct payment to the merchant via a credit, debit, or prepaid card. As seen in
Another current technique involves payment made indirectly to the merchant via a digital wallet. As seen in
Still another current technique involves direct interaction with the merchant via a Virtual Card Number (also known as a Virtual Account Number). Here, the user logs in at 8006 in
Referring now to
Advantageously, in this embodiment, consumers can generate a VCN to be used only for a specific transaction; consumers can create multiple VCNs to be used for different purposes and can specify the expiry date or the number of times that a VCN can be used; and/or consumers can set controls on their VCNs such as asking to be alerted or having the transaction declined if, for example, the transaction amount is beyond a stated limit, the amount spent on the VCN has reached its daily limit, and/or spending for a particular category has reached its limit.
In another aspect of the invention, proximity payments are made via NFC wallets. A virtual card number can be used for proximity payments in addition to remote payments via mobile payment technology. Instead of loading an actual credit card into the wallet, a VCN can be used instead when the consumer is wary of the merchant. Advantages of this aspect are similar to those discussed above for the remote payment aspect.
In a payment phase 8018, as seen at 8022, consumer 598 accesses the merchant's web site 1999, or accesses some other application of the merchant, and makes a purchase. As seen at 8023, the consumer is redirected to the wallet 597 at checkout. At step 8024, the consumer selects an existing VCN or creates a new VCN to be used. In step 8025, the wallet 597 passes the VCN details back to the merchant 1999. In step 8026, as part of the check-out review process, the details are shown to the consumer 598. In step 8027, the consumer 598 reviews the details and confirms payment. In step 8028, the merchant passes all the information to acquirer 990 which sends it to the issuer (not shown) over network 987. In step 8029, the operator of the network 987 uses MasterCard InControl® PAN (primary account number) mapping functionality 8016 to access a table or the like to map the VCN of the transaction to the corresponding RCN, before passing same to the issuer (registered mark of MasterCard International Incorporated, Purchase, N.Y. USA).
Other processes are shown at 8019. As seen at 8030, 8031, settlement and chargeback and/or reversal processes may be conventional, i.e., business as usual or “BAU.”
In some cases, as discussed elsewhere herein, a suitable application 12 resides on a smart phone 1420, 10 or the like and such phone is presented to a terminal 126 or the like at a brick and mortar location. The application 12 includes or has access to one or more locally stored VCNs and/or one or more locally stored offers 5994.
Thus, one or more embodiments of the invention are directed to, and/or advantageously work in conjunction with, an electronic wallet (e-wallet), also known as a digital wallet. As noted, an e-wallet provides consumers with a secure and convenient way to pay for purchases from accepting on-line merchants. Upon registration, consumers may store their card, billing and shipping information on a site hosted by a suitable entity (for example, an operator of a payment network 2008), and may access that information to pay conveniently and securely across participating merchants. The e-wallet platform may deliver additional security with the use of “virtual” account numbers to mask cardholders' real information.
In some cases, the aforementioned use of “virtual” account numbers, also known as PAN mapping, can be, for example, a network service that an operator of a payment network 2008 (e.g., an entity such as MasterCard International Incorporated) provides to issuers; in other instances, issuers may elect 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 possibility of the original PAN becoming compromised. A non-limiting example of PAN mapping is that offered under the “one time use number” feature of MasterCard International Incorporated's inControl™ payment solutions platform. The skilled artisan will be familiar with a variety of PAN mapping techniques, and, given the teachings herein, will be able to adapt same to one or more embodiments of the invention. For example, the payment network operator may create a translation table wherein external-facing instances of the number present the pseudo-PAN while internal-facing instances present the actual PAN. Commercially available PAN-mapping solutions which may be adapted to embodiments of the invention, given the teachings herein, include those available from Orbiscom Ltd., Block 1, Blackrock Business Park, Carysfort Avenue, Blackrock, Co. Dublin, Ireland (now part of MasterCard International Incorporated of Purchase, N.Y., USA); by way of example and not limitation, techniques of U.S. Pat. Nos. 6,636,833 and 7,136,835 of Flitcroft et al., the complete disclosures of both of which are expressly incorporated herein by reference in their entireties for all purposes.
For the avoidance of doubt, it is to be emphasized that MasterCard International Incorporated's inControl™ payment solutions platform is a non-limiting example, and many different techniques can be used to provide the “virtual number” described elsewhere herein, whether PAN mapping as described in the Flitcroft et al. patents or otherwise.
It should be noted that the person of ordinary skill in the art will be familiar with e-wallets per se, and, given the teachings herein, will be able to adapt same for implementing one or more embodiments of the invention. Non-limiting examples of known e-wallets include the PayPal service (mark of PayPal subsidiary of eBay, Inc., San Jose, Calif., USA); the Checkout by Amazon service (mark of Amazon.com, Inc., Seattle, Wash., USA); and the Google Checkout service (mark of Google, Inc. Mountain View, Calif., USA).
One or more embodiments advantageously employ a virtual card number inside the convenient user experience offered by an e-wallet. As discussed, a virtual card number advantageously offers an incremental level of security and trust from consumers (particularly in cross-border use cases where consumers are not familiar with the merchant that they are buying from); the possibility of implementing alerts, limits (time, amounts and number of transactions, merchant category, etc.); and/or risk management. On the other hand, a virtual card number is inconvenient in that it provides a cumbersome user experience where the consumer needs to swap between his or her virtual card number generator (browser, desktop plug-in, etc.) and his or her payment experience (merchant site).
As also discussed, the wallet offers the advantages that the consumer pays via mouse clicks or the like without even pulling his or her cards from his or her wallet (nor leaving the merchant's website); however, it is inconvenient in that the consumer needs to trust the merchant where the wallet application passes the card number to the merchant for processing; and the wallet may or may not offer a level of risk management that can offer liability shift for merchants.
Advantageously, one or more embodiments integrate a virtual card number and an e-wallet. In one or more embodiments, merchants do not need to change any integration to employ the e-wallet with virtual card number. Furthermore, in one or more embodiments, the difference between the merchant getting paid with a virtual card number or a real card number is transparent to the merchant.
In one or more embodiments, consumers are able to select, during their payment experience, when they want to use a VCN for a specific transaction, using only a few mouse clicks or the like. Pertinent use cases for one or more embodiments include the case where the consumer desires to have better control over alerts and/or limits for a particular card number or when he or she lacks trust in the merchants or country that he or she is buying from.
Consider now a current wallet payment experience. As seen in
With attention now to
In another aspect, one or more embodiments pertain to cross-border shipping for digital wallets.
Many foreign consumers now have a strong desire to shop overseas in the US and the UK. The US and UK are perceived as providing more options, better pricing, and a more pleasant experience in shopping. Many consumers go to the US on shopping sprees from all over the world.
In addition, broadband capability has been increasing around the world, often growing 150% on a yearly basis. There is also a stronger middle class in rapidly developing nations such as Brazil, India, China, and Russia. Consumers from these jurisdictions are finding their way to merchant web sites in the US and UK. 19% of all the browsing done on US e-merchants today is from consumers in other countries. However, US merchants for the most part do not accept foreign cards due to liability concerns. About 40% do accept foreign cards online; however, they accept foreign cards from only a handful of countries; say, 10-30 countries. Even when they do accept foreign cards, they typically do not ship overseas. Thus, there are barriers to both acceptance and fulfillment for foreigners wishing to purchase from US e-merchants.
Even for a US merchant that does ship all over the world, overseas shoppers have transparency issues as they may not be advised what taxes, customs duties, and the like will be due when the order arrives in their particular country; in some instances, they may not even be aware of the shipping charges.
As used in this discussion, the “domestic address” is the consumer's address in his or her country of residence; the “overseas address” is the consumer's address in the country of the merchant; “domestic shipping” is shipping from the merchant's warehouse to the consumer's overseas address; and “overseas shipping” is shipping from the consumer's overseas address to the domestic address.
Lower prices and the availability of the product are driving consumers to go online to purchase products from overseas. However, a commonly encountered problem is that merchants do not provide international shipping, typically offering only domestic shipping.
Currently, service providers (also referred to as logistics providers, logistics partners, or shipping merchants) such as Borderlinx offer a solution to this problem by providing consumers with an overseas address that the merchant can ship the consumer's purchased good to. Goods shipped to the overseas address can be stored free of charge for 30 days in order to accumulate goods and ship one large package instead of many smaller packages. Goods can also be combined with those of family and friends to create a larger package. Once the consumer requests the package to be shipped from his or her overseas address to his or her domestic address, the fully landed costs (including taxes and duties) are calculated and the consumer is able to make full and final payment for the cross border shipping service.
However, there are several limitations to this service as follows:
-
- Consumers will not know the cost of overseas shipping at the time of purchasing their goods as this service is provided by a third party and not the merchant.
- Consumers have to wait several days to finalize their transactions as they have to wait for their goods to arrive at their overseas address before they can arrange shipping to their domestic address.
- Consumers have to go to two different websites on two separate days to complete their transactions as they have to deal with two parties—the merchant and the service provider.
Advantageously, one or more embodiments improve the consumer experience by integrating the merchant with the service provider. In at least some instances, using information from the merchant regarding the weight of the goods and the size of the packaging together with the service provider's shipping charges, an exemplary embodiment of an e-wallet provides consumers with the cost of shipping at the time of purchase. Consumers are therefore able to arrange overseas shipment without having to wait for their goods to be delivered to their domestic addresses; furthermore, they only need to transact with one entity, namely, the e-wallet.
Furthermore, in one or more embodiments, an e-wallet in accordance with aspects of the invention allows consumers to compare prices across service providers in order to ship their goods at the lowest cost.
Even further, in one or more embodiments, an e-wallet is provided by an entity such as an operator of payment network 2008; such entity in turn preserves the value added features of an international shipping service provider such as bundling goods or repacking in order to lower shipping cost.
Referring now to
The current approach just discussed has the advantage that consumers follow the same purchasing process that they are familiar with, can consolidate packages and ship one large package instead of many small packages, and can repack their packages to reduce shipping charges. On the other hand, in this current approach, consumers do not know the cost of overseas shipping at the time of purchase, consumers have to wait till the package arrives at their overseas address to arrange overseas shipping, and consumers have to transact with the merchant and the international shipping service provider independently.
Consider now an exemplary approach in accordance with an aspect of the invention. Referring to
Advantageously, in this approach, consumers do not need to go through the inconvenience of filling in their billing addresses, shipping addresses or credit card information as their digital wallets already have this information. Furthermore, consumers know how much the total shipping charges will be before deciding if they wish to proceed with a purchase. As more international shipping services are added to the E-wallet, consumers are able to compare shipping prices across various service providers. Consumers have the flexibility of concluding the transaction immediately or consolidating packages at their overseas addresses.
In a sequence of steps 8072 in accordance with an embodiment of the invention, at step 8085, the user selects the domestic shipping method. In step 8086, he or she selects the E-wallet as his or her payment option. In step 8087, the user logs in to the E-wallet. In step 8088, the user selects the credit card to be used for payment and the shipping address. In step 8089, the user selects the shipping cost and pace (i.e., whether to ship now or to bundle). In step 8090, the consumer reviews and confirms the order.
In
In a payment phase 8103, as seen at 8107, consumer 598 accesses the merchant's web site 1999, or accesses some other application of the merchant, and makes a purchase. As seen at 8108, the consumer is redirected to the wallet 597 at checkout. In step 8109, the e-wallet 597 obtains the product details from the merchant 1999. In step 8110, the e-wallet 597 obtains the shipping cost from the logistics provider 8101. In step 8111, the e-wallet 597 shows the product and shipping costs to the consumer 598 for review. In step 8112, the consumer 598 reviews the details and confirms payment. In step 8113, the e-wallet passes all the information to the acquirer 990 for business as usual (“BAU”) processing via network 987. In step 8114, the e-wallet 597 passes the order to both the merchant 1999 and the logistics provider 8101.
Other processes are shown at 8104. As seen at 8115, 8116, settlement and chargeback and/or reversal processes may be conventional, i.e., BAU.
In some cases, as discussed elsewhere herein, a suitable application 12 resides on a smart phone 1420, 10 or the like and such phone is presented to a terminal 126 or the like at a brick and mortar location. The application 12 includes or has access to one or more locally stored VCNs and/or one or more locally stored offers 5994.
API 5999 is exposed to e-commerce retailer to allow integration of a web site of retailer 895 with platform 5497. Optional PAN mapping engine 5998 (optional in the sense that in some cases a PAN mapping engine external to the wallet 5497 can be employed) converts between VCNs and RCNs (e.g., via techniques disclosed in the Flitcroft patents); optional app store 5996 (optional in the sense that in some cases an app store external to the wallet 5497 can be employed, and completely optional in embodiments not using smart phones or the like) makes app 12 available for download (the term “store” does not necessarily imply a fee). Payment method engine 5997 allows the electronic wallet platform 5497 to affording consumers an option to select from multiple methods to pay for a transaction. The multiple methods (including one or more VCNs) are based, at least in part, on the registration information. This information can be stored in database 5479 and accessed and selected by engine 5997. Optional shipping engine 5995 determines shipping options; for example, based on data in database 5497 and/or based on a real-time link with one or more shipping companies. Engine 5995 also optionally calculates sizes and shapes of shipments and determines packaging requirements.
Comparison AspectsSome embodiments provide a comparison of prices across shipping services and merchant shipping. For example, in some cases, for both domestic and cross border shipping, the E-wallet provides consumers with several options. For domestic shipping, consumers have the choice between the shipping options offered by the merchant and other shipping services that operate domestically such as the postal service. For overseas shipping, consumers have several shipping services to choose from such as Borderlinx and Comgateway. Based on these options, consumers can find a combination of price, speed, reliability, and so on that is as close to their ideal as possible.
In another aspect, offers and incentives to use a specific funding source may be available. In some instances, the e-wallet aggregates various payment methods such as credit cards and mobile phone billing. Within each payment method, there can also be 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; displays to the consumer determine which funding source in the consumer's wallet provides the consumer with the lowest price option. Consumers are also able to view the price using each of their funding sources, with the associated promotions, thus creating the price differential.
In still another aspect, issuer promotions are passed through to the consumer regardless of the PAN mapping technique used (e.g., VCN or virtual prepaid card). In order for consumers to receive the promotions offered by their credit card issuers, the virtual card needs to either have the same bank identification number (BIN) as the real card or be mapped to the real card. The e-wallet can provide this functionality when either the VCN or virtual prepaid card is used.
In a further aspect, using a virtual card number (VCN) as a complement or replacement to the virtual prepaid card, the e-wallet can potentially use VCNs for both cross border and domestic transactions.
In addition, the consumer experience can be varied in several ways, such as having the e-wallet appear as a pop up window, wherein the consumer completes the transaction on the merchant site or wherein the consumer is redirected to the e-wallet site after checking out from the merchant site, completing the transaction on the wallet site.
In a still further aspect, in some embodiments, a “best deal card selector” is provided. In this aspect, the consumer registers credit cards (generally understood to include also debit, prepaid, and/or stored value cards in at least some cases) from various financial institutions onto his or her e-wallet. Each credit card comes with promotions that apply to selected merchants. When making a payment at one of these selected merchants, the consumer selects a credit card to use within his or her e-wallet and places his or her mobile phone over the proximity card reader. The e-wallet detects the merchant and checks for promotions associated with that merchant across all the payment cards in the wallet. If a better offer is found (in terms of paying the lowest price or otherwise (e.g., points or rewards)), the transaction is paused and an alert is sent to the consumer informing him or her about the better offer with the option to change the card used for payment. The consumer either chooses to continue with the current card or chooses a new card and places the mobile phone over the proximity card reader to complete the transaction.
RecapitulationGiven the discussion thus far, it will be appreciated that, in general terms, an exemplary method, according to an aspect of the invention, includes the step of obtaining, at an electronic wallet platform 5497, registration information for a plurality of consumers 598. This step can be carried out, for example, using registration module 5483, in at least some cases, via GUI 5477. Another step includes providing a mechanism to integrate the electronic wallet platform with a plurality of merchants 1999 (an e-commerce retailer 895 is a non-limiting example of a merchant). This step can be carried out, for example, by exposing an API 5999 to the merchants.
A further step includes, via the electronic wallet platform 5497, affording a given one of the consumers an option to select from multiple methods to pay for a transaction with a given one of the merchants 1999. 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 (VCN). As used herein, and as noted above, a virtual card number (VCN) is a randomly generated series of numbers which does not contain any identifying information but is linked to a real card number (RCN). Confusion should be avoided with the terminology “virtual card” as may be used in the case where an RCN is stored in some kind of device and a transaction occurs without a physical card corresponding to the RCN being present, yet where the RCN is supplied to the merchant. The step discussed in this paragraph can be carried out, for example, directly with the consumer via GUI 5477 or through the intermediary of the merchant, using e-commerce retailer interface module 5473; in either case, with the assistance of payment method engine 5997. An example screen is shown in
A still further step includes obtaining, from the given one of the consumers, a selection of the virtual card number for payment for the transaction. The step discussed in this paragraph can be carried out, for example, directly with the consumer via GUI 5477 or through the intermediary of the merchant, using e-commerce retailer interface module 5473; in either case, with the assistance of payment method engine 5997. An example screen is shown in
An even further step includes providing the given one of the merchants with the virtual card number. This step can be carried out, for example, by exposing API 5999 to the merchant. This facilitates the merchant being paid for the transaction. The given one of the merchants is provided with the virtual card number and the amount of the transaction is charged against an actual card number, not provided to the merchant, to which the virtual card number is linked.
Some embodiments further include intercepting an authorization request, from the given one of the merchants, for an amount of the transaction to be charged against the virtual card number; translating the virtual card number into an actual card number which is not provided to the merchant; and passing the authorization request to an issuer, with the actual card number therein. These steps can be carried out, for example, with an account number mapping engine 5998 within a payment network (e.g., 2008).
In some instances, the transaction includes an online transaction at a web site of the given one of the merchants 1999, and the selection of the virtual card number is obtained at the electronic 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
In some cases, a further 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 carried out or otherwise facilitated by the modules, as set forth above. In some cases, the distinct software modules further include an account number mapping engine module 5998, and further steps include intercepting an authorization request, from the given one of the merchants, for an amount of the transaction to be charged against the virtual card number, by executing the account number mapping engine module on the at least one hardware processor; translating the virtual card number into an actual card number which is not provided to the merchant, by executing the account number mapping engine module on the at least one hardware processor; and passing the authorization request to an issuer, with the actual card number therein, by executing the account number mapping engine module on the at least one hardware processor.
It is worth noting that the wallet can pop-up at the merchant web site or the consumer can be redirected to the e-wallet site.
One or more embodiments thus contemplate an apparatus, such as a server on which electronic wallet platform 5497 runs, including a memory, and at least one processor, coupled to the memory, and operative to carry out any one, 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 in to the memory, configure the at least one processor to be operative to carry out any one, some, or all of the method steps just described. As noted, the modules can include a registration module 5483, a user interface module 5477, an application program interface 5999, a payment method engine module 5997, and optionally, an account number mapping engine module 5998 and/or an e-commerce retailer interface module 5473.
In some instances, the transaction includes the given one of the consumers presenting a payment device (e.g., a “smart” phone 10), having an electronic wallet application 12 thereon, at a point-of-sale terminal 124, 126 of the given one of the merchants, and the virtual card number is provided to the merchant via communication between the payment device and the point-of-sale terminal of the given one of the merchants (e.g., via NFC). In such cases, an exemplary method includes the step of obtaining, at an electronic wallet platform, registration information for a plurality of consumers. Registration can be carried out, for example, using registration module 5483 and UI 5477. A further step includes making available to the consumers a secure application for portable devices of the consumers which affords the consumers an option to select from multiple methods to pay for transactions with merchants. 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. This step can be carried out, for example, using application store 5996. The terminology “store” does not necessarily imply that a fee is charged to download the application. The VCN(s) may by provided along with the application download or may 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 linking with the actual card number. Of course, the VCN itself, in at least some instances, can be dynamically created (i.e., the actual VCN may be created dynamically after the registration process). Nevertheless, with this understanding, the VCN is still understood to be based, at least in part, on the registration information.
A further step includes intercepting an authorization request, from a given one of the merchants, for an amount of a given one of the transactions to be charged against a given one of the virtual card numbers. The given one of the transactions includes a given one of the consumers presenting a given one of the portable devices, having the secure application thereon, at a point-of-sale terminal of the given one of the merchants. The virtual card number was provided to the merchant via communication between the given one of the portable devices and the point-of-sale terminal of the given one of the merchants. This step can be carried out, for example, with the account number mapping engine 5998 within the payment network (e.g., 2008).
Still further steps include translating the given one of the virtual card numbers into an actual card number which is not provided to the given one of the merchants; and passing the authorization request to an issuer, with the actual card number therein. These steps can be carried out, for example, with the account number mapping engine 5998 within the payment network (e.g., 2008).
In some cases, a further 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 store module 5996, and an account number mapping engine module 5998. The steps are then carried out or otherwise facilitated by the modules, as set forth above.
One or more embodiments thus contemplate an apparatus, such as a server on which electronic wallet platform 5497 runs, including a memory, and at least one processor, coupled to the memory, and operative to carry out any one, 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 in to the memory, configure the at least one processor to be operative to carry out any one, some, or all of the method steps just described. As noted, the modules can include a registration module 5483, a user interface module 5477, an application store module 5996, and an account number mapping engine module 5998.
Given the discussion thus far, it will be appreciated that, in general terms, one or more embodiments contemplate an exemplary method of providing a secure on-line shopping experience at an e-commerce retailer located in a first country to a plurality of consumers in at least one country other than the first country. The consumers have physical addresses (domestic addresses) in the at least one country other than the first country.
An optional step includes obtaining, at an electronic wallet server 597, from the plurality of consumers 598, registration information. The registration information in turn includes at least name, physical address in the at least one country other than the first country, and funding payment card account information. The aforementioned optional registration step can be carried out, for example, by interaction between the wallet platform 597 and consumer 598, facilitated by a suitable consumer user interface such as graphical user interface (GUI) 1477. GUI 1477 may include, for example, HTML served out from a server or servers on which platform 597 runs to a browser on a machine of consumer 598. The registration information can be stored in database 1479. Registration and account maintenance module 1483 also takes part in the registration (and account maintenance) process, interfacing with the consumer via GUI 1477. Optionally, the registration includes obtaining the information via one of a browser using a secure socket layer and a secure hypertext transfer protocol uniform resource locator, and the registration information is stored in database 1479 in an encrypted manner accessible to the electronic wallet server but shielded from the e-commerce retailer.
A further step includes facilitating assigning, to the plurality of consumers, local shipping addresses (overseas addresses) in the first country. This step may be carried out, for example, by shipping merchant interface module 1475.
A still further step includes obtaining, at the electronic wallet server, in connection with an on-line shopping session of a given one of the consumers at the e-commerce retailer 895, a request, from the e-commerce retailer, for a corresponding one of the local shipping addresses assigned to the given one of the consumers; and an even further step includes supplying the corresponding one of the local shipping addresses to the e-commerce retailer in response to the request therefor. These steps may be carried out, for example, by e-commerce retailer interface module 1473 interfacing with database 1479.
An even further step includes obtaining, at the electronic wallet server, in connection with the on-line shopping session of the given one of the consumers at the e-commerce retailer, product information and an indication of a desired form of shipping from the e-commerce retailer to the corresponding one of the local shipping addresses (domestic shipping). This step can be carried out in a variety of ways. In some cases, this information is provided to the wallet 597 from the e-commerce retailer 895, and the steps are carried out by the e-commerce retailer interface module 1473. On the other hand, in some cases, this information comes from the consumer 598 via a suitable consumer user interface such as GUI 1477.
Another step includes obtaining, at the electronic wallet server, in connection with the on-line shopping session of the given one of the consumers at the e-commerce retailer, an indication of a desired form of shipping from the corresponding one of the local shipping addresses to a corresponding one of the physical addresses in the at least one country other than the first country (overseas shipping). This step can also be carried out in a variety of ways. In some cases, this information is provided to the wallet 597 from the e-commerce retailer 895, and the steps are carried out by the e-commerce retailer interface module 1473. However, in other instances, this information comes from the consumer 598 via a suitable consumer user interface such as GUI 1477.
It is worth noting at this point that in some cases, interaction between consumer 598 and retailer 895 is used to specify the desired form of shipping from the e-commerce retailer 895 to the shipping merchant 599. Retailer 895 then provides this information to wallet 597. Fully landed cost includes, inter alia, costs for shipment from warehouse of merchant 895 to shipping merchant's warehouse 599, as well as costs for shipping from the shipping merchant's warehouse 599 to the consumer's physical address in his or her home country. However, retailer 895 typically does not care how shipment occurs from the shipping merchant's warehouse 599 to the consumer's physical address in his or her home country. Thus, in some cases, the wallet 597 obtains product information and local shipping information from e-commerce retailer 895. In some instances, the actual shipment from shipping merchant 599 to the consumer's physical address in his or her home country happens once it is known that the goods have been shipped from retailer 895 to warehouse 599. In some cases, the steps discussed just above are directed to an estimate for shipment from shipping merchant 599 to the consumer's physical address in his or her home country, used to develop an estimated fully landed cost. For purposes of estimating the fully landed cost, in a non-limiting example, consumer 598 interacts directly with wallet 597 via user interface 1477 or the like, to indicate how he or she wants the goods shipped to his or her home country from shipping merchant 599. As noted, however, in some cases the retailer 895 acts as an intermediary.
Yet another step includes dispatching, from the electronic wallet server, an indication, destined for the given one of the consumers, of an estimated fully landed cost associated with the on-line shopping session. The estimated fully landed cost is based at least upon the product information, the indication of the desired form of shipping from the e-commerce retailer to the corresponding one of the local shipping addresses, and the indication of the desired form of shipping from the corresponding one of the local shipping addresses to the corresponding one of the physical addresses in the at least one country other than the first country. This step may be carried out, for example, via user interface 1477 or the like (e.g., GUI 1477 serves HTML, code to the consumer's machine that causes another window to pop up thereon); however, in some cases the retailer 895 acts as an intermediary.
An additional step includes dispatching, from the electronic wallet server 597, shipping option information, destined for the given one of the consumers 598. The shipping option information provides at least two options for one or both of the shipments, i.e., the shipment from the e-commerce retailer to the corresponding one of the local shipping addresses, and the shipment from the corresponding one of the local shipping addresses to the corresponding one of the physical addresses in the at least one country other than the first country.
The indication of the desired form of shipping from the e-commerce retailer to the corresponding one of the local shipping addresses, or the indication of the desired form of shipping from the corresponding one of the local shipping addresses to the corresponding one of the physical addresses in the at least one country other than the first country, or both, as the case may be, is responsive to the shipping option information.
In one or more embodiments, the shipping option information includes at least one of cost and speed information for each of the at least two options.
Cross border shipping is currently an inconvenience to both the consumer and the merchant. From the consumer perspective, it involves having to deal with the merchant and cross border shipping service individually as the two entities do not have a relationship with each other. From a merchant perspective, cross border shipping is prohibitively expensive when dealing with low volumes and far more complex than domestic shipping due to differing regulations, taxes, insurance cost, etc. One or more embodiments advantageously solve both the merchant and consumer problem by integrating with a worldwide shipping provider and negotiating affordable rates by aggregating the volumes of multiple merchants. Merchants can log into their wallet accounts and select which countries their current logistics providers ship to and which countries they are willing to ship to. When a consumer is redirected to the wallet from the merchant site, the wallet compares the consumer's shipping address with both lists to determine if a cross border shipping service is required. If such a service is required, the wallet retrieves the shipping options and rates from the cross border shipping service and presents them to the consumer based on the rules preset by the merchant, or sends the rates to the merchant if no rules have been preset. Once the wallet receives confirmation from the merchant that the transaction was successful, the wallet passes an invoice and instructions on how to fulfill the order (shipping labels, pickup times & locations etc.) from the logistics provider to the merchant.
One or more embodiments advantageously address one or more of the following technical issues:
-
- Creating a process flow where the wallet is the pass-through between the merchant and logistics provider;
- Creating the shipping functions in the merchant account that allow merchants to select their preferences;
- Creating the comparison function in the wallet transaction flow 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, in general terms, still another exemplary method includes the step 8108 of obtaining, at an electronic wallet server 5497, product information in connection with an on-line shopping session of a consumer 598 with an e-commerce retailer 1999. This step can be carried out, for example, using e-commerce retailer interface module 5473. A further step 8111 includes dispatching, from the electronic wallet server, shipping option information, destined for the consumer, providing at least two options for shipping goods, associated with the product information, from the e-commerce retailer to the consumer. This step can be carried out, for example, using e-commerce retailer interface module 5473 and shipping engine module 5995. An even further step 8112 includes obtaining, at the electronic wallet server, in connection with the on-line shopping session, an indication of a desired form of shipping from the e-commerce retailer to the consumer. The indication is based on the shipping option information. This step can be carried out, for example, using e-commerce retailer interface module 5473 and/or GUI 5477.
In some embodiments, a third party provides alternative shipping methods beyond what the merchant will make available. This includes the all-domestic case and the cross-border case. Where the merchant outsources the shipping, some merchant integration may be appropriate. A choice can be provided with respect to domestic shipping, either because the whole transaction is in one country, or as to the first (domestic) part of an international transaction. If choice is only from the shipping merchant 599 to the consumer, merchant integration with retailer 895 is typically not required. The third party can be a shipping merchant 5999, the operator of platform 5497 (e.g., the operator of a payment network 2008), or the like.
Again, in one or more embodiments, the shipping option information includes at least one of cost and speed information for each of the at least two options.
In some cases, an additional step includes 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 shipping engine module 5995. The steps are then carried out or otherwise facilitated by the modules, as set forth above.
The wallet interface can pop-up at the merchant web site or the consumer can be redirected to the e-wallet site; therefore last step can be implemented either by the interface module 5473 or GUI 5477.
One or more embodiments thus contemplate an apparatus, such as a server on which electronic wallet platform 5497 runs, including a memory, and at least one processor, coupled to the memory, and operative to carry out any one, 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 in to the memory, configure the at least one processor to be operative to carry out any one, some, or all of the method steps just described. As noted, the modules can include an e-commerce retailer interface module 5473 and a shipping engine module 5995, and optionally a GUI module 5477.
Furthermore with regard to domestic shipping for the merchant, consider the following scenarios:
-
- 1. The merchant has yet to engage a logistics company (e.g., a start-up merchant);
- 2. The merchant's logistics company provides limited coverage domestically;
- 3. a logistics partner associated with the e-wallet, payment network operator, or the like, provides value added service that the merchant's logistics company does not.
When redirecting the consumers to wallet, in one or more embodiments, the merchants indicate if they provide domestic shipping and if there are cities or states that they are currently unable to ship to. Along with this information, the merchant also provides the wallet with an estimate of the package dimensions and weight.
When the wallet receives a consumer from a merchant site without domestic shipping, it calculates the rates for the different shipping options and presents them to the merchant. The merchant can then amend the rate before passing same back to the wallet to be presented to the consumer. Alternatively, the merchant can log into the merchant's wallet account and set pricing rules such as having a standard rate for a particular country or adding an x% surcharge on top of the logistics company's rate. Once the consumer has selected his or her preferred shipping option, he or she proceeds to pay for the merchant's goods & for the shipping cost. Once the wallet receives confirmation from the merchant that the transaction was successful, the wallet passes an invoice and instructions on how to fulfill the order (shipping labels, pickup times & locations etc.) from the logistics provider to the merchant.
When the wallet receives a consumer from a merchant site with limited domestic shipping coverage, it will compare the consumer's shipping address with the merchant's list of areas not covered. If the merchant is unable to ship to the consumer's address, the same process is initiated as in the case when the merchant does not have domestic shipping.
If a merchant already has complete domestic shipping but would like to use the wallet-based shipping due to lower prices or value added services such as insurance or pick up services, the merchant can select under which circumstances it would like to use the wallet shipping service by logging into the merchant's account in the wallet. Examples of such circumstances could be when the item to be shipped is fragile or when the value of the items exceeds a certain amount. With these settings integrated, the wallet will, in one or more embodiments, initiate domestic shipping when any of these conditions are met.
Merchants typically do not disseminate the weight and dimensions of their packages to other parties in the payment process. Large merchants have their own inventory management system and small or medium sized merchants set their own shipping charges or check the rate with the shipping service. In order for merchants (especially small and medium sized merchants) to send over volumetric data, they would have to come up with their own internal system for estimating the volumetric dimensions of the packaging needed for the products that the consumer has ordered. This is relatively straightforward when the products are identical or very similar in dimensions such as an order of multiple t-shirts. However, when different types of products are involved such as a belt, shoes, jeans and t-shirt, estimating the volumetric dimensions of the packaging accurately becomes far more challenging and is usually overestimated.
One or more embodiments address this issue by providing such a system for the merchants.
Given the discussion thus far, and referring to
For example, one funding source might yield thirty frequent flier points; another might yield a 1% discount. This aspect can be server based or implemented via a smart phone application, for example. In the latter case, a database (e.g., offers 5994 in memory 412) stores the discount locally on the phone after the consumer opts-in to downloading offers to his or her phone—in some cases, all representative offers are stored in a central location such as registry 1997, displayed to the consumer, and the consumer picks what he or she wants to locally store on his or her smart phone or the like.
In some instances, the first and second cost scenarios are determined based on different promotions available with use of the at least first and second funding sources (e.g., one card in the wallet offers a promotion and another doesn't; or they both offer promotions but the promotions differ).
In some cases, at least one of the payment options includes a virtual card number; the consumer selects the virtual card number; the merchant is provided with the virtual card number; and an authorization message for an amount of the transaction is sent to an issuer with an actual card number not provided to the merchant. In such cases, one or more embodiments determine at least a pertinent one of the first and second cost scenarios based on the actual card number, advantageously allowing the consumer to obtain a promotion or other benefit from the RCN while only divulging the VCN to the merchant. The notation “at least a pertinent one of the first and second cost scenarios” accounts for the case wherein one cost scenario is based on a VCN while another is based on an RCN and so any pertinent offers would already be known, as well as the case where both cost scenarios involve VCNs.
A point of sale (POS) device is typically designed to read only one card at a time. Therefore, mobile wallets typically require the consumers to activate the card they wish to use before presenting their mobile phones to the POS. In order to compare discounts across cards, the POS first has to detect the inactive cards on the mobile wallet then pass on the discounts for those inactive cards with the mobile wallet. Another current issue is the time taken to complete this process of comparing inactive cards. As an increasing number of cards are added to the wallet, the time taken for comparison increases. Since a transaction has to be completed in a fixed amount of time, this restricts the number of cards that can be compared within that timeframe. Finally, passing over the data for all the discounts on the cards stored in a consumer's wallet is likely to be error prone as a lot of information is being passed.
In some cases, the cards being compared are cards of an identical brand, e.g., MasterCard cards. In some cases, the wallet addresses this issue by creating an offers database and having the offers for the cards stored in the consumers' wallets downloaded onto their mobile phones, as seen at 5994; for example, whenever one of the consumers adds a card. In at least some instances, periodic updating occurs, 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, in order for a merchant to detect what type of card is being used, the first 8 digits of the virtual card number typically need to be the same as the real card number. However, a virtual card number is usually a randomly generated number thereby making the issuer of the card unrecognizable to the merchant. In some cases, the wallet solves this problem through an offers database. Before passing the transaction to the issuer for authorization, the wallet compares the real card number with the offers database and applies any applicable discounts. After the issuer authorizes the transaction, the wallet sends the updated amount along with the details of the discount applied to the issuer.
In some cases, an additional step includes 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 an offer comparison module (e.g. 1997, 1998), and an application program interface 5999. The steps are then carried out or otherwise facilitated by the modules, as set forth above.
One or more embodiments thus contemplate an apparatus, such as a server on which electronic wallet platform 5497 runs, including a memory, and at least one processor, coupled to the memory, and operative to carry out any one, 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 in to the memory, configure the at least one processor to be operative to carry out any one, some, or all of the method steps just described. As noted, the modules can include an e-commerce retailer interface module 5473 and an offer comparison module (e.g. 1997, 1998), and an application program interface 5999, and optionally a GUI module 5477.
In yet another aspect, a method includes the step of obtaining, by an electronic wallet mobile application 12, transaction data pertaining to a transaction between a consumer and a merchant for provision of at least one of goods and services (non-limiting examples of transaction data are provided above). The electronic wallet mobile application has at least first and second funding sources available. A further step includes determining, by the electronic wallet mobile application, based on the transaction data, a first cost scenario for the transaction based on use of the first one of the funding sources and a second cost scenario for the transaction based on use of the second one of the funding sources (e.g., by comparing offers 5994 downloaded into memory 412). A still further step includes obtaining, at the electronic wallet mobile application, from the consumer, a selection, from among the at least first and second funding sources, based on the first and second cost scenarios (e.g., via interaction with screen 410). An even further step includes providing the merchant an account number associated with the selected funding source (e.g., via antenna 1800). In some instances, a further optional step includes downloading to the electronic wallet mobile application at least first and second offers 5994. The first and second cost scenarios are based on the first and second offers.
“Cost scenarios” should be broadly understood to include direct total cost comparison, the possibility of receiving a free gift in one scenario but not another; the possibility of different free gifts being available in different scenarios, the possibility of coupons being offered in some scenarios but not others; the possibility of different coupons being offered in different scenarios, and so on.
From the perspective of one or more servers, steps include downloading the application, VCNs, and offers to the smart phone or the like, and intercepting an “auth” request with the VCN and converting same to the RCN.
One or more embodiments thus contemplate an apparatus, such as a mobile phone 10, including a memory, and at least one processor, coupled to the memory, and operative to carry out any one, some, or all of the method steps just described. In one or more embodiments, one or more distinct software modules stored in a non-transitory storage medium, when loaded in to the memory, configure the at least one processor to be operative to carry out any one, some, or all of the method steps just described. As noted, the modules can include wallet app 12.
As noted, one or more embodiments of the invention or elements thereof can be implemented in the form of a system (or apparatus) including a memory and at least one processor that is coupled to the memory and operative to perform or otherwise facilitate exemplary method steps. Examples include a server 300 or smart phone 10 or the like.
System and Article of Manufacture DetailsEmbodiments of the invention can employ hardware and/or hardware and software aspects. Software includes but is not limited to firmware, resident software, microcode, etc. Software might be employed, for example, in connection with one or more of a terminal 122, 124, 125, 126; a reader 132; payment devices such as cards 102, 112; a host, server, and/or processing center 140, 142, 144 (optionally with data warehouse 154) of a merchant, issuer, acquirer, processor, or operator of a network 2008 operating according to a payment system standard (and/or specification), as well as smart phone 10, a wallet server running wallet platform 597 or 5497, or other server(s). Firmware might be employed, for example, in connection with payment devices such as cards 102, 112 and reader 132. Firmware provides a number of basic functions (e.g., display, print, accept keystrokes) that in themselves do not provide the final end-use application, but rather are building blocks; software links the building blocks together to deliver a usable solution.
The notation “to/from network” is indicative of a variety of possible network interface devices.
As is known in the art, part or all of one or more aspects of the methods and apparatus discussed herein may be distributed as an article of manufacture that itself comprises a tangible computer readable recordable storage medium having computer readable code means embodied thereon. The computer readable program code means is operable, in conjunction with a computer system, to carry out all or some of the steps to perform the methods or create the apparatuses discussed herein. A computer-usable medium may, in general, be a recordable medium (e.g., floppy disks, hard drives, compact disks, EEPROMs, or memory cards) or may be a transmission medium (e.g., a network comprising fiber-optics, the world-wide web, cables, or a wireless channel using time-division multiple access, code-division multiple access, or other radio-frequency channel). Any medium known or developed that can store information suitable for use with a computer system may be used. The computer-readable code means is any mechanism for allowing a computer to read instructions and data, such as magnetic variations on a magnetic media or height variations on the surface of a compact disk. The medium can be distributed on multiple physical devices (or over multiple networks). For example, one device could be a physical memory media associated with a terminal and another device could be a physical memory media associated with a processing center. As used herein, a tangible computer-readable recordable storage medium is defined to encompass a non-transitory recordable medium, examples of which are set forth above, but does not encompass a transmission medium or disembodied signal.
The computer systems and servers described herein each contain a memory that will configure associated processors to implement the methods, steps, and functions disclosed herein. Such methods, steps, and functions can be carried out, by way of example and not limitation, by processing capability on elements 140, 142, 144, 597, 5497 (i.e., physical machine(s) on which e-wallet platform and its associated interface and/or database modules run), 2004, 2006, 2008, 2010; processor 402; or by any combination of the foregoing. The memories could be distributed or local and the processors could be distributed or singular. The memories could be implemented as an electrical, magnetic or optical memory, or any combination of these or other types of storage devices. Moreover, the term “memory” should be construed broadly enough to encompass any information able to be read from or written to an address in the addressable space accessed by an associated processor. With this definition, information on a network is still within a memory because the associated processor can retrieve the information from the network.
Thus, elements of one or more embodiments of the invention can make use of computer technology with appropriate instructions to implement method steps described herein as being performed by one or more processors. The various platforms can be implemented, for example, using one or more servers which include a memory and at least one processor coupled to the memory. The memory could load appropriate software. The processor can be operative to perform one or more method steps described herein or otherwise facilitate their performance.
Accordingly, it will be appreciated that one or more embodiments of the invention can include a computer program comprising computer program code means adapted to perform one or all of the steps of any methods or claims set forth herein when such program is run on a computer, and that such program may be embodied on a computer readable medium. Further, one or more embodiments of the present invention can include a computer comprising code adapted to cause the computer to carry out one or more steps of methods or claims set forth herein, together with one or more apparatus elements or features as depicted and described herein.
As used herein, including the claims, a “server” includes a physical data processing system (for example, system 300 as shown in
Furthermore, it should be noted that any of the methods described herein can include an additional step of providing a system comprising distinct software modules embodied on one or more tangible computer readable storage media. All the modules (or any subset thereof) can be on the same medium, or each can be on a different medium, for example. The modules can include any or all of the components shown in the figures. In one or more embodiments, the modules include modules to implement the functional blocks shown in
Computers discussed herein can be interconnected, for example, by one or more of network 138, 987, 2008, another virtual private network (VPN), the Internet, a local area and/or wide area network (LAN and/or WAN), via an EDI layer, and so on. The computers can be programmed, for example, in compiled, interpreted, object-oriented, assembly, and/or machine languages, for example, one or more of C, C++, Java, Visual Basic, JavaScript or other ECMAScript based scripting languages, and the like (an exemplary and non-limiting list), and can also make use of, for example, Extensible Markup Language (XML), JSON, name/value pairs, known application programs such as relational database applications, spreadsheets, and the like. The computers can be programmed to implement the logic depicted in the flow charts and other figures. At least some messages, in at least some instances, can 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 one skilled in the art without departing from the scope or spirit of the invention.
Claims
1. A method comprising the steps of:
- obtaining, at an electronic wallet platform, registration information for a plurality of consumers;
- making available to said consumers a secure application for portable devices of said consumers which affords said consumers an option to select from multiple methods to pay for transactions with merchants, said multiple methods being based, at least in part, on said registration information, at least one of said multiple methods comprising a virtual card number;
- intercepting an authorization request, from a given one of said merchants, for an amount of a given one of said transactions to be charged against a given one of said virtual card numbers, said given one of said transactions comprising a given one of said consumers presenting a given one of said portable devices, having said secure application thereon, at a point-of-sale terminal of said given one of said merchants, said virtual card number having been provided to said merchant via communication between said given one of said portable devices and said point-of-sale terminal of said given one of said merchants;
- translating said given one of said virtual card numbers into an actual card number which is not provided to said given one of said merchants; and
- passing said authorization request to an issuer, with said actual card number therein.
2. The method of claim 1, further comprising providing a system, wherein the system comprises distinct software modules, each of the distinct software modules being embodied on a non-transitory computer-readable storage medium, and wherein the distinct software modules comprise a registration module, a user interface module, an application store module, and an account number mapping engine module;
- wherein:
- said obtaining of said registration information is carried out by said registration module and said user interface module executing on at least one hardware processor;
- said making available of said secure application is carried out by said application store module executing on said at least one hardware processor;
- said intercepting of said authorization request, said translating of said virtual card number, and said passing of said authorization request are carried out by executing said account number mapping engine module on said at least one hardware processor.
Type: Application
Filed: Nov 1, 2021
Publication Date: Feb 24, 2022
Inventors: David Pardo (Singapore), Anand Shekaran (Singapore), Jose A. Alba (Long Island City, NY), Michael J. Shaon (Fayetteville, AR), Aimee G. Musil (O?Fallon, MO), Michael S. Ameiss (O?Fallon, MO), Eric R. Kitchen (O?Fallon, MO)
Application Number: 17/516,678
