Patent Application
20230153788
Electronic payment transactions and online banking via client devices (e.g., desktop devices and mobile devices) are increasingly prevalent. For example, many entities (e.g., banks) provide tools that allow customers to engage in payment transactions with other users (e.g., peer-to-peer payment transactions or peer-to-business payment transactions). Additionally, many entities have provided online availability of a number of operations by providing websites and proprietary applications. To illustrate, these websites and proprietary applications include tools for viewing information associated with customer accounts or performing other operations associated with the customer accounts.
While many existing systems provide online availability of a number of operations, these conventional systems continue to exclude online availability of some operations. In particular, some operations involved with banking entities or other financial entities (e.g., credit/debit card providers) require additional security measures that are difficult to verify through online communications. Due to the increased difficulty of providing adequate security of information exchange for such operations through online communications, the conventional systems restrict the performance of these operations to in-person or telephonic communications. In many instances, performing such operations online while complying with electronic payment standards is not possible via the infrastructure/design of the conventional systems. Accordingly, the conventional systems suffer from a number of disadvantages in security for online banking operations.
This disclosure describes one or more embodiments of methods, non-transitory computer readable media, and systems that solve the foregoing problems (in addition to providing other benefits) by utilizing encryption and double signature validation to perform card lifecycle actions for card accounts. Specifically, in one or more embodiments, in connection with a request to perform a card lifecycle action (e.g., setting a personal identification number) for a card account of a user, the disclosed systems provide an encryption key set to an issuing system server that issued the request. The disclosed systems then receive an encrypted request message from the issuing system server encrypted utilizing the encryption key set provided to the issuing system server and signed by the issuing system server and a client device of the user. Additionally, the disclosed systems validate that the signatures from the encrypted request message correspond to the issuing system server and the client device of the user. The disclosed systems also decrypt the encrypted request message and perform the card lifecycle action based on data in the decrypted request message. By utilizing encryption and double signature validation of requests to perform card lifecycle actions, the disclosed systems provide secure communications involving issuing system servers and user client devices.
The detailed description refers to the drawings briefly described below.
This disclosure describes one or more embodiments of a card lifecycle encryption system that performs card lifecycle actions based on encrypted request messages that are double signed by devices/servers that handle the request messages. Specifically, the card lifecycle encryption system receives from an issuing system server an indication of a request to perform a card lifecycle action associated with a card account (e.g., a payment card account) of a user. In connection with the indication of the request, the card lifecycle encryption system provides an encryption key set to a client device of the user to encrypt a request message associated with the card lifecycle action. The card lifecycle encryption system receives an encrypted request message that is encrypted with the encryption key set and signed by the client device and the issuing system server. The card lifecycle encryption system then performs the card lifecycle action after validating the signatures and decrypting the encrypted request message. The card lifecycle encryption system thus verifies the identities of devices involved in the request message and the contents of the request message.
As mentioned, in one or more embodiments, the card lifecycle encryption system receives an indication of a request to perform a card lifecycle action associated with a card account of a user. Specifically, the card lifecycle encryption system receives an indication from an issuing system server that a client device is requesting to perform the card lifecycle action for the card account of the user. For example, the client device can request to perform a card lifecycle action including setting a personal identification number (“PIN”), revealing a PIN, activating a card, or disabling a card for the card account of the user.
In one or more embodiments, the card lifecycle encryption system provides an encryption key set to the issuing system server for encrypting messages from the client device. For example, the card lifecycle encryption system provides the encryption key set to the issuing system server in response to receiving the indication of the request to perform the card lifecycle action. Additionally, in some embodiments, the card lifecycle encryption system provides a one-time access token to the issuing system server for authenticating communications from the issuing system server to the card lifecycle encryption system in connection with the request to perform the card lifecycle action.
In one or more embodiments, after the card lifecycle encryption system provides an encryption key set to an issuing system server, the issuing system server provides the encryption key set to a client device of a user. The client device generates and encrypts a request message including data associated with the card lifecycle action utilizing the encryption key set. Additionally, the client device signs the encrypted request message and sends the encrypted request message to the issuing system server. In one or more embodiments, the issuing system server validates the signed message, signs the encrypted request message, and passes the encrypted request message to the card lifecycle encryption system.
According to one or more embodiments, the card lifecycle encryption system validates signatures of an encrypted request message received from an issuing system server. Specifically, the card lifecycle encryption system verifies identities of a client device and an issuing system server involved in a request to perform a card lifecycle action for a card account. The card lifecycle encryption system can also authenticate the encrypted request message received from the issuing system server based on the inclusion of the one-time access token with the encrypted request message. The card lifecycle encryption system then decrypts the encrypted request message according to the previously provided encryption key set.
Upon validating and decrypting an encrypted request message from an issuing system server, the card lifecycle encryption system performs a card lifecycle action associated with the request message. In particular, the card lifecycle encryption system accesses the contents of the request message to determine the specific card lifecycle action and/or other details for performing the card lifecycle action. The card lifecycle encryption system can then generate a status code to provide to the issuing system server in a response message in connection with the request. Accordingly, the issuing system server can provide the status code or other response data to the client device of the user for displaying a message at the client device in connection with the card lifecycle action.
The disclosed card lifecycle encryption system provides a number of benefits over conventional systems. For example, the card lifecycle encryption system improves the security and flexibility of computing devices and systems that manage card account data and interact with issuing systems. In contrast to existing systems that are unable to securely perform card lifecycle actions associated with card accounts due to architecture and communication limitations, the card lifecycle encryption system securely communicates with issuing system servers and other devices in connection with performing card lifecycle actions. Specifically, the card lifecycle encryption system utilizes encryption authentication and double signature validation with any communications involving sensitive card data in a process for performing card lifecycle actions for card accounts. For instance, the card lifecycle encryption system utilizes encryption and signature validation to securely verify the identities of devices sending request messages and the contents of the request messages for card lifecycle actions. This allows the card lifecycle encryption system to mitigate men-in-the-middle attacks or attacks stemming from customers of the card lifecycle encryption system.
Furthermore, the card lifecycle encryption system improves the flexibility of computing systems that manage card account data and interact with issuing systems. In particular, by improving the security of communications involving card lifecycle actions utilizing encryption and double signature validation, the card lifecycle encryption system also improves the flexibility of the computing systems. For example, in contrast to conventional systems that are limited to performing a limited set of actions via online communication methods, the card lifecycle encryption system provides increased availability of actions via secure online communications.
Additionally, by leveraging encryption and double signing for card lifecycle action requests, the card lifecycle encryption system 102 removes the burden of maintaining compliance standards for issuing systems involved in the card lifecycle management workflow. Specifically, the card lifecycle encryption system 102 only provides an issuing system with an encryption key set (e.g., a public key) used for envelope encryption of request messages for card lifecycle action requests. Accordingly, the issuing system does not have access to the contents of the request message, and is thus not required to meet compliance standards for such communications. This also improves efficiency and simplicity of computing systems and integration of issuing systems involved in the card lifecycle workflow.
Turning now to the figures,
As shown, in
In connection with managing card accounts for users, the card lifecycle encryption system 102 also manages card lifecycles of the card accounts. Specifically, payment cards often have an amount of time for which a payment card is usable once the payment card is activated. Accordingly, as used herein, the term “card lifecycle action” refers to operations in connection with initiating, pausing, ending, or otherwise managing a payment card during a lifecycle of the payment card. For instance, card lifecycle actions include setting a PIN for a card account, revealing a PIN for a card account, activating a card associated with a card account, or disabling/deactivating a card associated with a card account. Thus, card lifecycle actions affect an accessibility or status of a card and/or a card account for a user.
In one or more embodiments, the issuing system 112 includes a system that provides card accounts for users. For example, the issuing system 112 includes an issuing bank or other entity that issues and/or manages the funds within a card account. In some embodiments, the issuing system 112 approves or declines transactions involving a card account. The issuing system also operates with the card lifecycle encryption system 102 to provide various card account services including, but not limited to, performing card lifecycle actions, engaging in payment transactions (e.g., peer-to-peer transactions, peer-to-business transactions, installment/buy-now-pay-later purchasing transactions, electronic transactions, point-of-sale transactions), or managing personal and account related information. In additional embodiments, the issuing system 112 communicates with the card lifecycle encryption system 102 and/or other systems within a payment network for processing payment transactions associated with card accounts.
As mentioned, the card lifecycle encryption system 102 communicates with the issuing system 112 to manage card lifecycles for card accounts of users. In one or more embodiments, the issuing system 112 (e.g., via the issuing system server 106) communicates with the client device 108 via the network 110 to perform various operations in connection with a card account of a user associated with the client device 108. In particular, the issuing system 112 provides access to the card account of the user and/or a plurality of tools for managing the card account via the banking application 114 at the client device 108. To illustrate, the issuing system 112 provides detailed information about the card account such as, but not limited to, an account balance and user information for the user. In addition, the issuing system 112 can provide options for performing card lifecycle actions associated with the card account.
In connection with performing card lifecycle actions, the issuing system 112 communicates with the card lifecycle encryption system 102 to provide information associated with requests to perform card lifecycle actions. Specifically, the card lifecycle encryption system 102 receives indications of requests to perform card lifecycle actions for card accounts from the issuing system 112. To illustrate, the card lifecycle encryption system 102 provides one or more application programming interfaces (“APIs”) for the issuing system 112 to interface with the card lifecycle encryption system 102 and provide the information associated with the requests.
Furthermore, the card lifecycle encryption system 102 utilizes one or more APIs to provide encryption and/or authentication tools for encrypting and/or authenticating information in connection with performing the card lifecycle actions. For example, the API(s) include interfacing protocols for systems to integrate with the card lifecycle encryption system 102 (e.g., by integrating software components from the card lifecycle encryption system 102 into applications) and perform various actions associated with account management and card management as defined within the API(s). In one or more embodiments, the issuing system 112 and/or the client device 108 utilize the encryption/authentication information from the card lifecycle encryption system 102 to encrypt and authenticate communications with the card lifecycle encryption system 102. The card lifecycle encryption system 102 also utilizes one or more APIs to validate and decrypt encrypted messages from the issuing system 112. Furthermore, the card lifecycle encryption system 102 performs card lifecycle actions based on requests and then notifies the issuing system 112 and the client device 108 of the results of performing the card lifecycle actions.
In one or more embodiments, the server(s) 104 include a variety of computing devices, including those described below with reference to
In addition, in one or more embodiments, the issuing system 112 is implemented on one or more issuing system servers. For example, while
Additionally, as shown in
In addition, as shown in
As described above, in one or more embodiments, the card lifecycle encryption system 102 securely communicates with the issuing system 112 (e.g., the server(s) 104 securely communicate with the issuing system server 106) to perform card lifecycle actions. In particular, the card lifecycle encryption system 102 utilizes double signature validation to verify the identities of the issuing system server 106 and the client device 108 in connection with a request message for performing a card lifecycle action. Additionally, the card lifecycle encryption system 102 utilizes encryption (e.g., envelope encryption involving an encryption key set provided by the card lifecycle encryption system 102) to verify and authenticate the contents of the request message for performing the card lifecycle action. More specifically, the card lifecycle encryption system 102 provides one or more APIs that issuing systems leverage to securely communicate with the card lifecycle encryption system 102 for card lifecycle management via encryption and double signature validation.
As mentioned, the card lifecycle encryption system 102 provides and utilizes one or more APIs to communicate with an issuing system in connection with requests for performing card lifecycle actions.
In one or more embodiments,
According to one or more embodiments, the banking application 114 provides tools for a user to view information associated with a card account and perform card lifecycle actions associated with the card account. For instance, the client device 108 displays tools within one or more graphical user interfaces of the banking application 114 to request that the issuing system 112 and/or the card lifecycle encryption system 102 perform a card lifecycle action for the card account. To illustrate, the client device 108 displays one or more options to set a PIN for the card account, reveal a PIN established for the card account, activate a payment card for the card account, or disable a payment card for the card account. In response to an interaction by the user with an option to perform a card lifecycle action for the card account, the client device 108 generates the request to perform the selected lifecycle action.
In one or more embodiments, as illustrated in
According to one or more embodiments, in response to receiving an indication of a request to perform a card lifecycle action for a card account, the issuing system 112 communicates with the card lifecycle encryption system 102 to request an authentication token for use in communicating with the card lifecycle encryption system 102. As illustrated in
In response to the request message for the one-time access token, the card lifecycle encryption system 102 obtains the one-time access token. For instance, the card lifecycle encryption system 102 obtains the one-time access token from a third-party system that generates the one-time access token. To illustrate, the card lifecycle encryption system 102 generates a request message (e.g., a POST request message) to send to the third-party system via an API of the third-party system. The card lifecycle encryption system 102 then receives the one-time access token from the third-party system. In alternative embodiments, the card lifecycle encryption system 102 generates the one-time access token.
As illustrated in
In addition to requesting a one-time access token from the card lifecycle encryption system 102, in one or more embodiments, the issuing system 112 also requests encryption tools from the card lifecycle encryption system 102. For example, as illustrated in
According to one or more embodiments, the encryption key set includes a plurality of public keys maintained by the card lifecycle encryption system 102 for encrypting data. Additionally, in some embodiments, the encryption key set also provides the ability for devices to sign tokens For example, the encryption key set can be associated with a particular signing algorithm for verifying keys in the encryption key set. In one or more embodiments, the encryption key set includes a JSON Web Key Set including public keys signed utilizing a particular signature algorithm for authenticating the keys in the encryption key set.
As illustrated in
After receiving the encryption key set from the issuing system 112, the client device 108 utilizes the encryption key set to initiate the request to perform a card lifecycle action. For example, if the card lifecycle action includes setting a PIN for a card account, the client device 108 determines a PIN to provide to the card lifecycle encryption system 102. As illustrated in
As illustrated in
Furthermore, the request message can include different information depending on the type of card lifecycle action being requested. For example, if the card lifecycle action includes an action to set a PIN for the card account, the request message also includes the received PIN. Alternatively, if the card lifecycle action includes an action to reveal a PIN already established for the card account, the request message includes an PIN reveal request. If the card lifecycle action includes an action to activate a card ready to be activated for the card account, the request message includes a request to activate the card. Furthermore, if the card lifecycle action includes an action to disable/deactivate a card for the card account, the request message includes a request to disable/deactivate the card.
As
In one or more embodiments, the client device 108 provides additional authentication for the encrypted request message. In particular, as illustrated in
As mentioned, in connection with a request to perform a card lifecycle action associated with a card account, the card lifecycle encryption system 102 provided an encryption key set (with a public key) to the issuing system 112. Because the issuing system 112 received only the encryption key set from the card lifecycle encryption system 102, the issuing system 112 is not able to access/decrypt the data in the encrypted request message. Accordingly, the issuing system 112 only validates the client device signature of the encrypted request message (e.g., using the public key in the private-public key pair used to sign the encrypted request message).
In one or more embodiments, the issuing system 112 also provides additional authentication for the encrypted request message. Specifically, as illustrated in
In one or more embodiments, the issuing system 112 sends the encrypted request message to the card lifecycle encryption system 102 by leveraging the API provided by the card lifecycle encryption system 102. For instance, the issuing system 112 utilizes a set of API calls for performing specific card lifecycle actions. To illustrate, the issuing system 112 generates a POST request message including the encrypted request message and the OTT header by utilizing an API call that routes the message to a particular software or hardware component. In one or more embodiments, for a card lifecycle action including setting or revealing a PIN for a card account, the issuing system 112 utilizes API calls for accessing or modifying a PIN of the card account. In one or more embodiments, for a card lifecycle action including activating or disabling a card of the card account, the issuing system 112 utilizes API calls corresponding to card information for the card account.
Upon receiving an encrypted request message from the issuing system 112 (e.g., from the issuing system server 106), the card lifecycle encryption system 102 performs a number of operations to authenticate the encrypted request message. Specifically, as illustrated in
Furthermore, as illustrated in
According to one or more embodiments, after validating the signatures on the encrypted request message, the card lifecycle encryption system 102 also authenticates the client device 108. For example, as illustrated in
To illustrate, the card lifecycle encryption system 102 utilizes a first API layer (e.g., associated with performing card lifecycle actions) to generate a POST request message including the one-time access token and an application token associated with the issuing system 112 and/or the banking application 114 in a header of the POST request message with an empty request body. The card lifecycle encryption system 102 then passes the POST request message to a second API layer (e.g., associated with managing card accounts) to authenticate the client device 108. In response to the POST request message, the card lifecycle encryption system 102 utilizes the second API layer to provide an access token to the first API layer. In some embodiments, the access token has a time limit for which the access token is usable.
In one or more embodiments, the card lifecycle encryption system 102 accesses the contents of the encrypted request message. As illustrated in
In one or more embodiments, as illustrated in
Additionally, the card lifecycle encryption system 102 can then perform the card lifecycle action according to the specific action type. For instance, if the card lifecycle action includes setting a PIN for the card account, the card lifecycle encryption system 102 generates a message (e.g., a PUT request message via the first API layer) including the control token with a PIN number. The card lifecycle encryption system 102 then sets the PIN for the card account (e.g., via the second API layer) according to the received PIN in the request message. In alternative embodiments involving other types of card lifecycle actions (e.g., PIN reveal, card activation, card disabling), the card lifecycle encryption system 102 utilizes the corresponding API calls with the control token to perform the various card lifecycle actions.
As illustrated in
In one or more embodiments, the card lifecycle encryption system 102 also generates and/or provides additional information within a response message. For instance, in response to performing a card lifecycle action of revealing a PIN associated with a card account, the card lifecycle encryption system 102 includes the PIN for the card account within the response message. If the response message includes a PIN or other sensitive information, the card lifecycle encryption system 102 can encrypt (and in some instances sign) the response message for securely communicating the information to the client device 108. Additionally, to prevent the issuing system 112 from having access to the contents of the response message, the card lifecycle encryption system 102 can utilize an encryption key to which the issuing system 112 does not have access (e.g., via a private-public key pair associated with the client device 108 or utilizing envelope encryption).
As illustrated in
Additionally, if the response message is encrypted or includes one or more encrypted portions, the client device 108 can decrypt the encrypted data/portions. To illustrate, in response to the card lifecycle encryption system 102 performing a card lifecycle action to reveal a PIN associated with card account of a user of the client device 108, the client device 108 can receive the PIN in a response message that has been encrypted. The client device 108 can then verify the authenticity of the response message and decrypt the response message utilizing one or more decryption methods according to the encryption method for the response message.
In one or more embodiments, the card lifecycle encryption system 102 utilizes one or more APIs to ensure the security of communications between the issuing system 112 and the card lifecycle encryption system 102. In additional embodiments, the card lifecycle encryption system 102 and/or the issuing system 112 ensures (e.g., via the banking application 114) the security of the card lifecycle action at the client device 108. For example, the card lifecycle encryption system 102 or the issuing system 112 can leverage the banking application 114 to verify that the client device 108 does not retain sensitive information associated with the card lifecycle action. To illustrate, the card lifecycle encryption system 102 or the issuing system 112 can ensure that a PIN and/or other information associated with the card account is not retained in memory on the client device 108 or communicated to any other devices. Additionally, the card lifecycle encryption system 102 or the issuing system 112 can encrypt PIN data displayed or entered into a graphical user interface to prevent an entire decrypted PIN from being stored in device memory.
In additional embodiments, the card lifecycle encryption system 102 provides additional security for communications involving the issuing system 112 and/or client devices for card lifecycle management. For example, card lifecycle encryption system 102 can utilizes key rotation to continually update encryption key pairs retained by client devices and revoke access to old encryption key pairs at the client devices. Additionally, the card lifecycle encryption system 102 can communicate with issuing systems to provide initial encryption keys via configuration updates for applications on devices (e.g., over-the-air application updates on mobile devices).
As mentioned, the card lifecycle encryption system 102 can provide secure communications for a plurality of card lifecycle actions. In one or more embodiments, the card lifecycle actions include setting a PIN of a card account, revealing a PIN of a card account, activating a card of a card account, and disabling a card of a card account.
In one or more embodiments, as mentioned, the card lifecycle encryption system 102 provides an API for an issuing system associated with the client application 302 to use in integrating the client application 302 with the card lifecycle encryption system 102. The issuing system can thus integrate with the card lifecycle encryption system 102 to include one or more software components in the client application 302 for performing card lifecycle actions. Accordingly, the client device 300 utilizes encryption and signing for securely communicating with the issuing system and the card lifecycle encryption system 102 (via the issuing system) based on the API provided by the card lifecycle encryption system 102.
For example,
After receiving the PIN, the client device 300 encrypts the PIN utilizing an encryption key from the card lifecycle encryption system 102. Additionally, the client device 300 signs the encrypted PIN and provides the encrypted and signed PIN to the issuing system. Furthermore, as described above, the issuing system validates the signature of the client device 300 and also signs the encrypted PIN to send to the card lifecycle encryption system. The card lifecycle encryption system 102 validates the signatures of the client device 300 and the issuing system, decrypts the PIN, and then sets the PIN for the card account of the user of the client device 300.
Additionally, as mentioned, in response to performing the card lifecycle action to set the PIN for the card account, the card lifecycle encryption system 102 generates a response message with a status code. In particular, in response to successfully setting the PIN for the card account, the card lifecycle encryption system 102 generates a response message including a status code indicating that the action was successful. The card lifecycle encryption system 102 then provides the status code to the client device 300.
In addition to setting a PIN of a card account, the card lifecycle encryption system 102 can also perform a card lifecycle action to reveal a PIN for a card account. For example,
In connection with the PIN reveal request and authenticating with the issuing system, the client device 400 encrypts a request message for providing to the card lifecycle encryption system 102 including data associated with the card lifecycle action. For instance, the client device 400 can generate the encrypted message to include a code or other indicator of the PIN reveal request. The client device 400 can encrypt and sign the request message to provide to the issuing system. Additionally, after validating the signature of the client device 400, the issuing system also signs the encrypted request message to provide to the card lifecycle encryption system 102.
Upon receiving the encrypted request from the issuing system, in one or more embodiments, the card lifecycle encryption system 102 validates the signatures of the issuing system and the client device 400. The card lifecycle encryption system 102 then decrypts the request message and utilizes the data in the request message to perform the corresponding card lifecycle action of revealing a PIN for a card account. Specifically, the card lifecycle encryption system 102 accesses the PIN stored for the card account and returns the PIN in an encrypted message to the client device 400 (e.g., in addition to a status code). As illustrated in
In one or more additional embodiments, the card lifecycle encryption system 102 provides a card lifecycle action for activating a card of a card account. Specifically,
After receiving a card number via the graphical user interface of the client application 502, the client device 500 encrypts the card number utilizing an encryption key from the card lifecycle encryption system 102 and signs the encrypted card number. In one or more alternative embodiments, the client device 500 has a previously stored token representation of the card number (e.g., a card account number). The client device 500 can thus use the previously stored token for the request message and sign the stored token (e.g., with other information within the request message) to send to the issuing system. After validating the client device signature and signing the encrypted request message, the issuing system provides the encrypted request message to the card lifecycle encryption system 102 for signature validation and decryption. The card lifecycle encryption system 102 also performs the card lifecycle action of activating the card based on the request message.
In response to performing the card lifecycle action to activate the card for the card account, the card lifecycle encryption system 102 generates a response message with a corresponding status code. Specifically, the card lifecycle encryption system 102 generates a response message including a status code indicating that the card lifecycle encryption system 102 successfully activated the card. The card lifecycle encryption system 102 also provides the response message with the status code to the client device 500.
According to one or more embodiments, the card lifecycle encryption system 102 provides a card lifecycle action for disabling a card of a card account. In particular,
In response to authenticating the user with the issuing system, the client device 600 encrypts a request message indicating the card lifecycle action of disabling a card. For instance, the client device 600 encrypts a request message including a token representing the card (e.g., a token representing the card number) and signs the encrypted request message. To illustrate, the client device 600 utilizes a previously stored token or requests that the user enter the card number for encrypting within the request message. The client device 600 provides the encrypted request message to the issuing system to validate the signature of the client device 600 and also sign before providing the encrypted message to the card lifecycle encryption system 102. Additionally, the card lifecycle encryption system 102 validates the signatures of the issuing system and the client device 600 before decrypting the request message and disabling the card indicated in the request message.
Based on performing the card lifecycle action to disable the card for the card account, the card lifecycle encryption system 102 generates a response message with a status code corresponding to the card lifecycle action. In particular, the card lifecycle encryption system 102 generates a response message including a status code indicating that the card lifecycle encryption system 102 successfully disabled the card. The card lifecycle encryption system 102 then sends the response message with the status code to the client device 600.
Although the above figures illustrate various embodiments of graphical user interfaces of client applications displayed on client devices, client devices can utilize other configurations and workflows for performing card lifecycle actions. To illustrate, the card lifecycle encryption system 102 or an issuing system can require that users authenticate (e.g., enter credentials) in connection with performing any card lifecycle action. Additionally, in some embodiments, the card lifecycle encryption system 102 or an issuing system can provide, via a client application, interfaces for selecting from a plurality of different cards to perform card lifecycle actions for a card account.
Turning now to
As shown, the series of acts 700 includes an act 702 of receiving an indication of a request to perform a card lifecycle action. For example, act 702 involves receiving, from a issuing system server, an indication of a request to perform a card lifecycle action in connection with a card account of a user.
Act 702 can involve receiving an indication of a request to set a personal identification number associated with the card account of the user via a banking application on the client device of the user. Act 702 can alternatively involve receiving an indication of a request to activate a payment card associated with the card account of the user. Act 702 can involve receiving an indication of a request to disable a payment card associated with the card account of the user. Additionally, act 702 can involve receiving an indication of a request to view a personal identification number associated with the card account of the user via a banking application on the client device of the user.
Act 702 can also involve receiving, from the issuing system server, a token request for a one-time access token based on the indication of the request. Act 702 can further involve providing the one-time access token to the issuing system server in response to the token request.
The series of acts 700 also includes an act 704 of providing an encryption key set to an issuing system server. For example, act 704 involves providing, based on the indication of the request, an encryption key set to the issuing system server.
Additionally, the series of acts 700 includes an act 706 of receiving an encrypted request message including double signatures. For example, act 706 involves receiving, from the issuing system server, an encrypted request message signed by the issuing system server and a client device of the user, the encrypted request message encrypted via the encryption key set and comprising data associated with the request to perform the card lifecycle action.
Act 706 can involve validating that a server signature for the encrypted request message corresponds to the issuing system server. Act 706 can also involve validating that a client device signature for the encrypted request message corresponds to the client device of the user. Act 706 can further involve verifying that a header associated with the encrypted request message comprises the one-time access token.
The series of acts 700 further includes an act 708 of performing the card lifecycle action based on the encrypted request message being double signed. For example, act 708 involves performing the card lifecycle action based on the encrypted request message being signed by the issuing system server and the client device of the user. Act 708 can involve setting a personal identification number associated with the card account of the user based on the data in the encrypted request message.
Act 708 can involve decrypting the encrypted request message to determine the data associated with the request to perform the card lifecycle action. For example, act 708 can involve decrypting the encrypted request message in response to verifying that a header associated with the encrypted request message received from the issuing system server comprises a one-time access token provided to the issuing system server in response to receiving the indication of the request to perform the card lifecycle action. Additionally, act 708 can involve accessing the data associated with the request to perform the card lifecycle action after decrypting the encrypted request message, the data comprising a client identifier of the client device, a user token associated with the user, a card token associated with the card account, and the card lifecycle action. Act 708 can then involve performing the card lifecycle action according to the data associated with the request to perform the card lifecycle action.
The series of acts 700 can also include generating a status code in response to performing the card lifecycle action. The series of acts 700 can then include generating a response message comprising the status code associated with performing the card lifecycle action. The series of acts 700 can then include providing the response message comprising the status code to the issuing system server for display at the client device of the user. In one or more embodiments, the response message causes the client device to display a response message at the client device of the user according to the status code.
Embodiments of the present disclosure may comprise or utilize a special purpose or general-purpose computer including computer hardware, such as, for example, one or more processors and system memory, as discussed in greater detail below. Embodiments within the scope of the present disclosure also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures. In particular, one or more of the processes described herein may be implemented at least in part as instructions embodied in a non-transitory computer-readable medium and executable by one or more computing devices (e.g., any of the media content access devices described herein). In general, a processor (e.g., a microprocessor) receives instructions, from a non-transitory computer-readable medium, (e.g., a memory, etc.), and executes those instructions, thereby performing one or more processes, including one or more of the processes described herein.
Computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer system. Computer-readable media that store computer-executable instructions are non-transitory computer-readable storage media (devices). Computer-readable media that carry computer-executable instructions are transmission media. Thus, by way of example, and not limitation, embodiments of the disclosure can comprise at least two distinctly different kinds of computer-readable media: non-transitory computer-readable storage media (devices) and transmission media.
Non-transitory computer-readable storage media (devices) includes RAM, ROM, EEPROM, CD-ROM, solid state drives (“SSDs”) (e.g., based on RAM), Flash memory, phase-change memory (“PCM”), other types of memory, other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.
A “network” is defined as one or more data links that enable the transport of electronic data between computer systems and/or modules and/or other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a transmission medium. Transmissions media can include a network and/or data links which can be used to carry desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. Combinations of the above should also be included within the scope of computer-readable media.
Further, upon reaching various computer system components, program code means in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to non-transitory computer-readable storage media (devices) (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a “NIC”), and then eventually transferred to computer system RAM and/or to less volatile computer storage media (devices) at a computer system. Thus, it should be understood that non-transitory computer-readable storage media (devices) can be included in computer system components that also (or even primarily) utilize transmission media.
Computer-executable instructions comprise, for example, instructions and data which, when executed at a processor, cause a general-purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. In some embodiments, computer-executable instructions are executed on a general-purpose computer to turn the general-purpose computer into a special purpose computer implementing elements of the disclosure. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.
Those skilled in the art will appreciate that the disclosure may be practiced in network computing environments with many types of computer system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, tablets, pagers, routers, switches, and the like. The disclosure may also be practiced in distributed system environments where local and remote computer systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks. In a distributed system environment, program modules may be located in both local and remote memory storage devices.
Embodiments of the present disclosure can also be implemented in cloud computing environments. In this description, “cloud computing” is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources. For example, cloud computing can be employed in the marketplace to offer ubiquitous and convenient on-demand access to the shared pool of configurable computing resources. The shared pool of configurable computing resources can be rapidly provisioned via virtualization and released with low management effort or service provider interaction, and then scaled accordingly.
A cloud-computing model can be composed of various characteristics such as, for example, on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service, and so forth. A cloud-computing model can also expose various service models, such as, for example, Software as a Service (“SaaS”), Platform as a Service (“PaaS”), and Infrastructure as a Service (“IaaS”). A cloud-computing model can also be deployed using different deployment models such as private cloud, community cloud, public cloud, hybrid cloud, and so forth. In this description and in the claims, a “cloud-computing environment” is an environment in which cloud computing is employed.
In one or more embodiments, the processor 802 includes hardware for executing instructions, such as those making up a computer program. As an example, and not by way of limitation, to execute instructions for dynamically modifying workflows, the processor 802 may retrieve (or fetch) the instructions from an internal register, an internal cache, the memory 804, or the storage device 806 and decode and execute them. The memory 804 may be a volatile or non-volatile memory used for storing data, metadata, and programs for execution by the processor(s). The storage device 806 includes storage, such as a hard disk, flash disk drive, or other digital storage device, for storing data or instructions for performing the methods described herein.
The I/O interface 808 allows a user to provide input to, receive output from, and otherwise transfer data to and receive data from computing device 800. The I/O interface 808 may include a mouse, a keypad or a keyboard, a touch screen, a camera, an optical scanner, network interface, modem, other known I/O devices or a combination of such I/O interfaces. The I/O interface 808 may include one or more devices for presenting output to a user, including, but not limited to, a graphics engine, a display (e.g., a display screen), one or more output drivers (e.g., display drivers), one or more audio speakers, and one or more audio drivers. In certain embodiments, the I/O interface 808 is configured to provide graphical data to a display for presentation to a user. The graphical data may be representative of one or more graphical user interfaces and/or any other graphical content as may serve a particular implementation.
The communication interface 810 can include hardware, software, or both. In any event, the communication interface 810 can provide one or more interfaces for communication (such as, for example, packet-based communication) between the computing device 800 and one or more other computing devices or networks. As an example, and not by way of limitation, the communication interface 810 may include a network interface controller (NIC) or network adapter for communicating with an Ethernet or other wire-based network or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network, such as a WI-FI.
Additionally, the communication interface 810 may facilitate communications with various types of wired or wireless networks. The communication interface 810 may also facilitate communications using various communication protocols. The communication infrastructure 812 may also include hardware, software, or both that couples components of the computing device 800 to each other. For example, the communication interface 810 may use one or more networks and/or protocols to enable a plurality of computing devices connected by a particular infrastructure to communicate with each other to perform one or more aspects of the processes described herein. To illustrate, the digital content campaign management process can allow a plurality of devices (e.g., a client device and server devices) to exchange information using various communication networks and protocols for sharing information such as electronic messages, user interaction information, engagement metrics, or campaign management resources.
In the foregoing specification, the present disclosure has been described with reference to specific exemplary embodiments thereof. Various embodiments and aspects of the present disclosure(s) are described with reference to details discussed herein, and the accompanying drawings illustrate the various embodiments. The description above and drawings are illustrative of the disclosure and are not to be construed as limiting the disclosure. Numerous specific details are described to provide a thorough understanding of various embodiments of the present disclosure.
The present disclosure may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. For example, the methods described herein may be performed with less or more steps/acts or the steps/acts may be performed in differing orders. Additionally, the steps/acts described herein may be repeated or performed in parallel with one another or in parallel with different instances of the same or similar steps/acts. The scope of the present application is, therefore, indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.
