# US 2021/0241240 A1 · Methods and systems for gateway load balancing > Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt - Number: US 2021/0241240 A1 - Document ID: US20210241240A1 - Status: Published application - Kind: A1 - Application number: 16/779,936 - Filed: 2020-02-03 - Published: 2021-08-05 - Earliest claimed: 2020-02-03 - Assignees: Shopify Inc. - Applicants: Shopify Inc. - Inventors: Andre LYVER; Richard BTAICHE - Web page: https://patentgrep.com/patent/US20210241240A1 ## CPC - G06Q 30/0272: Period of advertisement exposure - G06Q 20/02: involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] - G06Q 20/027: {involving a payment switch or gateway} - G06Q 20/202: {Interconnection or interaction of plural electronic cash registers [ECR] or to host computer, e.g. network details, transfer of information from host to ECR or from ECR to ECR} - G06Q 20/387: {Payment using discounts or coupons (relating to marketing G06Q30/02)} - G06Q 20/4016: {involving fraud or risk level assessment in transaction processing} - G06Q 20/405: {Establishing or using transaction specific rules} - G06Q 30/06: Buying, selling or leasing transactions - H04L 47/125: by balancing the load, e.g. traffic engineering - H04L 47/25: with rate being modified by the source upon detecting a change of network conditions - H04L 67/101: based on network conditions - H04L 67/1029: using data related to the state of servers by a load balancer - G06Q 20/12: specially adapted for electronic shopping systems - G06Q 20/306: {using TV related infrastructures (external card used for payment with client device H04N21/4185)} - H04L 47/122: by diverting traffic away from congested entities - H04N 21/2542: {for selling goods, e.g. TV shopping (payment schemes, payment architectures or payment protocols for electronic shopping systems G06Q20/12)} - H04N 21/47815: {Electronic shopping (payment schemes, payment architectures or payment protocols for electronic shopping systems G06Q20/12)} - 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 - H04L: TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION (arrangements common to telegraphic and telephonic communication H04M) - H04N: PICTORIAL COMMUNICATION, e.g. TELEVISION ## Abstract Methods and systems for load balancing of payment requests among payment gateways by an e-commerce platform. The method may include detecting an anticipated load event and identifying a first payment gateway to be impacted by the anticipated load event, wherein a merchant account is associated with the first payment gateway. The platform may then identify, based on merchant parameters associated with the merchant account, a second payment gateway and, during the anticipated load event, transmit at least some payment requests first to the second payment gateway instead of to the first payment gateway. ## Claims ### Claim 1 A computer-implemented method of load balancing payment requests among payment gateways, the method comprising: determining, based on a projected number of payment requests expected to be received, an anticipated load event; identifying a first payment gateway to be impacted by the anticipated load event, wherein a merchant account is associated with the first payment gateway; identifying, based on merchant parameters associated with the merchant account, a second payment gateway; and during the anticipated load event, transmitting at least some payment requests to the second payment gateway instead of to the first payment gateway. ### Claim 2 (depends on 1) The computer-implemented method of claim 1, wherein determining the anticipated load event includes determining that the projected number of payment requests expected is likely to exceed a threshold level based on a count of active sessions associated with the merchant account. ### Claim 3 (depends on 1) The computer-implemented method of claim 1, wherein determining the anticipated load event includes determining that the projected number of payment requests expected is likely to exceed a threshold level based on a count of active shopping carts associated with the merchant account. ### Claim 4 (depends on 1) The computer-implemented method of claim 1, wherein determining the anticipated load event includes determining that the projected number of payment requests expected is likely to exceed a threshold level based on a count of product items in active shopping carts associated with the merchant account. ### Claim 5 (depends on 1) The computer-implemented method of claim 1, wherein determining the anticipated load event includes determining from an external data source that the projected number of payment requests expected is likely to exceed a threshold level. ### Claim 6 (depends on 5) The computer-implemented method of claim 5, wherein the external data source includes one of information regarding an advertising campaign launch with respect to the merchant account, information regarding an endorsement announcement with respect to the merchant account, information regarding a seasonal event, or information regarding a load event with respect to another merchant account. ### Claim 7 (depends on 1) The computer-implemented method of claim 1, wherein determining the anticipated load event includes determining that the anticipated load event relates to the merchant account, and wherein identifying the first payment gateway includes determining that the merchant account is associated with the first payment gateway. ### Claim 8 (depends on 1) The computer-implemented method of claim 1, wherein identifying the first payment gateway to be impacted by the anticipated load event includes monitoring a health status of the first payment gateway and determining from the health status of the first payment gateway and the anticipated load event that the first payment gateway is incapable of processing the anticipated load event. ### Claim 9 (depends on 8) The computer-implemented method of claim 8, wherein monitoring the health status includes determining a current capacity for the first payment gateway, and wherein determining that the first payment gateway is incapable of processing the anticipated load event includes determining that the projected number of payment requests exceeds the current capacity. ### Claim 10 (depends on 1) The computer-implemented method of claim 1, wherein identifying the second payment gateway includes retrieving the merchant parameters associated with the merchant account from memory and determining that the second payment gateway is designated as an alternative payment gateway in the merchant parameters. ### Claim 11 (depends on 1) The computer-implemented method of claim 1, wherein identifying the second payment gateway includes: determining from the merchant parameters that the merchant account does not have a selected alternative gateway; sending a merchant device associated with the merchant account a message to select an alternative gateway for the anticipated load event; and receiving a response message selecting the second payment gateway. ### Claim 12 (depends on 11) The computer-implemented method of claim 11, further comprising identifying, from among a plurality of payment gateways, a recommended gateway for the anticipated load event, wherein the message includes the recommended gateway, and wherein the response message includes confirmation of selection of the recommended gateway as the second payment gateway. ### Claim 13 A system for load balancing payment requests among payment gateways, the system comprising: a processor; and a memory storing computer-executable instructions that, when executed by the processor, are to cause the processor to: determine, based on a projected number of payment requests expected to be received, an anticipated load event; identify a first payment gateway to be impacted by the anticipated load event, wherein a merchant account is associated with the first payment gateway; identify, based on merchant parameters associated with the merchant account, a second payment gateway; and during the anticipated load event, transmit at least some payment requests first to the second payment gateway instead of to the first payment gateway. ### Claim 14 (depends on 13) The system of claim 13, wherein the instructions, when executed, are to cause the processor to determine the anticipated load event by determining that the projected number of payment requests expected is likely to exceed a threshold level based on a count of active sessions associated with the merchant account. ### Claim 15 (depends on 13) The system of claim 13, wherein the instructions, when executed, are to cause the processor to determine the anticipated load event by determining that the projected number of payment requests expected is likely to exceed a threshold level based on a count of active shopping carts associated with the merchant account. ### Claim 16 (depends on 13) The system of claim 13, wherein the instructions, when executed, are to cause the processor to determine the anticipated load event by determining that the projected number of payment requests expected is likely to exceed a threshold level based on a count of product items in active shopping carts associated with the merchant account. ### Claim 17 (depends on 13) The system of claim 13, wherein the instructions, when executed, are to cause the processor to determine the anticipated load event determining from an external data source that the projected number of payment requests expected is likely to exceed a threshold level. ### Claim 18 (depends on 17) The system of claim 17, wherein the external data source includes one of information regarding an advertising campaign launch with respect to the merchant account, information regarding an endorsement announcement with respect to the merchant account, information regarding a seasonal event, or information regarding a load event with respect to another merchant account. ### Claim 19 (depends on 13) The system of claim 13, wherein the instructions, when executed, are to cause the processor to determine the anticipated load event by determining that the anticipated load event relates to the merchant account, and wherein the instructions, when executed, are to cause the processor to identify the first payment gateway by determining that the merchant account is associated with the first payment gateway. ### Claim 20 (depends on 13) The system of claim 13, wherein the instructions, when executed, are to cause the processor to identify the first payment gateway to be impacted by the anticipated load event by monitoring a health status of the first payment gateway and determining from the health status of the first payment gateway and the anticipated load event that the first payment gateway is incapable of processing the anticipated load event. ### Claim 21 (depends on 20) The system of claim 20, wherein monitoring the health status includes determining a current capacity for the first payment gateway, and wherein determining that the first payment gateway is incapable of processing the anticipated load event includes determining that the projected number of payment requests exceeds the current capacity. ### Claim 22 (depends on 13) The system of claim 13, the instructions, when executed, are to cause the processor to identify the first payment gateway by retrieving the merchant parameters associated with the merchant account from memory and determining that the second payment gateway is designated as an alternative payment gateway in the merchant parameters. ### Claim 23 (depends on 13) The system of claim 13, the instructions, when executed, are to cause the processor to identify the second payment gateway by: determining from the merchant parameters that the merchant account does not have a selected alternative gateway; sending a merchant device associated with the merchant account a message to select an alternative gateway for the anticipated load event; and receiving a response message selecting the second payment gateway. ### Claim 24 (depends on 23) The system of claim 23, the instructions, when executed, are to further cause the processor to identify, from among a plurality of payment gateways, a recommended gateway for the anticipated load event, wherein the message includes the recommended gateway, and wherein the response message includes confirmation of selection of the recommended gateway as the second payment gateway. ### Claim 25 A non-transitory computer-readable medium storing processor-executable instructions for load balancing payment requests among payment gateways by an e-commerce platform, wherein the instructions, when executed by one or more processors, are to cause the one or more processors to: determine, based on a projected number of payment requests expected to be received, an anticipated load event; identify a first payment gateway to be impacted by the anticipated load event, wherein a merchant account is associated with the first payment gateway; identify, based on merchant parameters associated with the merchant account, a second payment gateway; and during the anticipated load event, transmit at least some payment requests first to the second payment gateway instead of to the first payment gateway. ### Claim 26 (depends on 1) The computer-implemented method claimed in claim 1, wherein the projected number of payment requests expected to be received comprise a predicted number of requests expected over a future time period.