# US 12,118,519 B2 · Intelligent payment routing and payment generation > Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt - Number: US 12,118,519 B2 - Document ID: US12118519B2 - Status: Granted - Kind: B2 - Application number: 16/761,882 - Filed: 2018-11-06 - Published: 2021-07-15 - Granted: 2024-10-15 - Earliest claimed: 2017-11-06 - Assignees: Connexpay LLC - Applicants: Connexpay LLC - Inventors: Robert James Kaufman; Jacob Benjamin Eisen; Robin Jean Butler; Timothy Michael Arthur Chalk - Web page: https://patentgrep.com/patent/US12118519B2 ## CPC - G06Q 20/027: {involving a payment switch or gateway} - G06Q 20/04: Payment circuits - G06Q 20/10: specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems - G06Q 20/12: specially adapted for electronic shopping systems - G06Q 20/227: {characterised in that multiple accounts are available, e.g. to the payer} - G06Q 20/3821: {Electronic credentials} - G06Q 20/3827: {Use of message hashing} - G06Q 20/3829: {involving key management} - G06Q 20/4016: {involving fraud or risk level assessment in transaction processing} - G06Q 20/405: {Establishing or using transaction specific rules} - G06Q 30/0226: Incentive systems for frequent usage, e.g. frequent flyer miles programs or point systems - G06Q: INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR ## Abstract Systems and methods for receiving customer payment details and generating outgoing payment details on-demand. A network-connected interface can receive customer payment details for payment of an incoming amount. A data store can store a plurality of transaction tracking records including a unique key code and an allocatable amount. A payment gateway can receive authorization data for payment of the incoming amount. An outgoing payment generator can respond to an outgoing payment request comprising an offered key code and an outgoing payment amount if the offered key code matches an existing transaction tracking record in the data store. Outgoing payment details can be generated if the outgoing amount is less than or equal to the allocatable amount. Embodiments can route the transaction such that the customer payment details are passed through to the supplier. Embodiments can make routing and generation decisions based on transaction preferences. ## Claims ### Claim 1 A system for providing on-demand outgoing payment details, the system comprising: a memory storing computer-readable instructions that when executed by a processor cause the processor to implement: a network-connected interface to receive customer payment details, associated with a first payment type, for payment of an incoming amount, wherein the incoming amount includes a combination amount of one or more purchase types; a data store configured to store: a plurality of transaction tracking records, each transaction tracking record comprising a unique key code and an allocatable amount; and a plurality of payment type profiles, each payment type profile associating a payment type with one or more payment attributes; a payment gateway, communicably coupled to a payment processor and configured to: request authorization data for payment of the incoming amount from the payment processor, store a transaction tracking record in the data store upon receipt of the authorization data, the allocatable amount of the transaction tracking record being initialized to a value less than or equal to the incoming amount, and the unique key code being initialized to a cryptographic hash value calculated based on the authorization data and a current date and time; an outgoing payment generator configured to: receive at least one outgoing payment request, associated with the one or more purchase types, comprising an offered key code and an outgoing amount; for each outgoing payment request having an offered key code matching a unique key code of an existing transaction tracking record in the data store, generate outgoing payment details, associated with at least a second payment type, wherein the second payment type is associated with one of a second brand, organization, or group alternative to the first payment type for purchase of an outgoing first purchase type and a third payment type, wherein the third payment type is associated with one of a third brand, organization, or group alternative to the first and second payment types for outgoing purchase of a second purchase type; and reduce the allocatable amount of the existing transaction tracking record by the outgoing amount if the outgoing amount is less than or equal to the allocatable amount, wherein the at least second and third payment types, selected between multiple payment types, is selected by a filter defined by a plurality of transaction preferences comprising one or more optimization goals associated with the one of the brands, organizations, or groups in compliance with the filter, wherein the filter selection maintains an outgoing percentage or currency amount distributed between the multiple payment types within a predetermined period of time, and wherein the filter selection dynamically updates expected fees based on historic fees to predict likely fee amounts for each payment type. ### Claim 2 (depends on 1) The system of claim 1, wherein the payment generation engine is configured to provide the outgoing payment details to a user. ### Claim 3 (depends on 1) The system of claim 1, wherein the payment details request further comprises identifying information for a supplier and wherein the payment generation engine is configured to provide the outgoing payment details to the supplier. ### Claim 4 (depends on 1) The system of claim 1, wherein the outgoing payment request comprises a supplier identifier and at least one or more a purchase types; wherein the data store is further configured to store a plurality of transaction preferences, each transaction preference defining one or more desired payment attributes based on at least one of: the outgoing amount, the supplier identifier, or the at least one or more purchase types. ### Claim 5 (depends on 4) The system of claim 4, wherein the outgoing payment generator is configured to generate the outgoing payment details by selecting an outgoing payment type based on the outgoing payment request, the plurality of transaction preferences, and the plurality of payment type profiles. ### Claim 6 (depends on 4) The system of claim 4, wherein each of the one or more payment attributes is selected from the group consisting of: a payment method, a brand, a loyalty program, an account number group, and an expected fee. ### Claim 7 (depends on 4) The system of claim 4, further comprising a transaction router configured to: bypass the payment processor and the outgoing payment generator and provide the customer payment details for payment of at least a portion of the outgoing amount based on the customer payment details, the plurality of transaction preferences, the plurality of payment type profiles, and the outgoing transaction information. ### Claim 8 (depends on 4) The system of claim 4, wherein the data store is configured to update the payment type profile for the payment type associated with the customer payment details based on one or more payment terms received from the payment processor. ### Claim 9 A method for providing on-demand outgoing payment details by a network-connected computing system, the method comprising: receiving, at network-connected interface, customer payment details, associated with a first payment type, for payment of an incoming amount; requesting authorization data for payment of the incoming amount from a payment processor, storing a transaction tracking record in a data store upon receipt of the authorization data, the transaction tracking record comprising a unique key code and an allocatable amount, the allocatable amount being initialized to a value less than or equal to the incoming amount, and the authorization data and a current date and time; storing a plurality of payment type profiles in the data store, each payment type profile associating a payment type with one or more payment attributes; and in response to receiving an outgoing payment request, associated with one or more purchase types, comprising an offered key code and an outgoing amount: verifying that the offered key code matches an existing key code of an existing transaction record in the data store and that the outgoing amount is less than or equal to the allocatable amount of the existing transaction record, and generating outgoing payment details for each purchase type, associated with at least a second payment type, alternative to the first payment type, wherein the third payment type is associated with one of a second brand, organization, or group for purchase of an outgoing first purchase type and a third payment type, wherein the third payment type is associated with one of a third brand, organization, or group alternative to the first and second payment types for outgoing purchase of a second purchase type; and reducing the allocatable amount of the existing transaction record by the outgoing amount, wherein the at least second and third payment types, selected between multiple payment types, is automatically selected by a filter defined by a plurality of transaction preferences comprising one or more optimization goals in compliance with the filter, wherein the filter selection maintains an outgoing percentage or currency amount distributed between the multiple payment types within a predetermined period of time, and wherein the filter selection dynamically updates expected fees based on historic fees to predict likely fee amounts for each payment type, and wherein each outgoing payment request is automatically processed and an outgoing payment generated for each outgoing payment without need for further user intervention. ### Claim 10 (depends on 9) The method of claim 9, further comprising providing the outgoing payment details to a user. ### Claim 11 (depends on 9) The method of claim 9, wherein the payment details request further comprises identifying information for a supplier; the method further comprising to providing the outgoing payment details to the supplier. ### Claim 12 (depends on 9) The method of claim 9, wherein the outgoing payment request comprises a supplier identifier and at least one or more purchase types; and the method further comprising storing a plurality of transaction preferences in the data store, each transaction preference defining one or more desired payment attributes based on at least one of: the outgoing amount, the supplier identifier, or the at least one or more purchase types. ### Claim 13 (depends on 12) The method of claim 12, wherein generating the outgoing payment details comprises selecting an outgoing payment type based on the outgoing payment request, the plurality of transaction preferences, and the plurality of payment type profiles. ### Claim 14 (depends on 12) The method claim 12, wherein each of the one or more payment attributes is selected from the group consisting of: a payment method, a brand, a loyalty program, an account number group, and an expected fee. ### Claim 15 (depends on 12) The method of claim 12, further comprising providing the customer payment details for a payment of at least a portion of the outgoing amount based on the customer payment details, the plurality of transaction preferences and the plurality of payment type profiles. ### Claim 16 (depends on 9) The method of claim 9, further comprising updating the payment type profile for the payment type associated with the customer payment details based on one or more payment terms received from the payment processor. ### Claim 17 (depends on 9) The method of claim 9, providing a fraud detection result based on the customer payment details and the incoming amount. ### Claim 18 A system for providing on-demand outgoing payment details, the system comprising: a memory storing computer-readable instructions that when executed by a processor cause the processor to implement: a network-connected interface to receive customer payment details associated with a first payment type for payment of an incoming amount, a data store configured to store: a plurality of transaction tracking records, each transaction tracking record comprising a unique key code and an allocatable amount, a plurality of payment type profiles, each payment type profile associating a payment type with one or more payment attributes, and a plurality of transaction preferences, each transaction preference defining one or more desired payment attributes based on at least one of: an outgoing amount, a supplier identifier, or a purchase type; a payment gateway, communicably coupled to a payment processor and configured to: request authorization data for payment of the incoming amount from the payment processor, store a transaction tracking record in the data store upon receipt of the authorization data, the allocatable amount of the transaction tracking record being initialized to a value less than or equal to the incoming amount; and the unique key code being initialized to a cryptographic hash value calculated based on the authorization data and a current date and time; an outgoing payment generator configured to: receive at least one outgoing payment request, associated with one or more purchase types, comprising an offered key code and an outgoing amount; and for each outgoing payment request having an offered key code matching an unique key code of an existing transaction tracking record in the data store, generate outgoing payment details, associated with at least a second payment type, alternative to the first payment type, wherein the second payment type is associated with one of a second brand, organization, or group alternative to the first payment type for purchase of an outgoing first purchase type and a third payment type, wherein the third payment type is associated with one of a third brand, organization, or group alternative to the first and second payment types for outgoing purchase of a second purchase type; and each payment type is automatically selected between multiple payment types by a filter defined by a plurality of transaction preferences comprising one or more optimization goals in compliance with the filter, wherein the filter selection maintains an outgoing percentage or currency amount distributed between the multiple payment types within a predetermined period of time, and wherein the filter selection dynamically updates expected fees based on historic fees to predict likely fee amounts for each payment type; and reduce the allocatable amount of the existing transaction tracking record by the outgoing amount if the outgoing amount is less than or equal to the allocatable amount, wherein each outgoing payment request is automatically processed and an outgoing payment generated for each outgoing payment without need for further user intervention; and a transaction router configured to: receive outgoing transaction information comprising at least one of identifying information for a supplier or at least one or more of the types of purchase; and bypass the payment processor and the outgoing payment generator and provide the customer payment details for payment of at least a portion of the outgoing amount based on the customer payment details, the plurality of transaction preferences, the plurality of payment type profiles, and the outgoing transaction information. ### Claim 19 (depends on 1) The system of claim 1, wherein the system is communicatively coupled to a data store that receives historical transaction data, which uses historic fees to predict the likely fee amounts for each payment type to further payment type decision making.