System, method, and computer program product for dynamic authorization response timeout

Abstract

Systems, methods, and computer program products can receive an authorization request associated with a transaction from a merchant system; transmit the authorization request to an issuer system and start a response timer associated with the transaction; in response to the response timer satisfying a predetermined response time amount without receiving an authorization response associated with the authorization request from the issuer system, determine an extended response time; and in response to receiving the authorization response from the issuer system before the response timer satisfies the sum of the extended response time amount and the predetermined response time amount, transmit the authorization response to the merchant system.

Description

Technical Field

[0001] The present disclosure relates to electronic payment networks and, in some non-limiting embodiments or aspects, to dynamic calculation of authorization response timeouts. Background Art

[0002] In a typical payment scenario, a card-based payment authorization may be routed by a payment network or transaction service provider system to an issuer system for an informed authorization decision. The issuer system may be expected to provide a response within a timeout threshold (e.g., typically 5 to 10 seconds, etc.). However, due to various issues, such as slow processing by the issuer host, network delays, etc., the payment network may not receive an authorization response within the timeout threshold. In this timeout scenario, the payment network may respond on behalf of the issuer system using predetermined settings or rules associated with the issuer system. For example, the ability to respond on behalf of the issuer system in such a timeout scenario may be referred to as Stand-In Processing (STIP). For example, a payment network or transaction service provider system may respond on behalf of the issuer system due to issuer instructions and / or processing errors (e.g., an incorrect transaction amount submitted by an acquirer, etc.).

[0003] A payment network or transaction service provider system that provides STIP functionality can monitor and ensure that each authorization request is responded to by the issuer within a set amount of time (e.g., within a timeout threshold, etc.), and if no response is received from the issuer system when the set amount of time expires, the payment network or transaction service provider system can respond on behalf of the issuer system. Summary of the invention

[0004] Thus, improved systems, apparatus, products, devices and / or methods for dynamic authorization response timeout are provided.

[0005] According to some non-limiting embodiments or aspects, a computer-implemented method is provided, comprising: receiving, using at least one processor, an authorization request associated with a transaction from a merchant system, wherein the authorization request includes transaction data associated with the transaction; transmitting, using the at least one processor, the authorization request to an issuer system; in response to transmitting the authorization request to the issuer system, starting, using the at least one processor, a response timer associated with the transaction; in response to the response timer satisfying a predetermined response time amount without receiving an authorization response associated with the authorization request from the issuer system, determining, using the at least one processor, an extended response time amount associated with the transaction by providing, as input to a machine learning model, transaction data associated with the transaction and historical transaction data associated with at least one historical transaction associated with the issuer system, and receiving the extended response time amount as an output from the machine learning model; and in response to receiving the authorization response from the issuer system before the response timer satisfies the sum of the extended response time amount and the predetermined response time amount, transmitting, using the at least one processor, the authorization response to the merchant system, wherein the authorization response includes one of authorizing the transaction and denying the transaction.

[0006] In some non-limiting embodiments or aspects, the method further includes: in response to the response timer satisfying the sum of the extended response time amount and the predetermined response time amount before receiving the authorization response from the issuer system, utilizing the at least one processor to perform an alternative processing operation by generating an alternative response based on the transaction data and at least one rule associated with the issuer system and transmitting the alternative response to the merchant system, wherein the alternative response includes one of authorizing the transaction and denying the transaction.

[0007] In some non-limiting embodiments or aspects, the method further includes, in response to receiving an authorization response associated with the authorization request from the issuer system before the response timer satisfies the predetermined response time amount, transmitting, using the at least one processor, the authorization response to the merchant system.

[0008] In some non-limiting embodiments or aspects, the transaction data includes at least one of the following parameters: the type of point of sale (POS) terminal associated with the merchant system; the type of merchant associated with the merchant system; the country associated with the merchant system; the country associated with the issuer system; a merchant category code (MCC); season; time of day; or any combination thereof.

[0009] In some non-limiting embodiments or aspects, the historical transaction data includes a processing time of at least one historical authorization request at the issuer system for the at least one historical transaction.

[0010] In some non-limiting embodiments or aspects, the method further comprises, prior to determining the amount of extended response time, verifying, with the at least one processor, that the issuer system is eligible for the extended response time.

[0011] In some non-limiting embodiments or aspects, the sum of the predetermined amount of response time and the extended amount of response time is less than a merchant timeout amount of time, and in response to expiration of the merchant timeout amount of time, the merchant system cancels the transaction.

[0012] According to some non-limiting embodiments or aspects, a system is provided, comprising: at least one processor programmed and / or configured to: receive an authorization request associated with a transaction from a merchant system, wherein the authorization request includes transaction data associated with the transaction; transmit the authorization request to an issuer system; in response to transmitting the authorization request to the issuer system, start a response timer associated with the transaction; in response to the response timer satisfying a predetermined response time amount without receiving an authorization response associated with the authorization request from the issuer system, determine an extended response time amount associated with the transaction by providing transaction data associated with the transaction and historical transaction data associated with at least one historical transaction associated with the issuer system as input to a machine learning model and receiving the extended response time amount as output from the machine learning model; and in response to receiving the authorization response from the issuer system before the response timer satisfies the sum of the extended response time amount and the predetermined response time amount, transmit the authorization response to the merchant system, wherein the authorization response includes one of authorizing the transaction and denying the transaction.

[0013] In some non-limiting embodiments or aspects, the at least one processor is further programmed and / or configured to: in response to the response timer satisfying the sum of the extended response time amount and the predetermined response time amount before receiving the authorization response from the issuer system, perform an alternative processing operation by generating an alternative response based on the transaction data and at least one rule associated with the issuer system and transmitting the alternative response to the merchant system, wherein the alternative response includes one of authorizing the transaction and denying the transaction.

[0014] In some non-limiting embodiments or aspects, the at least one processor is further programmed and / or configured to, in response to receiving an authorization response associated with the authorization request from the issuer system before the response timer satisfies the predetermined response time amount, transmit the authorization response to the merchant system.

[0015] In some non-limiting embodiments or aspects, the transaction data includes at least one of the following parameters: the type of point of sale (POS) terminal associated with the merchant system; the type of merchant associated with the merchant system; the country associated with the merchant system; the country associated with the issuer system; a merchant category code (MCC); season; time of day; or any combination thereof.

[0016] In some non-limiting embodiments or aspects, the historical transaction data includes a processing time of at least one historical authorization request at the issuer system for the at least one historical transaction.

[0017] In some non-limiting embodiments or aspects, the at least one processor is further programmed and / or configured to: verify that the issuer system is eligible for the extended response time before determining the extended response time amount.

[0018] In some non-limiting embodiments or aspects, the sum of the predetermined amount of response time and the extended amount of response time is less than a merchant timeout amount of time, and in response to expiration of the merchant timeout amount of time, the merchant system cancels the transaction.

[0019] According to some non-limiting embodiments or aspects, a computer program product is provided, comprising at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium comprising program instructions, which when executed by at least one processor causes the at least one processor to: receive an authorization request associated with a transaction from a merchant system, wherein the authorization request includes transaction data associated with the transaction; transmit the authorization request to an issuer system; in response to transmitting the authorization request to the issuer system, start a response timer associated with the transaction; in response to the response timer satisfying a predetermined response time amount without receiving an authorization response associated with the authorization request from the issuer system, determine an extended response time amount associated with the transaction by providing transaction data associated with the transaction and historical transaction data associated with at least one historical transaction associated with the issuer system as input to a machine learning model and receiving the extended response time amount as output from the machine learning model; and in response to receiving the authorization response from the issuer system before the response timer satisfies the sum of the extended response time amount and the predetermined response time amount, transmit the authorization response to the merchant system, wherein the authorization response includes one of authorizing the transaction and denying the transaction.

[0020] In some non-limiting embodiments or aspects, the program instructions, when executed by the at least one processor, further cause the at least one processor to perform the following operations: in response to the response timer satisfying the sum of the extended response time amount and the predetermined response time amount before receiving the authorization response from the issuer system, perform an alternative processing operation by generating an alternative response based on the transaction data and at least one rule associated with the issuer system and transmitting the alternative response to the merchant system, wherein the alternative response includes one of authorizing the transaction and denying the transaction.

[0021] In some non-limiting embodiments or aspects, the program instructions, when executed by the at least one processor, further cause the at least one processor to perform the following operations: in response to receiving an authorization response associated with the authorization request from the issuer system before the response timer satisfies the predetermined response time amount, transmitting the authorization response to the merchant system.

[0022] In some non-limiting embodiments or aspects, the transaction data includes at least one of the following parameters: the type of point of sale (POS) terminal associated with the merchant system; the type of merchant associated with the merchant system; the country associated with the merchant system; the country associated with the issuer system; a merchant category code (MCC); season; time of day; or any combination thereof.

[0023] In some non-limiting embodiments or aspects, the historical transaction data includes a processing time of at least one historical authorization request at the issuer system for the at least one historical transaction.

[0024] In some non-limiting embodiments or aspects, the sum of the predetermined amount of response time and the extended amount of response time is less than a merchant timeout amount of time, and in response to expiration of the merchant timeout amount of time, the merchant system cancels the transaction.

[0025] Additional non-limiting embodiments or aspects are set forth in the following numbered clauses:

[0026] Clause 1. A computer-implemented method comprising: receiving, using at least one processor, an authorization request associated with a transaction from a merchant system, wherein the authorization request includes transaction data associated with the transaction; transmitting, using the at least one processor, the authorization request to an issuer system; in response to transmitting the authorization request to the issuer system, starting, using the at least one processor, a response timer associated with the transaction; in response to the response timer satisfying a predetermined response time amount without receiving an authorization response associated with the authorization request from the issuer system, determining, using the at least one processor, an extended response time amount associated with the transaction by providing, as input to a machine learning model, transaction data associated with the transaction and historical transaction data associated with at least one historical transaction associated with the issuer system, and receiving the extended response time amount as an output from the machine learning model; and in response to receiving the authorization response from the issuer system before the response timer satisfies the sum of the extended response time amount and the predetermined response time amount, transmitting, using the at least one processor, the authorization response to the merchant system, wherein the authorization response includes one of authorizing the transaction and denying the transaction.

[0027] Clause 2. The computer-implemented method according to Clause 1 further includes: in response to the response timer satisfying the sum of the extended response time amount and the predetermined response time amount before receiving the authorization response from the issuer system, utilizing the at least one processor to perform an alternative processing operation by generating an alternative response based on the transaction data and at least one rule associated with the issuer system and transmitting the alternative response to the merchant system, wherein the alternative response includes one of authorizing the transaction and rejecting the transaction.

[0028] Clause 3. The computer-implemented method according to Clause 1 or 2 further includes: in response to receiving an authorization response associated with the authorization request from the issuer system before the response timer satisfies the predetermined response time amount, transmitting the authorization response to the merchant system using the at least one processor.

[0029] Clause 4. A computer-implemented method according to any of Clauses 1-3, wherein the transaction data includes at least one of the following parameters: the type of point of sale (POS) terminal associated with the merchant system; the type of merchant associated with the merchant system; the country associated with the merchant system; the country associated with the issuer system; a merchant category code (MCC); season; time of day; or any combination thereof.

[0030] Clause 5. The computer-implemented method of any of Clauses 1-4, wherein the historical transaction data comprises a processing time of at least one historical authorization request at the issuer system for the at least one historical transaction.

[0031] Clause 6. The computer-implemented method of any of Clauses 1-5, further comprising: verifying, with the at least one processor, that the issuer system is eligible for the extended response time before determining the amount of extended response time.

[0032] Clause 7. A computer-implemented method according to any of clauses 1-6, wherein the sum of the predetermined amount of response time and the extended amount of response time is less than a merchant timeout amount of time, and in response to expiration of the merchant timeout amount of time, the merchant system cancels the transaction.

[0033] Clause 8. A system comprising: at least one processor programmed and / or configured to: receive an authorization request associated with a transaction from a merchant system, wherein the authorization request includes transaction data associated with the transaction; transmit the authorization request to an issuer system; in response to transmitting the authorization request to the issuer system, start a response timer associated with the transaction; in response to the response timer satisfying a predetermined response time amount without receiving an authorization response associated with the authorization request from the issuer system, determine an extended response time amount associated with the transaction by providing transaction data associated with the transaction and historical transaction data associated with at least one historical transaction associated with the issuer system as input to a machine learning model and receiving the extended response time amount as output from the machine learning model; and in response to receiving the authorization response from the issuer system before the response timer satisfies the sum of the extended response time amount and the predetermined response time amount, transmit the authorization response to the merchant system, wherein the authorization response includes one of authorizing the transaction and denying the transaction.

[0034] Clause 9. A system according to clause 8, wherein the at least one processor is further programmed and / or configured to: in response to the response timer satisfying the sum of the extended response time amount and the predetermined response time amount before receiving the authorization response from the issuer system, perform an alternative processing operation by generating an alternative response based on the transaction data and at least one rule associated with the issuer system and transmitting the alternative response to the merchant system, wherein the alternative response includes one of authorizing the transaction and rejecting the transaction.

[0035] Clause 10. A system according to clause 8 or 9, wherein the at least one processor is further programmed and / or configured to: in response to receiving an authorization response associated with the authorization request from the issuer system before the response timer satisfies the predetermined response time amount, transmit the authorization response to the merchant system.

[0036] Clause 11. A system according to any of clauses 8-10, wherein the transaction data includes at least one of the following parameters: the type of point of sale (POS) terminal associated with the merchant system; the type of merchant associated with the merchant system; the country associated with the merchant system; the country associated with the issuer system; a merchant category code (MCC); season; time of day; or any combination thereof.

[0037] Clause 12. The system of any of Clauses 8-11, wherein the historical transaction data comprises a processing time of at least one historical authorization request at the issuer system for the at least one historical transaction.

[0038] Clause 13. The system of any of clauses 8-12, wherein the at least one processor is further programmed and / or configured to: verify that the issuer system is eligible for the extended response time before determining the amount of extended response time.

[0039] Clause 14. The system of any one of clauses 8-13, wherein the sum of the predetermined amount of response time and the extended amount of response time is less than a merchant timeout amount of time, and in response to expiration of the merchant timeout amount of time, the merchant system cancels the transaction.

[0040] Clause 15. A computer program product comprising at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium comprising program instructions that, when executed by at least one processor, cause the at least one processor to: receive an authorization request associated with a transaction from a merchant system, wherein the authorization request includes transaction data associated with the transaction; transmit the authorization request to an issuer system; in response to transmitting the authorization request to the issuer system, start a response timer associated with the transaction; in response to the response timer satisfying a predetermined response time amount without receiving an authorization response associated with the authorization request from the issuer system, determine an extended response time amount associated with the transaction by providing transaction data associated with the transaction and historical transaction data associated with at least one historical transaction associated with the issuer system as input to a machine learning model and receiving the extended response time amount as output from the machine learning model; and in response to receiving the authorization response from the issuer system before the response timer satisfies the sum of the extended response time amount and the predetermined response time amount, transmit the authorization response to the merchant system, wherein the authorization response includes one of authorizing the transaction and denying the transaction.

[0041] Clause 16. A computer program product according to clause 15, wherein the program instructions, when executed by the at least one processor, further cause the at least one processor to perform the following operations: in response to the response timer satisfying the sum of the extended response time amount and the predetermined response time amount before receiving the authorization response from the issuer system, performing an alternative processing operation by generating an alternative response based on the transaction data and at least one rule associated with the issuer system and transmitting the alternative response to the merchant system, wherein the alternative response includes one of authorizing the transaction and denying the transaction.

[0042] Clause 17. A computer program product according to clause 15 or 16, wherein the program instructions, when executed by the at least one processor, further cause the at least one processor to perform the following operations: in response to receiving an authorization response associated with the authorization request from the issuer system before the response timer satisfies the predetermined response time amount, transmitting the authorization response to the merchant system.

[0043] Clause 18. A computer program product according to any of Clauses 15-17, wherein the transaction data includes at least one of the following parameters: the type of point of sale (POS) terminal associated with the merchant system; the type of merchant associated with the merchant system; the country associated with the merchant system; the country associated with the issuer system; a merchant category code (MCC); season; time of day; or any combination thereof.

[0044] Clause 19. The computer program product of any of Clauses 15-18, wherein the historical transaction data comprises a processing time of at least one historical authorization request at the issuer system for the at least one historical transaction.

[0045] Clause 20. A computer program product according to any of clauses 15-19, wherein the sum of the predetermined amount of response time and the extended amount of response time is less than a merchant timeout amount of time, and in response to expiration of the merchant timeout amount of time, the merchant system cancels the transaction.

[0046] These and other features and characteristics of the present disclosure, as well as methods of operation and functions of combinations of related structural elements and parts and economies of manufacture, will become more apparent when considering the following description and the appended claims with reference to the accompanying drawings, all of which form a part of this specification, wherein like reference numerals indicate corresponding parts in the various figures. However, it is to be expressly understood that the figures are for illustration and description purposes only and are not intended as definitions of limitations. Unless the context clearly dictates otherwise, as used in this specification and claims, the singular forms "a", "an", and "the" include plural referents. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Additional advantages and details are explained in more detail below with reference to exemplary embodiments shown in the schematic drawings, in which:

[0048] Figure 1 are diagrams of non-limiting embodiments or aspects of environments in which the systems, apparatus, products, devices, and / or methods described herein may be implemented;

[0049] Figure 2 yes Figure 1diagrams of non-limiting embodiments or aspects of one or more devices and / or components of one or more systems;

[0050] Figure 3 is a flow chart of a non-limiting embodiment or aspect of a process for dynamic authorization response timeout;

[0051] Figure 4 is a flowchart of an implementation of a non-limiting embodiment or aspect of a process for dynamic authorization response timeout; and

[0052] Figure 5 is a graph illustrating example authorization response times for an example issuer system for an example transaction. DETAILED DESCRIPTION

[0053] It should be understood that, except where expressly specified to the contrary, the present disclosure may employ various alternative variations and step sequences. It should also be understood that the specific devices and processes shown in the accompanying drawings and described in the following specification are merely exemplary and non-limiting embodiments or aspects. Therefore, specific dimensions and other physical characteristics associated with the embodiments or aspects disclosed herein should not be considered limiting.

[0054] Aspects, components, elements, structures, actions, steps, functions, instructions, etc. used herein should not be understood as critical or necessary unless explicitly described as such. Also, as used herein, the articles "a" and "an" are intended to include one or more items, and can be used interchangeably with "one or more" and "at least one". In addition, as used herein, the term "group" is intended to include one or more items (e.g., related items, unrelated items, combinations of related items and unrelated items, etc.), and can be used interchangeably with "one or more" or "at least one". In the case of wishing to have only one item, the term "one" or similar language is used. Also, as used herein, the term "having" etc. is intended to be an open term. In addition, unless otherwise explicitly stated, the phrase "based on" is intended to mean "based at least in part on".

[0055] As used herein, the term "communication" may refer to the reception, acceptance, transmission, transmission, provision, etc. of data (e.g., information, signals, messages, instructions, commands, etc.). A unit (e.g., a device, a system, a component of a device or system, a combination thereof, and / or the like) communicating with another unit means that the unit is able to directly or indirectly receive information from the other unit and / or send information to the other unit. This may refer to a direct or indirect connection (e.g., a direct communication connection, an indirect communication connection, and / or the like) that is wired and / or wireless in nature. In addition, although the information sent may be modified, processed, relayed, and / or routed between the first unit and the second unit, the two units may also communicate with each other. For example, even if the first unit passively receives information and does not actively send information to the second unit, the first unit may communicate with the second unit. As another example, if at least one intermediate unit processes the information received from the first unit and transmits the processed information to the second unit, the first unit may communicate with the second unit.

[0056] Obviously, the systems and / or methods described herein can be implemented in different forms of hardware, software, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods does not limit the implementation. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it should be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0057] As used herein, the term "transaction service provider" may refer to an entity that receives transaction authorization requests from merchants or other entities and, in some cases, provides payment assurance through an agreement between the transaction service provider and the issuer organization. For example, a transaction service provider may include, for example , or any other entity that processes transactions. The term "transaction processing system" may refer to one or more computing devices operated by or on behalf of a transaction service provider, such as a transaction processing server that executes one or more software applications. A transaction processing system may include one or more processors and, in some non-limiting embodiments, may be operated by or on behalf of a transaction service provider.

[0058] As used herein, the term "account identifier" may include one or more primary account numbers (PANs), tokens, or other identifiers associated with a customer account. The term "token" may refer to an identifier used as a replacement or substitute identifier for an original account identifier such as a PAN. An account identifier may be alphanumeric, or any combination of characters and / or symbols. A token may be associated with a PAN or other original account identifier in one or more data structures (e.g., one or more databases, etc.) such that the token can be used to conduct transactions without directly using the original account identifier. In some instances, an original account identifier such as a PAN may be associated with multiple tokens for different individuals or purposes.

[0059] As used herein, the terms "issuer institution", "portable financial device issuer", "issuer" or "issuer bank" may refer to one or more entities that provide one or more accounts to a user (e.g., a customer, consumer, organization, etc.) to conduct a transaction (e.g., a payment transaction), such as initiating a credit card payment transaction and / or a debit card payment transaction. For example, an issuer institution may provide an account identifier such as a PAN to a user that uniquely identifies one or more accounts associated with the user. The account identifier may be embodied on a portable financial device such as a physical financial instrument (e.g., a payment card), and / or may be electronic and used for electronic payments. In some non-limiting embodiments or aspects, an issuer institution may be associated with a bank identification number (BIN) that uniquely identifies the issuer institution. As used herein, an "issuer institution system" may refer to one or more computer systems operated by or on behalf of an issuer institution, such as a server computer that executes one or more software applications. For example, an issuer institution system may include one or more authorization servers for authorizing payment transactions.

[0060] As used herein, the term "merchant" may refer to an individual or entity that provides goods and / or services or the right to use goods and / or services to a user (e.g., a customer) based on a transaction (e.g., a payment transaction). As used herein, the term "merchant" or "merchant system" may also refer to one or more computer systems, computing devices, and / or software applications operated by or on behalf of a merchant, such as a server computer that executes one or more software applications. As used herein, a "point of sale (POS) system" may refer to one or more computers and / or peripheral devices used by a merchant to conduct payment transactions with a user, including one or more card readers, near field communication (NFC) receivers, radio frequency identification (RFID) receivers, and / or other contactless transceivers or receivers, contact-based receivers, payment terminals, computers, servers, input devices, and / or other similar devices that can be used to initiate payment transactions. A POS system may be part of a merchant system. A merchant system may also include a merchant plug-in for facilitating online Internet-based transactions through a merchant webpage or software application. A merchant plug-in may include software that runs on a merchant server or is hosted by a third party to facilitate such online transactions.

[0061] As used herein, the term "mobile device" may refer to one or more portable electronic devices configured to communicate with one or more networks. As an example, a mobile device may include a cellular phone (e.g., a smart phone or a standard cellular phone), a portable computer (e.g., a tablet computer, a laptop computer, etc.), a wearable device (e.g., a watch, glasses, lenses, clothing, etc.), a personal digital assistant (PDA), and / or other similar devices. As used herein, the terms "client device" and "user device" refer to any electronic device configured to communicate with one or more servers or remote devices and / or systems. Client devices or user devices may include mobile devices, network-enabled devices (e.g., network-enabled TVs, refrigerators, thermostats, etc.), computers, POS systems, and / or any other devices or systems capable of communicating with a network.

[0062] As used herein, the term "computing device" may refer to one or more electronic devices configured to process data. In some examples, a computing device may include the necessary components to receive, process, and output data, such as a processor, a display, a memory, an input device, a network interface, etc. The computing device may be a mobile device. For example, a mobile device may include a cellular phone (e.g., a smart phone or a standard cellular phone), a portable computer, a wearable device (e.g., a watch, glasses, lenses, clothing, and / or the like), a PDA, and / or other similar devices. A computing device may also be a desktop computer or other form of non-mobile computer.

[0063] As used herein, the terms "electronic wallet" and "electronic wallet application" refer to one or more electronic devices and / or software applications configured to initiate and / or conduct payment transactions. For example, an electronic wallet may include a mobile device executing an electronic wallet application, and may also include server-side software and / or databases for maintaining and providing transaction data to the mobile device. An "electronic wallet provider" may include an entity that provides and / or maintains electronic wallets for customers, such as Google Android Apple Samsung And / or other similar electronic payment systems. In some non-limiting examples, the issuing bank may be an electronic wallet provider.

[0064] As used herein, the term "payment device" may refer to a portable financial device, an electronic payment device, a payment card (e.g., a credit or debit card), a gift card, a smart card, smart media, a payroll card, a healthcare card, a wristband, a machine-readable medium containing account information, a key chain device or pendant, an RFID transponder, a retailer discount or membership card, a cellular phone, an electronic wallet mobile application, a PDA, a pager, a security card, a computer, an access card, a wireless terminal, a transponder, etc. In some non-limiting embodiments or aspects, a payment device may include volatile or non-volatile memory to store information (e.g., an account identifier, an account holder's name, etc.).

[0065] As used herein, the terms "server" and / or "processor" may refer to or include one or more computing devices that are operated by or facilitate communication and processing by multiple parties in a network environment such as the Internet, but it should be understood that communication may be facilitated through one or more public or private network environments, and that there may be various other arrangements. In addition, multiple computing devices (e.g., servers, POS devices, mobile devices, etc.) that communicate directly or indirectly in a network environment may constitute a "system." As used herein, references to "server" or "processor" may refer to previously described servers and / or processors, different servers and / or processors, and / or combinations of servers and / or processors that are stated to implement previous steps or functions. For example, as used in the specification and claims, a first server and / or first processor stated to implement a first step or function may refer to the same or different servers and / or processors stated to implement a second step or function.

[0066] As used herein, the term "acquirer" may refer to an entity that is licensed by a transaction service provider and / or approved by a transaction service provider to initiate a transaction using a portable financial device of a transaction service provider. An acquirer may also refer to one or more computer systems operated by or on behalf of an acquirer, such as a server computer (e.g., "acquirer server") that executes one or more software applications. An "acquirer" may be a merchant bank, or in some cases, a merchant system may be an acquirer. The transaction may include an original credit transaction (OCT) and an account funds transaction (AFT). The transaction service provider may authorize an acquirer to sign a merchant of the service provider to initiate a transaction using a portable financial device of a transaction service provider. The acquirer may sign a contract with a payment service provider to enable the service provider to sponsor a merchant. The acquirer may monitor the compliance of the payment service provider according to the regulations of the transaction service provider. The acquirer may perform due diligence on the payment service provider and ensure that appropriate due diligence is performed before signing a sponsored merchant. The acquirer may be responsible for all transaction service provider programs they operate or sponsor. The acquirer may be responsible for the behavior of its payment service provider and the merchant sponsored by it or its payment service provider.

[0067] As used herein, the term "payment gateway" may refer to an entity and / or a payment processing system operated by or on behalf of such an entity, wherein the entity (e.g., a merchant service provider, a payment service provider, a payment facilitator, a payment facilitator contracted with an acquirer, a payment aggregator, etc.) provides payment services (e.g., a transaction service provider payment service, a payment processing service, etc.) to one or more merchants. The payment service may be associated with the use of a portable financial device managed by a transaction service provider. As used herein, the term "payment gateway system" may refer to one or more computer systems, computer devices, servers, server groups, etc. operated by or on behalf of a payment gateway.

[0068] As used herein, the term "application programming interface" (API) may refer to computer code that allows communication between different systems or (hardware and / or software) system components. For example, an API may include function calls, functions, subroutines, communication protocols, fields, etc. that can be used and / or accessed by other systems or other (hardware and / or software) system components.

[0069] As used herein, the term "user interface" or "graphical user interface" refers to a generated display, such as one or more graphical user interfaces (GUIs), with which a user can interact directly or indirectly (e.g., via keyboard, mouse, touch screen, etc.).

[0070] As previously described, the payment network or transaction service provider system providing a STIP capability can monitor and ensure that each authorization request is responded to by the issuer within a set amount of time (e.g., within a timeout threshold, etc.), and if no response is received from the issuer system when the set amount of time expires, the payment network or transaction service provider system can respond on behalf of the issuer system (e.g., generate an authorization response on behalf of the issuer system and provide it to the merchant system, etc.). Table 1 below shows an example maximum timeout threshold for the issuer system to respond to authorization requests for different regions and different transaction types.

[0071]

[0072] Table 1

[0073] Since the communication for processing transactions requires a limited amount of time to propagate from the transaction service provider system to the acquirer system (and back to the merchant system), the acquirer system and / or the merchant system may typically wait for a longer period of time than the transaction processing system before timing out to account for network propagation time. In addition, due to the variability of the STIP timeout threshold in different regions, the acquirer system and / or the merchant system may typically wait for a maximum value across each region. Although there may be no standard, for responses from the transaction service provider system, the acquirer system may typically wait for a timeout period of 25 seconds or longer at the POS terminal or a timeout period of 35 seconds or longer at the ATM terminal. If no response is received (e.g., due to network congestion between the transaction service provider system and the acquirer system, etc.), the merchant system may request an alternative form of payment and / or cancel the transaction. For example, a merchant system or terminal may use a timeout of 120 seconds (e.g., for local integration, etc.) or a timeout of 150 seconds (e.g., for cloud integration, etc.).

[0074] The parameter definitions provided in Table 2 below are referred to below for determining the transmission time and processing time associated with the authorization request and the authorization response.

[0075]

[0076] Table 2

[0077] Let t 0 is equal to the time when the authorization request is initiated at the merchant system or terminal, and t R = is equal to the time it takes for the merchant system or terminal to receive the authorization response. In a normal processing scenario (e.g., where an authorization response is received from the issuer system, etc.), the total transmission and processing time of the transaction is t R –t 0 It can be defined according to the following formula (1):

[0078] tR –t 0 =t MA +t A +t AV +t V +t VI +t I +t VI +t V +t AV +t A +t MA (1)

[0079] For example, the total transmission and processing time of a transaction is t R –t 0 It can be equal to (transmission time of authorization request from merchant system to acquirer system) + (processing time of authorization request at acquirer system) + (transmission time of authorization request from acquirer system to transaction service provider (TSP) system) + (processing time of authorization request at TSP system) + (transmission time of authorization request from TSP system to issuer system) + (processing time of authorization request at issuer system) + (transmission time of authorization response from issuer system to TSP system) + (processing time of authorization response at TSP system) + (transmission time of authorization response from TSP system to acquirer system) + (processing time of authorization response at acquirer system) + (transmission time from acquirer system to merchant system or terminal). For example, formula (1) can be rewritten as the following formula (2):

[0080] t R –t 0 =2t MA +2t A +2t AV +2t V +2t VI +t I (2)

[0081] Some benchmarks indicate that a typical chip card transaction (e.g., EMV chip card transactions, etc.) takes two seconds to make a round trip. Other benchmarks place the average time somewhere between eight and thirteen seconds; however, it is worth noting that processing times have improved significantly since the benchmarks were performed. Therefore, assuming that the total transmission and processing time for the transaction is t R –t 0 is about ten seconds, then formula (2) can be rewritten as the following formula (3):

[0082] 10≈2t MA +2t A +2t AV +2t V +2t VI +tI (3)

[0083] Therefore, assuming t VI and t I is zero or close to zero, then formula (3) can be rewritten as the following formula (4):

[0084] 10≈2t MA +2t A +2t AV +2t V (4)

[0085] In a STIP scenario (e.g., where no authorization response is received from the issuer system, where the TSP system executes STIP, etc.), the total transmission and processing time for a transaction in which STIP is invoked can be defined according to the following formula (5): R –t 0 ):

[0086] STIP(t R –t 0 ) = t MA +t A +t AV +t V +t TO +t V +t AV +t A +t MA (5)

[0087] For example, the total transmission and processing time of a transaction in which STIP is called STIP(t R –t 0 ) may be equal to (transmission time of the authorization request from the merchant system to the acquirer system) + (processing time of the authorization request at the acquirer system) + (transmission time of the authorization request from the acquirer system to the transaction service provider (TSP) system) + (processing time of the authorization request at the TSP system) + (timeout associated with the issuer system) + (STIP processing time at the TSP system) + (transmission time of the authorization response from the TSP system to the acquirer system) + (processing time of the authorization response at the acquirer system) + (transmission time from the acquirer system to the merchant system or terminal). For example, formula (5) may be rewritten as the following formula (6):

[0088] STIP(t R –t 0 )=2t MA +2t A +2t AV +2t V +t TO (6)

[0089] Using formula (3), where the total transmission and processing time of the transaction t R –t 0 Assuming it is about ten seconds, the total transmission and processing time STIP(t R –t 0 ):

[0090] STIP(t R –t 0 )<10+t TO (7)

[0091] For example, for a transaction in which STIP is invoked, the total transmission and processing time STIP(t R –t 0 ) can be equal to the average transmission and processing time for a normal transaction (e.g., 10 seconds, etc.) plus a timeout period associated with the issuer system.

[0092] The maximum total transmission and processing time MAX (t R –t 0 ) should be less than the timeout time of the merchant system or terminal. For example, assuming that the merchant timeout time described in the example above is 120 seconds, the maximum total transmission and processing time MAX(t R –t 0 ):

[0093] MAX(t R –t 0 )<=120 (8)

[0094] Therefore, as long as STIP(t R –t 0 ) is less than or equal to MAX(t R –t 0 ), the transaction can be successfully processed (normally or using STIP processing). It should be noted that for the sake of discussion, it is assumed that the timeout of the acquirer system is consistent with the timeout of the merchant system or terminal, and is less than the transmission time of the authorization request from the merchant system or terminal to the acquirer system. In this way, the STIP for successfully processing a transaction (t R –t 0 ) and MAX(t R –t 0 )

[0095] STIP(t R –t0 ) <MAX(t R –t 0 ) (9)

[0096] Using formulas (7) and (8), when 10 plus t TO When t is less than or equal to 120, the transaction can be successfully processed during the timeout period of the example merchant timeout period of 120 seconds described above, TO It can be defined according to the following formula (10):

[0097] t TO <=110 (10)

[0098] Therefore, as long as t TO In less than 110 seconds (for this example scenario), the transaction can be successfully processed. R –t 0 Formulas (1)-(10) are described for an example scenario of approximately ten seconds and a merchant timeout of 120 seconds, but non-limiting embodiments or aspects of the present disclosure are not limited thereto and may apply to any total transmission and processing time t for a transaction and / or any merchant timeout. R –t 0 For example, formula (9) is a general statement, and formula (10) is a specific instance of formula (5).

[0099] Reference now Figure 5 , Figure 5 5 is a graph 500 illustrating example authorization response times of an example issuer system for an example transaction. Figure 5 As shown in , most authorization responses for the example issuer system are received within a few seconds, and for the remaining authorization responses, the response times are distributed over a wide range. For this example, for a timeout set to ten seconds, 0.336% (64,486) of the total number of transactions had a response time of >10 seconds from the issuer system, with the peak distribution being around 11 seconds. Each of these transactions (where the response time was ten seconds or more) invoked the STIP process due to the timeout period for the issuer system response to timeout.

[0100] The approval rate for transactions processed using STIP has dropped by approximately 20% compared to transactions approved by normal issuer systems. One reason for the drop in approval rates is that STIP is a rules-based system, and some issuer systems may have minimal STIP rules, which may result in higher transaction rejection rates. The number of rejections may increase as issuers around the world add more STIP codes, which may result in negative customer experiences and / or lost revenue for members of the electronic payment network.

[0101] Because the transaction service provider system is about Figure 5 The example issuer discussed applies a static timeout, so each transaction results in a STIP being called after ten seconds if no authorization response is received from the issuer system, resulting in a lower approval rate. Figure 5 As can be seen in Figure 1, authorization responses are received from the issuer system for most of these STIP transactions within eleven seconds. Using formula (10), it can be assumed that as long as for a particular merchant / acquirer / terminal provider combination t TO <= 110, the transaction can be successfully processed. Therefore, using a conservative approach, if the transaction service provider system increases the timeout of the example issuer by 2 seconds, most of the STIP transactions of the issuer system may have been directly responded to by the issuer system without adversely affecting the electronic payment network.

[0102] Thus, static timeout values ​​for authorization responses from issuer systems do not take into account real-time processing conditions, which can lead to increased transaction rejections. For example, when the issuer system does not provide a direct authorization response to the transaction service provider system, the approval rate of transactions may be reduced, which may be due to various factors, such as time delays in sending the authorization response to the transaction service provider system, etc.

[0103] Issuer systems may have unique requirements and processes that affect how the issuer systems respond to transactions, and these issuer systems are currently subject to static rules that do not take into account the different unique characteristics of the issuer systems. Although most issuers have complied with these static rules for many years, and transaction service provider systems have been successful with these rules, there are opportunities for improvement. For example, when issuer systems fail to meet these rules, there are alternative solutions for issuer systems, but these existing solutions are not sufficient, resulting in the defect of declining transactions, which in turn results in a poor customer experience for cardholders, merchants, and lost revenue for electronic payment network members.

[0104] An improved system, apparatus, product, device and / or method for receiving a dynamic authorization response timeout for an authorization request associated with a transaction from a merchant system, wherein the authorization request includes transaction data associated with the transaction; transmitting the authorization request to an issuer system; in response to transmitting the authorization request to the issuer system, starting a response timer associated with the transaction; in response to the response timer satisfying a predetermined response time amount without receiving an authorization response associated with the authorization request from the issuer system, determining an extended response time amount associated with the transaction by providing transaction data associated with the transaction and historical transaction data associated with at least one historical transaction associated with the issuer system as input to a machine learning model and receiving an extended response time amount as output from the machine learning model; and in response to receiving the authorization response from the issuer system before the response timer satisfies the sum of the extended response time amount and the predetermined response time amount, transmitting the authorization response to the merchant system, wherein the authorization response includes one of authorizing the transaction and denying the transaction.

[0105] Thus, non-limiting embodiments or aspects of the present disclosure may provide a machine learning / AI-based solution that uses historical response time data to extend the authorization response timeout of an issuer system to decide when to extend the timeout of a transaction, which may enable the issuer system to appropriately decide on the transaction, increase the positive impact on approval rates, reduce the risk of approving fraud-related transactions, and / or improve the cardholder experience. Therefore, non-limiting embodiments or aspects of the present disclosure may solve the technical problem of static time rules applicable to each issuer system in a region in a manner that adapts to the uniqueness of each issuer when responding to authorization requests, and reduce the processing time for providing dynamic response times by determining the dynamic response time only after the static timer expires, wherein the dynamic response time itself enables a reduction in the number of alternate processing (STIP) transactions that have minimal or reduced impact on the overall transaction processing time in the electronic payment network.

[0106] Reference now Figure 1 , Figure 1 1 is a diagram of an example environment 100 in which the apparatus, systems, methods, and / or products described herein may be implemented. Figure 1As shown in , environment 100 includes transaction processing network 101, user device 112 and / or communication network 114, and transaction processing network may include merchant system 102, payment gateway system 104, acquirer system 106, transaction service provider system 108, issuer system 110. Transaction processing network 101, merchant system 102, payment gateway system 104, acquirer system 106, transaction service provider system 108, issuer system 110 and / or user device 112 may be interconnected (e.g., establish connection for communication, etc.) via wired connection, wireless connection or a combination of wired connection and wireless connection.

[0107] The merchant system 102 may include one or more devices that can receive information and / or data from the payment gateway system 104, the acquirer system 106, the transaction service provider system 108, the issuer system 110, and / or the user device 112 through the communication network 114, and / or transmit information and / or data to the payment gateway system 104, the acquirer system 106, the transaction service provider system 108, the issuer system 110, and / or the user device 112 through the communication network 114. For example, the merchant system 102 may include a computing device, such as a server (e.g., a server computer 120, etc.), a server group, a client device, a client device group, and / or other similar devices. In some non-limiting embodiments or aspects, the merchant system 102 may be associated with the merchant described herein. In some non-limiting embodiments or aspects, the merchant system 102 may include one or more devices that can be used by merchants to conduct payment transactions with users, such as computers, computer systems, and / or peripheral devices. For example, the merchant system 102 may include a POS device and / or a POS system.

[0108] The payment gateway system 104 may include one or more devices capable of receiving information and / or data from the merchant system 102, the acquirer system 106, the transaction service provider system 108, the issuer system 110, and / or the user device 112 via the communication network 114, and / or transmitting information and / or data to the merchant system 102, the acquirer system 106, the transaction service provider system 108, the issuer system 110, and / or the user device 112 via the communication network 114. For example, the payment gateway system 104 may include a computing device, such as a server, a server group, and / or other similar devices. In some non-limiting embodiments or aspects, the payment gateway system 104 is associated with the payment gateway described herein.

[0109] The acquirer system 106 may include one or more devices capable of receiving information and / or data from the merchant system 102, the payment gateway system 104, the transaction service provider system 108, the issuer system 110, and / or the user device 112 via the communication network 114, and / or transmitting information and / or data to the merchant system 102, the payment gateway system 104, the transaction service provider system 108, the issuer system 110, and / or the user device 112 via the communication network 114. For example, the acquirer system 106 may include a computing device, such as a server, a server group, and / or other similar devices. In some non-limiting embodiments or aspects, the acquirer system 106 may be associated with an acquirer as described herein.

[0110] The transaction service provider system 108 may include one or more devices capable of receiving information and / or data from the merchant system 102, the payment gateway system 104, the acquirer system 106, the issuer system 110, and / or the user device 112 via the communication network 114, and / or transmitting information and / or data to the merchant system 102, the payment gateway system 104, the acquirer system 106, the issuer system 110, and / or the user device 112 via the communication network 114. For example, the transaction service provider system 108 may include a computing device, such as a server (e.g., a transaction processing server, a server computer 120, etc.), a server group, and / or other similar devices. In some non-limiting embodiments or aspects, the transaction service provider system 108 may be associated with a transaction service provider described herein. In some non-limiting embodiments or aspects, the transaction service provider system 108 may include and / or access one or more internal and / or external databases, including transaction data.

[0111] The issuer system 110 may include one or more devices that are capable of receiving information and / or data from the merchant system 102, the payment gateway system 104, the acquirer system 106, the transaction service provider system 108, and / or the user device 112 via the communication network 114, and / or transmitting information and / or data to the merchant system 102, the payment gateway system 104, the acquirer system 106, the transaction service provider system 108, and / or the user device 112 via the communication network 114. For example, the issuer system 110 may include a computing device, such as a server (e.g., a server computer 120, etc.), a server group, and / or other similar devices. In some non-limiting embodiments or aspects, the issuer system 110 may be associated with an issuer organization described herein. For example, the issuer system 110 may be associated with an issuer organization that issues payment accounts or instruments (e.g., credit accounts, debit accounts, credit cards, debit cards, etc.) to users (e.g., users associated with the user device 112, etc.).

[0112] In some non-limiting embodiments or aspects, the transaction processing network 101 includes multiple systems in a communication path for processing transactions. For example, the transaction processing network 101 may include a merchant system 102, a payment gateway system 104, an acquirer system 106, a transaction service provider system 108, and / or an issuer system 110 in a communication path (e.g., a communication path, a communication channel, a communication network, etc.) for processing electronic payment transactions. For example, the transaction processing network 101 may process (e.g., initiate, conduct, authorize, etc.) electronic payment transactions via the communication path between the merchant system 102, the payment gateway system 104, the acquirer system 106, the transaction service provider system 108, and / or the issuer system 110.

[0113] The user device 112 may include one or more devices capable of receiving information and / or data from the merchant system 102, the payment gateway system 104, the acquirer system 106, the transaction service provider system 108, and / or the issuer system 110 via the communication network 114 and / or transmitting information and / or data to the merchant system 102, the payment gateway system 104, the acquirer system 106, the transaction service provider system 108, and / or the issuer system 110 via the communication network 114. For example, the user device 112 may include a client device or the like.

[0114] The communication network 114 may include one or more wired and / or wireless networks. For example, the communication network 114 may include a cellular network (e.g., a long term evolution (LTE) network, a third generation (3G) network, a fourth generation (4G) network, a fifth generation (5G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., a public switched telephone network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber-based network, a cloud computing network, etc. and / or a combination of these or other types of networks.

[0115] supply Figure 1 The number and arrangement of devices and systems shown are examples. Additional devices and / or systems, fewer devices and / or systems, different devices and / or systems, and / or devices and / or systems may be present. Figure 1 The devices and / or systems shown in the drawings may be arranged in different ways. In addition, the invention may be implemented in a single device and / or system. Figure 1 Two or more devices and / or systems shown, or Figure 1The single device and / or system shown may be implemented as multiple distributed devices and / or systems. Additionally or alternatively, a set of devices and / or systems (e.g., one or more devices or systems) of environment 100 may perform one or more functions described as being performed by another set of devices and / or systems of environment 100.

[0116] Reference now Figure 2 , Figure 2 is a diagram of example components of a device 200. Device 200 may correspond to one or more devices of merchant system 102, one or more devices of payment gateway system 104, one or more devices of acquirer system 106, one or more devices of transaction service provider system 108, one or more devices of issuer system 110, and / or user device 112 (e.g., one or more devices of a system of user device 112, etc.). In some non-limiting embodiments or aspects, one or more devices of merchant system 102, one or more devices of payment gateway system 104, one or more devices of acquirer system 106, one or more devices of transaction service provider system 108, one or more devices of issuer system 110, and / or user device 112 (e.g., one or more devices of a system of user device 112, etc.) may include at least one device 200 and / or at least one component of device 200. As shown in FIG. Figure 2 As shown, apparatus 200 may include a bus 202 , a processor 204 , a memory 206 , a storage component 208 , an input component 210 , an output component 212 , and a communication interface 214 .

[0117] The bus 202 may include components that permit communication between components of the device 200. In some non-limiting embodiments or aspects, the processor 204 may be implemented in hardware, software, or a combination of hardware and software. For example, the processor 204 may include a processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), etc.), a microprocessor, a digital signal processor (DSP), and / or any processing component that can be programmed to perform a function (e.g., a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.). The memory 206 may include a random access memory (RAM), a read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, optical memory, etc.) that stores information and / or instructions for use by the processor 204.

[0118] The storage component 208 may store information and / or software associated with the operation and use of the device 200. For example, the storage component 208 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, a solid-state disk, etc.), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cassette, a magnetic tape, and / or another type of computer-readable medium, and a corresponding drive.

[0119] Input components 210 may include components that permit device 200 to receive information, such as through user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, buttons, switches, a microphone, etc.). Additionally or alternatively, input components 210 may include sensors for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, etc.). Output components 212 may include components that provide output information from device 200 (e.g., a display, a speaker, one or more light emitting diodes (LEDs), etc.).

[0120] The communication interface 214 may include a transceiver-type component (e.g., a transceiver, a separate receiver and transmitter, etc.) that enables the device 200 to communicate with other devices, for example, via a wired connection, a wireless connection, or a combination of a wired connection and a wireless connection. The communication interface 214 may permit the device 200 to receive information from another device and / or provide information to another device. For example, the communication interface 214 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, Interface, cellular network interface, etc.

[0121] The device 200 can perform one or more processes described herein. The device 200 can perform these processes based on the processor 204 executing software instructions stored by a computer-readable medium such as the memory 206 and / or the storage component 208. Computer-readable media (e.g., non-transitory computer-readable media) are defined herein as non-transitory memory devices. Non-transitory memory devices include memory space located within a single physical storage device or memory space spread across multiple physical storage devices.

[0122] The software instructions may be read into the memory 206 and / or storage component 208 from another computer-readable medium or from another device via the communication interface 214. When executed, the software instructions stored in the memory 206 and / or storage component 208 may cause the processor 204 to perform one or more processes described herein. Additionally or alternatively, hard-wired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, the embodiments or aspects described herein are not limited to any specific combination of hardware circuitry and software.

[0123] The memory 206 and / or storage component 208 may include a data storage device or one or more data structures (e.g., a database, etc.). The device 200 can receive information from, store information in, transfer information to, or search for information stored in the data storage device or one or more data structures in the memory 206 and / or storage component 208.

[0124] supply Figure 2 The number and arrangement of components shown in FIG. are provided as examples. In some non-limiting embodiments or aspects, Figure 2 Compared to those shown in , device 200 may include additional components, fewer components, different components, or components arranged in a different manner. Additionally or alternatively, a set of components (e.g., one or more components) of device 200 may perform one or more functions described as being performed by another set of components of device 200.

[0125] Reference now Figure 3 , Figure 3 is a flow chart of a non-limiting embodiment or aspect of a process 300 for dynamic authorization response timeout. In some non-limiting embodiments or aspects, one or more steps in the process 300 may be performed (e.g., in whole, in part, etc.) by a transaction service provider system 108 (e.g., one or more devices of the transaction service provider system 108). In some non-limiting embodiments or aspects, one or more steps of the process 300 may be performed (e.g., in whole, in part, etc.) by another device or group of devices that is independent of or includes the transaction service provider system 108, such as a merchant system 102 (e.g., one or more devices of the merchant system 102, etc.), a payment gateway system 104 (e.g., one or more devices of the payment gateway system 104), an acquirer system 106 (e.g., one or more devices of the acquirer system 106), an issuer system 110 (e.g., one or more devices of the issuer system 110), and / or a user device 112 (e.g., one or more devices of a system of the user device 112).

[0126] like Figure 3 As shown in , process 300 includes receiving an authorization request at step 302. For example, transaction service provider system 108 may receive an authorization request associated with a transaction from merchant system 102, the authorization request including transaction data associated with the transaction.

[0127] The transaction data may include parameters associated with the transaction, such as an account identifier (e.g., PAN, etc.), a transaction amount, a transaction date and time, a type of product and / or service associated with the transaction, a currency conversion rate, a type of currency, a merchant type, a merchant name, a merchant location, a merchant category group (MCG), a merchant category code (MCC), a type of point-of-sale (POS) terminal associated with the merchant system 102, a type of merchant associated with the merchant system 102, a country associated with the merchant system 102, a country associated with the issuer system 110, a season, a time of day, a processing code, or any combination thereof.

[0128] Also refer to Figure 4 , Figure 4 4 is a flow chart of a non-limiting embodiment or aspect of an implementation 400 of a process 300 for dynamic authorization response timeout. Figure 4 As shown in FIG. 4 , at reference numeral 401, the merchant system 102 may receive an account identifier (e.g., PAN, etc.) and / or other information associated with a payment device from a user (e.g., a cardholder, etc.). At reference numeral 402, the merchant system 102 may transmit an authorization request to the acquirer system 106. As shown at reference numeral 403, the transaction service provider system 108 may receive the authorization request from the acquirer system 106.

[0129] like Figure 3 As shown in FIG. 3 , at step 304, process 300 includes transmitting the authorization request to the issuer system. For example, transaction service provider system 108 may transmit the authorization request to issuer system 110. For example, issuer system 110 may be identified by transaction data (e.g., PAN, BIN, etc.). For example, and again referring to Figure 4 At reference numeral 404 , the transaction service provider system 108 may transmit and / or forward the authorization request to the issuer system 110 .

[0130] like Figure 3 As shown in , at step 306, process 300 includes starting a response timer. For example, the transaction service provider system 108 may start a response timer associated with the transaction in response to transmitting the authorization request to the issuer system. For example, the response timer may be configured with a static or predetermined timeout value.

[0131] Reference again Figure 4 At reference numeral 405, in response to receiving the authorization request, the issuer system 110 can query an account associated with the cardholder, and at reference numeral 406, the cardholder can be billed.

[0132] like Figure 3As shown in , at step 308, process 300 includes determining whether an authorization response is received within a response time. For example, transaction service provider system 108 may determine whether an authorization response associated with an authorization request is received from issuer system 110 before a response timer satisfies a predetermined amount of response time (e.g., before a response timer times out, etc.).

[0133] like Figure 3 As shown in , if, at step 308, process 300 determines that the authorization response is received within the response time, at step 310, process 300 includes transmitting the authorization response to the merchant system. For example, transaction service provider system 108 may transmit the authorization response to issuer system 110 in response to receiving the authorization response associated with the authorization request from issuer system 110 before the response timer satisfies a predetermined amount of response time (e.g., before the response timer times out, etc.).

[0134] like Figure 3 As shown in , if, at step 308, process 300 determines that an authorization response is not received within the response time, at step 312, process 300 includes determining an extended response time. For example, transaction service provider system 108 may determine an extended amount of response time associated with the transaction in response to a response timer satisfying a predetermined amount of response time (e.g., in response to a response timer timing out, etc.) without receiving an authorization response associated with the authorization request from issuer system 110. For example, transaction service provider system 108 may determine an extended amount of response time associated with the transaction by providing transaction data associated with the transaction and historical transaction data associated with at least one historical transaction of an associated issuer system as input to a machine learning model, and receiving the extended amount of response time from an output of the machine learning model.

[0135] The transaction service provider system 108 may generate a machine learning model to predict or generate an extended timeout value for a particular transaction using historical transaction data associated with the issuer system 110 (e.g., by predicting or estimating the parameters described in Table 1 herein, etc.) to satisfy formula (9). For example, the transaction service provider system 108 may generate a guaranteed STIP (t R –t 0 ) <MAX(t R –t 0 ). In this example, for each transaction, t can be identified by the timestamp contained in each incoming message (e.g., authorization request, etc.) received from the merchant system 102. 0 .

[0136] In some non-limiting embodiments or aspects, the transaction service provider system 108 may estimate MAX(t R –t 0 ).

[0137] In some non-limiting embodiments or aspects, the transaction service provider system 108 may estimate MAX(t R –t 0 ), the issuer, upon receiving the revocation, updates the account balance (if the authorization is approved) or ignores the revocation (if the authorization is denied), which ensures that the cardholder has the correct available balance. Using this rule or assumption, the transaction service provider system 108 can determine that the revocation transmission time A is equal to the time when the transaction service provider system 108 receives the revocation minus the revocation initiation (t 0 ), and the time between revocation and authorization B is equal to the revocation initiation (t 0 ) minus authorization initiated (t 0 ). Therefore, the terminal timeout value can be equal to B minus A, and MAX(t R –t 0 ).

[0138] The transaction service provider system 108 can estimate STIP(t R –t 0 ):

[0139] ATR(t R -t 0 )=2t MA +2t A +2t AV +2t V +t TO (11)

[0140] Where C = to t MA +t A +t AV , which is equal to the time when the transaction service provider system 108 receives the authorization response minus the time when the authorization is initiated (t 0 ), and where D = t V , so that formula (11) can be rewritten as the following formula (12):

[0141] 2C+D+t TO <B–A (12)

[0142] Therefore, because the transaction service provider system 108 can estimate A, B, C, and D with high accuracy (and can dynamically update the estimates based on real-time processing conditions), the transaction service provider system 108 can estimate the maximum value t of the transaction level with high accuracy. TO .

[0143] The transaction service provider system 108 may determine when to extend the response timer to be greater than or beyond a static or predetermined timeout value (e.g., greater than 10 seconds, etc.). For example, if the response timer is extended for every transaction, there is a processing impact on transaction speed, as well as consumer experience issues (e.g., no consumer wants to wait 110 seconds to complete a card payment, etc.). For example, the transaction service provider system may estimate how long it typically takes the issuer system 110 to provide an authorization response for these types of transactions (e.g., an estimated average E, etc.) based on historical patterns associated with the issuer system 110 in historical transaction data associated with at least one historical transaction (e.g., historical patterns of transaction types, country, current conditions, etc.). As long as E is less than the calculated t TO , the transaction service provider system 108 can extend the response timer. For example, the sum of the predetermined response time amount and the extended response time amount of the response timer can be less than the merchant timeout amount, and in response to the merchant timeout amount expiring, the merchant system 102 can cancel the transaction.

[0144] The historical transaction data may include at least one of the following parameters associated with at least one historical transaction: the total transmission and processing time t of the transaction; R –t 0 ; Transmission time t of the authorization request from the merchant system 102 to the acquirer system 106 MA ; Processing time t of the authorization request at the acquirer system 106 A ; Transmission time t of the authorization request from the acquirer system 106 to the transaction service provider system 108 AV ; Processing time t of the authorization request at the transaction service provider system 108 V ; Transmission time t of the authorization request from the transaction service provider system 108 to the issuer system 110 V ; Processing time t of the authorization request at the issuer system 110 I ; Transmission time t of the authorization response from the issuer system 110 to the transaction service provider system 108 AV ; Processing time t of the authorization response at the transaction service provider system 108 V ; Transmission time t of the authorization response from the transaction service provider system 108 to the acquirer system 106 AV ; Processing time t of the authorization response at the acquirer system 106 A; Transmission time t from the acquirer system 106 to the merchant system 102 MA ; The total transmission and processing time of the transaction calling STIP is STIP(t R –t 0 ) ; timeout period t associated with the issuer system TO ; STIP processing time t at the transaction service provider system 108 V ; account identifier (e.g., PAN, etc.); transaction amount; transaction date and time; type of product and / or service related to the transaction; currency conversion rate; type of currency; merchant type; merchant name; merchant location; merchant category group (MCG); merchant category code (MCC); type of point of sale (POS) terminal associated with merchant system 102; type of merchant associated with merchant system 102; country associated with merchant system 102; country associated with issuer system 110; season; time of day; processing code; or any combination thereof.

[0145] The transaction service provider system 108 may generate a machine learning model (e.g., an estimator, a classifier, a prediction model, a detector model, etc.) using machine learning techniques, including, for example, supervised and / or unsupervised techniques, such as decision trees (e.g., gradient boosted decision trees, random forests, etc.), logistic regression, artificial neural networks (e.g., convolutional neural networks, deep neural networks, LSTMs, etc.), Bayesian statistics, learning autoanalysis, hidden Markov modeling, linear classifiers, quadratic classifiers, association rule learning, etc. The machine learning model may be trained to provide an output (including an extended amount of response time associated with a transaction (e.g., an amount of time to extend a response timer, etc.)) in response to inputs including transaction data associated with a transaction (e.g., one or more parameters of a transaction, etc.) and / or historical transaction data associated with at least one historical transaction associated with the issuer system 110 (e.g., one or more parameters of at least one historical transaction, etc.). For example, the transaction service provider system 108 may train the model based on training data (e.g., training transactions, historical transactions, etc.) associated with one or more training transactions and / or one or more historical training transactions. In this example, the extended response time may include a probability score associated with the extended response time. For example, the extended response time may include a probability of receiving an authorization response from the issuer system 110 within the extended response time.

[0146] In some non-limiting embodiments or aspects, the transaction service provider system 108 may store the model (e.g., store the model for later use). In some non-limiting embodiments or aspects, the transaction service provider system 108 may store the model in a data structure (e.g., a database, a linked list, a tree, etc.). In some non-limiting embodiments or aspects, the data structure is located within the transaction service provider system 108 or external to (e.g., remote from) the transaction service provider system 108 (e.g., in a database such as a database). Figure 4 , etc.).

[0147] For example, and again referring to Figure 4 At reference numeral 407, a response timer associated with the issuer system 110 may elapse without the transaction service provider system 108 receiving an authorization response from the issuer system 110. At reference numeral 408, the transaction service provider system 108 may call the AI ​​platform 109 (e.g., if the issuer system 110 is verified as eligible for an extended response time, etc.) to request an amount of extended response time for the transaction. At reference numeral 409, the AI ​​platform 109 may provide a response to the transaction service provider system 108 indicating whether the issuer system 110 is eligible for an extension and the duration of the extension to be granted. For example, when the authorization request is routed through the transaction service provider system 108, the transaction service provider system 108 may set or start a response timer, and if the issuer system 110 does not respond within the specified time limit of the response timer, the transaction service provider system 108 may send a query to the AI ​​platform 109 for a recommendation, and at reference numeral 409, the AI ​​platform 109 may respond to the transaction service provider system 108 with a message indicating whether the issuer system 110 is eligible for an extension, and if so, the duration of the extension. In this example, the AI ​​platform 109 may generate the recommendation by processing transaction data associated with the transaction and / or historical transaction data associated with the issuer system 110 (e.g., historical response patterns of the issuer system 110 to any one or any combination of transaction parameters) using a machine learning model. In some non-limiting embodiments or aspects, the transaction service provider system 108 may verify that the issuer system is eligible (e.g., participates in, subscribes to a program, etc.) to obtain an extended response time (e.g., by using a lookup table based on the issuer BIN, etc.) before calling the AI ​​platform 109.

[0148] Still refer to Figure 4At reference numeral 410, the transaction service provider system 108 may extend the response time of the issuer system 110. In this example, the extended time may be determined by a limiting factor, where the sum of the predetermined response time amount and the extended response time amount is less than the merchant timeout amount, and in response to the merchant timeout amount expiring, the merchant system cancels the transaction. Figure 4 108 as being external to (eg, remote from) the transaction service provider system 108 , but the AI ​​platform 109 may be included within and / or implemented by the transaction service provider system 108 .

[0149] like Figure 3 As shown in , at step 314, process 300 includes determining whether an authorization response is received within the extended response time. For example, transaction service provider system 108 may determine whether an authorization response is received from issuer system 110 within the extended response time (e.g., before a response timer satisfies the sum of the extended response time amount and the predetermined response time amount).

[0150] like Figure 3 As shown in , if at step 314, process 300 determines that an authorization response is received within the extended response time, at step 316, process 300 includes transmitting the authorization response to the merchant system. For example, transaction service provider system 108 may transmit an authorization response to merchant system 102 in response to receiving an authorization response from issuer system 110 before the response timer satisfies the sum of the extended response time amount and the predetermined response time amount. In this example, the authorization response may include one of authorizing the transaction and declining the transaction. As an example, and again referring to Figure 4 At reference numeral 411, the transaction service provider system 108 may transmit or forward the authorization response received from the issuer system 110 to the acquirer system 106 within the extended response time, and at reference numeral 412, the acquirer system 106 may transmit or forward the authorization response to the merchant system 102. At reference numeral 413, the merchant system 102 may complete the exchange of goods and / or services between the merchant and the cardholder.

[0151] like Figure 3 As shown in , if at step 314, process 300 determines that an authorization response is not received within the extended response time, at step 318, process 300 includes performing an alternative process. For example, transaction service provider system 108 may perform an alternative process operation by generating an alternative response based on transaction data and at least one rule associated with the issuer system and transmitting the alternative response to merchant system 102 in response to the response timer satisfying the sum of the extended response time amount and the predetermined response time amount before receiving the authorization response from issuer system 110. In this example, the alternative response may include one of authorizing the transaction and declining the transaction.

[0152] Thus, non-limiting embodiments or aspects of the present disclosure may enable issuer systems to directly and appropriately and by extension decide (e.g., authorize, decline, etc.) transactions, reduce the risk of declining cardholder transactions where authorization responses are delayed, and improve issuer approval rates, which increases interchange fee revenue. Non-limiting embodiments or aspects of the present disclosure may also help issuers reduce fraud risk and maximize customer experience for their cardholders.

[0153] Additionally, non-limiting embodiments or aspects of the present disclosure may enable merchants to complete sales and reduce the risk of fraudulent transactions at the point of sale, and / or promote a positive card experience for cardholders and / or reduce the incidence of negative customer experiences associated with declined transactions during the STIP period.

[0154] Although embodiments or aspects have been described in detail for purposes of illustration and description, it will be understood that such detail is intended solely for that purpose and that the embodiments or aspects are not limited to the disclosed embodiments or aspects, but, on the contrary, are intended to cover modifications and equivalent arrangements within the spirit and scope of the appended claims. For example, it will be understood that the present disclosure contemplates that, to the extent possible, one or more features of any embodiment or aspect may be combined with one or more features of any other embodiment or aspect. Indeed, any of these features may be combined in a manner not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may be directly dependent on only one claim, the disclosure of possible embodiments includes each dependent claim in combination with each other claim in the claim set.

Claims

1. A computer-implemented method comprising: receiving, with at least one processor of a transaction service provider system, from a merchant system an authorization request associated with a transaction in an electronic payment network, wherein the authorization request includes transaction data associated with the transaction, and wherein the transaction data includes an authorization initiation time t0 at which the authorization request was initiated at the merchant system; transmitting, using at least one processor of the transaction service provider system, the authorization request to an issuer system; in response to transmitting the authorization request to the issuer system, starting, with at least one processor of the transaction service provider system, a response timer associated with the transaction; determining, with at least one processor of the transaction service provider system, that the response timer satisfies a predetermined amount of response time without receiving an authorization response associated with the authorization request from the issuer system; In response to determining that the response timer satisfied a predetermined amount of response time without receiving the authorization response associated with the authorization request from the issuer system, determining, using at least one processor of the transaction service provider system, an extended amount of response time associated with the transaction by providing transaction data associated with the transaction and historical transaction data associated with at least one historical transaction associated with the issuer system as inputs to a machine learning model, and receiving the extended amount of response time as output from the machine learning model, wherein the historical transaction data includes at least one transmission and processing time associated with at least one historical transaction with the issuer system, and wherein the machine learning model provides the extended amount of response time to ensure that if a STIP is invoked instead of a processing STIP, the estimated total transmission and processing time for the transaction (t R – t0) is less than the estimated maximum total transmission and processing time MAX (t R – t0); receiving, with at least one processor of the transaction service provider system, the authorization response from the issuer system after determining that the response timer satisfies the predetermined amount of response time and an authorization response associated with the authorization request has not been received from the issuer system, and before the response timer satisfies a sum of the extended amount of response time and the predetermined amount of response time, wherein the sum of the predetermined amount of response time and the extended amount of response time is less than a merchant timeout amount of time, in response to expiration of the merchant timeout amount of time, canceling the transaction in the electronic payment network by the merchant system; and In response to receiving the authorization response from the issuer system before the response timer satisfies the sum of the extended response time amount and the predetermined response time amount, transmitting, using at least one processor of the transaction service provider system, the authorization response to the merchant system, wherein the authorization response comprises one of authorizing the transaction and denying the transaction in the electronic payment network.

2. A computer-implemented method according to claim 1, wherein the transaction data includes at least one of the following parameters: a type of point of sale (POS) terminal associated with the merchant system; a type of merchant associated with the merchant system; a country associated with the merchant system; a country associated with the issuer system; a merchant category code (MCC); season; time of day; or any combination thereof.

3. The computer-implemented method of claim 1 , further comprising: Prior to determining the extended amount of response time, verifying, with at least one processor of the transaction service provider system, that the issuer system is eligible for the extended response time.

4. The computer-implemented method of claim 1, wherein: If the transaction is successfully processed with or without invoking STIP, then estimate the estimated maximum total transmission and processing time MAX (t R – t0), wherein, for the at least one historical transaction, A is the revocation transmission time, which is equal to the time when the transaction service provider system receives the revocation minus the revocation initiation time, and B is the time between revocation and authorization, which is equal to the revocation initiation time minus the authorization initiation time.

5. The computer-implemented method of claim 4, wherein: The machine learning model provides an extended response time amount to ensure that if STIP is invoked, the estimated total transmission and processing time of the transaction STIP (t R – t0) is less than the estimated maximum total transmission and processing time MAX (t0) of the transaction if the transaction is successfully processed with or without invoking STIP R – t0), as shown below: 2C + D + t TO < B – A Where C = to t MA + t A + t AV , which is equal to the time when the transaction service provider system receives the authorization response minus the authorization initiation time (t0), D = t V , t MA is the network propagation time between the merchant system and the acquirer system, t AV is the network propagation time between the acquirer system and the transaction service provider system, t VI is the network propagation time between the transaction service provider system and the issuer system, t A is the processing time at the acquirer system, t V is the processing time at the transaction service provider, t I is the processing time at the issuer system, and t TO is the STIP timeout value of the issuer system.

6. A system comprising: At least one processor of a transaction service provider system, the at least one processor of the transaction service provider system being programmed and / or configured to: receiving, from a merchant system, an authorization request associated with a transaction in an electronic payment network, wherein the authorization request includes transaction data associated with the transaction, and wherein the transaction data includes an authorization initiation time t0 at which the authorization request is initiated at the merchant system; transmitting the authorization request to an issuer system; in response to transmitting the authorization request to the issuer system, starting a response timer associated with the transaction; determining that the response timer satisfies a predetermined amount of response time without receiving an authorization response associated with the authorization request from the issuer system; In response to determining that the response timer satisfied a predetermined amount of response time without receiving the authorization response associated with the authorization request from the issuer system, determining an extended amount of response time associated with the transaction by providing transaction data associated with the transaction and historical transaction data associated with at least one historical transaction associated with the issuer system as input to a machine learning model, and receiving the extended amount of response time as output from the machine learning model, wherein the historical transaction data includes at least one transmission and processing time associated with at least one historical transaction with the issuer system, and wherein the machine learning model provides the extended amount of response time to ensure that if a STIP is invoked instead of a processing STIP, an estimated total transmission and processing time for the transaction (t R – t0) is less than the estimated maximum total transmission and processing time MAX (t R – t0); receiving the authorization response from the issuer system after determining that the response timer satisfies the predetermined amount of response time and an authorization response associated with the authorization request has not been received from the issuer system, and before the response timer satisfies a sum of the extended amount of response time and the predetermined amount of response time, wherein the sum of the predetermined amount of response time and the extended amount of response time is less than a merchant timeout amount of time, in response to expiration of the merchant timeout amount of time, the merchant system canceling the transaction in the electronic payment network; and In response to receiving the authorization response from the issuer system before the response timer satisfies the sum of the extended response time amount and the predetermined response time amount, transmitting the authorization response to the merchant system, wherein the authorization response includes one of authorizing the transaction and denying the transaction in the electronic payment network.

7. A system according to claim 6, wherein the transaction data includes at least one of the following parameters: the type of point of sale (POS) terminal associated with the merchant system; the type of merchant associated with the merchant system; the country associated with the merchant system; the country associated with the issuer system; a merchant category code (MCC); season; time of day; or any combination thereof.

8. The system of claim 6, wherein the at least one processor of the transaction service provider system is further programmed and / or configured to: Prior to determining the amount of extended response time, verifying that the issuer system is eligible for the extended response time.

9. A computer program product comprising at least one non-transitory computer readable medium, the at least one non-transitory computer readable medium comprising program instructions that, when executed by at least one processor of a transaction service provider system, cause the at least one processor of the transaction service provider system to: receiving, from a merchant system, an authorization request associated with a transaction in an electronic payment network, wherein the authorization request includes transaction data associated with the transaction, and wherein, The transaction data includes an authorization initiation time t0, at which the authorization request is initiated in the merchant system; transmitting the authorization request to an issuer system; in response to transmitting the authorization request to the issuer system, starting a response timer associated with the transaction; determining that the response timer satisfies a predetermined amount of response time without receiving an authorization response associated with the authorization request from the issuer system; In response to determining that the response timer satisfied a predetermined amount of response time without receiving the authorization response associated with the authorization request from the issuer system, determining an extended amount of response time associated with the transaction by providing transaction data associated with the transaction and historical transaction data associated with at least one historical transaction associated with the issuer system as input to a machine learning model, and receiving the extended amount of response time as output from the machine learning model, wherein the historical transaction data includes at least one transmission and processing time associated with at least one historical transaction with the issuer system, and wherein the machine learning model provides the extended amount of response time to ensure that if a STIP is invoked instead of a processing STIP, an estimated total transmission and processing time for the transaction (t R – t0) is less than the estimated maximum total transmission and processing time MAX (t R – t0); receiving, with at least one processor of the transaction service provider system, the authorization response from the issuer system after determining that the response timer satisfies the predetermined amount of response time and an authorization response associated with the authorization request has not been received from the issuer system, and before the response timer satisfies a sum of the extended amount of response time and the predetermined amount of response time, wherein the sum of the predetermined amount of response time and the extended amount of response time is less than a merchant timeout amount of time, the merchant system canceling the transaction in the electronic payment network in response to expiration of the merchant timeout amount of time; and In response to receiving the authorization response from the issuer system before the response timer satisfies the sum of the extended response time amount and the predetermined response time amount, transmitting the authorization response to the merchant system, wherein the authorization response includes one of authorizing the transaction and denying the transaction in the electronic payment network.

10. A computer program product according to claim 9, wherein the transaction data includes at least one of the following parameters: a type of point of sale (POS) terminal associated with the merchant system; a type of merchant associated with the merchant system; a country associated with the merchant system; a country associated with the issuer system; a merchant category code (MCC); season; time of day; or any combination thereof.

Images