SYSTEMS AND METHODS FOR PROCESSING, FACILITATING, PROVIDING, OR USING ONLINE CHECKOUT USING A SHARED WALLET ACROSS ISSUERS

A method including receiving a unique identifier for a user. The method also can include determining, using a wallet directory, a shared wallet associated with the unique identifier. The shared wallet can include identifying information for cards issued from multiple different issuers. The method additionally can include sending the identifying information for the cards to enable the user to select one of the cards for a first transaction at a first merchant. The method further can include obtaining information about a first selected card of the cards based on a selection from the user. The method additionally can include requesting a first payment authorization token for the first selected card from a wallet network system. The method further can include sending the first payment authorization token to enable the first merchant to process the first transaction using the first selected card. Other embodiments of related systems and methods are described.

TECHNICAL FIELD

This disclosure relates generally to processing, facilitating, providing, or using online checkout using a shared wallet across issuers.

BACKGROUND

Conventional online checkout typically involves a user providing card details to the merchant for the transaction. The merchant often provides the option to store the card information so that the user is not asked for the card information the next time the user does an online checkout at the same merchant. User often have multiple different cards, which are often issued by multiple different card issuers. Additionally, users often use websites of many different merchants, each with their own checkout system.

The terms “couple,” “coupled,” “couples,” “coupling,” and the like should be broadly understood and refer to connecting two or more elements or signals, electrically, mechanically or otherwise. Two or more electrical elements may be electrically coupled, but not mechanically or otherwise coupled; two or more mechanical elements may be mechanically coupled, but not electrically or otherwise coupled; two or more electrical elements may be mechanically coupled, but not electrically or otherwise coupled. Coupling (whether mechanical, electrical, or otherwise) may be for any length of time, e.g., permanent or semi-permanent or only for an instant.

“Electrical coupling” and the like should be broadly understood and include coupling involving any electrical signal, whether a power signal, a data signal, and/or other types or combinations of electrical signals. “Mechanical coupling” and the like should be broadly understood and include mechanical coupling of all types. The absence of the word “removably,” “removable,” and the like near the word “coupled,” and the like does not mean that the coupling, etc. in question is or is not removable.

DESCRIPTION OF EXAMPLES OF EMBODIMENTS

Various embodiments include a computer-implemented method. The method can include receiving a unique identifier for a user. The method also can include determining, using a wallet directory, a shared wallet associated with the unique identifier. The shared wallet can include identifying information for cards issued from multiple different issuers. The method additionally can include sending the identifying information for the cards to enable the user to select one of the cards for a first transaction at a first merchant. The method further can include obtaining information about a first selected card of the cards based on a selection from the user. The method additionally can include requesting a first payment authorization token for the first selected card from a wallet network system. The method further can include sending the first payment authorization token to enable the first merchant to process the first transaction using the first selected card.

A number of embodiments include a system including one or more processors and one or more non-transitory computer-readable media storing computing instructions that, when executed on the one or more processors, cause the one or more processors to perform operations. The operations can include receiving a unique identifier for a user. The operations also can include determining, using a wallet directory, a shared wallet associated with the unique identifier. The shared wallet can include identifying information for cards issued from multiple different issuers. The operations additionally can include sending the identifying information for the cards to enable the user to select one of the cards for a first transaction at a first merchant. The operations further can include obtaining information about a first selected card of the cards based on a selection from the user. The operations additionally can include requesting a first payment authorization token for the first selected card from a wallet network system. The operations further can include sending the first payment authorization token to enable the first merchant to process the first transaction using the first selected card.

Further embodiments include one or more non-transitory computer-readable media storing computing instructions that, when executed on the one or more processors, cause the one or more processors to perform operations. The operations can include receiving a unique identifier for a user. The operations also can include determining, using a wallet directory, a shared wallet associated with the unique identifier. The shared wallet can include identifying information for cards issued from multiple different issuers. The operations additionally can include sending the identifying information for the cards to enable the user to select one of the cards for a first transaction at a first merchant. The operations further can include obtaining information about a first selected card of the cards based on a selection from the user. The operations additionally can include requesting a first payment authorization token for the first selected card from a wallet network system. The operations further can include sending the first payment authorization token to enable the first merchant to process the first transaction using the first selected card.

Turning to the drawings,FIG.1illustrates an exemplary embodiment of a computer system100, all of which or a portion of which can be suitable for (i) implementing part or all of one or more embodiments of the techniques, methods, and systems and/or (ii) implementing and/or operating part or all of one or more embodiments of the non-transitory computer readable media described herein. As an example, a different or separate one of computer system100(and its internal components, or one or more elements of computer system100) can be suitable for implementing part or all of the techniques described herein. Computer system100can comprise chassis102containing one or more circuit boards (not shown), a Universal Serial Bus (USB) port112, a Compact Disc Read-Only Memory (CD-ROM) and/or Digital Video Disc (DVD) drive116, and a hard drive114. A representative block diagram of the elements included on the circuit boards inside chassis102is shown inFIG.2. A central processing unit (CPU)210inFIG.2is coupled to a system bus214inFIG.2. In various embodiments, the architecture of CPU210can be compliant with any of a variety of commercially distributed architecture families.

Continuing withFIG.2, system bus214also is coupled to memory storage unit208that includes both read only memory (ROM) and random access memory (RAM). Non-volatile portions of memory storage unit208or the ROM can be encoded with a boot code sequence suitable for restoring computer system100(FIG.1) to a functional state after a system reset. In addition, memory storage unit208can include microcode such as a Basic Input-Output System (BIOS). In some examples, the one or more memory storage units of the various embodiments disclosed herein can include memory storage unit208, a USB-equipped electronic device (e.g., an external memory storage unit (not shown) coupled to universal serial bus (USB) port112(FIGS.1-2)), hard drive114(FIGS.1-2), and/or CD-ROM, DVD, Blu-Ray, or other suitable media, such as media configured to be used in CD-ROM and/or DVD drive116(FIGS.1-2). Non-volatile or non-transitory memory storage unit(s) refer to the portions of the memory storage units(s) that are non-volatile memory and not a transitory signal. In the same or different examples, the one or more memory storage units of the various embodiments disclosed herein can include an operating system, which can be a software program that manages the hardware and software resources of a computer and/or a computer network. The operating system can perform basic tasks such as, for example, controlling and allocating memory, prioritizing the processing of instructions, controlling input and output devices, facilitating networking, and managing files. Exemplary operating systems can include one or more of the following: (i) Microsoft® Windows® operating system (OS) by Microsoft Corp. of Redmond, Washington, United States of America, (ii) Mac® OS X by Apple Inc. of Cupertino, California, United States of America, (iii) UNIX® OS, and (iv) Linux® OS. Further exemplary operating systems can comprise one of the following: (i) the iOS® operating system by Apple Inc. of Cupertino, California, United States of America, (ii) the Blackberry® operating system by Research In Motion (RIM) of Waterloo, Ontario, Canada, (iii) the WebOS operating system by LG Electronics of Seoul, South Korea, (iv) the Android™ operating system developed by Google, of Mountain View, California, United States of America, (v) the Windows Mobile™ operating system by Microsoft Corp. of Redmond, Washington, United States of America, or (vi) the Symbian™ operating system by Accenture PLC of Dublin, Ireland.

In the depicted embodiment ofFIG.2, various I/O devices such as a disk controller204, a graphics adapter224, a video controller202, a keyboard adapter226, a mouse adapter206, a network adapter220, and other I/O devices222can be coupled to system bus214. Keyboard adapter226and mouse adapter206are coupled to a keyboard104(FIGS.1-2) and a mouse110(FIGS.1-2), respectively, of computer system100(FIG.1). While graphics adapter224and video controller202are indicated as distinct units inFIG.2, video controller202can be integrated into graphics adapter224, or vice versa in other embodiments. Video controller202is suitable for refreshing a monitor106(FIGS.1-2) to display images on a screen108(FIG.1) of computer system100(FIG.1). Disk controller204can control hard drive114(FIGS.1-2), USB port112(FIGS.1-2), and CD-ROM and/or DVD drive116(FIGS.1-2). In other embodiments, distinct units can be used to control each of these devices separately.

In some embodiments, network adapter220can comprise and/or be implemented as a WNIC (wireless network interface controller) card (not shown) plugged or coupled to an expansion port (not shown) in computer system100(FIG.1). In other embodiments, the WNIC card can be a wireless network card built into computer system100(FIG.1). A wireless network adapter can be built into computer system100(FIG.1) by having wireless communication capabilities integrated into the motherboard chipset (not shown), or implemented via one or more dedicated wireless communication chips (not shown), connected through a PCI (peripheral component interconnector) or a PCI express bus of computer system100(FIG.1) or USB port112(FIGS.1-2). In other embodiments, network adapter220can comprise and/or be implemented as a wired network interface controller card (not shown).

Although many other components of computer system100(FIG.1) are not shown, such components and their interconnection are well known to those of ordinary skill in the art. Accordingly, further details concerning the construction and composition of computer system100(FIG.1) and the circuit boards inside chassis102(FIG.1) are not discussed herein.

When computer system100inFIG.1is running, program instructions stored on a USB drive in USB port112, on a CD-ROM or DVD in CD-ROM and/or DVD drive116, on hard drive114, or in memory storage unit208(FIG.2) are executed by CPU210(FIG.2). A portion of the program instructions, stored on these devices, can be suitable for carrying out all or at least part of the techniques described herein. In various embodiments, computer system100can be reprogrammed with one or more modules, system, applications, and/or databases, such as those described herein, to convert a general purpose computer to a special purpose computer. For purposes of illustration, programs and other executable program components are shown herein as discrete systems, although it is understood that such programs and components may reside at various times in different storage components of computer system100, and can be executed by CPU210. Alternatively, or in addition to, the systems and procedures described herein can be implemented in hardware, or a combination of hardware, software, and/or firmware. For example, one or more application specific integrated circuits (ASICs) or Field Programmable Gate Arrays (FPGAs) can be programmed to carry out one or more of the systems and procedures described herein. For example, one or more of the programs and/or executable program components described herein can be implemented in one or more ASICs or FPGAs.

Turning ahead in the drawings,FIG.3illustrates a block diagram of a system300that can be employed for processing, facilitating, providing, or using online checkout using a shared wallet across issuers, according to an embodiment. System300is merely exemplary, and embodiments of the system are not limited to the embodiments presented herein. The system can be employed in many different embodiments or examples not specifically depicted or described herein. In some embodiments, certain elements of system300can perform various procedures, processes, and/or activities. In other embodiments, the procedures, processes, and/or activities can be performed by other suitable elements of system300. Generally, therefore, system300can be implemented with hardware and/or software, as described herein. In some embodiments, part or all of the hardware and/or software can be conventional, while in these or other embodiments, part or all of the hardware and/or software can be customized (e.g., optimized) for implementing part or all of the functionality of system300described herein.

In many embodiments, system300can include various systems, such as one or more user devices320used by one or more users321, one or more merchant systems330, one or more wallet network systems340, a wallet system350, services systems370, and issuer systems390used by issuers. In some embodiments, the systems of system300can be in data communication with each other through a network310. Network310can be the Internet or another suitable network, or multiple different networks. In some embodiments, network310can be public or private, or can include one or more public networks and one or more private networks.

The systems of system300, such as user devices320, merchant systems330, wallet network systems340, wallet system350, services systems370, and/or issuer systems390, can each be a computer system, such as computer system100(FIG.1), as described above, and can each be a single computer, a single server, or a cluster or collection of computers or servers, or a cloud of computers or servers. In another embodiment, a single computer system can host multiple systems of system300. For example, in some embodiments, a single computer system can host wallet system350and services systems370. In some embodiments, wallet system350can be provided and/or operated by an entity that is different from the entities operating merchant systems330, wallet network systems340, and/or issuer systems390.

In many embodiments, one or more merchant systems330can be operated by one or more merchants or payment service providers, which can host one or more websites and/or application servers. For example, merchant system330can host a website, or provide a server that interfaces with an application (e.g., a mobile application), on user device320, which can allow users321(e.g., consumers) to search for items (e.g., products, grocery items), to add items to an electronic cart, and/or to purchase items through an online merchant checkout process, in addition to other suitable activities. These websites or application servers hosted by merchant system330can provide a payment application331to users321using user devices320. Payment application331can provide the online merchant checkout process to user devices320, to allow user321to make a payment.

In a number of embodiments, merchant systems330also can run a wallet SDK (software development kit)332to enable merchant system330provide an online “bank checkout” process to users321. For example, as part of the online merchant checkout process provided by payment application331, payment application331can launch wallet SDK332to provide an online “bank checkout” process to users321. Wallet SDK332can serve user interfaces to the users321. Wallet SDK332can interface with wallet system350to obtain wallet services in merchant system330, which can enable merchant system330to provide to users (e.g.,350) an online “bank checkout” process that uses the wallet services. Wallet SDK332can be embedded within merchant system330to provide merchant system330with various functions. For example, wallet SDK332can provide user recognition through obtaining or collecting user information from the user, such as an email address of the user. Wallet SDK332can send the email address to wallet system350to determine the eligibility of the user for using the bank checkout process, such as based on whether there is a wallet for the user in wallet directory357with a matching email address. Wallet SDK332also can provide one or more user authentication screens, which can allow the user to provide authentication information, such as a one-time passcode (OTP) or multi-factor authentication (MFA). Wallet SDK332additionally can provide one or more payment selection screens, which can allow the user to select which payment card to use for the transaction. Wallet SDK332further can retrieve payment information from wallet system350, such as the token cryptogram, to allow the merchant to process the payment using payment application331. In some embodiments, wallet SDK332can interface with one or more services in services systems370, such as to provide risk management, behavioral analytics, device fingerprinting, and/or other suitable functions. In some embodiments, wallet SDK332can obtain device fingerprinting and/or behavioral analytics services through SEON Technologies, WhiteHat Security, Digital Guardian, OneSpan Mobile Authenticator, and/or other suitable services. In the same or other embodiments, wallet SDK332can include some of or all of such functionality, and/or other functionality, within wallet SDK332.

In many embodiments, in addition to communicating with merchant systems330, wallet system350can communicate with other systems, such as wallet network systems340, services systems370, and/or issuer systems390, to provide the wallet services. In many embodiments, the wallet services provided by wallet system350can provide a shared wallet for multiple payment cards (e.g., credit cards, debit cards, etc.) that were issued by multiple different issuers (e.g., issuers operating issuer systems390). In several embodiments, wallet system350can provide the wallet services to multiple different merchants (individually or simultaneously), each using a merchant system (e.g.,330).

In certain embodiments, user devices320can be desktop computers, laptop computers, mobile devices, and/or other endpoint devices used by one or more users (e.g., user321). A mobile device can refer to a portable electronic device (e.g., an electronic device easily conveyable by hand by a person of average size) with the capability to present audio and/or visual data (e.g., text, images, videos, music, etc.). For example, a mobile device can include at least one of a digital media player, a cellular telephone (e.g., a smartphone), a personal digital assistant, a handheld digital computer device (e.g., a tablet personal computer device), a laptop computer device (e.g., a notebook computer device, a netbook computer device), a wearable user computer device, or another portable computer device with the capability to present audio and/or visual data (e.g., images, videos, music, etc.). Thus, in many examples, a mobile device can include a volume and/or weight sufficiently small as to permit the mobile device to be easily conveyable by hand. For examples, in some embodiments, a mobile device can occupy a volume of less than or equal to approximately 1790 cubic centimeters, 2434 cubic centimeters, 2876 cubic centimeters, 4056 cubic centimeters, and/or 5752 cubic centimeters. Further, in these embodiments, a mobile device can weigh less than or equal to 15.6 Newtons, 17.8 Newtons, 22.3 Newtons, 31.2 Newtons, and/or 44.5 Newtons.

Exemplary mobile devices can include (i) an iPod®, iPhone®, iTouch®, iPad®, MacBook® or similar product by Apple Inc. of Cupertino, California, United States of America, (ii) a Lumia® or similar product by the Nokia Corporation of Keilaniemi, Espoo, Finland, and/or (iii) a Galaxy™ or similar product by the Samsung Group of Samsung Town, Seoul, South Korea. Further, in the same or different embodiments, a mobile device can include an electronic device configured to implement one or more of (i) the iPhone® operating system by Apple Inc. of Cupertino, California, United States of America, (ii) the Android™ operating system developed by the Open Handset Alliance, or (iii) the Windows Mobile™ operating system by Microsoft Corp. of Redmond, Washington, United States of America.

In many embodiments, the systems of system300can each include one or more input devices (e.g., one or more keyboards, one or more keypads, one or more pointing devices such as a computer mouse or computer mice, one or more touchscreen displays, a microphone, etc.), and/or can each comprise one or more display devices (e.g., one or more monitors, one or more touch screen displays, projectors, etc.). In these or other embodiments, one or more of the input device(s) can be similar or identical to keyboard104(FIG.1) and/or a mouse110(FIG.1). Further, one or more of the display device(s) can be similar or identical to monitor106(FIG.1) and/or screen108(FIG.1). The input device(s) and the display device(s) can be coupled to the systems of system300in a wired manner and/or a wireless manner, and the coupling can be direct and/or indirect, as well as locally and/or remotely. As an example of an indirect manner (which may or may not also be a remote manner), a keyboard-video-mouse (KVM) switch can be used to couple the input device(s) and the display device(s) to the processor(s) and/or the memory storage unit(s). In some embodiments, the KVM switch also can be part of the system of systems300. In a similar manner, the processors and/or the non-transitory computer-readable media can be local and/or remote to each other.

Meanwhile, in many embodiments, the systems of system300also can be configured to communicate with one or more databases. The one or more databases can include a wallet directory357, for example, among other databases. The one or more databases can be stored on one or more memory storage units (e.g., non-transitory computer readable media), which can be similar or identical to the one or more memory storage units (e.g., non-transitory computer readable media) described above with respect to computer system100(FIG.1). Also, in some embodiments, for any particular database of the one or more databases, that particular database can be stored on a single memory storage unit or the contents of that particular database can be spread across multiple ones of the memory storage units storing the one or more databases, depending on the size of the particular database and/or the storage capacity of the memory storage units.

In many embodiments, merchants operating or employing merchant systems330can enroll with the wallet service provided by wallet system350, so that wallet system350can provide wallet SDK332or another suitable interface that enables merchant system330to interface with wallet system350and provide the bank checkout process to users321. For example, merchant system330can run wallet SDK332to operate the bank checkout process that uses the shared wallet provided by wallet system350. Wallet system350can create and/or store a wallet for each user (e.g.,321) in wallet directory357. Wallet directory357can include a single shared wallet for a user (e.g.,321) that can be used for multiple different payment cards associated with the user, including multiple cards from different issuers (e.g., issuers operating issuer systems390). In many embodiments, wallet directory357can be centralized, so that it handles payment cards across multiple issuers. In several embodiments, communications between wallet system350and issuer systems390can occur through wallet network systems340. The wallet for a user can include information about the payment cards, such as tokenization information for the payment cards, along with other information identifying the user, such as an email address of the user, a phone number of the user, a social security number of the user (or hash thereof). Wallet directory357can be pre-populated before the merchant offers the user (e.g.,321) the opportunity to use the bank checkout process that uses the wallet of payment cards associated with the user.

In a number of embodiments, wallet network systems340can be operated by wallet network providers, such as payment networks (e.g., Visa, MasterCard, Discover, American Express, etc.). Wallet network system340can facilitate transactions between merchants (e.g., merchants operating merchant systems330) and issuers (e.g., issuers operating issuer systems390) by providing token services, and also can be referred to as token service providers. In some embodiments, wallet network system340can include systems, modules, and/or functions, which can provide the token services. For example, wallet network system340can include a token provisioning system341, a token lifecycle management system342, and/or a device binding system343. Token provisioning system341can tokenize credentials and/or provision such tokens. Token lifecycle management system342can manage the lifecycle of such tokens. Device binding system343can enable operating of such tokens in a cloud environment and binding the tokens to devices, such as user devices320. In some embodiments, wallet network system340can provide additional functions (not shown), such as authorization, processing clearing and settlement, processing chargebacks and disputes, etc.

In many embodiments, wallet system350can provide the wallet services, such as delivering payment credentials to merchant systems330. For example, the payment credentials can include a token cryptogram that can be used by merchant system330to process the payment using a card in the wallet associated with a user (e.g.,321). In some embodiments, the token cryptogram can be a dynamic payment authorization token. In a number of embodiments, wallet system350can include systems, modules, and/or functions, which can perform providing the wallet services and interfacing with other systems (e.g., wallet network systems340, infrastructure systems360, services systems370). For example, wallet system350can include a checkout system351, a token gateway352, a communication system353, a directory system354, an analytics system355, and/or a wallet management system356. In a number of embodiments, these systems (e.g.,351-356) of wallet system350can provide core wallet services to wallet SDK332and interface with other systems (e.g., wallet network systems340, infrastructure systems360, services systems370) to provide such wallet services. In some embodiments, wallet system350can include infrastructure systems360, which can support the systems (e.g.,351-356) of wallet system350. In other embodiments, infrastructure systems360can be outside of wallet system350. Infrastructure systems360are described below in further detail.

In several embodiments, checkout system351can interface with wallet SDK332in merchant systems330. For example, checkout system351can provide APIs (application programming interfaces) for wallet SDK332to interface with wallet system350, and/or for wallet system350to provide the bank checkout process to wallet SDK332. For example, when a user (e.g.,321) is at a checkout page for the merchant, the functionality and associated data for the bank checkout process can be provided by wallet SDK332based on wallet SDK332interfacing with checkout system351to obtain a list of payment cards in wallet directory357and a corresponding purchase payload for a selected payment card to enable payment application331of merchant system330to process the payment.

In a number of embodiments, token gateway352can provide a gateway to interface with wallet network systems340. In many embodiments, token gateway352can provide an abstraction layer to provide a uniform interface experience to the other systems of wallet system350, such as checkout system351, despite the different underlying wallet network services provided by wallet network systems340. For example, Visa Token Service (VTS) and MasterCard Digital Enablement Services (MDES) are different wallet network services that have different interfaces, but token gateway352can allow checkout system351to communicate with each of these services using the common interface provided by token gateway352. For example, various systems of wallet system350can communicate with wallet network systems340to provision cards, such as during auto-enrollment of cards provided by an issuer (e.g., an issuer operating issuer system390) before the checkout process access by the user (e.g.,321), and/or to obtain a token cryptogram as payment credentials during a payment transaction. In many embodiments, the users can be auto-enrolled based on credentials provided by wallet network systems340and/or from issuer systems390, such as issuer systems390communicating to wallet system350through wallet network system340.

In several embodiments, communication system353can provide connectivity and/or integration services. For example, communication system353can provide connections, interfaces, and/or integration with the systems in infrastructure systems360and/or services systems370, and/or with other systems, such as wallet network systems340, merchant systems330, and/or issuer systems390.

In a number of embodiments, directory system354can provide access to and/or maintain the data within wallet directory357. Wallet directory357can be a database that stores wallets for users321. The wallets can include personal information, such as names, addresses, email addresses, phone numbers (e.g., mobile phone number of a user device (e.g.,320)), social security number (or hash thereof), payment data (e.g., tokenized payment credentials, etc.), bank names of enrolled credentials, an indication of the default payment card for a wallet for a user, whether the user has successfully completed a transaction, the state of the wallet, etc. In some embodiments, wallet directory357can be distributed across multiple systems of storage devices. In several embodiments, each wallet in wallet directory357can include a wallet identifier or other key that can be used to associate the various elements of the respective wallet. In some embodiments, wallet directory357can be completely within wallet system350. In other embodiments, wallet directory357can be outside wallet system350. In yet other embodiments, wallet directory can be a distributed database that is partially within wallet directory357and partially within another system, such as one or more of services systems370.

In several embodiments, analytics system355can aggregate and/or analyze information from checkout transactions. For example, analytics system can generate reports by merchant, such as to determine success or failure rates per merchant, to determine rates of continued use by users after first using through a merchant, and/or to provide other suitable analytics.

In a number of embodiments, wallet management system356can provides an interface to directory system354from services systems370, such as a user management system374of services system370. As described below, user management system374can allow a user (e.g.,321) to access a portal, such as through a website or a mobile app, to manage the wallet for the user, such as updating consumer profile data, opting out, or other activities. In some embodiments, wallet management system356can receive provisioning information from directory system354.

In a number of embodiments, infrastructure systems360can include systems, modules, and/or functions, which can support the systems (e.g.,351-356) of wallet system350. For example, infrastructure systems360can include an API authorization broker361, a business-to-business (B2B) gateway362, hardware security modules (HSMs)363, business intelligence (BI) services364, and/or other suitable infrastructure services. In many embodiments, API authorization broker361can determine a riskiness of API calls made over network310, such as calls over a public network or the Internet, detecting bots, preventing denial of service attacks, verifying cookies, identifying users, performing device fingerprinting and/or behavior analytics, and/or other functions. In some embodiments, these functions can be provided by Amazon Cognito, Okta, Azure Active Directory, and/or other suitable services.

In many embodiments, B2B gateway362can provide a business-to-business authenticated API gateway. In some embodiments, this function can be performed by Amazon API Gateway, Apigee, Azure API Management, IBM API Connect, and/or other suitable services.

In many embodiments, HSMs363can be physical devices in a data center used to safeguard and manage cryptographic keys and/or perform cryptographic functions. HSMs363can be used to generate dynamic data for payments and protect keys used for data at rest and data in transit. In some embodiments, these services can be provided by Amazon Web Services (AWS) CloudHSM, AWS Key Management Services, Azure Key Vault, and/or other suitable services.

In many embodiments, BI services364can provide tools for generating reports and/or dashboards for analytics system355. In some embodiments, these services can be provided by AWS Tableau, AWS QuickSight, Microsoft Power BI, Looker, and/or other suitable services.

In a number of embodiments, services systems370can include systems, modules, and/or functions, which can support wallet SDK332and/or the systems of wallet system350and/or infrastructure systems360. These systems, modules, or functions can be part of a single system, or spread across multiple different systems. For example, services systems370can include a services portal371, an authentication system372, a risk management system373, a user management system374, a device fingerprinting system375, an SMS (Short Message Service) aggregator376, a CDN (content delivery network) system377, an analytics system378, a testing system379, a reporting system380, a merchant profiling system381, a developer portal382, and/or other suitable systems.

In many embodiments, services portal371can provide a portal for merchants and/or issuers to access their accounts with the entity providing wallet system350and/or obtain customer service.

In many embodiments, authentication system372can authenticate users321using user devices320when interfacing with wallet SDK332. For example, authentication system372can provide OTP, MFA, and/or other authentication services. In some embodiments, MFA can involve confirming the identity of the user (e.g.,321) using evidence in two or more factors. Factors can include knowledge (e.g., something only the user (e.g.,321) should know, such as passwords, PINs (personal identification numbers), answers to secret questions, etc.), possession (e.g., something only the user (e.g.,321) should have, such as security tokens, etc.), and/or inherence (e.g., something only the user (e.g.,321) is, such as biometric attributes, etc.).

In many embodiments, risk management system373can provide fraud and/or risk management services to reliably and/or safely evaluate wallet interactions. For example, risk management system373can apply rules, statistical modeling, machine learning, and/or other techniques to various data inputs, such as information about the mobile device, the owner of the mobile device, the payment card account, the owner of the payment card account, the mobile network operator, the token service provider, and/or other suitable information, to determine a risk of fraud or other level of risk. In some embodiments, the output can be a score and/or a decision of whether to allow or reject the provisioning or transaction, and/or to impose further verification procedures. The rules and/or models (e.g., statistical, machine learning, etc.) can use as inputs the data inputs listed above, and/or can be based on blacklists, whitelists, watch lists, velocities (e.g., counts of activities with a common anchor point within a period of time), familiarity (e.g., association with the account or device in the past), integrity (e.g., device malware, crimeware, root, jailbreak), obfuscation (e.g., location spoofing, proxying IP address, spoofing user agent), behavioral patterns, mismatches, anomalies, inconsistencies, and/or other suitable information or rules, or modeling. In some embodiments, a card security code, such as CVV (card verification value), CVV2 (card verification value 2), CVC (card validation code), etc., can be used to authenticate the card as part of the fraud risk determination. Additionally, the user may be asked to verify the ZIP code associated with the card. Further, there may be checks to determine whether the card has been reported lost, stolen, or counterfeit, or for reported fraud or compromise using the card or account.

In many embodiments, different types of risk models can be used with different rules that are relevant to different types of actions attempted by users. In some embodiments, a series of signals can be collected for the risk model from various data sources (e.g., on-device, mobile network operator, in-application history, card association APIs, etc.). In many embodiments, signals can be aggregated and/or translated to be applied into a set of rules (e.g., positive or negative rules) in the risk model. In several embodiments, at a risk moment, risk rules can trigger in the risk model depending on the underlying characteristics of the transaction and/or user behavior/interaction, which result in a risk score. In various embodiments, risk points can be added to the risk score if a negative rule is triggered. In some embodiments, risk points can be subtracted from the risk score if a positive rule is triggered. In several embodiments, risk points can be tallied from each rule and create a total score. In many embodiments, if the score is above a defined threshold (e.g., decline threshold) the attempted action can be declined for potential fraud. In several embodiments, transactional fraud feedback data can subsequently be received, which can be matched into transactions for adjusting/tuning of individual rules to true fraud, and seeding blacklists with risk signals (e.g., mobile devices, IP Addresses, etc.) belonging to fraudsters. In a number of embodiments, the “levers and knobs” of the risk model that allow it to be tuned and/or calibrated for improving possible detection are the set of risk rules included, the risk points/scores/weights, thresholds for each risk rule, and the thresholds for the overall model. The weights can indicate a relative riskiness of an attempted action.

In many embodiments, the decline threshold and/or scores associated with risk rules can be adjusted to tune the risk model based on actual data, such as details of fraud that were not previously caught and the associated risk signals. Some rules can have positive scores, which can correspond to potentially high-risk situations, and, if triggered, can increase the risk score. Other rules can have negative scores, which can correspond to low-risk situations, and, if triggered, can decrease the risk score. As an example, an attempted action (e.g., transaction, provisioning, etc.) can generate a number of risk signals, which can be positive and/or negative. Various rules can be triggered, which can add or subtract risk points. If the risk score for a provisioning attempt exceeds the decline threshold, card provisioning fraud is likely, and the provisioning can be denied. In other embodiments, the provisioning attempt can be further investigated.

In several embodiments, risk rule tuning can be contingent on receiving “ground truth” fraud feedback data, such as issuer-contributed fraud performance data. In many embodiments, statistical measures of effectiveness can be used to consider adjustments to rule weighting (e.g., rule points/rule scores) within the model based on one or more of the following factors, for example: coverage (considering the percentage of total transactions flagged by the rule), detection (considering the percentage of total fraudulent transactions flagged by the rule, or the percentage of total fraudulent dollars flagged by the rule), hit rate (considering the percentage of flagged transactions that were actually fraudulent), lift (considering how much better a rule does when compared to random selection, such as based on detection divided by coverage), false positive rate (considering the proportion of good users tagged as bad by model), false negative rate (considering the proportion of bad users tagged as good by model), and/or other suitable factors. In many embodiments, customized risk rules can be created based on specific feedback data. For example, blacklist risk rules can be developed based on specific fraud risk signals used in the past.

In many embodiments, user management system374can allow users321to access a portal, such as through a website or a mobile app, to manage the wallet for the user. For example, the user can update consumer profile data, opt out, or perform other activities. In some embodiments, user management system374can interface with wallet system350through wallet management system356, a described above.

In many embodiments, device fingerprinting system375can provide device fingerprinting and/or behavioral analytics services, which can be used to collect device and/or browser-related data to identify a specific device (e.g., user device320) connected to network310(e.g., the Internet) and/or to provide a device identifier. The device identifier can be used by risk management system373to determine risk scores for the device. In some embodiments, device fingerprinting system375can be performed through SEON Technologies, WhiteHat Security, Digital Guardian, OneSpan Mobile Authenticator, and/or other suitable services.

In many embodiments, SMS aggregator system376can be an SMS aggregator and/or gateway system used to aggregate and deliver SMS messages to user devices (e.g.,320) via mobile network operators. These SMS messages can be used for sending the OTP authentication messages, among other messages. In some embodiments, SMS aggregator system376can be performed through Twilio, MessageBird, Podium, and/or other suitable services.

In many embodiments, CDN system377can provide a geographically distributed, networked system for fast delivery of internet content. In some embodiments, CDN system377also can provide protection against distributed denial of service (DDOS) attacks. In some embodiments, CDN system377can be performed through Akamai, AWS, Lumen, and/or other suitable services.

In many embodiments, analytics system378can be used to track and/or report website traffic. In some embodiments, analytics system378can be performed through Adobe Analytics, Glassbox, Amplitude Analytics, Semrush, Pendo, and/or other suitable services.

In many embodiments, testing system379can provide testing services, such as A-B split testing to optimize a digital experience. For example, testing system379can compare two versions of user interface screens (e.g., checkout screens) against each other to determine which ones performs better or has better market acceptance, but displaying to or more variants of the page to users at random, and performing statistical analysis to determine which variation performs better for a given conversion goal. In some embodiments, testing system379can be performed through AB Tasty, VWO Testing, Split, Salesforce Marketing Cloud Personalization, and/or other suitable services.

In many embodiments, reporting system380can provide reporting services based on wallet transactions, such as transactions through wallet network systems340. These reports can be provided on regularly set intervals or on an ad-hoc basis.

In many embodiments, merchant profiling system381can be used to onboard and manage merchants for participating in the bank checkout process using wallet system350. In some embodiments, merchant profiling system381can perform KYC (know your client) services and/or other compliance checks to determine whether or not the merchant is valid and is not participating in fraudulent activity. In a number of embodiments, merchant profiling system381can be accessed through an API or a portal. For example, in some embodiments, merchants can be onboarded through the API or the portal, and once onboarded, the profile for the merchant can be managed through the portal. The profile can include merchant information, such as merchant name, DBA (doing business as) name, URL (uniform resource locator), address, contact details etc. The profile also can be used to determine the capabilities of the merchant and the preferences of the merchant for enabling the checkout experience, to determine whether the merchant is a basic eCommerce merchant or is also a token requestor (e.g., for Credential on File tokens), and/or whether the merchant will provide the keys to secure the communication and access to wallet system350.

In many embodiments, developer portal382can be used by developers interfacing with the systems or components thereof of system300to obtain development and/or API information, perform sandbox testing, and/or other development activities.

Turning ahead in the drawings,FIG.4illustrates a flow chart for a method400of processing, facilitating, providing, or using online checkout using a shared wallet across issuers, according to an embodiment. Method400is merely exemplary and is not limited to the embodiments presented herein. Method400can be employed in many different embodiments or examples not specifically depicted or described herein. In some embodiments, the procedures, the processes, and/or the activities of method400can be performed in the order presented. In other embodiments, the procedures, the processes, and/or the activities of method400can be performed in any suitable order. In still other embodiments, one or more of the procedures, the processes, and/or the activities of method400can be combined or skipped.

In many embodiments, system300(FIG.3), wallet system350(FIG.3), and/or services system370(FIG.3) can be suitable to perform method400and/or one or more of the activities of method400. In these or other embodiments, one or more of the activities of method400can be implemented as one or more computing instructions configured to run at one or more processors and configured to be stored at one or more non-transitory computer readable media. Such non-transitory computer readable media can be part of system300(FIG.3), wallet system350(FIG.3), and/or services system370(FIG.3). The processor(s) can be similar or identical to the processor(s) described above with respect to computer system100(FIG.1). In some embodiments, method400and other activities in method400can include using a distributed network including distributed memory architecture to perform the associated activity. This distributed architecture can reduce the impact on the network and system resources to reduce congestion in bottlenecks while still allowing data to be accessible from a central location.

Referring toFIG.4, method400can include an activity405of receiving a unique identifier for a user. The user can be similar or identical to user321(FIG.3). In some embodiments, the unique identifier can be an email address of the user, such as an email address entered by the user through payment application331(FIG.3) or wallet SDK332(FIG.3). In other embodiments, the unique identifier can be another suitable unique identifier, such as a phone number.

In several embodiments, method400also can include an activity410of determining, using a wallet directory, a shared wallet associated with the unique identifier. The wallet director can be similar or identical to wallet directory357(FIG.3). The shared wallet can include identifying information for cards issued from multiple different issuers. The issuers can be associated with issuer systems (e.g.,390(FIG.3). In some embodiments, the cards can be preloaded into the shared wallet before a transaction (such as the first transaction described below) based on the cards being provisioned in the shared wallet based at least in part on information provided from the multiple different issuers. In some embodiments, each of the cards can be provisioned in the shared wallet based at least in part on an acceptable outcome of a respective fraud risk determination for provisioning each of the cards. In some embodiments, the shared wallet further can include an email address of the user, a phone number of the user, a hash of a social security number of the user, and/or other suitable information.

In a number of embodiments, method400further can include an activity415of performing an authentication of the user. In some embodiments, activity415of performing the authentication of the user can include causing a multi-factor authentication to be performed based at least in part on using a phone number of a mobile device of the user. In other embodiments, other suitable authentication procedures can be performed by wallet system350(FIG.3), authentication system372(FIG.3), wallet network system340(FIG.3), and/or issuer system390(FIG.3), as described above.

In several embodiments, method400additionally can include an activity420of sending the identifying information for the cards to enable the user to select one of the cards for a first transaction at a first merchant. For example, the first transaction can be an online checkout at the first merchant, which can be an online merchant. In some embodiments, the identifier information for the cards can be sent to wallet SDK332(FIG.3) to be displayed on a user interface on user device320(FIG.3) to the user (e.g.,321(FIG.3)).

In a number of embodiments, method400further can include an activity425of obtaining information about a first selected card of the cards based on a selection from the user. For example, the user can select one of the cards displayed to the user through wallet SDK332(FIG.3).

In several embodiments, method400additionally can include an activity430of performing a fraud risk determination for the first transaction with the first selected card. In several embodiments, the fraud risk determination can be performed by wallet system350(FIG.3), authentication system372(FIG.3), wallet network system340(FIG.3), and/or issuer system390(FIG.3), as described above. In some embodiments, activity430of performing the fraud risk determination can include causing one or more fraud risk determinations to be performed by one or more third-party systems, and the performing the fraud risk determination for the first transaction based in part on the one or more fraud risk determinations. In some embodiments, the one or more fraud risk determinations can be performed by the wallet network system. In some embodiments, the one or more fraud risk determinations can be based at least in part on a card security code for the first selected card, as described above. In some embodiments, the one or more fraud risk determinations can be based at least in part on a device fingerprinting for a mobile device of the user, as described above. In some embodiments, the one or more fraud risk determinations can be based at least in part on behavior analytics of the user, as described above. In some embodiments, the fraud risk determination can be based at least in part on one or more of rules, one or more statistical models, and/or or one or more machine-learning models, as described above. In some embodiments, the fraud risk determination can be based at least in part on inputs comprising registered owner information for a mobile device of the user, registered owner information for the first selected card, and/or other suitable information, such as described above.

In a number of embodiments, method400further can include an activity435of requesting a first payment authorization token for the first selected card from a wallet network system. For example, wallet system350(FIG.3) can request the first payment authorization token from wallet network system340(FIG.3) for the first transaction.

In several embodiments, method400additionally can include an activity440of sending the first payment authorization token to enable the first merchant to process the first transaction using the first selected card. In some embodiments, the first payment authorization token can include a dynamic payment authorization token, such as an authorization token that is different from each transaction. In some embodiments, the first payment authorization token can include a token cryptogram.

In several embodiments, one or more of the activities of method400can be performed for a second transaction, such as a second transaction using a second selected card at a second merchant. For example, at the second merchant, the user can enter the email address of the user, and activity405can involve receiving such email address, such as at wallet system350. Activity410can similarly determine the shared wallet associated with the unique identifier, after which activity415can involve performing an authentication of the user, and activity420can involve sending identifying information for the cards to enable the user to make a selection for the second transaction at the second merchant. Activity425can involve obtaining the second selected card, and activity430can involve performing a fraud risk determination for the second transaction. Activity435can involve requesting a second payment authorization token, and sending the second payment authorization token to enable the second merchant to process the second transaction using the second selected card.

Although systems and methods for processing, facilitating, providing, or using online checkout using a shared wallet across issuers has been described with reference to specific embodiments, it will be understood by those skilled in the art that various changes may be made without departing from the spirit or scope of the invention. Accordingly, the disclosure of embodiments of the invention is intended to be illustrative of the scope of the invention and is not intended to be limiting. It is intended that the scope of the invention shall be limited only to the extent required by the appended claims. For example, to one of ordinary skill in the art, it will be readily apparent that any element ofFIGS.1-4may be modified, and that the foregoing discussion of certain of these embodiments does not necessarily represent a complete description of all possible embodiments. For example, one or more of the procedures, processes, or activities ofFIG.4may include different procedures, processes, and/or activities and be performed by many different modules, in many different orders. As another example, the components within system300(FIG.3) can be interchanged or otherwise modified.