Patent ID: 12223476

DETAILED DESCRIPTION

Consumers paying for goods and services often use credit or debit cards as a payment method. However, payment using debit or credit cards for a user typically involves obtaining the account and then waiting for the card to arrive so that it can be used. For the card issuer, typically there are time and money costs involved in generating and shipping the card, which leaves the user unable to use the card to purchase goods and services until the card arrives. Both issuers and users (i.e., consumers) would benefit from the ability of an issuer to instantly issue a digital card to the user on a mobile device.

Many users have secure mobile devices that are personally owned and used. For example, many users have a mobile cellular telephone and/or tablet. A mobile device may include a digital pay wallet. A pay wallet may be software on the mobile device that allows a user to link a payment source (e.g., credit or debit card) to the mobile device so that the payment source can be used to purchase goods and services without having a physical card or check, for example. Often near field communication is used between the point-of-sale device and the mobile device to securely provide the payment information from the mobile device to the point-of-sale device.

In some existing systems, the user of the mobile device typically uses the physical card information to set up the pay wallet with the payment source. For example, a user can use a pay wallet application on their mobile device and either take a picture of the physical card or manually enter the information from the physical card to add the card to their pay wallet in this manner. This type of provisioning of a card into a pay wallet is typically termed pull provisioning. The payment source information is “pulled” into the pay wallet. The user is limited, however, to waiting until the physical card arrives to provision the card into the pay wallet. Entering the physical card information, however, assures the pay wallet provider, the issuer, and the token service provider that the user is the owner of the payment source. As such the user can be authenticated for provisioning the payment source into the pay wallet.

Described herein are methods and systems for facilitating push provisioning, which may allow an issuer to provide a button in an issuer's mobile application for the user to simply push the button to request that the payment source be imported into the user's pay wallet. In this way, the payment source information is “pushed” into the pay wallet. Using push provisioning, the user need not enter any physical card information. However, the user must be authenticated properly to prove to each of the issuer, the pay wallet provider, and the token service provider that the user owns the payment method.

In existing systems, various different pay wallet providers and issuers have differing requirements for provisioning a payment source into a pay wallet. Because of the complications associated with tracking the various requirements of each pay wallet provider, issuers are reluctant to implement push provisioning in their issuer mobile applications. Described herein is a software development kit for including by an issuer in the issuer's mobile application that provides the interfaces for easily implementing push provisioning with any pay wallet provider.

Further, in existing systems, obtaining the primary account number (“PAN”) data and appropriately encrypting the information varies by token service provider, making the issuer even more reluctant and sometimes simply unable to implement push provisioning. In addition to the software development kit, the described solution provides a PAN gateway lookup service and a PAN gateway encryption service with which the software development kit can interface for ensuring that the push provisioning works not only with any pay wallet but with any token service provider.

FIG.1illustrates a system100for instant digital issuance of payment sources. The system100can include a wallet device105, a gateway110, a token service provider115, domain servers120, and a pay wallet server125.

The wallet device105may be any suitable device that can support a digital wallet. The wallet device105may be computer system400as described with respect toFIG.4. The wallet device105may be, for example, a mobile cellular telephone, a tablet, a personal digital assistant, or the like. The wallet device105(also referred to herein as a user device or a mobile device) may include a pay wallet140and an issuer mobile application130. While only a single wallet device105is depicted inFIG.1, any number of wallet devices105may be supported within system100.

The pay wallet140may be any suitable digital wallet. The pay wallet140may be implemented as a software application installed and executed upon the wallet device105. Currently digital wallets are available from multiple vendors including, for example, Apple Pay® from Apple Inc., Google Pay™ from Google LLC, and Samsung Pay® from Samsung.

The issuer mobile application130may be a software user interface application provided by the card issuer. The card issuer may be any suitable payment source (e.g., debit or credit card) issuer. Example card issuers include, for example, JPMorgan Chase & Co, Wells Fargo, Bank of America Corporation, Capital One, and so forth. Each issuer may provide an issuer mobile application130. The issuer mobile application130may be a software application that is installed on the wallet device105and allows the user to access the user's account information with the issuer.

The issuer mobile application130may incorporate a software development kit135. The software development kit135may provide interfaces and methods for interfacing with pay wallet140and domain servers120that facilitate push provisioning of a payment source from the issuer that provides issuer mobile application130into the pay wallet140for use on the wallet device105.

The token service provider115may provide a token service for digital use of the payment source. For example, when sending digital payment information, the full account information, such as the sixteen digit account number may not be sent to protect the account information. Rather, a token may be generated and assigned to the sixteen digit account number. The token service provider115may receive and validate the push provision request with the encrypted provision data and activation data. The token service provider115may authorize the token and provide notification of the approval to the pay wallet server125as well as the issuing host platform155. While only one token service provider115is depicted inFIG.1, any number of token service providers115may be included in system100. Token service provider115may be, for example First Data universal token service by First Data Corporation or Visa token service by Visa Inc. The token service provider115may be a service provided on a computer system (e.g., a server) such as computer system400ofFIG.4.

The domain servers120may include the issue mobile application server160and the issuing host platform155. The domain servers120may be any suitable servers the issuer of the payment source provides and may be computer systems400ofFIG.4. The issuer mobile application server160may be a server managed by the issuer that the issuer mobile application130interfaces with to obtain user account information for display in the user interface of the issuer mobile application130on the user's wallet device105. The issuing host platform155may be the host server managed by the issuer that stores and manages all user account information.

The pay wallet server125may be any suitable server provided by the pay wallet provider (e.g., Google LLC for Google Pay, Samsung for Samsung Pay®, and so forth), such as for example computer system400ofFIG.4. The pay wallet server125may interface between the token service provider115and the pay wallet140to provision the payment source in the pay wallet140. While a single pay wallet server125is depicted inFIG.1, any number of pay wallet servers125may be included in system100.

The gateway110may include full PAN encryption service145and full PAN lookup service150. The gateway may be one or more servers that are hosted on a network (not shown) for communication with the domain servers120and the token service provider115. The gateway110may be computer system400ofFIG.4. While a single gateway110is shown inFIG.1, any number of gateways110may be included. The full PAN encryption service145and the full PAN lookup service150provided by gateway110provide a many-to-many gateway service for encrypting PAN data. Each pay wallet server125has specific encryption requirements that differ. For example, Apple Pay® has different encryption requirements than Samsung Pay®. Further, each token service provider115has differing encryption requirements. For example, First Data universal token service has different encryption requirements than Visa token service. The combination of digital wallet (e.g., Apple Pay®, Samsung Pay®, or the like) and token service provider (e.g., Visa token service, First Data universal token service, or the like) each has a unique combination of encryption requirements that complicate push provisioning for an issuer to implement push provisioning in the issuer's mobile application. The gateway110with the full PAN encryption service145and the full PAN lookup service150in combination with the software development kit135provide a technical solution that simplifies implementing push provisioning in the issuer's mobile application (issuer mobile application130).

The full PAN lookup service150and the full PAN encryption service145may be software services installed upon the gateway110for providing their respective services as described in more detail herein.

The full PAN lookup service150may provide lookup services of a user's PAN from an issuing host platform155. The full PAN lookup service150may obtain the information for a user account including the full sixteen digit account number, a card nickname, an associated address of the user, credentials (e.g., user name of the user) from the issuer mobile application130, and so forth. The full PAN lookup service150is optional. In some embodiments, the issuer may provide the full sixteen digit account number and all other necessary information such that the full PAN lookup service150is not used.

The full PAN encryption service145may obtain the user account information from the full PAN lookup service150and prepare encrypted provision data used to complete the push provisioning as described in detail herein. The encrypted provision data is encrypted and signed by the full PAN encryption service145. The encryption is completed using an encryption key provided to the full PAN encryption service145by the token service provider115. Each token service provider115provides an encryption key for encryption of user data. In some embodiments. The token service provider115provides a single encryption key for all user accounts that use the token service provider115, and in some embodiments an encryption key unique to each issuer is provided. The encryption ensures that only the destined token service provider115or the destined pay wallet server125can decrypt the data. The encryption provision data is also signed by the full PAN encryption service145using a validation key established by the full PAN encryption service145and exchanged with the token service provider115. The signature ensures the token service provider115can validate the signature in the provision request to ensure the chain of trust is complete as described in more detail herein.

FIG.2illustrates a swim diagram200of a method for instant digital issuance of a payment source using the components described with respect toFIG.1. Along the top of the swim diagram200, the components described with respect toFIG.1are shown including the wallet device105, issuer mobile application130, software development kit135, pay wallet140, pay wallet server125, issuer mobile application server160, gateway110, full PAN encryption service145, full PAN lookup service150, token service provider115, and issuing host platform155.

Beginning with the issuer mobile application130, as arrow202, the issuer mobile application130transmits user information entered by the user using the user interface of the issuer mobile application130. The user information is transmitted to the issuer mobile application server160.

The issuer mobile application server160may authenticate the user using the user information (e.g., a user name and password, biometric data, and so forth). The issuer mobile application server160may transmit a request, shown by arrow204, to issuing host platform155for a list of eligible accounts for the user. The eligible accounts may include any user accounts the issuer has recorded for the user. For example, a user may have one or more checking or savings accounts associated with one or more debit cards and/or one or more credit cards from the same issuer (e.g., Wells Fargo, Capital One, and so forth).

The issuing host platform155may transmit the full PAN suffix data (e.g., the last four digits of the sixteen digit account number) for each eligible account for the user to the issuer mobile application server160as shown by arrow206. The issuer mobile application server160may transmit the full PAN suffix data to the issuer mobile application130as shown by arrow208. The issuer mobile application130may not maintain account information for the user on the wallet device105, so all account information may be obtained from the issuer mobile application server160for display in the user interface of the issuer mobile application130.

Once the issuer mobile application130has obtained the full PAN suffix data, the issuer mobile application130can invoke methods provided by the software development kit135as shown by arrow210. Arrow212indicates that the software development kit135may include a method to query the pay wallet140for whether the full PAN suffix data identifies an account (i.e., payment source) that has previously been provisioned by the pay wallet140. If the account has previously been provisioned by the pay wallet140, there is no need to provision the account again. However, if the account has not previously been provisioned by the pay wallet140, the user may wish to use push provisioning to provision the pay source into the pay wallet140.

The pay wallet140may respond to the query, as shown by arrow214, with information indicating whether the account associated with the full PAN suffix data for each eligible account has previously been provisioned.

If at least one account has not previously been provisioned, the software development kit135may invoke another method to request wallet data for push provisioning. Wallet data may include, for example, a wallet identifier (i.e., an identifier for pay wallet140), a device identifier (e.g., an Internet Protocol address for wallet device105, a media access control (“MAC”) address for wallet device105, or any other suitable identifier for wallet device105), a binding identifier or a digital signature that binds the user to the pay wallet140, a name of the wallet device105, the push provision request (used to prevent the request from being replayed or spoofed), a wallet certificate that contains a public key for encrypting PAN data to be sent back to the pay wallet server125, and the like. For simplicity of explanation, only a single account provision is described, but multiple accounts from an issuer may be provisioned into pay wallet140in parallel or serially. The software development kit135may request the wallet data from the pay wallet140as shown by arrow216. The pay wallet140may request the wallet data from the pay wallet server125as shown by arrow218. The pay wallet server125may provide the wallet data for the account to the pay wallet140as shown by arrow220. The pay wallet140may provide the wallet data to the software development kit as shown by arrow222. The software development kit135may provide the wallet data to the issuer mobile application130as shown by arrow224. The issuer mobile application130may then display a button within the user interface of the issuer mobile application130. The button, when pressed by the user, may invoke the push provisioning process for adding the account to the pay wallet140.

Arrow226may transmit the wallet data from the issuer mobile application130to the issuer mobile application server160when the user pushes the button within the issuer mobile application130to invoke the push provisioning process for adding the payment source (i.e., eligible account for which the full PAN suffix data was obtained) to the pay wallet140.

The issuer mobile application server160may authenticate the user and confirm the authenticity of the received information. Once authenticated, the issuer mobile application server160may provide the account information (e.g., the user name, the full PAN suffix data, and so forth), the wallet data, and an issuer nonce to the Full PAN encryption service145as shown by arrow228. The issuer nonce may be a randomly generated identifier that indicates that the user has been authenticated by the issuer mobile application server160(the user was previously authenticated at arrow202) and is used in the push provision request for the transaction beginning at arrow228. Optionally, the PAN data including the full sixteen digit account number may have been provided to the full PAN encryption service145from the issuer mobile application server160as well.

The full PAN encryption service145may determine whether a full PAN lookup is needed based on whether the full PAN encryption service145has the PAN data. If the full PAN encryption service145does not have the PAN data, the full PAN encryption service145may transmit the account information, the wallet data, and the issuer nonce to the full PAN lookup service150as shown by arrow230.

The full PAN lookup service150may request the PAN data from the issuing host platform155as shown by arrow232. The request may include the user information, account information, and/or credentials obtained from the issuer mobile application server sent through the full PAN encryption service. The issuing host platform155may search a database or other data source using the user information, account information, and/or credentials to identify the requested PAN data. The issuing host platform155may return the PAN data to the full PAN lookup service150as shown by arrow234. The PAN data may include the full sixteen digit account number, the user's address, and/or the payment source (e.g., credit card) nickname.

As shown by arrow236, the PAN data may be transmitted from the full PAN lookup service150to the full PAN encryption service145. The full PAN encryption service may encrypt the PAN data to create encrypted provision data. Optionally, the user information, account information, wallet data, issuer nonce, PAN data, user's address, and/or card nickname may be included with the PAN data and encrypted. The full PAN encryption service145may encrypt the PAN data (including the user information, account information, wallet data, issuer nonce, PAN data, user's address, and/or card nickname) using an encryption key and may digitally sign the PAN data using a validation key. The encryption key and/or the validation key may be set with the token service provider information. In other words, the encryption key and/or the validation key may identify the token service provider. The encryption key and/or the validation key may be obtained from the issuer when the issuer registers with the gateway110, which may optionally include registering with the full PAN encryption service145and/or the full PAN lookup service150. Optionally, the encryption key and/or the validation key may be established directly between the full PAN encryption service114and the token service provider115, and all provision requests for issuers that use that token service provider115have data that is encrypted with the encryption key and signed with the validation key for that token service provider115. Optionally, multiple issuers may utilize the same encryption key and/or validation key. When the full PAN encryption service145obtains an encryption and/or validation key, the encryption and/or validation key may be stored with other keys in a database or other storage location accessible to the full PAN encryption service145. The full PAN encryption service145may search the key database using, for example, the primary account number data. As an example, the first four digits of a sixteen digit account number may identify an issuer, so the database may be queried using the first four digits of the sixteen digit account number from the PAN data to identify the encryption key and/or validation key. As another example, the issuer may be identified based on the PAN data and the database may be queried using the issuer for the encryption key and/or validation key. Optionally, the PAN data encrypted with the encryption key may also be encrypted with the wallet certificate from the wallet data. The wallet certificate may include a public key used for encrypting the PAN data. The pay wallet server125may have the corresponding private key for decryption that the pay wallet server may use to decrypt the PAN data as described below.

In some embodiments, the validation key is unique to the issuer and the token service provider. In other embodiments, the token service provider permits the full PAN encryption gateway to use the same validation key across multiple issuers processed by that gateway because the gateway performs mutual authentication with the issuer server, and the token service provider trusts the gateway's authentication of the issuer server. Using the same validation key across multiple issuers speeds up the implementation timeline for enabling this gateway service for a new issuer. The chain of trust generated by the process is sufficient to ensure security. For example, the chain of trust is that the issuer authorizes the user and sends the request to the encryption gateway. The encryption gateway has mutual authentication of the issuer and signs the request payload with a key trusted by the token service provider. Accordingly, because the request is encrypted with a trusted key by a trusted partner that in turn has authenticated the issuer, and the issuer has in turn authenticated the user, the token service provider can be assured that the user is validly requesting the provisioning of the payment source into the user's digital pay wallet.

As discussed above with respect to gateway110ofFIG.1, the token service provider115and the pay wallet server125may each have different encryption requirements. Further, for any given push provision request, any available digital wallet (i.e., pay wallet server125) and any available token service provider (i.e., token service provider115) may be used so that any given push provision request may require any combination of encryption requirements that meet both the selected token service provider encryption requirements and the digital wallet encryption requirements. The full PAN encryption service145may identify the set of encryption requirements for the token service provider identified by the encryption key. The full PAN encryption service145may also identify the set of encryption requirements for the pay wallet server125based on the wallet data included with the PAN data. The encryption requirements for all available token service providers115may be stored in a database available to full PAN encryption service145. The encryption requirements for all available pay wallet servers125may also be stored in a database available to full PAN encryption service145. Full PAN encryption service145may identify each set of encryption requirements (i.e., the set of encryption requirements for the token service provider and the set of requirements for the pay wallet server) and ensure the encryption of the PAN data complies with each set of requirements. Example requirements may include the type of encryption algorithm (e.g., symmetric-key algorithm, format-preserving algorithm, and so forth) that may be used, the minimum length of the encryption key (e.g., 128-bit key, 256-bit key, and so forth) that may be used, and so forth.

Once the full PAN encryption service145has generated the encrypted provision data, the full PAN encryption service145may transmit the encrypted provision data to the issuer mobile application server160as shown by arrow238. The issuer mobile application server160may transmit the encrypted provision data to the issuer mobile application130as shown by arrow240. The issuer mobile application130may invoke an add card method that may call methods within the software development kit135as shown by arrow242.

The software development kit135may initiate a request to add the card to the pay wallet140by transmitting the encrypted provision data to the pay wallet140as shown by arrow244. The pay wallet may transmit the provision request to the pay wallet server125by transmitting the encrypted provision data as shown by arrow246. The pay wallet server125may transmit the provision request and the encrypted provision data to the token service provider115as shown by arrow248.

The token service provider115may use the encryption key to decrypt the encrypted provision data and may use the validation key to authenticate the data as from the encryption gateway. The token service provider115may identify within the decrypted provision data the account information including the PAN data (e.g., the sixteen digit account number), the user information, the wallet data, and so forth, and use the identified information to generate a token to be used by the user within the pay wallet140. The token service provider115may transmit a provision authorization, including the token and the issuer nonce, to the issuing host platform155as shown by arrow250.

The issuing host platform155may store the token with the PAN data. Optionally, the issuer mobile application130may have previously sent the issuer nonce to the issuing host platform155(not depicted inFIG.2). The issuing host platform155may check the issuer nonce from the issuer mobile application130against the issuer nonce received at250to confirm that the push provision request was authenticated by the issuer mobile application server160, thereby validating the chain-of-trust. The issuing host platform may transmit an acknowledgement to the token service provider115as shown by arrow252. The token service provider may then transmit a provision notification to the issuing host platform155as shown by arrow254, and the issuing host platform155may transmit an acknowledgement to the token service provider115as shown by arrow256. After these acknowledgements, the token service provider115and the issuing host platform155both acknowledge the token and consider the account provisioned into the pay wallet140.

The token service provider115then transmits the provision response (e.g., successful provisioning indicated by the token, which is also transmitted) to the pay wallet server125as shown by arrow258. The pay wallet server125then stores the token with the user information and account information so that future requests to determine whether the add button should be included in the issuer mobile application will result in a negative response. Further, the pay wallet140will obtain the token from the pay wallet server125to allow the user to use the payment source (i.e., account associated with the token) from the pay wallet140. The pay wallet server125transmits the token to the pay wallet140as shown by arrow260. The pay wallet140transmits the token and/or a success or failure message indicating whether the payment source was successfully provisioned or not to the software development kit135as shown by arrow262. The software development kit135transmits the token and/or the success or failure message to the issuer mobile application130as shown by arrow264. The issuer mobile application130then optionally displays a notification to the user that the account was successfully provisioned into the pay wallet140or indicates a failure if the provisioning was unsuccessful.

FIG.3illustrates a method300for instant digital issuance of a payment source. The method may be performed by the gateway110as described with respect toFIG.1. The method300begins at block305with the gateway encryption service (e.g., full PAN encryption service145ofFIG.1) receiving user information for a user and account information for a payment source of the user from an issuer mobile application server (e.g., issuer mobile application server160). Optionally, the user information and account information is transmitted to the gateway encryption service in response to a user requesting push provisioning of the account into a pay wallet from the issuer's mobile application.

At block310, the gateway encryption service may transmit the user information and the account information to a gateway lookup service (e.g., full PAN lookup service150ofFIG.1). The account information may include a PAN suffix (e.g., the last four digits of the sixteen digit account number), the user's name, the user's credentials (e.g., a username and password, biometric data including a fingerprint or iris scan, and/or so forth), wallet data for the pay wallet into which the user wishes to provision the account, an issuer nonce, and so forth.

At block315, the gateway lookup service may receive PAN data for the payment source from an issuing host platform. The gateway lookup service may have transmitted the PAN suffix, the user's name, the user's credentials, the wallet data, and/or the issuer nonce to the issuing host platform requesting the PAN data. The PAN data may include the sixteen digit account number, the user's address, and/or a nickname the user may have assigned to the account.

At block320, the gateway lookup service may provide the PAN data to the gateway encryption service. At block325, the gateway encryption service may encrypt the PAN data to generate encrypted provision data. The gateway encryption service may use an encryption key to encrypt the data and a validation key to sign the data. The encryption key and validation key may be set with a specific token service provider for the issuer that the issuer may have provided to the gateway encryption service. In some embodiments, the encryption key and the validation key used for a token service provider is used for all issuers that use that token service provider. The gateway encryption service may user the encryption key to encrypt the PAN data. Optionally, the gateway encryption service may combine the PAN data, the user's credentials, the PAN suffix, the user's name, the wallet data, and/or the issuer nonce before encrypting with the encryption key. The gateway encryption service also signs the data with the validation key. Optionally, the gateway encryption service may further encrypt the encrypted data with the wallet certificate. The encrypted provision data is any or all of the above described data that was combined and encrypted with the encryption key and/or the wallet certificate.

At block330, the gateway encryption service may transmit the encrypted provision data to the issuer mobile application server, which can be used to finalize the push provisioning process as described in detail with respect toFIG.2.

FIG.4illustrates an embodiment of a computer system400. A computer system400as illustrated inFIG.4may be incorporated into devices such as a personal computer, server computer, mobile device (e.g., smartphone, smart watch, tablet, and the like), point of service (“POS”) terminal, and the like.FIG.4provides a schematic illustration of one embodiment of a computer system400that can perform some or all of the steps of the methods provided by various embodiments. It should be noted thatFIG.4is meant only to provide a generalized illustration of various components, any or all of which may be utilized as appropriate.FIG.4, therefore, broadly illustrates how individual system elements may be implemented in a relatively separated or relatively more integrated manner.

The computer system400is shown comprising hardware elements that can be electrically coupled via a bus405, or may otherwise be in communication, as appropriate. The hardware elements may include one or more processors410, including without limitation one or more general-purpose processors and/or one or more special-purpose processors such as digital signal processing chips, graphics acceleration processors, and/or the like; one or more input devices415, which can include without limitation a mouse, a keyboard, a camera, a remote control, and/or the like; and one or more output devices420, which can include without limitation a display device, a printer, and/or the like.

The computer system400may further include and/or be in communication with one or more non-transitory storage devices425, which can comprise, without limitation, local and/or network accessible storage, and/or can include, without limitation, a disk drive, a drive array, an optical storage device, a solid-state storage device, such as a random access memory (“RAM”), and/or a read-only memory (“ROM”), which can be programmable, flash-updateable, and/or the like. Such storage devices may be configured to implement any appropriate data stores, including without limitation, various file systems, database structures, and/or the like.

The computer system400might also include a communications subsystem430, which can include without limitation a modem, a network card (wireless or wired), an infrared communication device, a wireless communication device, and/or a chipset such as a Bluetooth® device, an 802.11 device, a Wi-Fi device, a WiMax device, cellular communication facilities, etc., and/or the like. The communications subsystem430may include one or more input and/or output communication interfaces to permit data to be exchanged with a network such as the network described below to name one example, other computer systems, television, and/or any other devices described herein. Depending on the desired functionality and/or other implementation concerns, a portable electronic device or similar device may communicate transaction and/or other information via the communications subsystem430. In other embodiments, a portable electronic device, may be incorporated into the computer system400(e.g., an electronic device), as an input device415. In many embodiments, the computer system400will further comprise a working memory435, which can include a RAM or ROM device, as described above.

The computer system400also can include software elements, shown as being currently located within the working memory435, including an operating system440, device drivers, executable libraries, and/or other code, such as one or more application programs445, which may comprise computer programs provided by various embodiments, and/or may be designed to implement methods, and/or configure systems, provided by other embodiments, as described herein. Merely by way of example, one or more procedures described with respect to the methods discussed above, such as those described in relation toFIG.6, might be implemented as code and/or instructions executable by a computer and/or a processor within a computer; in an aspect, then, such code and/or instructions can be used to configure and/or adapt a general purpose computer or other device to perform one or more operations in accordance with the described methods.

A set of these instructions and/or code might be stored on a non-transitory computer-readable storage medium, such as the storage device(s)425described above. In some cases, the storage medium might be incorporated within a computer system, such as computer system400. In other embodiments, the storage medium might be separate from a computer system (e.g., a removable medium), such as a compact disc, and/or provided in an installation package, such that the storage medium can be used to program, configure, and/or adapt a general purpose computer with the instructions/code stored thereon. These instructions might take the form of executable code, which is executable by the computer system400and/or might take the form of source and/or installable code, which, upon compilation and/or installation on the computer system400(e.g., using any of a variety of generally available compilers, installation programs, compression/decompression utilities, etc.), then takes the form of executable code.

It will be apparent to those skilled in the art that substantial variations may be made in accordance with specific requirements. For example, customized hardware might also be used, and/or particular elements might be implemented in hardware, software including portable software, such as applets, etc., or both. Further, connection to other computing devices such as network input/output devices may be employed.

As mentioned above, in one aspect, some embodiments may employ a computer system such as the computer system400to perform methods in accordance with various embodiments of the technology. According to a set of embodiments, some or all of the procedures of such methods are performed by the computer system400in response to processor410executing one or more sequences of one or more instructions, which might be incorporated into the operating system440and/or other code, such as an application program445, contained in the working memory435. Such instructions may be read into the working memory435from another computer-readable medium, such as one or more of the storage device(s)425. Merely by way of example, execution of the sequences of instructions contained in the working memory435might cause the processor(s)410to perform one or more procedures of the methods described herein. Additionally or alternatively, portions of the methods described herein may be executed through specialized hardware.

The terms “machine-readable medium” and “computer-readable medium,” as used herein, refer to any medium that participates in providing data that causes a machine to operate in a specific fashion. In an embodiment implemented using the computer system400, various computer-readable media might be involved in providing instructions/code to processor(s)410for execution and/or might be used to store and/or carry such instructions/code. In many implementations, a computer-readable medium is a physical and/or tangible storage medium. Such a medium may take the form of a non-volatile media or volatile media. Non-volatile media include, for example, optical and/or magnetic disks, such as the storage device(s)425. Volatile media include, without limitation, dynamic memory, such as the working memory435.

Common forms of physical and/or tangible computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, EPROM, a FLASH-EPROM, any other memory chip or cartridge, or any other medium from which a computer can read instructions and/or code.

Various forms of computer-readable media may be involved in carrying one or more sequences of one or more instructions to the processor(s)410for execution. Merely by way of example, the instructions may initially be carried on a magnetic disk and/or optical disc of a remote computer. A remote computer might load the instructions into its dynamic memory and send the instructions as signals over a transmission medium to be received and/or executed by the computer system400.

The communications subsystem430and/or components thereof generally will receive signals, and the bus405then might carry the signals and/or the data, instructions, etc. carried by the signals to the working memory435, from which the processor(s)410retrieves and executes the instructions. The instructions received by the working memory435may optionally be stored on a non-transitory storage device425either before or after execution by the processor(s)410.)

FIG.5illustrates an exemplary mobile device500(e.g., wallet device105) which is displaying a user interface of the issuer mobile application (e.g., issuer mobile application130). The user interface may be for a card issuer, which may be displayed in a banner505, in this case “Your Bank” is the issuer. The card nickname (“My Card”) and the PAN suffix data (“8712”) is displayed as shown at515. A balance520, credit line525, and available credit530, for example, may be shown in the user interface. A collapsible link535for recent transaction may be available. Further, a collapsible link540for adding an account to a pay wallet may be available. Once the collapsible link540is selected, the button545for push provisioning the account, which has an associated nickname of “My Card” and a PAN suffix of 8712, into Pay Wallet 1. The button545may be provided as a result of the actions described in the swim diagram200associated with arrows202,204,206,208,210,212,214,216,218,220,22, and224. If the user selects the button545to initiate the push provisioning process, the actions described in swim diagram200beginning with arrow226may ensue to successfully complete the push provisioning process and make the account with PAN suffix 8712 available for use on the mobile device500within Pay Wallet 1.

Turning toFIG.6, another example push provisioning system600is shown, in accordance with some embodiments of the present disclosure. Similar to the system100ofFIG.1, the push provisioning system600includes a client device602(e.g., the wallet device105) in communication with a token service provider604via a gateway606and an issuer application server608. The client device602may be any suitable device that a user (e.g., cardholder) may use to make a payment. For example, in some embodiments, the client device602may include a mobile cellular telephone, a tablet, a personal digital assistant, a laptop, a wearable device (e.g., smart watch, etc.), or the like. The client device602may be the computer system400as described above with respect toFIG.4. In some embodiments, the client device602may be configured to access a pay wallet application610(e.g., similar to the pay wallet140) and a merchant application612.

In some embodiments, either or both of the pay wallet application610and the merchant application612may be a mobile application (e.g., software application) that is installed, and designed to run, on the client device602. In other embodiments, either or both of the pay wallet application610and the merchant application612may be a web application (e.g., software application) that is configured to run on a web server and may be configured for access via a web browser. For example, in some embodiments, the user (e.g., cardholder) may open a web browser on the client device602and enter a web address (e.g., Uniform Resource Locator) associated with the pay wallet to access the pay wallet application610of that pay wallet. Similarly, in some embodiments, the user (e.g., cardholder) may open a web browser on the client device602and enter a web address (e.g., Uniform Resource Locator) associated with a merchant to access the merchant application612of that merchant. In some embodiments, the client device602may be configured to access a web application (whether the pay wallet application610or the merchant application612) via the client device602and also have a mobile application ((whether the pay wallet application or the merchant application) installed on the client device.

While only a single pay wallet application (e.g., the pay wallet application610) and a single merchant application (e.g., the merchant application612) is shown on the client device602, in other embodiments, the client device may have multiple pay wallet applications (e.g., one pay wallet application for each type of pay wallet) and multiple merchant applications (e.g., one merchant application for each merchant). Further, in some embodiments, the pay wallet application610may correspond to any suitable digital wallet. Example digital wallets may include, for example, Apple Pay® from Apple Inc., Google Pay™ from Google LLC, and Samsung Pay® from Samsung. In other embodiments, the pay wallet application610may correspond to other or additional digital wallets. Similarly, the merchant application612may correspond to any merchant (e.g., card-on-file merchants, click-to-pay merchants, etc.) that allows online transactions, or in other words, allows buying and/or selling products and/or services using the client device602.

The client device602may also be configured to access an issuer application614. In some embodiments, the issuer application614may be a mobile application (e.g., software application) that is installed, and designed to run on, the client device602. In other embodiments, the issuer application614may be a web application that is run on a web server and may be accessed using a web browser on the client device602. For example, in some embodiments, the user (e.g., cardholder) may open a web browser on the client device602and enter a web address (e.g., Uniform Resource Locator) associated with the issuer to access the issuer application614of that issuer. The issuer application614may be associated with an issuer of a payment source (also referred to herein as a payment instrument). For example, in some embodiments, the issuer application614may be associated with issuers such as JPMorgan Chase & Co, Wells Fargo, Bank of America Corporation, Capital One, etc. In other embodiments, the issuer application614may be associated with other or additional issuers. In some embodiments, the payment source may be any suitable payment mechanism. For example, in some embodiments, the payment source may be a debit card, a credit card, etc. Using the issuer application614, the user (e.g., cardholder) may view account details, payment details, user profile details, advertisements, rewards, etc., and any other service or information that the issuer makes available to the user via the issuer application. In some embodiments, the user may also use the issuer application614to push provision a payment source issued by the issuer of the issuer application to a merchant or pay wallet.

The issuer application614may incorporate a software development kit616. The software development kit616may include software tools and programs to provide interfaces and methods for facilitating the push provisioning operations to a pay wallet or to a merchant. In some embodiments, the software development kit616may be embedded into the issuer application614and may be configured for use both via a mobile application implementation of the issuer application or via a web application implementation of the issuer application. The software development kit616may be configured to hide the complexity of the push provisioning operation from the user. For example and as explained in greater detail below, in some embodiments, different token service providers (e.g., the token service provider604), different merchants, and/or different pay wallets may have varying communication protocols (e.g., may require different messaging formats) and/or require different types of messages (e.g., different types of API calls) for performing the same or similar functions. In some embodiments, the operations for push provisioning to a merchant may be different from the operations for push provisioning to a pay wallet, which in turn may vary based upon the type of merchant or pay wallet, as well as whether the push provisioning is occurring through a mobile application or a web application. The software development kit616may be configured to hide all of this complexity from the user. From the user's standpoint, the software development kit616provides a set of simple interfaces that guide the user through the push provisioning process.

The software development kit616may be configured to interface with the pay wallet application610and the merchant application612. For example, and as discussed below, the software development kit616may be configured to redirect the user between the issuer application614and the pay wallet application610if the user is push provisioning to a pay wallet or between the issuer application and the merchant application612if the user is push provisioning to a merchant. Although not shown, the software development kit616may include, or be associated with, computer-readable instructions that may be executed by a processor (e.g., a processor of the user device602). In some embodiments, the computer-readable instructions may be located on the user device602, while in other embodiments, the computer-readable instructions may be located remote (e.g., on a cloud) from the user device and accessible by the user device.

The token service provider604(e.g., similar to the token service provider115) may provide a token service for digital use of the payment source. For example, when sending digital payment information, the full account information, such as the sixteen digit account or card number may not be sent to protect the account information. Rather, the token service provider604may generate a token and associate that token with the payment source. The token service provider604may receive and validate the push provision request by issuing a token for a payment source to a pay wallet or to a merchant. The token service provider604may be any of a variety of token service providers. For example, in some embodiments, the token service provider604may be a MasterCard Digital Enablement Service (“MDES”) token service provider. In other embodiments, the token service provider604may be a Visa Token Service (“VTS”) token service provider. In yet other embodiments, the token service provider604may be a First Data Universal Token Service token service provider. In other embodiments, the token service provider604may be any other type of a token service provider.

The token service provider604may be configured for communication with a merchant server618, a pay wallet server620, and an issuing host platform622. The token service provider604may receive a push provisioning request from the merchant server618or the pay wallet server620. In response, the token service provider604may determine that the push provisioning request is a valid request and generate a token (e.g., a payment token) for a payment source selected by the user (e.g., cardholder). The token service provider604may return the generated token to the merchant server618or the pay wallet server620that made the push provisioning request. In some embodiments, the token service provider604may also provide a notification of approval (and/or the generated token) to the issuing host platform622. Although not shown, the token service provider604may include, or be associated with computer-readable instructions that may be executed by a processor.

The merchant server618(also referred to as a commerce server) may be associated with the merchant application612. The merchant server618may be configured to handle transactions occurring via the merchant application612. For example, in some embodiments, the merchant server618may be configured to establish a secure channel of communication between the user and the issuer of the payment source that the user is using to make a payment for a transaction (e.g., purchase) using the merchant application612. Thus, the merchant server618may be configured to implement an electronic commerce protocol. In some embodiments, the merchant server618may be located remote from the merchant application612. The merchant server618may include, or be associated with, computer-readable instructions that may be executed by a processor associated with the merchant server. The merchant server618may receive a push provisioning request to push provision a payment source to the merchant associated with the merchant server, and correspond with the token service provider604and/or the gateway606to receive a token for the payment source.

The pay wallet server620(similar to the pay wallet server125) may be associated with the pay wallet application610. The pay wallet server620may be configured to handle transactions occurring via the pay wallet application610. For example, in some embodiments, the pay wallet server620may be configured to establish a secure channel of communication between the user and the issuer of the payment source that the user is using to a make payment for a transaction (e.g., purchase) using the pay wallet application610. Thus, the pay wallet server620may be configured to implement an electronic commerce protocol. In some embodiments, the pay wallet server620may be located remote from the pay wallet application610. The pay wallet server620may include, or be associated with, computer-readable instructions that may be executed by a processor associated with the pay wallet server. The pay wallet server620may receive a push provisioning request to push provision a payment source to the pay wallet associated with the pay wallet server, and correspond with the token service provider604and/or the gateway606to receive a token for the payment source.

The issuing host platform622may be associated with the issuer providing the issuer application614. The issuing host platform622(similar to the issuing host platform155) may be configured to store and/or manage user account information. Although the issuing host platform622is shown separate from the issuer application server608, in some embodiments, the issuing host platform and the issuer application server may be combined together into a single system (e.g., the domain servers120). The issuer application server608may be provided by the issuer associated with the issuer application614. The issuer application server608may be configured to establish communication between the issuer application614and the gateway606or between the issuer application and the issuing host platform622. The issuer application server608may include, or be associated with, computer-readable instructions that may be executed by a processor associated with the issuer application server.

The gateway606may be similar to the gateway110. The gateway606may be configured to communicate with the software development kit616and the issuer application614via the issuer application server608. For example, the gateway614may receive a request for information from the issuer application614via the issuer application server608. The gateway606may need to communicate with the token service provider604to fulfill the request for information. In some embodiments, and as discussed above, different token service providers may employ different communication protocols. The gateway606may be configured to determine the type (e.g., MDES, VTS, etc.) of the token service provider604, determine the communication protocol associated with the type of the token service provider, and format messages to the token service provider in accordance with the determined format. The gateway606is also configured to hide the complexity of the push provisioning operation from the user. Further, by virtue of the gateway606, additional types of token service providers may be added without needing to alter the operations or functionality of the issuer application614, the pay wallet application610, the merchant application612, the software development kit616, or the issuer application server608.

In some embodiments, the gateway606may include, or be associated with computer-readable instructions that may be executed by a processor associated with the gateway. In some embodiments, the software development kit616and the gateway606may be implemented by the same processor (even though the software development kit and the gateway may be located remote from one another). In other embodiments, the software development kit616and the gateway606may be implemented by separate processors.

Notwithstanding the elements shown inFIG.6, it is to be understood that the push provisioning system600may include other or additional elements. Generally speaking, the push provisioning system600may include any element or component that may be considered desirable to have or may be needed in performing the functions described herein. Thus, the push provisioning system600enables a user (e.g., cardholder) to provide a tokenized payment card number to merchants and pay wallets for easy and secure transactions (e.g., purchases). The push provisioning system600allows a digital first experience to the user by permitting new account usage without needing to wait for a physical card activation. The push provisioning system600allows the user to complete transactions using any device (e.g., any web-enabled device) and provides a frictionless enablement of the payment source as the payment option in the merchant checkout flow. The push provisioning system600is configured to work with a variety of token requesting merchants and pay wallets through a variety of token service providers. The push provisioning system600provides a simple, normalized integration through the software development kit616and the gateway606, as well as provides a one time provisioning of the payment source regardless of changes in the account status, account numbers, etc.

The push provisioning system600also provides technical improvements. Specifically, the push provisioning system600provides technical improvements in the area of computer networks. The push provisioning system600also improves the operations of the client device602. For example, the push provisioning system600enables the user to push provision to both pay wallets and merchants using the same issuer application (e.g., the issuer application614) via the software development kit616. The push provisioning system600also allows the user to push provision to both the pay wallets and merchants using either mobile application or web application, thereby avoiding the need for the user to download specialized software and consuming additional memory and storage space on the client device. Thus, the push provisioning system600improves the storage capabilities of the client device602. The push provisioning system600also allows the client device602to hide the complexity of the push provisioning process by providing simple interfaces regardless of which token service provider is used, which merchant or pay wallet is being provisioned to, and what communication protocols they follow. The push provisioning system600simplifies communications over the network by using simple Application Program Interface (“API”) messages and calls, and automatically formatting the messages in accordance with the preferred communication protocol of the recipient (e.g., the token service provider). The problems being addressed by the push provisioning system600are specific to transactions occurring over the web using the client device602.

Turning toFIG.7, an example swimlane diagram outlining operations of a process700is shown, in accordance with some embodiments of the present disclosure. The process700may be used for push provisioning a payment source to a merchant using the issuer application614. Specifically, the process700may be used to push provision the payment source to the merchant such that the merchant may obtain a token from a token service provider, and particularly, an MDES token service provider. To push provision a payment source to a merchant, a user (e.g., cardholder702) logs into an issuer application704at operation706. The issuer application704is analogous to the issuer application614and may be a mobile application or a web application. The issuer application704may be accessed on a client device (e.g., the client device602) of the cardholder702. In some embodiments, the cardholder702may log into the issuer application704by entering authentication information such as a username, password, account number, biometrics, and/or in any other suitable way. The issuer application704sends the authentication information (e.g., via a network) to an issuer application server708at operation710.

The issuer application server708, which may be considered analogous to the issuer application server608, may authenticate the cardholder by verifying the authentication information. In some embodiments, the issuer application server708may obtain data from an issuing host platform712to authenticate the cardholder702. The issuing host platform712is analogous to the issuing host platform622. Upon authenticating the cardholder702, the issuer application server708requests, from the issuing host platform712, a list of payment sources (e.g., list of cards, list of accounts, etc.) issued by the issuer to the cardholder at operation714. In some embodiments, the payment sources may include credit cards. In other embodiments, the payment sources may include debit cards or any other form of payment mechanism that the cardholder may use to make payments. In some embodiments, the issuer application server708may also send the authentication information and/or other cardholder details to the issuing host platform712to enable the issuing host platform to retrieve the list of payment sources. The issuing host platform712may retrieve the list of payment sources and send the list back to the issuer application server708at operation716. The issuer application server708sends the list of payment sources to the issuer application704at operation718, for display (e.g., on the client device) to the cardholder702in the issuer application.

To push provision a payment source to a merchant, the cardholder702selects a payment source from the list of payment sources displayed within the issuer application704at operation720. The issuer application704receives the cardholder's selection of the payment source (referred to herein as the “selected payment source”) at the operation720. The issuer application704sends a request to the issuer application server708for a list of merchants at operation722. The list of merchants may include those merchants that are eligible for receiving the selected payment source via push provisioning. Upon receiving the request from the issuer application704, the issuer application server708transmits the request to a gateway724at operation726. The gateway724may be considered analogous to the gateway606and may be configured to communicate with a token service provider728. The token service provider728may be considered analogous to the token service provider604.

In some embodiments, the gateway724may be configured to communicate with a variety of different token service providers, as discussed above. Different token service providers may adopt different communication protocols. For example, the MDES token service provider may adopt a different communication protocol than the VTS token service provider, which in turn may adopt a yet another communication protocol compared to another token service provider. A communication protocol may dictate a type and/or format of messages or calls (the terms “message” and “call” are used interchangeably herein) that a particular token service provider may communicate in. The communication protocol may include other communication details or operations that are specific to a particular token service provider and that the gateway724needs to follow to communicate with (e.g., request information from, send information to, etc.) the particular token service provider. For example, in some embodiments, to provide the list of merchants, an MDES token service provider (e.g., the token service provider728) may require a specific type of message (e.g., a specific type of API call) from the gateway724while a VTS token service provider may require a different type of message (e.g., a different API call) for providing the same list of merchants.)

Thus, before establishing communication with a token service provider, the gateway724may first determine the type of the token service provider (e.g., MDES, VTS, etc.). In some embodiments, the gateway724may determine the type of the token service provider based upon the issuer. In some embodiments, the gateway724may determine the issuer from the information included in the request of the operation722. For example, in some embodiments, the request may include at least some information of the selected payment source that may enable the gateway724to identify the issuer. In other embodiments, the gateway724may identify the issuer in other ways. Further, in some embodiments, the gateway724may maintain an issuer registration table for each issuer that the gateway is configured to interact with. The issuer registration table may indicate the type of the token service provider that the issuer is associated with. In some embodiments, the issuer registration table may also indicate the communication protocol associated with that type of the token service provider. In other embodiments, the gateway724may maintain another look up table to determine the communication protocol of the type of the token service provider identified from the issuer registration table. In some embodiments, the gateway724may, additionally or alternatively, use the cardholder's account information (e.g., PAN), issuer registration data, and/or other information to identify the type of the token service provider and/or the communication protocol associated with the identified type of the token service provider.

Therefore, the gateway724is configured to communicate with a variety of token service providers. To add a new token service provider, only the functionality of the gateway724needs to be modified to establish communication with the new token service provider. There is no need to modify the issuer application704, the issuer application server708, or the issuing host platform712. There is also no need to modify the new token service provider in any way. Thus, a single gateway (e.g., the gateway724) is configured to communicate with a variety token service providers, while hiding the complexity of communications occurring between the gateway and the token service provider728from the issuer application704, the issuer application server708, the issuing host platform712, and the token service provider728.

Upon determining the type of the token service provider (e.g., MDES inFIG.7) and the communication protocol associated with the MDES token service provider, the gateway724sends a request for the list of merchants to the token service provider728. In some embodiments, the gateway724may make an API call to the token service provider728to request the list of merchants. For example, in some embodiments, the gateway724may make a “getEligibleTokenRequestors” API call to the token service provider728to request the list of merchants. In other embodiments, the gateway724may make another type of API call to request the list of merchants. In some embodiments, the gateway724may use messaging protocols other than or in addition to API calls to communicate with the token service provider728, as well as to request the list of merchants. By making the “getEligibleTokenRequestors” API call, the gateway724requests the list of merchants that are eligible for receiving the selected payment source via push provisioning. Upon receiving the “getEligibleTokenRequestors” API call from the gateway724, the token service provider728provides the gateway with the list of merchants at operation732.

The gateway724, in some embodiments, may send a follow-up request to identify those merchants from the list of merchants to which the selected payment source has already been provisioned. In other words, the gateway724may identify those merchants that already have a token (e.g., a payment token) from the token service provider728for the selected payment source. In some embodiments, the gateway724may send a “search” API call, at operation734, to the token service provider728to request the merchants that already have a token. In other embodiments, the gateway724may use other API calls or other messaging protocols to make the request. In some embodiments, the gateway724may combine the “getEligibleTokenRequestors” and the “search” API calls into a single API call.

At operation736, the token service provider728sends the list of merchants back to the gateway724that already have a token for the selected payment source from the token service provider. The gateway724thus receives a first list of merchants (e.g., via the “getEligibleTokenRequestors” API call) at the operation732including all merchants that are eligible for push provisioning the selected payment source and a second list of merchants (e.g., via the “search” API call) at the operation736including those merchants that already have a token for the selected payment source. The gateway724may then combine the first list of merchants and the second list of merchants to generate a third list of merchants. For example, in some embodiments, the gateway724may create the third list of merchants that includes all of those merchants that are included in the first list of merchants. Further, for the merchants that are included in the second list of merchants, the gateway724may include a notification or indication in the third list of merchants indicating that the selected payment source has already been provisioned for those merchants. For example, if the first list of merchants includes merchants A, B, and C, and the second list of merchants includes merchant B, the third list of merchants may include merchants A, B, and C, with an indication against merchant B indicating that merchant B already has a token. This way, the cardholder702may easily identify which merchants currently do not have a token for the selected payment source.

The gateway724sends the third list of merchants to the issuer application server708at operation738. In some embodiments, the gateway724may also send the first list of merchants and/or the second list of merchants to the issuer application server708. In some embodiments, the gateway724and/or the token service provider728may associate an asset identifier with each merchant in the third list of merchants. In some embodiments, the “asset identifier” may be a unique identifier associated with a particular merchant to identify that merchant. In some embodiments, if the token service provider728returns a merchant that does not have an asset identifier associated therewith, the gateway724and/or the token service provider728may assign a new asset identifier to the new merchant. In other embodiments, the gateway724may include other or additional types of information for one or more merchants in the third list of merchants. For each merchant in the third list of merchants, the issuer application server708may determine a logo, button image, or other identifying indicia (e.g., web address, etc.) and update the third list of merchants to include the logo, button image, or the other identifying indicia. In some embodiments, the issuer application server708may determine that the third list of merchants includes a new merchant that the issuer application server has not seen before (and thus does not have a logo, button image, or other identifying indicia cached therefor). For example, in some embodiments, the issuer application server708may identify a new asset identifier in the third list of merchants.

The issuer application server708may send a request back to the gateway724at operation740to obtain the logo, button image, or other identifying indicia for the merchant(s) associated with the new asset identifier. In some embodiments, the issuer application server708may make a “Get Asset” API call to the gateway724to request the logo, button image, or other identifying indicia of the merchant associated with the new asset identifier(s). In some embodiments, the gateway724transmits the request to the token service provider728at operation742. In some embodiments, if the gateway724has the logo, button image, or other identifying indicia information available, the gateway724may send that information to the issuer application server708without asking the token service provider728. Upon getting the request from the gateway724, the token service provider728sends the logo, button image, or other identifying indicia information for the merchant(s) associated with new asset identifier(s) to the gateway724at operation744, which then forwards that information to the issuer application server708at operation746. Thus, the issuer application server708communicates with the token service provider728through the gateway724.

Upon receiving the logo, button image, or other identifying indicia information from the gateway724, the issuer application server708may add that information to the third list of merchants. The issuer application server708then sends the third list of merchants with the logo, button image, or other identifying indicia added, to the issuer application704at operation748, for display to the cardholder702(e.g., via the cardholder's client device). Additionally, the issuer application704sends initializing inputs, at operation752, to a software development kit750for initiating the push provisioning operation of the selected payment source. The software development kit750may be considered analogous to the software development kit616. In some embodiments, the initializing inputs may include cardholder data associated with the cardholder702such as the first name, last name, any nickname that the cardholder may have set in the issuer application704, the language (e.g., English, French, etc.) associated with the cardholder, country where the cardholder resides, billing address, and any other information that may be considered useful or desirable to have. The software development kit750acknowledges the receipt of initializing inputs by sending a reply to the issuer application704at operation754. In some embodiments, the reply754may be a “success” output indicating that the software development kit750has received the initializing inputs successfully or a “failure” output indicating that the software development kit has not received some or all of the initializing inputs successfully. If the software development kit750sends a “failure” reply, the issuer mobile application704may send the initializing inputs again to the software development kit. In some embodiments, the software development kit750may perform setback checking, syntax checking, and/or other types of authentication to ensure the validity of the initializing inputs.

The issuer application704also receives a selection of a merchant (referred to herein as a selected merchant) from the cardholder702from the third list of merchants presented to the cardholder at operation756. Although the operation756is shown as occurring after the operations752and754, in some embodiments, the operations756may occur before or along with the operations752/754. In some embodiments, the issuer application704may also receive, along with the selected merchant, the asset identifier associated with the selected merchant and/or any other information associated with the selected merchant at the operation756. In some embodiments, the merchants that have the selected payment source already provisioned may be disabled in the third list of merchants displayed to the cardholder702to prevent the cardholder from selecting those merchants. In other embodiments, those merchants may not be disabled, but the issuer mobile application704may display a notification indicating that the selected payment source is already provisioned with those merchants if the cardholder selects one of those merchants.

Upon receiving the selected merchant, the issuer application704passes the selected merchant, the asset identifier, and any other information associated with the selected merchant to the software development kit750at operation758. The software development kit750may prepare a data package, referred to herein as pass-through data, to send to the issuer application704. The pass-through data may also include the cardholder information received at the operation752as part of the initializing inputs, the device information (e.g., mobile number) of the mobile device of the cardholder702on which the issuer application704is accessed, the selected payment source, the selected merchant (and the associated asset identifier), any other merchant information (e.g., link to merchant's application—whether mobile or web), the PAN associated with the selected payment source, the expiration month and/or year of the selected payment source, the as well as any other information that may be needed or considered desirable in push provisioning the payment source to the selected merchant.

The software development kit750transmits the pass-through data to the issuer application704at operation760. The issuer mobile application704transmits that pass-through data to the issuer application server708at operation762. The issuer application server708makes a push provisioning request at operation764with the gateway724. The push provisioning request may include the pass-through data. The gateway724forwards the push provisioning request, including the pass-through data, to the token service provider728at operation766via a “pushAccount” API call. In some embodiments, the gateway724may compile (e.g., sort, filter, arrange, etc.) the pass-through data to obtain push-account data. The push-account data may include data that the token service provider728needs to push provision the selected payment source with the selected merchant (e.g., to create a token for the merchant). The push-account data and the “pushAccount” API call may be in a format that the token service provider728understands. Upon receiving the “pushAccount” API call, the token service provider728may generate a receipt identifier. The receipt identifier may assume any configuration and size. In some embodiments, the receipt identifier may include numbers, letters, special characters, or a combination thereof. The receipt identifier may serve as an acknowledgment that the token service provider728has received the “pushAccount” API call (and the associated push-account data).

The receipt identifier is sent from the token service provider728to the gateway724at operation768, from the gateway to the issuer server application708at operation770, and from the issuer application server to the issuer application704at operation772. The issuer application704forwards the receipt identifier to the software development kit750at operation774. The software development kit750sends the receipt identifier to a merchant server776at operation778. The merchant server776may be considered analogous to the merchant server618. To send the receipt identifier to the merchant server776, in some embodiments, the software development kit750may redirect the cardholder702from the issuer application704to a merchant application (whether mobile application or web application) on the client device of the cardholder through which the process700is being performed. The merchant application may be considered analogous to the merchant application612. The merchant application may be associated with the merchant server776. In some embodiments, to redirect the cardholder702to the merchant application (and therefore to the merchant server776), the software development kit750may use a uniform resource identifier (URI) such as a Uniform Resource Locator, etc. In some embodiments, the software development kit750may also include a call back URI along with the receipt identifier at the operation778. The call back URI may be a URI (e.g., the Uniform Resource Locator) associated with the issuer application704to allow the merchant server776to send a response back to the issuer application (e.g., redirect back to the issuer application from the merchant application).

Thus, at the operation778, the merchant server776receives the receipt identifier and the call back URI from the software development kit750. In other embodiments, the software development kit750may send other or additional information to the merchant server776. The merchant server776does not receive the cardholder data (e.g., the initializing inputs), the pass-through data, the push-account data, etc., thereby maintaining the security and integrity of that data. In some embodiments, the cardholder702may be required to sign in or log into the cardholder account on the merchant application to which the redirecting has occurred. In some embodiments, the cardholder702may be required to download the merchant application if the mobile device does not already have the merchant application installed thereon or the redirecting may occur to the web application of the selected merchant.

The merchant server776then sends the receipt identifier to the token service provider728along with a tokenize provision request at operation780. By way of the tokenize provision request, the merchant server776requests a token from the token service provider728for the selected payment source associated with the receipt identifier. The token service provider728receives the receipt identifier from the merchant server776and compares the receipt identifier with the receipt identifier generated at the operations766and768for verification. If there is a match, the token service provider728generates a token for the selected payment source. The token service provider712also notifies the issuing host platform712of the generation of the token at operation782. In some embodiments, the token service provider728may also include the token to the issuing host platform712. The issuing host platform712may make a record of the token and associate the token with the selected payment source and the selected merchant. At operation784, the issuing host platform712sends an acknowledgment to the token service provider728. Upon receiving the acknowledgment, the token service provider728sends the token to the merchant server776at operation786, which then redirects back to the issuer application704at operation788. The merchant server776may also store the received token and make the token available to the cardholder702in the merchant application for making payments for transactions using the merchant application.

The redirection of the operation788may be to the call back URI that was included along with the receipt identifier at the operation778. The redirection may include a reply message indicating a success or failure of the push provisioning process. In some embodiments, the merchant server776may send a success message if the merchant server776receives the token from the token service provider728successfully. In some embodiments, the merchant server776may send a failure message if the merchant server776does not receive the token from the token service provider728for some reason. In some embodiments, the merchant server776may send other or additional messages to the issuer application704. The issuer application704transmits the reply message to the software development kit750at operation790for interpretation. The software development kit750may interpret the reply message from the merchant server776to determine whether the merchant server776successfully received the token or not. For example, the software development kit750may associate a “success” message from the merchant server776as meaning that the merchant server has successfully received the token. In such cases, the software development kit750sends a “success” message to the issuer application704at operation792, which then displays the message on the cardholder's client device at operation794. On the other hand, if at the operation790, the software development kit750receives a “failure” reply message from the issuer application704, the software development kit may associate that message as meaning that the merchant server has not successfully received the token from the token service provider728. In such a case, the software development kit750sends a “failure” message to the issuer mobile application704at the operation792, which then displays the message on the cardholder's mobile device at the operation794.

Thus, the process700provides an easy, reliable, and convenient mechanism to a cardholder to receive a token for a selected merchant via a mobile or web issuer application for an MDES token service provider.

Turning now toFIG.8, an example swimlane diagram outlining operations of a process800is shown, in accordance with some embodiments of the present disclosure. The process800may be used for push provisioning a payment source to a merchant. Specifically, the process800may be used to push provision the payment source to the merchant such that the merchant may obtain a token from a token service provider, and particularly, a VTS token service provider. To push provision a payment source to a merchant, a user (e.g., cardholder802) logs into an issuer application804at operation806. The issuer application804may be considered analogous to the issuer application614and may be either a mobile application or a web application. The issuer application804sends the authentication information to an issuer application server808at operation810. The issuer application server808may be considered analogous to the issuer application server608. The operations806and810are equivalent to the operations706and710, and therefore, are not described again. The issuer application server808requests a list of payment sources associated with the issuer from an issuing host platform812at operation814. The issuing host platform812may be considered analogous to the issuing host platform622. The issuing host platform provides the list of payment sources, which are sent to the issuer application804via the issuer application server808at operations816and818for display on a client device associated with the cardholder802. The operations814-818are similar to the operations714-718, respectively.

At operation820, the cardholder802selects a payment source (e.g., selected payment source) from the list of payment sources similar to the operation720and the selection is sent to the issuer application804. The issuer application804then makes a request, at operation822, for a list of merchants from the issuer application server808. The issuer application server808sends the request to a gateway824at operation826. The operations820,822, and826are equivalent to the operations720,722, and726, respectively. The gateway824may be considered analogous to the gateway606. The gateway824sends a request to a token service provider828for the list of merchants at operation830. In some embodiments, the token service provider828may be a VTS token service provider. The token service provider828may be considered analogous to the token service provider604.

As discussed above, the gateway824adopts the communication protocol for communication with the token service provider828based upon the type of the token service provider. Thus, to request the list of merchants (e.g., the first list of merchants, as discussed above) from a VTS token service provider (e.g., the token service provider828), the gateway824may format messages in a form accepted by the VTS token service provider. For example, the gateway824may send a “retrieveNHPProfiles” API call to the token service provider828to request the list of merchants at the operation830. The token service provider828provides the list of merchants to the gateway824at operation832. In some embodiments, the token service provider828may include logo, button image, or other identifying information with the list of merchants. The gateway824then requests the list of merchants that already have a token issued for the selected payment source from the token service provider828at operation834(e.g., the second list of merchants, as discussed above). For example, the gateway824may send a “retreieveTokenInfo” API call to the token service provider828at the operation834. At operation836, the token service provider828transmits the second list of merchants to the gateway824, which creates the third list of merchants and sends the third list of merchants to the issuer application server808at operation838.

The issuer application server808associates each merchant on the third list of merchants with the logo, button image, or other identifying information and sends a request to the gateway at operation840for logo or identifier information for any new asset identifier identified in the third list of merchants, as discussed above at the operation740. The gateway824may maintain a cache of logo, button image, or other identifying information of each merchant that the gateway receives from the token service provider828at the operation832. In some embodiments, the gateway824may receive the logo, button image, or other identifying information directly from the respective merchant and store that information within the cache. In some embodiments, upon receiving the request from the issuer application server808at the operation840, the gateway824provides the requested logo, button image, or other identifying information at operation842to the issuer application server. In some embodiments, the gateway824may provide the logo, button image, or other identifying information to the issuer application server808at the operation838when providing the third list of merchants.

The issuer application server808transmits the third list of merchants having the logo, button image, or other identifying information therein to the issuer application804at operation844, similar to the operation748. The issuer application804displays the third list of merchants on the client device of the cardholder802. The issuer application804also sends the initializing inputs to a software development kit846at operation848. The software development kit846is analogous to the software development kit616. The software development kit846acknowledges the receipt of the initializing inputs at operation850. The operations848and850are equivalent to the operations752and754, respectively. The issuer application804also receives the selected merchant from the cardholder802at operation852, similar to the operation756. The issuer application804then passes the selected merchant to the software development kit846at operation854similar to the operation758. The software development kit846prepares the pass-through data and sends that pass-through data to the issuer application808at operation856similar to the operation760. The issuer application808sends the pass-through data to the issuer application server808at operation858and the issuer application server makes a push provision request at operation860to the gateway824. The operations858and860are similar to the operations762and764, respectively.

The gateway824receives the pass-through data and prepares an encrypted payload by encrypting the pass-through data. The gateway824encrypts the pass-through data as discussed above. The gateway824sends the encrypted payload back to the issuer application server808at operation862, which then sends the encrypted payload to the issuer application804at operation864. Thus, instead of sending the receipt identifier as inFIG.7with the MDES token service provider, the gateway824sends the encrypted payload to the issuer application804. The issuer application804then passes the encrypted payload to the software development kit846at operation866. Since the issuer application804is simply transferring the encrypted payload (as inFIG.8) or the receipt identifier (as inFIG.7) to the software development kit846, the complexity of different communication protocols associated with different token service providers may be hidden from the issuer application. Further, any time a new token service provider is associated with the issuer, the issuer application804does not need to be updated. At operation868, the software development kit846redirects the cardholder802from the issuer application804to a merchant server870. The merchant server870may be considered analogous to the merchant server618. The software development kit846may also send the encrypted payload to the merchant server870as part of the redirection.

The merchant server870transfers the encrypted payload to the token service provider828at operation872and request validation of the encrypted payload. The token service provider828may decrypt the encrypted payload, as discussed above, using a key to verify the authenticity of the encrypted payload. If the token service provider828is able to decrypt the encrypted payload, the token service provider828confirms validation of the encrypted payload at operation874. Upon receiving the confirmation, the merchant server870makes a “provisionedToken” API call to the token service provider828to request a token for the selected payment source included in the encrypted payload at operation876. The token service provider828generates a token for the selected payment source and sends the token to the merchant server870and the issuing host platform812at operations878,880,882similar to the operations782,784, and786, respectively. The merchant server870then redirects back to the issuer application804at the callback URI and sends a reply message to the issuer application at operation884. The reply message may be similar to the message described above at the operation788. The issuer application804sends the reply message to the software development kit846at operation886, which then interprets the reply message and sends the interpretation result back to the issuer application804at operation888for display to the cardholder on the client device at operation890. The operations886-890are similar to the operations790-794, respectively.

Referring now toFIGS.9A-9E, example interfaces of push provisioning a payment source to a merchant is shown, in accordance with some embodiments of the present disclosure. It is to be understood that the shape, size, configuration, orientation, information, etc. of the various features shown inFIGS.9A-9Eare only examples and not intended to be limiting in any way. Similarly, the names, logos, and other information of merchants shown in the list of merchants inFIGS.9A-9Eare only an illustrative example and not intended to be limiting (e.g., not intended to be the actual or only list of merchants who can receive a payment source via push provisioning). The number of merchants shown in the list are also only an example. Referring toFIG.9A, to push provision a payment source900to a merchant, the cardholder associated with the payment source may log into an issuer application902associated with the payment source. For example, if the payment source900is issued by First Bank, the cardholder may log into the First Bank application on a client device904. The issuer application902may be analogous to the issuer application614and the client device904may be analogous to the client device602. The issuer application902may be either a mobile application or a web application. User interface906of the client device904shown inFIG.9Amay correspond to the operation720or820. To push provision the payment source900to a merchant, the cardholder may select an “add to merchants” option908. The user may also select to push provision the payment source900to a pay wallet, as discussed above and further discussed below, by selecting an “add to pay wallet” option910.

Upon selecting the “add to merchants” option908, a user interface912ofFIG.9Bmay be presented in the issuer application902. The user interface912may present a list of merchants914, as obtained in the operations722-748or the operations822-844. The cardholder may select a merchant916for push provisioning the payment source900to. Upon selecting the merchant916, a user interface918ofFIG.9Con the client device904may be presented. The user interface918may correspond to the redirecting to the merchant server776in the operation778or to the merchant server870in the operation868. Thus, the user interface918opens a merchant application920associated with the merchant916that the cardholder selected inFIG.9B. In some embodiments, the merchant application920may require the cardholder to log in. In other embodiments, the merchant application920may automatically log the cardholder into the merchant application.

The merchant application920may display the payment source900that the cardholder is attempting to push provision to the merchant916. The cardholder may confirm the push provisioning operation by clicking on an add button922. When the cardholder clicks the add button922, the operations780-786or the operations872-882may be performed in the background. Upon clicking the add button922, the cardholder may be directed to a user interface924ofFIG.9D. The user interface924may indicate whether the push provisioning operation is successful. For example, the user interface924may indicate a message926in the merchant application920. The cardholder may confirm completion of the push provisioning operation by clicking on a done button928. Upon clicking on the done button928, the operations788-794or the operations884-890may be performed. Specifically, the cardholder may be redirected back to the issuer application902, as shown in user interface930ofFIG.9E.

The user interface930may show the list of merchants914, including the merchant916that the user just push provisioned the payment source900too. The merchant916may be associated with a notification932indicating that the payment source900has been push provisioned to the merchant916. Thus, the cardholder may easily and conveniently push provision a payment source to a merchant without needing to wait for a physical copy of the payment source while hiding all the background complexity associated with varying communication protocols of various token service providers by virtue of using the software development kit750/the gateway724and the software development kit846/the gateway824.

Referring toFIG.10, an example swimlane diagram outlining operations of a process1000is shown, in accordance with some embodiments of the present disclosure. The process1000may be used for push provisioning a payment source to a pay wallet, and particularly to an Apple Pay® wallet, using a web application of the issuer application614. The process1000starts with a cardholder1002selecting a payment source at operations1004-1014similar to the operations706-720, respectively. Upon receiving the selected payment source at the operation1014, an issuer web application1016requests a list of pay wallets, at operation1018, from an issuer application server1020. The issuer web application1016may be considered analogous to the issuer application614and the issuer application server1020may be considered analogous to the issuer application server608. The issuer application server1020forwards the request to a gateway1022at operation1024similar to the operation726. The gateway1022may be considered analogous to the gateway606.

In some embodiments, the gateway1022may prepare the list of pay wallets. In some embodiments, since there are a limited number of pay wallets, the gateway1022may maintain all the data needed to prepare the list of pay wallets without needing to request that data from a token service provider. In other embodiments, the gateway1022may request the list of pay wallets from a token service provider1026similar to the operations730-736for an MDES token service provider or the operations830-836for a VTS token service provider. The token service provider1026may be considered analogous to the token service provider604. The gateway1022returns the list of pay wallets to the issuer application server1020at operation1028. In response, the gateway1022receives a request from the issuer application server1020at operation1030for the logo, button image, or other identifying information for each pay wallet that the issuer application server1020does not have the logo, button image, or other identifying information for. The operation1030is similar to the operation840. In some embodiments, the gateway1022may maintain the logo, button image, or other identifying information for each pay wallet. In such cases, the gateway may retrieve the logo, button image, or other identifying information and send it back to the issuer application server1020at operation1032similar to the operation842. In other embodiments, the gateway1022may request the logo, button image, or other identifying information from the token service provider1026similar to the operations734and736.

In some embodiments, the gateway1022may also indicate which pay wallets already have tokens for the selected payment source. The issuer application server1020may generate a list of pay wallets (e.g., similar to the third list of merchants but with pay wallets instead of merchants) and send that list to the issuer web application1016at operation1034. The issuer web application1016, upon receiving the list of pay wallets, sends initializing inputs to a software development kit1036at operation1038. The software development kit1036may be considered analogous to the software development kit616. The operation1038is similar to the operation752. The initializing inputs may include any inputs that may be needed to provision the selected payment source to Apple Pay® wallet. The initializing inputs may be provided (e.g., via an “initiAddToAppleWallet” call) to the browser of the issuer web application1016to facilitate pushing the initializing inputs to a software development kit associated with a wallet server1040associated with Apple Pay® wallet at operation1042. Thus, in some embodiments, the initializing inputs may sit in a holding state in the browser of the issuer web application1016before sending to the wallet server1040. At operations1044and1046, the issuer web application1016receives a response, via the software development kit1036, from the browser of issuer web application that the initializing inputs have been received.

At operation1048, the cardholder1002selects a pay wallet, and particularly Apple Pay® wallet, for provisioning the selected payment source to. The selected pay wallet (e.g., Apple Pay® wallet) is sent to the issuer web application1016at the operation1048along with an asset identifier associated with the selected pay wallet. The issuer web application1016sends the selected pay wallet and the associated asset identifier to the software development kit1036at operation1050. At operation1052, the software development kit1036receives a Java web token (or another type of identifier) from the wallet server1040. The Java web token may be associated with a current push provisioning session. Although the operations1038,1042, and1048-1052have been described as occurring in a specific order, in other embodiments, those operations may occur in a different order.

The software development kit1036passes the Java web token to the issuer web application1016at operation1054, which then transmits the Java web token along with pass-through data (as discussed above) to the issuer application server1020at operation1056to make a push provisioning request. The issuer application server1020forwards the push provisioning request along with the Java web token and the pass-through data to the gateway1022at operation1058. The gateway1022may temporarily store all the pass-through data, including the Java web token temporarily and acknowledge receipt at operations1060and1062. The issuer web application1016then calls the software development kit1036at operation1064similar to the operation774. The software development kit1036, at operation1066, redirects the cardholder1002to the web application associated with the wallet server1040(e.g., the Apple pay web page). The redirection may be similar to the operation778but to the wallet server1040instead of the merchant server776. The wallet server1040may be similar to the pay wallet server620. Upon being redirected to the pay wallet application associated with the wallet server1040, the cardholder1002logs into the cardholder's pay wallet account at operation1068using, for example, their Apple identifier. Upon logging into the wallet server account, in some embodiments, the cardholder1002may be presented a list of Apple devices (e.g., mobile devices (e.g., iPhone), iPad, Apple TV, etc.) on which the selected payment source may be provisioned to. In some embodiments, only those Apple devices may be presented that are suitable for receiving the selected payment source.

Upon selecting an Apple device for provisioning the selected payment source to, at operation1070, the wallet server1040sends the Java web token to the gateway1022to request a target identifier. The gateway1022receives the Java web token, matches the Java web token with the Java web token receives at the operation1058, and issues a receipt identifier upon finding a match. If there is no match, the gateway1022may issue an error message. The gateway1022sends the receipt identifier back to the wallet server1040at operation1072. Upon receiving the receipt identifier, in some embodiments, the wallet server1040may send a status message to the gateway1022at operation1074to ensure that the current push provisioning session is still active. Upon receiving a response from the gateway1022at operation1076indicating that the current push provisioning session is still active, the wallet server1040requests the pass-through data from the gateway at operation1078. In some embodiments, the wallet server1040may also send the receipt identifier to the gateway1022.

The gateway1022may retrieve the pass-through data that was stored at the operation1058and sends that data to the wallet server1040at operation1080. The wallet server1040sends the pass-through data to the token service provider1026at operation1082to request a token (e.g., a payment token) for the selected payment source. The token service provider1026generates a token and sends the token to the wallet server at operations1084,1086, and1088via an issuing host platform1090. The issuing host platform1090may be considered analogous to the issuing host platform622. The operations1084-1088are similar to the operations782-786. Upon receiving the token, the wallet server1040redirects back to the issuer web application1016and sends a reply message (e.g., success, failure, etc.) to the software development kit1036at operation1092, which then interprets the message and sends a result back to the issuer web application1016at operation1094for display to the cardholder1002at operation1096. The operations1094and1096are similar to the operations792and794, respectively.

Referring toFIG.11, an example swimlane diagram outlining operations of a process1100is shown, in accordance with some embodiments of the present disclosure. The process1100may be used for push provisioning a payment source to a pay wallet, and particularly to a Google Pay™ wallet using a web application of the issuer application614. The process1100starts with a cardholder1102selecting a payment source at operations1104-1114similar to the operations1004-1014, respectively. Upon selecting the payment source, the cardholder1102requests a list of pay wallets to select a pay wallet (e.g., Google Pay™ wallet) from at operations1116-1126similar to the operations1018-1034, respectively. An issuer web application1128sends initializing inputs to a software development kit1130at operations1132and1134similar to the operations758and760. The issuer web application1128may be considered analogous to the issuer application614and the software development kit may be considered analogous to the software development kit616. At operation1136, the cardholder1102selects a pay wallet (e.g., Google Pay™ wallet) from the list of pay wallets via the issuer web application1128. The selected pay wallet along with the associated asset identifier is sent to the software development kit1130at operation1138, which then redirects the cardholder1102to a web page associated with a wallet server1140of Google Pay™ wallet. The wallet server1140may be considered analogous to the pay wallet server620.

The cardholder1102logs into their Google account using their Google credentials and selects a suitable Google device at operation1142for provisioning the selected payment source to similar to the operation1068. Upon logging in and selecting a device, the wallet server1140sends a session identifier (or token) to the software development kit1130at operation1144. The software development kit1130passes on the session identifier along with pass through data to the issuer web application1128at operation1146. The issuer web application1128sends the pass through data along with the session identifier, at operations1148and1150, to a gateway1152via an issuer application server1154. The gateway1152may be considered analogous to the gateway606and the issuer application server1154may be considered analogous to the issuer application server608.

The gateway1152encrypts the pass-through data to generate an encrypted payload similar to the operation860and sends the encrypted payload to the wallet server1140at operation1152, which acknowledges receipt at operation1154. In some embodiments, upon the wallet server1140acknowledging receipt of the encrypted payload, the gateway1152sends a message (without the encrypted payload) to the software development kit1130via the issuer application server1154and the issuer web application1128at operations1156-1160. The wallet server1140sends the encrypted payload to a token service provider1162for requesting a token for the selected payment source at operation1164. The token service provider1162may be an MDES token service provider, a VTS token service provider, or any other token service provider similar to the token service provider604. The token service provider1162generates a token and sends that token to the wallet server1140via an issuing host platform1166at operations1168-1172, as discussed above. The wallet server1140generates a reply message (e.g., success, failure, etc.) indicating whether the wallet server successfully received the token or not, and sends the message to the software development kit1130at operation1174. The software development kit1130interprets the reply message and sends an interpretation back to the issuer web application1128at operation1176(similar to the operation1094) for display to the cardholder1102at operation1178.

Referring toFIG.12, an example swimlane diagram outlining operations of a process1200is shown, in accordance with some embodiments of the present disclosure. The process1200may be used for push provisioning a payment source to a pay wallet, and particularly to a Samsung Pay® wallet, using a web application of the issuer application614. The process1200starts with a cardholder1202selecting a payment source at operations1204-1214similar to the operations1004-1014, respectively. Upon selecting the payment source, the cardholder1202requests a list of pay wallets to select a pay wallet (e.g., Samsung Pay® wallet) from at operations1216-1226similar to the operations1018-1034, respectively. An issuer web application1228sends initializing inputs to a software development kit1230at operations1232and1234similar to the operations1132and1134, respectively. The issuer web application1228may be considered analogous to the issuer application614and the software development kit1230may be considered analogous to the software development kit616. At operation1236similar to the operation1136, the cardholder1102selects a pay wallet (e.g., Samsung Pay® wallet) from the list of pay wallets via the issuer web application1228. The selected pay wallet along with the associated asset identifier is sent to the software development kit1230at operation1238(similar to the operation1138).

The software development kit1230prepares pass-through data and sends that pass-through data to the issuer web application1228at operation1240, which then makes a push provisioning request to a gateway1242via an issuer application server1244at operations1246and1248. The issuer application server1244may be considered analogous to the issuer application server608and the gateway1242may be considered analogous to the gateway606. The gateway1242may hold on to the pass-through data temporarily and send a receipt identifier to a wallet server (e.g., Samsung wallet server)1250at operation1252. The wallet server1250, may be considered analogous to the pay wallet server620, may send an acknowledgment message to the gateway at operation1254. The gateway1242also sends a message to the software development kit1230via the issuer application server1244and the issuer web application1230at operations1256,1258, and1260indicating the start of the push provisioning process. The software development kit1230redirects the cardholder1202to a pay wallet application associated with the wallet server1250and sends the receipt identifier to the wallet server.

At operation1264, upon being redirected to the pay wallet application of the wallet server1250, the cardholder1202logs into their Samsung account and selects a suitable device for push provisioning the selected payment source to, similar to the operation1068. Upon selecting a device, the wallet server1250sends the receipt identifier to the gateway1242at operation1266. The gateway1242compares the receipt identifier received from the wallet server1250at the operation1266with the receipt identifier sent at the operation1252to determine a match. If the gateway1242determines that the receipt identifier received from the wallet server1250at the operation1266matches with the receipt identifier sent at the operation1252, and that the current session is still active, the gateway retrieves the pass-through data and sends the pass-through data to the wallet server at operation1268. In some embodiments, the gateway1242may encrypt the pass-through data before sending to the wallet server1250.

The wallet server1250sends the pass-through data to a token service provider1270at operation1272. The token service provider1270may be an MDES token service provider, a VTS token service provider, or any other token service provider similar to the token service provider604. The token service provider1270generates a token and sends that token to the wallet server1250via an issuing host platform1274at operations1276-1280, as discussed above. The issuing host platform1274may be considered analogous to the issuing host platform622. The wallet server1250generates a message (e.g., success, failure, etc.) indicating whether the wallet server successfully received the token or not, and sends the message to the software development kit1230at operation1282. The software development kit1230interprets the message and sends an interpretation back to the issuer web application1228at operation1284(similar to the operation1094) for display to the cardholder1202at operation1286. In some embodiments, the wallet server1250may also send a status message to the gateway1242at operation1288to indicate whether the wallet server successfully received the token or not. The gateway1242may send a response back at operation1290.

Turning now toFIGS.13A-13E, example interfaces of push provisioning a payment source to a pay wallet using an issuer's web application is shown, in accordance with some embodiments of the present disclosure. It is to be understood that the shape, size, configuration, orientation, information, etc. of the various features shown inFIGS.13A-13Eare only examples and not intended to be limiting in any way. Similarly, the names, logos, and other information shown inFIGS.13A-13Eare only an example and not intended to be limiting. AlthoughFIGS.13A-13Eare directed to push provisioning to Apply Pay®, similar operations may be performed for Google Pay™ and Samsung Pay®.

To push provision a payment source issued by an issuer to a pay wallet, the cardholder logs into an issuer web application1300associated with the issuer on a client device1302. The cardholder may access the issuer web application1300by opening a web browser on the client device1302and entering URI information (e.g., the Uniform Resource Locator (URL)) of the issuer into the web browser. For example, if the issuer is First Bank, the cardholder may enter the web address of First Bank into a web browser to be taken to First Bank's website. It is to be understood that First bank is only an example and not intended to be limiting in any way. In other embodiments, the description applies to other issuers as well. On the issuer's website, the cardholder may log into their cardholder account similar to the operation1004. Upon successfully logging into the cardholder account on the issuer web application, the cardholder may be presented with a list of accounts1304of the operation1012in a user interface1306ofFIG.13A.

The cardholder may select one account from the list of accounts1304for push provisioning by clicking on an “add to Apple wallet” button. For example, in some embodiments, to select debit card associated with account1308for push provisioning, the cardholder may select button1310. In the user face1306, the selection of the payment source and the selection of the pay wallet occurs by way of the select button1310. In other embodiments, the cardholder may first select a payment source (e.g., account) and then click on another button to start the push provisioning process. Upon clicking on the select button1310to start the push provisioning process, the cardholder may be directed to a user interface1312ofFIG.13B. The user interface1312may redirect the cardholder to a web application1314associated with Apple server as in the operation1066. The cardholder may be required to log in to their Apple account and select an Apple device. Upon selecting an Apple device, the cardholder may click on a next button1316to open a user interface1318ofFIG.13C. The user interface1318may present terms and conditions to the cardholder to accept. The cardholder may accept the terms and conditions by clicking on an agree button1320. In other embodiments, the cardholder may be presented other or additional user interfaces.

Upon clicking on the agree button1320, the cardholder may be directed to a user interface1322ofFIG.13Dwhere the cardholder may get a message1324indicating whether the push provisioning process is successful. The message1324may correspond to the operation1096. When the cardholder clicks on the agree button1320, the operations1070-1094may be performed in the background. Upon clicking on a done button1326, the cardholder may be directed to a user interface1328ofFIG.13E. The user interface1328takes the cardholder back to the issuer web application1300and shows a message1330indicating that the selected payment source has been push provisioned to the pay wallet.

The methods, systems, and devices discussed above are examples. Various configurations may omit, substitute, or add various procedures or components as appropriate. For instance, in alternative configurations, the methods may be performed in an order different from that described, and/or various stages may be added, omitted, and/or combined. Also, features described with respect to certain configurations may be combined in various other configurations. Different aspects and elements of the configurations may be combined in a similar manner. Also, technology evolves and, thus, many of the elements are examples and do not limit the scope of the disclosure or claims.

Specific details are given in the description to provide a thorough understanding of exemplary configurations including implementations. However, configurations may be practiced without these specific details. For example, well-known circuits, processes, algorithms, structures, and techniques have been shown without unnecessary detail in order to avoid obscuring the configurations. This description provides example configurations only, and does not limit the scope, applicability, or configurations of the claims. Rather, the preceding description of the configurations will provide those skilled in the art with an enabling description for implementing described techniques. Various changes may be made in the function and arrangement of elements without departing from the spirit or scope of the disclosure.

Also, configurations may be described as a process which is depicted as a flow diagram or block diagram. Although each may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be rearranged. A process may have additional steps not included in the figure. Furthermore, examples of the methods may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, the program code or code segments to perform the necessary tasks may be stored in a non-transitory computer-readable medium such as a storage medium. Processors may perform the described tasks.

Having described several example configurations, various modifications, alternative constructions, and equivalents may be used without departing from the spirit of the disclosure. For example, the above elements may be components of a larger system, wherein other rules may take precedence over or otherwise modify the application of the technology. Also, a number of steps may be undertaken before, during, or after the above elements are considered. Accordingly, the above description does not bind the scope of the claims.

As used herein and in the appended claims, the singular forms “a”, “an”, and “the” include plural references unless the context clearly dictates otherwise. Thus, for example, reference to “a user” includes a plurality of such users, and reference to “the processor” includes reference to one or more processors and equivalents thereof known to those skilled in the art, and so forth.

Also, the words “comprise”, “comprising”, “contains”, “containing”, “include”, “including”, and “includes”, when used in this specification and in the following claims, are intended to specify the presence of stated features, integers, components, or steps, but they do not preclude the presence or addition of one or more other features, integers, components, steps, acts, or groups.