Patent Application
20230297995
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 capabilities for engaging in electronic payment transactions utilizing credit/debit cards via mobile devices.
While many existing systems provide online or mobile integration of electronic payment systems for users to engage in payment transactions via online or mobile platforms, these conventional systems are rigidly limited to processing specific types of transactions. In particular, conventional systems limit peer-to-business electronic payment transactions to a one-to-one structure in which a single person engages in a transaction with a single merchant (e.g., a single customer utilizes a physical or digital credit card to complete a purchase at a business). For example, the conventional systems restrict payment transactions to the one-to-one structure due to the slow changing nature of payment networks (e.g., the various card networks, issuing banks, gateway payment systems) and the difficulty of changing hardware (e.g., point-of-sale devices) and software (e.g., online applications) of merchants to integrate with the payment networks. In many instances, modifying the structure of payment transactions given the limitations of the payment networks and merchant systems (e.g., hardware and software) is not possible via the infrastructure/design of the conventional systems. Accordingly, the conventional systems lack flexibility 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 solve the foregoing problems (in addition to providing other benefits). Specifically, in one or more embodiments, the disclosed systems utilize a single card to provide multi-funding source payment transactions between a plurality of users and a merchant system. For example, in response to a request to process a multi-funding source transaction for a card in connection with a merchant system, the disclosed systems access an account mapping to determine whether to process the transaction utilizing a plurality of funding sources associated with the card (e.g., based on transaction attributes or merchant attributes). The disclosed systems also utilize the account mapping to determine proportions for processing the transaction with the plurality of funding sources. Additionally, the disclosed systems generate authorization messages to send to one or more payment networks for processing the multi-funding source payment transaction utilizing the plurality of funding sources for specific payment amounts based on the proportions. By utilizing a card linked to a plurality of different payment accounts to process payment transactions, the disclosed systems provide secure, flexible, and efficient multi-funding source transactions with existing payment network and merchant hardware/software infrastructure.
The detailed description refers to the drawings briefly described below.
This disclosure describes one or more embodiments of a card system that utilizes cards to process multi-funding source transactions involving a plurality of separate funding payment accounts. Specifically, the card system utilizes an account mapping between a card and two or more payment accounts to process a multi-funding source transaction with a merchant. For example, users can utilize the card to engage in individual or recurring payment transactions with the merchant to fund the payment transactions according to defined proportions and other parameters of the card. For example, in response to a request message for a multi-funding source transaction involving a card identification number, the card system accesses the account mapping to determine how to process the transaction. The card system determines funding proportions corresponding to the payment accounts based on the account mapping and a transaction amount for the multi-funding source transaction. Additionally, the card system processes the multi-funding source transaction by generating separate authorization messages for the different funding proportions and payment accounts.
As mentioned, in one or more embodiments, the card system initiates a transaction process in response to receiving a request message from a merchant system to process a payment transaction. In particular, the card system receives a request message including information associated with the transaction for initiating and processing the transaction. For instance, the request message includes a transaction amount and a card identification number. In some embodiments, the merchant system issues the request message in response to a transaction via a point-of-sale device or an application or website associated with the merchant system. In additional embodiments, the merchant system initiates the transaction without having access to information that the transaction is a multi-funding source transaction (e.g., multi-funding source information is obfuscated to the merchant). Accordingly, the card system determines that the transaction is a multi-funding source transaction based on information provided in the request message without the merchant system having knowledge of the multi-funding source configuration of the transaction.
In one or more embodiments, upon receiving authorization for the transaction the card system determines separate proportions corresponding to a plurality of payment accounts in connection with a multi-funding source transaction. Specifically, the card system accesses an account mapping in an account mapping database based on the card identification number in the request message. To illustrate, the card system determines a plurality of payment options associated with the card identification number from the account mapping. For example, the card system determines that two individual payment accounts may be used to each pay for (“fund”) 50% of a given payment transaction. Additionally, the card system determine the proportions (e.g., portions of the transaction amount) for each of the payment accounts based on the account mapping.
According to one or more embodiments, the card system generates authorization messages to send to the source payment accounts. For example, the card system generates a first authorization message to authorize the multi-funding source transaction against a first payment account for a first proportion of a transaction amount. Additionally, the card system generates N number of subsequent authorization messages to authorize the multi-funding source transaction against additional payment accounts for corresponding proportions of the transaction amount until the combined proportions meet the full amount of the transaction. The card system sends the authorization messages to one or more card payment networks or other payment networks or ledger accounts corresponding to the payment accounts to process the multi-funding source transaction.
In some embodiments, the card system also manages account mappings for cards. In particular, the card system generates a card with an account mapping between a card identification number of the card and a plurality of payment accounts. Furthermore, the card system determines multi-funding source transaction parameters associated with the card for processing multi-funding source transactions involving the card identification number. To illustrate, the multi-funding source transaction parameters define percentages, amounts, and/or transaction configuration parameters for determining when and how to process multi-funding source transactions involving the card identification number.
The disclosed card system provides a number of benefits over conventional systems. For example, the card system improves the flexibility and efficiency of computing systems that process electronic payment transactions. In contrast to existing systems that are rigidly limited to one-to-one transaction structures (e.g., between a single payor and a single recipient), the card system enables electronic multi-funding source transactions funded by a plurality of different sources. Specifically, the card system maps a card to a plurality of payment accounts for funding a single transaction between the card and a merchant system while utilizing existing payment hardware/software infrastructure.
The card system also improves the efficiency of computing systems by leveraging a many-to-one structure in electronic transactions. Specifically, in contrast to existing payment systems that restrict transactions to one-to-one transactions (thus requiring the processing of multiple one-to-one transactions to fund a purchase via a plurality of payment accounts), the card system utilizes existing hardware/software infrastructure to enable many-to-one transactions. To illustrate, by utilizing an intermediate card with its own card identification number to initiate a payment transaction with a merchant system, the card system is able to leverage existing payment infrastructure to utilize a plurality of payment accounts while appearing to the merchant system as a single funding entity. Furthermore, by modifying the transaction process via a card mapped to a plurality of accounts, the card system eliminates the need for merchant systems and payment networks to perform any integration or processing steps to enable multi-funding source transactions. Additionally, processing multi-funding source transactions via a card allows the card system to set up a consistent/recurring payment transaction involving a plurality of funding sources for a purchase or payment without requiring separate devices and/or user interactions associated with the separate payment accounts, thereby eliminating extra steps in transaction processes typical of conventional systems.
Additionally, the card system provides additional security in electronic payment transactions via the use of cards. For instance, in contrast to conventional systems that rely on third-party systems (e.g., payment card networks) to detect fraudulent transactions, the card system provides preventative control over electronic payment transactions via the cards. In particular, the card system provides fine-grained control over whether to initiate/process transactions via a card based on a number of different user-defined parameters, including device/merchant location data, date/time, transaction types, etc. Accordingly, the card system allows a user (in connection with an account mapping of a card) to establish specific parameters for determining whether to initiate a given payment transaction.
Turning now to the figures,
As shown, in
In one or more embodiments, in connection with managing cards for users, the card system includes the multi-funding source mapping database 114 to map the cards to corresponding payment accounts. In particular, the multi-funding source mapping database 114 includes account mappings between card identification numbers associated with the cards and payment accounts and payment credentials (e.g., credit/debit card numbers or account numbers) of corresponding payment accounts. In some embodiments, a card identification number includes a unique 16-digit number that refers to a specific card (e.g., similar to a credit card number). In addition, the card identification number may be tokenizable (e.g., capable of being tokenized by one or more account tokenization systems for securely processing payment transactions). As used herein, the term “account mapping” refers to an entry stored in a database that links a card identification number to one or more payment accounts of one or more users. Additionally, the multi-funding source mapping database 114 includes (e.g., with account mappings) parameters associated with processing multi-funding source payment transactions involving cards.
As used herein, the term “multi-funding source transaction” refers to an electronic payment transaction in which a plurality of payment accounts fund a payment to a single merchant using a single card. For instance, a multi-funding source transaction includes an electronic payment transaction between two or more payment accounts associated with a card and a merchant system (e.g., the merchant system 106). A multi-funding source transaction can include a single transaction (e.g., friends or coworkers paying for a meal at a restaurant) or a recurring transaction (e.g., roommates or spouses paying for rent or a phone bill) between a plurality of separate payment accounts and a single recipient. In one or more embodiments, a multi-funding source transaction involves a plurality of payment accounts associated with a single user or a plurality of users.
As illustrated in
The card system 102 processes multi-funding source transactions by communicating with the payment network 110 to transfer funds from various payment accounts to merchant accounts. In one or more embodiments, the payment network 110 includes a plurality of payment account provider systems 120a-120n that provide payment accounts for users. For instance, the payment account provider systems 120a-120n include 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, debit card accounts, checking accounts, ledgers, cryptocurrency accounts, etc. To illustrate, a payment account provider system can provide payment accounts of one or more payment account types to one or more users. In addition to the payment account provider systems 120a-120n, in some embodiments, the payment network 110 includes gateway payment systems and other devices or systems involved in processing electronic payment transactions. In one or more embodiments, one or more of the payment account provider systems 120a-120n include proprietary systems associated with the card system 102 or with a third party that provide ledgers or other payment sources carrying balances available for use in payment transactions.
In one or more embodiments, in connection with managing cards, the card system 102 also provides one or more additional systems or devices with card management tools. For example, the one or more additional systems or devices include the client device 108 and/or the payment account provider systems 120a-120n of the payment network 110. In one or more embodiments, the card system 102 provides one or more application programming interfaces (“APIs”) for the systems or devices to configure a card and generate an account mapping to one or more payment accounts with a plurality of parameters. To illustrate, payment account provider systems can communicate with the card system 102 via interfacing protocols of the API to provide card management tools at a client device of a user.
In one or more embodiments, the card system 102 securely communicates with the merchant system 106 and the payment network 110 (e.g., the server(s) 104 securely communicates with the merchant system 106 and the payment network 110) to process electronic payment transactions with cards. In particular, the card system 102 utilizes encryption to verify and authenticate data passed to and from the merchant system 106 and/or the payment network 110 in connection with processing electronic payment transactions. More specifically, the 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 card system 102 for 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 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 card system 102 provides management of cards for multi-funding source transactions.
In one or more embodiments,
In one or more embodiments, the card system 102 links the card identification number of the card to the first payment account 202a and the second payment account 202b with parameters 204 for the card account 200. For example, as described in more detail with respect to
According to one or more embodiments, the card system 102 utilizes the account mapping and the parameters 204 to process a first multi-funding source transaction 206a with a first merchant system 208a. Specifically, as described in more detail with respect to
As mentioned,
In response to the request to set up a card, the card system 102 establishes the card. In particular, as illustrated in
In one or more embodiments, as illustrated in
In some embodiments, as previously mentioned, the card system 102 is able to connect a variety of different payment accounts to a card. For instance, the card system 102 determines one or more payment accounts, such as credit card accounts, debit card accounts, checking accounts, or demand deposit accounts. To illustrate, the card system 102 determines (e.g., in response to information provided from or via the client device 300) that a first selected payment account includes a credit card account associated with a user. Additionally, the card system 102 can also determine that a second selected payment account includes a checking account associated with the user or a different user.
In alternative embodiments, the card system 102 determines any combination of payment accounts and payment account types. For example, the card system 102 determines selected payment accounts including a plurality of payment accounts of a single payment account type (e.g., two credit card accounts). In another example, the card system 102 determines one or more payment accounts of a plurality of different payment account types (e.g., two credit card accounts and a demand deposit account). Accordingly, the card system 102 provides customizable combinations of payment accounts for linking to a card.
According to one or more embodiments, the card system 102 determines proportions based on selected percentages for the payment accounts. To illustrate, the selected funding proportions can indicate a percentage of one or more multi-funding source transactions involving the card to fund utilizing a specific payment account. In some embodiments, determining a percentage allows the card system 102 to determine a percentage for another payment account (e.g., for a card linked to two payment accounts). In some embodiments, the card system 102 utilizes a plurality of percentages to determine proportions for all payment accounts.
In additional embodiments, the card system 102 determines one or more proportions based on one or more fixed amounts. Specifically, the card system 102 receives a selection of one or more fixed amounts for one or more payment accounts corresponding to a card. By assigning a fixed amount to a payment account, the card system 102 can determine how much to fund a given multi-funding source transaction utilizing each payment account linked to the card. In some embodiments, the card system 102 utilizes a combination of one or more percentages and one or more fixed amounts to determine funding proportions for the payment accounts.
In one or more embodiments, as illustrated in
In additional embodiments, the client device 300 displays options for setting limitations or determining proportions according to characteristics of one or more payment accounts linked to the card. For instance, the options can include interest rates, rewards, or balances associated with one or more payment accounts. More specifically, by allowing a user to set usage limitations (e.g., via the client device 300) for a card based on payment account characteristics in addition to characteristics of multi-funding source transactions, the card system 102 can provide dynamic transaction processing for a variety of different users, payment accounts, merchants, and other scenarios.
According to one or more embodiments, in response to receiving information associated with linking and using a card, the card system 102 verifies the information for processing multi-funding source transactions. In particular, as illustrated in
In one or more embodiments, as illustrated in
Furthermore, in one or more embodiments, the card system 102 stores funding proportions and any additional parameters with an account mapping for a card. For instance, the card system 102 stores the funding proportions and additional parameters in one or more entries/values associated with the card identification number of the card and/or one or more payment accounts in the multi-funding source mapping database 114. The card system 102 can thus store any limitations or other information for processing multi-funding source transactions utilizing the card in the multi-funding source mapping database 114.
In at least some embodiments, the card system 102 modifies a card based on additional user input. For example, as
As illustrated in
Although
In one or more embodiments, the card system 102 utilizes cards to process multi-funding source transactions with merchant systems.
As illustrated in
In one or more embodiments, the card system 102 determines that the payment transaction indicated in the request message corresponds to a multi-funding source transaction involving a plurality of payment accounts. In particular, as illustrated in
According to some embodiments, the card system 102 determines a card account corresponding to a card based on the card identification number. Specifically, the card system 102 utilizes the card identification number to perform a lookup in the multi-funding source mapping database 114. Based on previously generating a card account for the card identification number in the multi-funding source mapping database 114, the card system 102 determines the card account in response to performing the lookup. Additionally, in some embodiments, after determining the card identification number from the request message, the card system 102 determines a validity of the card identification number (e.g., via a card network or issuer of the card identification number).
In addition to determining the card account, the card system 102 also determines a plurality of parameters associated with the card identification number. In one or more embodiments, as illustrated in
In one or more embodiments, as illustrated in
Furthermore, in one or more embodiments, the card system 102 determines whether to process the payment transaction as a multi-funding source transaction utilizing the card account. To illustrate, in response to determining that the card identification number is mapped to a plurality of payment accounts and/or based on additional parameters associated with the card identification number, the card system 102 determines that the card account is compatible with multi-funding source transactions. For instance, the card system 102 determines that the card account indicates to process payment transactions of a particular transaction type, merchant type, or with specific transaction parameters as multi-funding source transactions.
In some embodiments, the card system 102 also utilizes the additional parameters associated with the card identification number to determine how to divide a transaction amount among a plurality of payment accounts. To illustrate, the card system 102 determines a first set of proportions for payment accounts in response to determining that the card account includes parameters indicating the first set of proportions for a payment transaction. For example, the card system 102 determines the first set of proportions based on parameters including, but not limited to, the transaction type, merchant system, month, location, rewards associated with the payment accounts, interest rates associated with the cards, or other account balances. Alternatively, the card system 102 determines a second set of proportions for payment accounts in response to determining that the card account includes parameters indicating the second set of proportions for a payment transaction (e.g., based on a different transaction type or merchant system).
In alternative embodiments, the card system 102 determines that the card account is not compatible with or does not qualify for multi-funding source transactions (or that the payment transaction does not qualify as a multi-funding source payment transaction with the card). For example, the card system 102 determines that the card account is not compatible with multi-funding source transactions based on a mapping of the card identification number to a single payment account or other parameters associated with the card account. To illustrate, the card system 102 determines not to process the payment transaction of the request message as a multi-funding source transaction in response to determining that a setting associated with the card account indicates not to process payment transactions of a particular transaction type, merchant type, or with specific transaction parameters as multi-funding source transactions. Accordingly, the card system 102 determines to process a payment transaction as a single-source transaction in response to determining that the card account is not compatible with processing the payment transaction as a multi-funding source transaction.
According to one or more embodiments, in response to determining funding proportions for funding sources, the card system 102 optionally verifies the payment transaction with one or more payment account provider systems. As illustrated in
In one or more embodiments, the card system 102 verifies an account balance for each payment account by verifying that the payment account has sufficient funds to fund a corresponding payment amount/portion. To illustrate, the card system 102 can communicate with the first payment account provider system 402a and the second payment account provider system 402b to determine balance amounts, available credit, etc., associated with the payment accounts. Alternatively, the card system 102 maintains account balances for one or more payment accounts or data associated with the account balances to quickly verify account balances for one or more payment accounts.
As illustrated in
According to one or more embodiments, the card system 102 processes the payment transaction after accepting the payment transaction. For instance, as illustrated in
In one or more embodiments, the card system 102 generates each authorization message to include a request to authorization according to the specific payment account. To illustrate, the card system 102 can generate the first authorization message according to a first authorization protocol for the first payment account and the second authorization message according to a second authorization protocol for the second payment account. As an example, the first authorization message includes a credit card authorization message to authorize the first proportion with a payment card network for funding by a credit card (e.g., according to PCI standards). Additionally, for example, the second authorization message includes a cryptocurrency authorization message to authorize the second proportion with a system that manages cryptocurrencies for funding by a cryptocurrency account. Thus, the card system 102 can generate each authorization message to include a structure and content specific to the type of payment account funding each proportion of the transaction.
According to one or more embodiments, the card system 102 also provides one or more authorization messages for one or more ledger accounts. For example, in response to determining that a ledger account associated with the card corresponds to a third-party system (e.g., an external system) that manages ledger accounts, the card system 102 can generate and send an authorization message to request authorization of funding via the ledger account to the third-party system. Alternatively, in response to determining that a ledger account associated with the card corresponds to an internal ledger system that manages ledger accounts (e.g., managed by the card system 102 or otherwise associated with the card system 102), the card system 102 can generate and send an authorization message to request authorization of funding via the ledger account to the internal ledger system.
As illustrated in
Additionally, as illustrated in
In connection with authorizing the payment transaction with the payment account provider systems, the card system 102 finishes processing the payment transaction. In one or more embodiments, the authorization messages to the payment account provider systems causes the payment account provider systems to transfer funds from the payment accounts to a payment account of the merchant system and/or to a payment account associated with the card system 102 (e.g., in a settlement process by the separate payment account provider systems). Specifically, the first payment account provider system 402a processes the first payment transaction to transfer funds from the first payment account to the payment account of the merchant system. Additionally, second payment account provider system 402b processes the second payment transaction to transfer funds from the second payment account to the payment account of the merchant system.
In some embodiments, the card system 102 utilizes Just-In-Time (“JIT”) funding to fund a multi-funding source transaction. For example, the card system 102 can communicate with the payment account provider systems 402a-402b utilizing JIT funding messages to fund and authorize multi-funding source transactions in real-time. To illustrate, the card system 102 sends a JIT funding message to a payment account provider system (e.g., the first payment account provider system 402a) to obtain program reserve funding (e.g., via clearing house or wire transfer) to fund a portion of a multi-funding source transaction. In alternative embodiments, the card system 102 provides the JIT funding message directly to a user device if the user manages the balance of the corresponding payment account. In additional embodiments, the card system 102 utilizes blockchain transactions, automated clearing house transfers, or real-time transport protocol transactions to transfer funds from one account to another.
In some embodiments, the card system 102 processes the payment transaction in response to receiving confirmation of authorization of the payment amounts for the payment accounts associated with the card identification number. For example, the card system 102 only completes the payment transaction in response to successful authorization of all payment amounts for all payment accounts. Thus, the card system 102 can prevent situations in which one payment account fails authorization and another payment account passes authorization. In alternative embodiments, the card system 102 performs a pre-authorization request for each payment account prior to sending the authorization messages (e.g., by obtaining pre-authorization when verifying account balances). In additional embodiments, the card system 102 performs the account balance verification and authorization operations for each payment account in a single request (or batch of requests).
According to some embodiments, the card system 102 determines one or more backup transaction processes for cases in which one or more funding sources fails. To illustrate, in response to determining that a payment account does not have sufficient funds or does not have permissions to fund a corresponding proportion of a multi-funding source transaction, the card system 102 can select one or more alternative funding sources to fund the corresponding proportion. For instance, the card system 102 can automatically determine a backup funding source according to established preferences of the card (e.g., a default backup funding source) and utilize the backup funding source to fund the proportion. In some embodiments, the card system 102 determines a backup funding source based on a plurality of possible backup funding sources for a particular scenario (e.g., a first backup funding source for a first transaction type or a second backup funding source for a second transaction type). Additionally, the card system 102 can also adjust one or more proportions in response to replacing a rejected funding source with one or more backup funding sources.
In additional embodiments, the card system 102 provides a notification to an owner or managing user of the card in response to a funding failure with one or more options for selecting a backup funding source for the transaction. The card system 102 can determine one or more selected backups funding source based on a selection of the one or more backup funding sources by the user. The card system 102 can then continue processing the transaction utilizing the one or more selected backup funding sources. In response to determining that a card does not have a backup funding source in case of a failure, the card system 102 may alternatively reject the payment transaction.
In one or more embodiments, the card system 102 also determines whether one or more parameters of one or more funding sources in the transaction prevent the transaction from being processed as a multi-funding source transaction. For example, the card system 102 can determine that one or more payment accounts associated with the card do not have sufficient funds, have card controls preventing the one or more payment accounts from being used with the transaction, or otherwise cannot be used to process the transaction. The card system 102 may also determine that one or more backup funding sources do not allow for processing the transaction with multiple funding sources. Accordingly, in response to determining that one or more of the payment accounts is not compatible with a multi-funding source transaction, the card system 102 converts the payment transaction to a single funding source transaction and processes the transaction with a single payment account (e.g., with a primary/default account).
In one or more embodiments, the card system 102 generates one or more notifications that the payment transaction processed. In particular, as illustrated in
In additional embodiments, the card system 102 provides one or more messages to one or more client devices associated with the card identification number in connection with processing the payment transaction. For example, the card system 102 generates a payment completion message including transaction information for providing to a client device that initiated the payment transaction with the merchant system 400. To illustrate, the card system 102 provides a payment completion message including the transaction amount, a plurality of payment accounts used to fund the payment transaction, and separate payment amounts corresponding to the different payment accounts.
In one or more embodiments, the card system 102 generates a merchant identifier to indicate that the payment transaction is processed utilizing a card. For example, the card system 102 generates a separate merchant identifier that indicates that the card and the merchant system 400 were involved in processing the payment transaction. The card system 102 can store the merchant identifier with the payment transaction for easily identifying the merchant system and the card system in a transaction history for a payment account or for the card identification number. To illustrate, the card system 102 can generate the merchant identifier based on a name corresponding to the merchant system 400 and/or a name corresponding to the card system 102.
Although
As mentioned, the card system 102 provides tools for creating and configuring a card for use in multi-funding source transactions. Specifically, the card system 102 provides tools for linking a card to a plurality of payment accounts and setting proportions and other parameters for determining how to process payment transactions with the card.
According to one or more embodiments, as illustrated in
As illustrated in
According to one or more embodiments, the client device 500 also displays an account element 508 for adding new accounts to the card and a settings element 510 for configuring the card. In particular, in response to a selection of the account element 508, the client device 500 navigates to a new interface for adding one or more additional payment accounts to the card. To illustrate,
As mentioned,
For instance, in response to a selection of a card account option 512, the client device 500 displays elements for providing relevant information for adding a credit/debit card account. More specifically,
The client device 500 provides the entered information to the card system 102 to verify the payment account information and add the payment account to the card. For example, the client device 500 displays an add element 514 to verify payment account information, login information or other information entered via the client device 500. The client device 500 can communicate with a payment account provider system (e.g., based on the payment account provider system being integrated with the card system 102 an API provided by the card system 102) to verify the payment account information and add the payment account to the card. Additionally, in response to verifying and adding a payment account, the card system 102 links the payment account to the card by mapping the payment account information to a card identification number of the payment card.
To illustrate, the card system 102 can create and manage an API that exposes a plurality of interaction operations to third-party systems such as the payment account provider system. The payment account provider system can integrate with the card system 102 via the API to allow the card system 102 to access data associated with payment accounts. In one or more embodiments, the payment account provider system integrates with the card system 102 via the API in response to a request to establish a payment account associated with the card system 102 via the payment account provider system. Additionally, the card system 102 can utilize the integration of the payment account provider system via the API to notify the payment account provider system of a link to a card identification number, verify an account balance, access an account history, or other data or operations associated with a payment account.
In one or more embodiments, the percentage option 516 includes a dropdown menu from which a user can select one of a plurality of different percentages. To illustrate, the percentage option 516 displays percentages in specific increments, such as 1% increments, 5% increments, 10% increments, etc. Alternatively, the client device 500 displays an option for manually entering the percentage via numerical text in a text entry field. In response to a selection of a percentage for a payment account, the client device 500 displays the selected percentage.
Additionally, in some embodiments, the client device 500 utilizes a selection of one or more percentage options of one or more payment accounts to determine percentages associated with one or more additional payment accounts. For example, in response to a selection of a percentage for a first payment account and based on determining that two payment accounts are linked to a card, the client device 500 determines a percentage of a second payment account. More specifically, the client device 500 automatically determines the percentage for the second payment account by subtracting the percentage for the first payment account from 100%. In other embodiments, the client device 500 utilizes a selection of a percentage for each separate payment account. In some instances, the client device 500 provides a default percentage value of equal percentages for the plurality of payment accounts.
In additional embodiments, as mentioned, the client device 500 provides the fixed amount option 518 for setting a fixed amount for a payment account. In particular, entering a fixed amount for a particular payment amount indicates that the card system 102 determines a proportion for the payment account to fund a payment transaction up to the fixed amount. Accordingly, the card system 102 funds any remaining payment amounts for the payment transaction utilizing one or more other payment accounts. In some embodiments, the client device 500 displays an error in response to determining that entered percentages, fixed amounts, or other proportions do not allow for complete funding of payment transactions.
In one or more embodiments, although not shown, the card system 102 determines proportions according with one or more payment accounts linked to a card based on additional parameters. For example, the client device 500 can provide elements for entering various combinations of total payment amounts for payment accounts, time periods associated with particular proportions, merchants associated with particular proportions, account interest rates, account rewards, and/or other parameters that can affect proportions funded by the payment accounts. Additionally, the client device 500 can determine, based on user input, settings to fund a first fixed amount of multi-funding source transactions with a first set of proportions and a second set of proportions after reaching the first fixed amount (e.g., funding 100% of the first $200 in a month with a first payment account and then splitting additional amounts equally between a plurality of amounts after the first $200, or vice-versa). Accordingly, the client device 500 can provide tools for dynamically modifying the funding proportions of the payment accounts according to different scenarios of multi-funding source payment transactions.
In some instances, the client device 500 also provides an option for real-time determination of funding proportions of payment accounts for a card. For instance, the card system 102 can communicate with one or more systems (e.g., card networks or issuing systems) to determine interest rates or account rewards on a daily basis (or other incremental time period). The card system 102 can use the periodically updated information to determine the funding proportions for that day (or time period). The card system 102 can thus provide opportunities for real-time (or near real-time) dynamic proportion adjustments for processing payment transactions.
In one or more embodiments, the card system 102 provides notifications to owners of payment accounts based on changes made to the card. To illustrate, in response to generating a mapping between the card and a payment account, the card system 102 notifies an owner of the payment account (e.g., via a client device of the owner of the payment account). Additionally, the card system 102 can notify owners of payment accounts in response to other actions, such as changes to proportions assigned to the payment accounts linked to the card or allowed/disallowed recipients.
In further embodiments, the card system 102 provides customizability over when and how a card can be involved in payment transactions (or multi-funding source transactions). To illustrate, as shown in
As mentioned, the client device 500 provides options to select specific recipients for the card.
Furthermore, as illustrated in
Additionally, in response to a selection of the additional settings element 522 of
To illustrate, as shown in
Once the card system 102 has created a card and linked the card to a plurality of payment accounts in an account mapping with funding proportions (and additional parameters, if applicable), the card system 102 utilizes the account mapping to process multi-funding source transactions involving the card.
Additionally, as shown in
In one or more additional embodiments, the client device 600 also displays a payment completion message 610 in response to completion of the payment transaction. In particular, in response to receiving an indication of successful completion of the payment transaction from the card system 102, the client device 600 can display the payment completion message 610 including details associated with the payment transaction. For instance, the payment completion message 610 can include a total transaction amount associated with the payment transaction.
The payment completion message 610 can also include separate payment amounts charged to the payment accounts mapped to the card. To illustrate, the payment completion message 610 can include a first payment amount charged to a first payment account linked to the card and a second payment amount charged to a second payment account linked to the card. In one or more embodiments, the card system 102 processes the payment transaction based on proportions for the separate payment accounts as indicated with the account mapping for the card. In additional embodiments, the payment completion message 610 also includes other information, such as a recipient identifier (e.g., a recipient name), time data, location data, and/or a reason associated with the purchase.
Turning now to
As shown, the series of acts 700 includes an act 702 of receiving a request message for a multi-funding source transaction. For example, act 702 involves receiving, from a merchant system, a request message comprising a transaction amount and a card identification number associated with a multi-funding source transaction. Act 702 can involve receiving the request message based on a client device initiating the multi-funding source transaction with the merchant system utilizing a card associated with the card identification number.
Furthermore, the series of acts 700 includes an act 704 of determining payment accounts and proportions from an account mapping. For example, act 704 involves determining, from an account mapping for the card identification number in an account mapping database, a plurality of proportions corresponding to a plurality of payment accounts, the plurality of proportions comprising a first proportion corresponding to a first payment account and a second proportion corresponding to a second payment account.
Act 704 can involve determining that the account mapping for the card identification number links the card identification number to the first payment account and the second payment account. Act 704 can also involve determining the first proportion and the second proportion based on the account mapping and the transaction amount.
For example, act 704 can involve accessing, from a multi-funding source mapping database, the account mapping based on the card identification number. Act 704 can involve determining the first proportion based on the transaction amount and a first percentage corresponding to the first payment account in the account mapping. Act 704 can also involve determining the second proportion based on the transaction amount and a second percentage corresponding to the second payment account in the account mapping.
Act 704 can alternatively involve determining the first proportion as a fixed amount based on the account mapping. Act 704 can also involve determining the second proportion based on a difference between the fixed amount and the transaction amount.
Act 704 can involve determining a plurality of attributes associated with the multi-funding source transaction and the merchant system. For example, act 704 can involve determining a plurality of attributes comprising a merchant type, a merchant location, or a transaction time associated with the multi-funding source transaction and the merchant system. Act 704 can involve determining a validity of the multi-funding source transaction for the card identification number based on the plurality of attributes. Act 704 can also involve determining the first proportion and the second proportion based on the plurality of attributes or based on the validity of the multi-funding source transaction.
The series of acts 700 also includes an act 706 of generating authorization messages for the payment accounts based on the proportions. For example, act 706 involves generating, based on the transaction amount, a first authorization message comprising an authorization request for the multi-funding source transaction against the first payment account according to the first proportion. Additionally, act 706 involves generating, based on the transaction amount, a second authorization message comprising an authorization request for the multi-funding source transaction against the second payment account according to the second proportion.
Act 706 can involve generating the first authorization message in response to verifying an account balance associated with the first payment account. Additionally, act 706 can involve generating the first authorization message comprising a first amount based on the first proportion and a transaction identifier based on the card identification number and the merchant system. Act 706 can also involve generating the second authorization message in response to verifying an account balance associated with the second payment account. Act 706 can further involve generating the second authorization message comprising a second amount based on the second proportion and the transaction identifier based on the card identification number and the merchant system.
Act 706 can involve generating the first authorization message according to a first account type associated with the first payment account. Act 706 can also involve generating the second authorization message according to a second account type associated with the second payment account, the first account type being different from the second account type.
Additionally, the series of acts 700 includes an act 708 of processing the multi-funding source transaction via one or more payment networks. For example, act 708 involves processing the multi-funding source transaction by sending the first authorization message and the second authorization message to one or more payment networks. Act 708 can involve sending the first authorization message to a first payment account provider system and the second authorization message to a second payment account provider system. Act 708 can involve providing the first authorization message and the second authorization message to the one or more payment networks in parallel. Alternatively, act 708 can involve providing the first authorization message and the second authorization message to the one or more payment networks in sequence.
The series of acts 700 can also include generating the account mapping for the card identification number. For example, the series of acts 700 can include authenticating, via the one or more payment networks, the first payment account according to first account credentials associated with a first account type. The series of acts 700 can also include authenticating, via the one or more payment networks, the second payment account according to second account credentials associated with a second account type different from the first account type. Additionally, the series of acts 700 can include generating the account mapping for the card identification number in response to authenticating the first payment account and authenticating the second payment account.
The series of acts 700 can further include determining one or more account parameters associated with the first payment account or the second payment account. The series of acts 700 can also include linking the first payment account and the second payment account to the card identification number within the account mapping according to the one or more account parameters.
The series of acts 700 can also include generating, in response to processing the multi-funding source transaction, a transaction completion message comprising the transaction amount, a first payment amount corresponding to the first payment account, and a second payment amount corresponding to the second payment account. The series of acts 700 can further include sending the transaction completion message to one or more client devices associated with the card identification number. For example, the series of acts 700 can include sending a first transaction completion message to a client device that initiated the multi-funding source transaction. The series of acts 700 can also include sending a second transaction completion message to an additional client device associated with the first payment account or the second payment account.
In one or more embodiments, the series of acts 700 includes receiving, from an additional merchant, an additional request message comprising the card identification number associated with a payment transaction. The series of acts 700 can include determining a plurality of attributes associated with the payment transaction and the additional merchant system. The series of acts 700 can further include determining, based on the plurality of attributes, that the payment transaction does not qualify as a multi-funding source payment transaction. The series of acts 700 can include processing via the one or more payment networks, the payment transaction utilizing the first payment account.
The series of acts 700 can include updating, in response to a request, the account mapping to link a third payment account to the card identification number. The series of acts 700 can also include modifying transaction parameters associated with the account mapping based on the first payment account, the second payment account, and the third payment account.
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.
