Patent Application
20230334467
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). In particular, entities often provide electronic payment transactions via the use of online tools such as websites or proprietary applications. These websites/applications allow users to initiate electronic payment transactions using information stored on personal devices (e.g., desktops, laptops, mobile devices), such as in a digital wallet or otherwise entered/stored via the personal devices.
While many existing systems provide online and mobile integration of electronic payment systems for users to engage in payment transactions via online or mobile platforms, conventional systems often introduce security concerns in implementing electronic payment transactions. Conventional systems often lack security by exposing payment card credentials (e.g., primary account numbers) and other user information to third parties such as merchant systems, client applications (e.g., browsers), or other systems. By exposing the private information to third parties, these conventional systems can introduce vulnerabilities such as by allowing malicious actors to acquire and use the information for fraudulent purposes.
To overcome some of these security concerns, the conventional systems adopt industry privacy and security standards for electronic payment transactions that require certain information to be transmitted in real-time. To illustrate, payment card industry (“PCI”) standards typically prevent the storage of specific information such as card verification values (e.g., “CVV2” codes) related to payment card accounts. Accordingly, conventional systems require users to manually enter/provide such information each time they authorize payment cards for electronic payment transactions. It is common for users to have difficulty entering payment information, run-out of time, or otherwise become frustrated with the checkout process. Such frustrations often cause potential consumers to abandon their transactions. Frustration with the checkout process is often exacerbated when using a mobile device due to the small screen size and difficulty of typing-in information. Along similar lines, users with older mobile devices or mobile devices with low complexity often do not even attempt to perform transactions on these devices due to the difficulty of entering payment information.
Thus, to comply with such industry standards, the conventional systems often trade usability and ease-of-use for increased security, which interrupts a transaction flow and slows down the transaction process. Accordingly, the conventional systems lack security and efficiency in facilitating electronic payment transactions for users and merchants.
This disclosure describes one or more embodiments of methods, non-transitory computer readable media, and systems that solves one or more of the foregoing problems (in addition to providing other benefits). Specifically, in one or more embodiments, the disclosed systems utilize one or more virtual cards to autofill payment information at a user client device for a payment transaction. For example, in response to receiving a request to select a particular payment card account for a payment transaction, the disclosed systems utilize a reference identifier in the request to determine a virtual card corresponding to the payment card account based on a virtual card account mapping. The disclosed systems provide a stored virtual card identification number and virtual card verification data (e.g., an expiration date and a card verification value) to a user client device for autofilling the virtual card identification number and the virtual card verification data at the user client device in connection with a payment transaction. Additionally, the disclosed systems utilize the virtual card account mapping to process the payment transaction in response to receiving a virtual card from a merchant system by swapping the virtual card with the payment card account when providing transaction details to a payment network. By generating one or more virtual cards linked to a payment card account to autofill payment card details, the disclosed systems provide secure and efficient payment transaction processing.
The detailed description refers to the drawings briefly described below.
This disclosure describes one or more embodiments of a virtual card system that generates virtual cards for autofilling verification data of a payment card and processing payment transactions. In particular, the virtual card system generates one or more limited use virtual cards representing a payment card account in a virtual card account mapping in response to a request to register the payment card account with the virtual card system. In response to a request to select the payment card account for use with a payment transaction, the virtual card system utilizes a reference identifier from the request to obtain a virtual card and verification data (e.g., expiration date and a card verification value) associated with the virtual card. The virtual card system provides the virtual card and verification data to the client device to autofill payment card details in a payment interface for providing to a merchant system. Additionally, in response to receiving a message from the merchant system to process the payment transaction via the virtual card, the virtual card system utilizes the virtual card account mapping to validate the virtual card and swap the virtual card with the payment card account for processing the payment transaction.
As mentioned, in one or more embodiments, the virtual card system receives a request to register a payment card account (e.g., a credit card or debit card) with an autofill service. In response to the request, the virtual card system generates one or more virtual cards to represent the payment card account within a virtual card account mapping. For example, the virtual card system determines a primary account number (“PAN”) associated with the payment card account and maps the PAN to virtual card identification numbers of the one or more virtual cards. Additionally, the virtual card system generates a reference identifier (e.g., a token or other unique identifier) corresponding to the virtual account mapping. In some embodiments, the virtual card system generates a plurality of limited use virtual cards associated with the payment card account for separate purposes (e.g., tied to specific merchant systems).
In one or more embodiments, the virtual card system utilizes a virtual card account mapping to autofill payment card details for a payment transaction. For instance, the virtual card system receives a card selection message including a reference identifier corresponding to a payment card account. The virtual card system utilizes the reference identifier to identify the virtual card account mapping and determine a virtual card corresponding to the payment card account. To illustrate, the virtual card system determines a virtual card identification number and virtual card verification data (e.g., a card verification value, an expiration date) associated with the virtual card.
Additionally, the virtual card system provides the virtual card to the client device in response to the request. Specifically, the virtual card system sends the virtual card, including the virtual card identification number and the virtual card verification data, to the client device. In some embodiments, the virtual card system also provides autofilling instructions to the client device (e.g., via an application programming interface) to cause the client device to autofill payment card details for the payment transaction utilizing the virtual card and corresponding data. Accordingly, the virtual card system causes the client device to autofill payment card details associated with the virtual card in place of payment card details of the payment card account. Furthermore, to initiate the payment transaction, the client device can submit the payment card details associated with the virtual card to a merchant system involved in the payment transaction.
According to one or more embodiments, the virtual card system processes the payment transaction in response to receiving a transaction processing message from the merchant system. For example, the virtual card system determines that the transaction processing message includes information associated with the virtual card provided to the client device. In particular, the virtual card system validates payment card details in the transaction processing message by accessing the virtual card account (e.g., based on a virtual card identification number in the transaction processing message) and comparing the payment card details to data stored in connection with the virtual card account mapping.
In additional embodiments, in response to validating the payment card details in the transaction processing message, the virtual card system communicates with a payment network to process the payment transaction. Specifically, the virtual card system replaces payment card details associated with the virtual card with payment card details associated with the payment card account. To illustrate, the virtual card system can replace the virtual card identification number of the virtual card with the PAN of the payment card account in an authorization message provided to the payment network to process the payment transaction utilizing the payment card account.
The disclosed virtual card system provides a number of benefits over conventional systems. For example, the virtual card system improves the security of computing systems that process electronic payment transactions. In contrast to existing systems that expose payment card credentials (e.g., PANs or user information) to third parties, the virtual card system utilizes virtual cards to provide secure transaction processing by limiting the use of payment card credentials for processing payment transactions. Specifically, the virtual card system improves security of electronic payment transactions by preventing third parties such as browsers/applications and merchants from having access to payment card details by replacing payment card details with virtual card details via a virtual card account mapping. Furthermore, by generating virtual cards for payment card accounts and utilizing the virtual cards to provide payment card details to third parties, the virtual card system can maintain the security of the payment card account even if the virtual card details are accessed or stolen by a malicious actor (e.g., by generating a new virtual card and discarding the compromised virtual card or by minimizing the situations where the stolen details are usable for payment). Thus, by using virtual cards, virtual card system increases security and reduce fraud by allowing a user to purchase items from any number of commerce sites/applications using one or more virtual cards without ever having to provide a payment card number to the commerce sites/applications.
Additionally, the disclosed virtual card system improves the efficiency of computing systems via the use of virtual cards. While existing systems prevent autofilling of certain payment card details such as expiration dates and card verification values due to PCI standards that prevent storage of card verification values—thus requiring users to manually enter such information each time such information is requested—the virtual card system leverages a dynamic virtual card to provide autofilling of payment card details in a transaction. For example, by swapping payment card details of a payment card account for virtual card details of a virtual card, the virtual card system can provide all necessary information for initiating a payment transaction between a user and a merchant system. In particular, the virtual card system can cause a client device to autofill verification data such as an expiration date and a card verification value associated with the virtual card (in addition to other payment data), which provides sufficient information for validating the virtual card for a transaction while complying with PCI standards.
The virtual card system, thus, improves security while also streamlining the transaction process for users. In particular, in one or more embodiments, the virtual card system enables users to efficiently complete a transaction without having to enter most, if not all, payment details necessary to complete a transaction. As such, the virtual card system increases the ease and speed of performing transactions, while also increasing security, particularly on mobile devices with small touch screens that are difficult to use to enter information. On a similar note, the virtual card system enables users to easily and efficiently perform transactions on older or low complexity mobile devices by eliminating the need to enter most, if not all, payment information to complete a transaction.
Turning now to the figures,
As shown, in
In one or more embodiments, the virtual card system 102 communicates with the client device 108 to manage a virtual card associated with a payment card account of the user. In particular, a virtual card is linked to an actual payment card account and provides a layer of security. As described below, a virtual card includes details that make the virtual card appear like an actual payment card (e.g., a payment card identification number, an expiration date, and a card verification value) but are different than the corresponding details of the actual payment card account. In one or more embodiments, the virtual card has no algorithmic relationship with an associated actual payment card number, so that the payment card number cannot be derived from the virtual card (such as by merely applying a decryption algorithm to the virtual card). Accordingly, the virtual card is not considered cardholder data, because it is a generated string from which it is not possible to extrapolate any original cardholder data without a mapping between the virtual card and the actual card. By using virtual cards, the virtual card system 102 can process a transaction without having to comply with regulatory standards, e.g., the PCI DSS standards, as explained below.
In one or more embodiments, in connection with managing virtual cards for users, the virtual card system 102 includes the autofill service 114 to perform autofilling of payment card details involving virtual cards for processing payment transactions in connection with the processing platform 116. In particular, the autofill service 114 generates and stores virtual card account mappings between virtual cards and payment card accounts. For instance, the autofill service 114 generates a virtual card account mapping including one or more virtual cards to represent a payment card account. Additionally, the autofill service 114 provides virtual card data for autofilling payment card details at a client device (e.g., the client device 108). Furthermore, the autofill service 114 communicates with the processing platform 116 to process payment transactions based on the virtual card account mappings.
As used herein, the terms “virtual card account mapping” refers to an entry stored in a database or other data storage medium that links one or more virtual cards to a payment credential of a payment card account of a user. To illustrate, a virtual card account mapping creates an association between one or more virtual card identification numbers and a PAN (e.g., a credit/debit card number) of a payment card account. In some embodiments, a virtual card identification number includes a unique number that refers to a specific virtual card (e.g., similar to a credit card number such that it includes 13-19 digits according to industry standards). Furthermore, a virtual card account mapping can include virtual card verification data such as expiration dates and card verification values for virtual cards. In additional embodiments, a virtual card account mapping includes additional parameters associated with processing payment transactions involving one or more virtual cards.
As used herein, the term “payment transaction” refers to an electronic payment transaction in which a payment card account funds a payment to a merchant or merchant system. For instance, a payment transaction includes an electronic payment transaction between a payment card account of a user and a recipient account associated with a merchant system (e.g., the merchant system 106) in a peer-to-business transaction. In one or more embodiments, a payment transaction involves an online purchase via a client application of a client device (e.g., via the client application 118 of the client device 108).
As illustrated in
The virtual card system 102 (e.g., via the processing platform 116) processes payment transactions by communicating with the payment network 110 to transfer funds from various payment card accounts to merchant accounts. In one or more embodiments, the payment network 110 includes a payment card account provider systems 120 that provides/services one or more payment card accounts for a user. For instance, the payment card account provider system 120 includes one or more payment card networks (e.g., VISA, DISCOVER, or MASTERCARD), issuing or acquiring bank systems, or other systems that provide access to funds via credit card accounts or debit card accounts. To illustrate, a payment card account provider system can provide payment card accounts of one or more payment card account types to one or more users. In addition to the payment card account provider system 120, in some embodiments, the payment network 110 includes gateway payment systems and other devices or systems involved in processing electronic payment transactions. The payment network 110 can also include additional payment account provider networks associated with one or more payment card networks and/or payment account types.
In one or more embodiments, in connection with managing virtual cards for payment card accounts, the virtual card system 102 also provides one or more additional systems or devices with virtual card management tools. For example, the one or more additional systems or devices include the client device 108 and/or the payment card account provider system 120 of the payment network 110. In one or more embodiments, the virtual card system 102 provides one or more application programming interfaces (“APIs”) for the systems or devices to generate one or more virtual cards and generate a virtual card account mapping to a payment card account with a plurality of parameters. To illustrate, payment card account provider system 120 can communicate with the virtual card system 102 via interfacing protocols of the API to provide virtual card management tools at a client device of a user.
In one or more embodiments, the virtual card system 102 securely communicates with the merchant system 106 and the payment network 110 (e.g., the server(s) 104 securely communicates directly or indirectly with the merchant system 106 and the payment network 110) to process electronic payment transactions with virtual cards. In particular, the virtual card system 102 utilizes encryption to verify and authenticate data passed to and from the merchant system 106 (or with a payment facilitator system or other entity assisting with payment transactions such as a browser/application) and/or the payment network 110 in connection with processing electronic payment transactions. More specifically, the virtual card system 102 provides one or more APIs that the merchant system 106 and/or the payment networks 110 leverage to securely communicate with the virtual card system 102 for virtual card management and payment transaction processing.
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 virtual card system 102 is implemented on one or more servers. For example, while
Additionally, as shown in
In addition, as shown in
As mentioned, the virtual card system 102 generates a virtual card for autofilling payment card details associated with a payment transaction and for processing the payment transaction.
In one or more embodiments, the virtual card system 102 generates a virtual card account mapping between a payment card account 200 and a virtual card 202. For instance, the virtual card system 102 generates the virtual card 202 in response to a request to register the payment card account 200 with an autofill service 114 of the virtual card system 102, as further described in more detail with respect to
As illustrated in
In one or more embodiments, as illustrated in
According to additional embodiments, the virtual card system 102 validates the virtual card 202 based on the virtual account mapping. Specifically, the virtual card system 102 (e.g., the autofill service 114) utilizes the virtual card 202 and the corresponding virtual card verification data to validate the virtual card 202 received from the merchant system 208. In response to validating the virtual card, and as illustrated in
As mentioned,
As illustrated in
In some embodiments, the client device 300 displays an option to associate the payment card (e.g., a corresponding payment card account of the payment card) with a virtual card within a purchase interface associated with a purchase of goods or services from a merchant system. For example, the client device 300 can display the option to select the payment card within the process flow of a payment transaction (e.g., during checkout). In alternative embodiments, the client device 300 displays the option to associate the payment card with a virtual card independently of a given payment transaction. For instance, the client device 300 can display the option within a card management interface of the client application 302.
In one or more embodiments, in response to a selection of a payment card at the client device 300,
As used herein, the term “card verification value” refers to a series of numbers that acts as a security feature for payment transactions. In one or more embodiments, a card verification value (typically referred to as “CVV” or “CVV2”) includes three digits or four digits that provide security for a payment card in addition to a PAN (or other payment card number), especially for transactions in which a payment card is not present at a site of the payment transaction (e.g., not at a physical location of a point-of-sale terminal). Thus, payment transactions involving online purchases may require a card verification value and/or other information associated with a payment card account to validate the payment card account.
According to one or more embodiments, the client device 300 sends the payment card information to the virtual card system 102 via an API provided by the virtual card system 102. For example, the virtual card system 102 can create and manage an API that exposes a plurality of interaction operations to devices or systems such as the client device 300 (e.g., via the client application 302) or a payment account provider system. The client device 300 can integrate with the virtual card system 102 via the API to allow the virtual card system 102 to access data associated with payment card accounts, validate payment card accounts, and perform other operations associated with payment card accounts. In one or more embodiments, the client device 300 integrates with the virtual card system 102 via the API (e.g., in an API call via the client application 302) in response to, or otherwise in connection with, a request to register a payment card account with the autofill service 114. The client device 300 can thus send the payment card information to the autofill service 114 via a secure communication according to the API protocols established by the virtual card system 102.
As illustrated in
In one or more embodiments, as part of registering the payment card for autofill, the virtual card system 102 validates the payment card information. In particular, the virtual card system 102 (e.g., via the processing platform 116) can provide some, or all, of the payment card information to a payment account provider system of a payment network. The payment account provider system can verify that the payment card information is accurate based on stored data for the payment card. More specifically, because the payment account provider system created the payment card account, the payment account provider system can verify that the information received from the virtual card system 102 matches the generated information. The payment account provider system can notify the virtual card system 102 that the payment card information is valid. The virtual card system 102 can register the payment card for autofill in response to receiving the notification that the payment card information is valid.
In addition, as illustrated in
In connection with generating the virtual cards to represent the payment card, the virtual card system 102 also generates virtual card information corresponding to the virtual cards. For example, the virtual card system 102 generates a unique virtual card identification number for each virtual card. Additionally, the virtual card system 102 can generate virtual card verification data for each virtual card including, but not limited to, an expiration date and a card verification value. The virtual card verification data thus provides additional security measures for validating the virtual cards in connection with payment transactions. The virtual card system 102 can store the virtual card identification numbers and virtual card verification data with the payment card in the virtual card account mapping.
In one or more embodiments, as illustrated in
According to one or more embodiments, as illustrated in
According to one or more embodiments, the virtual card system 102 also provides tools for setting additional parameters for virtual cards associated with a payment card. As illustrated in
Additionally, as illustrated in
In additional embodiments, rather than generating the virtual cards prior to storing the card controls, the virtual card system 102 utilizes the card controls to determine how many virtual cards to generate for the payment card. To illustrate, the virtual card system 102 can determine that a card control limits use of the payment card to a set of defined (e.g., allowed) merchants. The virtual card system 102 can generate a virtual card for each of the defined merchants. Thus, the virtual card system 102 can limit the number of virtual cards associated with the payment card by generating the virtual cards after first determining the usage limits of the payment card.
Once the virtual card system 102 has set up a virtual card for a payment card account, the virtual card is usable in connection with payment transactions.
According to one or more embodiments, the client device 400 engages in a payment transaction with the merchant system 404 in connection with a purchase of a good or service offered by the merchant system 404. For example, as illustrated in
As illustrated in
In one or more embodiments, as illustrated in
Additionally, the client device 400 sends the reference identifier to the virtual card system 102 (e.g., to the autofill service 114) by leveraging an API provided by the virtual card system 102. To illustrate, the client device 400 can execute the client application 402 to make an API call to the autofill service 114 to retrieve a virtual card corresponding to the payment card by utilizing the reference identifier. The client device 400 may thus interface with the virtual card system 102 utilizing the API call to perform operations in connection with autofilling payment card details within the purchase interface including requesting to retrieve a virtual card utilizing the reference identifier.
In one or more additional embodiments, as illustrated in
As illustrated in
In connection with accessing the virtual card account mapping corresponding to the reference identifier, the virtual card system 102 selects a virtual card from the virtual card account mapping. In particular, in response to determining that the virtual card account mapping includes a plurality of virtual cards corresponding to the payment card, the virtual card system 102 utilizes transaction information to select a specific virtual card. For instance, the virtual card system 102 utilizes a merchant identifier from the transaction information received from the client device 400 to select, from the plurality of virtual cards, a virtual card limited to use with a specific merchant system. In alternative embodiments, the virtual card system 102 utilizes other transaction information such as a transaction date/time or transaction type to select a particular virtual card from the virtual card account mapping.
In additional embodiments, the virtual card system 102 randomly selects a virtual card from the plurality of virtual cards to utilize in connection with the payment transaction. For example, the virtual card system 102 can generate a predetermined number of virtual cards for a payment card. Alternatively, the virtual card system 102 can generate virtual cards on-demand (e.g., based on transactions involving different merchant systems or other transaction scenarios). The virtual card system 102 can also register the randomly selected virtual card to the merchant system (or transaction type, etc.) associated with the transaction. The virtual card system 102 can utilize the registration of the virtual card to the merchant system so that subsequent transactions involving the merchant system utilize the same virtual card. Additionally, in response to the virtual card being compromised, the virtual card system 102 can replace the virtual card with a new virtual card and register the new virtual card with the merchant system, a payment facilitator system, a digital wallet, or other card system.
In one or more embodiments, the virtual card system 102 utilizes a model that leverages a database of merchant information to more accurately identify the merchant and/or transaction information. For example, the virtual card system 102 can obtain a URL and/or keywords associated with the payment transaction from the client application 402 (e.g., from a browser). The virtual card system 102 can then perform a search in the database to determine a merchant system corresponding to the URL/keywords. The virtual card system 102 can also obtain a merchant identifier from the database to identify the merchant system 404 and select a virtual card.
In one or more embodiments, as illustrated in
In one or more embodiments, the virtual card system 102 also utilizes controls to manage the use of the virtual card in payment transactions. For example, the virtual card system 102 can establish merchant controls that prevent tokenization of the virtual card identification number (or virtual card verification data) of the virtual card. To illustrate, the virtual card system 102 blocks tokenization attempts from the merchant system 404 (e.g., by blocking certain types of payment models or requests to add the virtual card to a digital wallet).
As illustrated in
As previously mentioned, the virtual card system 102 can retrieve the virtual card to provide to the client device 400 in response to an API call. The virtual card system 102 can also provide autofilling instructions to the client device 400 (e.g., for executing via the client application 402) to autofill information associated with the virtual card into the purchase interface based on the API call. Accordingly, the virtual card system 102 can cause the client device 400 to automatically insert required information for the virtual card to initiate the payment transaction into the purchase interface based on the previous selection of a corresponding payment card.
Once the client device 400 has received and autofilled the virtual card information for the payment transaction,
As illustrated in
In one or more embodiments, in response to receiving the transaction authorization message from the merchant system 404,
In additional embodiments, the virtual card system 102 also performs an act 430 of verifying the card controls, as illustrated in
As illustrated in
In one or more embodiments, the virtual card system 102 performs an act 434 of processing the transaction using the payment card, as illustrated in
The payment account provider system 408 can validate the payment card based on the PAN (and any additional information provided with the PAN). The payment account provider system 408 can also process the transaction by transferring funds from the payment card account of the payment card to an account of the merchant system 404. The payment network 406 can notify the virtual card system 102 in response to successfully processing the payment transaction to transfer funds from the payment card account to the account of the merchant system 404.
As illustrated in
In one or more additional embodiments, the virtual card system 102 also provides virtual cards for use in processing recurring payment transactions. For example, the virtual card system 102 can utilize an autofill service to provide the virtual card to a client device in an initial payment transaction for a recurring charge. The client device can autofill the virtual card details and provide the virtual card to the recipient system. The recipient system can utilize the virtual card to process the initial payment transaction via the virtual card system 102. In some embodiments, the virtual card system 102 can authorize recurring transactions based on the virtual in response to an indication of the recurring transactions provided with the initial transaction to the virtual card system 102. The virtual card system 102 can register the virtual card to the merchant system so that subsequent transactions are not required to be initiated via a browser or client application of the client device.
As mentioned, the virtual card system 102 provides tools for creating and configuring a virtual card for use in an autofilling service for payment transactions. Specifically, the virtual card system 102 provides tools for linking a payment card account to one or more virtual cards and setting card controls for use of the payment card/virtual cards.
The graphical user interface 502 includes one or more options for entering information associated with a payment card. To illustrate in
In response to a selection to add a payment card, the virtual card system 102 can provide a request for the user to register the card with an autofill service (e.g., to generate a virtual card for the payment card).
Additionally, as shown, the overlay 508 can include a visual representation 512 of a virtual card. Specifically, the overlay 508 can include the request to save the payment card as a virtual card with a note indicating that the payment card information will be stored and used securely via the use of the virtual card. Accordingly, the virtual card system 102 also provides a save option 514 to save the payment card as a virtual card by generating an autofill registration message to send to the virtual card system 102 with payment card details. In addition to securely storing and using the payment card via the virtual card, saving the payment card can also register the payment card for an autofill service.
In some embodiments, the virtual card system 102 also provides options for setting payment card controls for the payment card and corresponding virtual card to customize when and how a virtual card can be involved in payment transactions. For instance, the virtual card system 102 generates a graphical user interface 502 that includes options for selecting a variety of additional restrictions or parameters that determine how to process payment transactions for the virtual card. In one or more embodiments, the additional parameters include, but are not limited to, locations, transaction types, dates, times, total payment amounts, account balances, or other characteristics that the virtual card system 102 can use in validating the virtual card for a payment transaction.
Once the virtual card system 102 has created a virtual card for a payment card and registered the payment card for an autofill service in an account mapping, the virtual card system 102 utilizes the account mapping to process payment transactions involving the payment card.
Furthermore, the graphical user interface 602 includes a payment method option 606 that allows a user to select a payment method for initiating a payment transaction for the purchase. In one or more embodiments, the client device 600 determines whether a user account associated with a user of the client device 600 includes one or more existing payment accounts (e.g., via a digital wallet stored on the client device 600). Additionally, in some embodiments, the client device 600 detects a selection of the payment method option 606 to select from the existing accounts or to enter a new account for use in initiating a payment transaction to complete the purchase.
As illustrated in
In one or more embodiments, the overlay 608 includes an add card option 612 to add a new payment card for use as the payment method for the purchase. Specifically, in response to a selection of the add card option 612, the client device 600 can display an additional interface or overlay for adding payment card details associated with a new payment card. After receiving the payment card details for the new payment card, the client device 600 can validate the payment card (e.g., via the virtual card system 102 or another system) and provide the added card within the input field of the overlay 608. The client device 600 can also display a selected card from the dropdown list 610 within the input field of the overlay 608 in response to a selection of a previously entered card.
According to one or more embodiments, the client device 600 determines whether a selected payment card (e.g., a previously stored card selected from the dropdown list 610) is associated with a virtual card of the virtual card system 102. To illustrate, the client device 600 sends a reference identifier to the virtual card system 102 in response to a selection of a payment card with a corresponding reference identifier. In one or more embodiments, the virtual card system 102 determines that the selected payment card is associated with one or more virtual cards via the reference identifier from the client device 600 and according to a virtual card account mapping at the virtual card system 102.
Additionally, the virtual card system 102 can select a virtual card from the virtual card account mapping based on transaction information associated with the payment transaction. For instance, the client device 600 can also provide a merchant identifier or other transaction data to the virtual card system 102. The virtual card system 102 can select a virtual card from a plurality of virtual cards based on the merchant identifier or additional transaction data. The virtual card system 102 can return the virtual card to the client device 600. In addition, the virtual card system 102 can send virtual card verification data including an expiration date and a card verification value to the client device 600.
In response to the virtual card system 102 determining that the payment card corresponds to a virtual card, the virtual card system 102 sends the virtual card details to the client device 600 with autofilling instructions to autofill a plurality of payment credential fields of the graphical user interface 602 with the virtual card details. For example, as illustrated in
Furthermore, as illustrated in
Additionally, the graphical user interface includes a checkout option 622 to initiate the transaction process. For example, in response to a selection of the checkout option 622, the client device 600 sends the virtual card details to a merchant system for processing the payment transaction. The merchant system can also send the received virtual card details to the virtual card system 102 to validate the virtual card details and process the payment transaction. Furthermore, in response to validating the received virtual card details, the virtual card system 102 utilizes the virtual card account mapping to swap the virtual card for the corresponding payment card and process the payment transaction via a payment network.
As illustrated in
Turning now to
As shown, the series of acts 700 includes an act 702 of receiving a card selection message including a reference identifier corresponding to a payment card. For example, act 702 involves receiving, from a client device, a card selection message comprising a reference identifier indicating a selection of a payment card account in connection with autofilling payment account information for a payment transaction.
Act 702 can involve providing an application programming interface comprising a plurality of interaction operations for access by a browser at the client device. Act 702 can involve receiving, via the browser of the client device, the card selection message based on an interaction operation of the plurality of interaction operations.
Act 702 can involve receiving the card selection message comprising transaction data corresponding to the payment transaction. Act 702 can also involve selecting the virtual card of the plurality of virtual cards based on the transaction data indicating one or more transaction scenarios.
As part of act 702, or as an additional act, the series of acts 700 includes receiving, via a browser of the client device, an autofill registration message comprising a primary account number corresponding to a payment card account. The series of acts 700 can include generating, in response to the autofill registration message, the virtual card comprising the virtual card identification number representing the primary account number. For example, the series of acts 700 can include receiving, from a client device associated with the payment card account, a request to generate the virtual card for the payment card account. The series of acts 700 can include generating the virtual card in response to the request and providing a reference number corresponding to the virtual card to the client device. Additionally, the series of acts 700 can include generating the virtual card further comprises generating the virtual card verification data comprising an expiration date and a card verification value associated with the virtual card.
The series of acts 700 can also include generating a plurality of virtual cards representing the payment card account for a plurality of different transaction scenarios involving the payment card account. For example, the series of acts 700 can include generating the virtual card for one or more transaction scenarios of the plurality of transaction scenarios. The series of acts 700 can also include generating an additional card for one or more additional transaction scenarios of the plurality of transaction scenarios.
For example, the series of acts 700 can include generating a first virtual card representing the payment card account in connection with the merchant system, and generating a second virtual card representing the payment account in connection with an additional merchant system. In one or more embodiments, the series of acts 700 includes determining a plurality of merchant systems involved in payment transactions associated with the payment card account and generating a plurality of virtual cards corresponding to the plurality of merchant systems. The series of acts 700 can also include associating the first virtual card and the second virtual card with the reference identifier in the virtual card account mapping.
In one or more embodiments, the series of acts 700 includes generating virtual card controls limiting use of the plurality of virtual cards to payment transactions involving the plurality of merchant systems. Additionally, the series of acts 700 can include generating virtual card controls that limit use of the plurality of virtual cards based on one or more additional attributes of a payment transaction including location data, time data, or a payment amount.
The series of acts 700 can also include generating the reference identifier by mapping the virtual card to the payment card account in the virtual card account mapping. The series of acts 700 can then include providing the reference identifier corresponding to the virtual card to the client device.
The series of acts 700 also includes an act 704 of determining a virtual card based on the reference identifier and a virtual card account mapping. For example, act 704 involves determining, based on the reference identifier received from the client device, a virtual card corresponding to the payment card account from a virtual card account mapping for the payment card account.
Act 704 can involve determining that a merchant identifier received in connection with the card selection message corresponds to the merchant system. For example, act 704 can involve receiving a merchant identifier corresponding to the merchant system in connection with the card selection message. Act 704 can involve selecting from the plurality of virtual cards, the virtual card based on the merchant identifier. For example, act 704 can involve selecting the first virtual card from the virtual card account mapping based on the merchant identifier corresponding to the merchant system.
Additionally, the series of acts 700 includes an act 706 of providing a response message including the virtual card and verification data. For example, act 706 involves providing, to the client device, a response message comprising a virtual card identification number and virtual card verification data corresponding to the virtual card. In one or more embodiments, the virtual card verification data comprises an expiration date and a card verification value.
Act 706 can involve providing, to the client device, the expiration date and the card verification value associated with the virtual card with the virtual card identification number. Act 706 can also involve providing autofilling instructions to a client application of the client device to cause the client device to autofill a plurality of payment credential fields comprising the virtual card identification number, the expiration date, and the card verification value. For example, the client application can include a browser.
Act 706 can involve determining, from the virtual card account mapping, one or more transaction requirements based on virtual card account controls associated with the virtual card. Act 706 can further involve providing the response message comprising in response to determining that the payment transaction meets the one or more transaction requirements.
The series of acts 700 further includes an act 708 of processing the payment transaction utilizing the payment card based on a transaction processing message from a merchant system. For example, act 708 involves processing, in response to receiving a transaction processing message from a merchant system, the payment transaction utilizing the payment card account based on the virtual card account mapping and the transaction processing message comprising the virtual card identification number and the virtual card verification data.
Act 708 can involve receiving the transaction processing message from the merchant system and transaction data corresponding to the payment transaction. Act 708 can also involve validating the virtual card based on the virtual card identification number, the virtual card verification data, and the transaction data. Act 708 can involve providing, to a payment network comprising a payment card provider system associated with the payment card account, payment credentials for the payment card account and the transaction data.
Act 708 can involve validating, utilizing the virtual card account mapping, the virtual card based on the virtual card identification number and the virtual card verification data from the transaction processing message. Act 708 can also involve providing payment credentials associated with the payment card account to a payment network in response to validating the virtual card.
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.
