Method, system, and computer program product for processing payment transactions via a proxy guarantor

Abstract

A method for processing a payment transaction via a proxy guarantor includes receiving a transaction request associated with a payment transaction for a transaction amount. The payment transaction is associated with a user, and the transaction request includes payment device data associated with a payment device of the user, the payment device being associated with a debit account; and guarantor data identifying a guarantor associated with a credit account. The method also includes transmitting a hold request to an issuer system associated with the credit account, causing the issuer system associated with the credit account to place a hold on the credit account for at least a portion of the transaction amount; and transmitting an authorization request to the issuer system associated with the debit account.

Description

Technical Field

[0001] The present disclosure relates to processing payment transactions and, in some non-limiting embodiments or aspects, to a method, system, and computer program product for processing payment transactions via a proxy guarantor. Background Art

[0002] Some merchants, including some merchants that sell goods and / or services through their websites, only accept credit cards as a payment method. This limitation is a problem for many users who may have debit cards and / or bank accounts but not credit cards, as these users do not have a payment device capable of initiating payment transactions with merchants that only accept credit cards. Existing systems do not provide an effective solution that allows users to still use their debit cards or bank accounts to conduct payment transactions with merchants that only accept credit cards. Summary of the Invention

[0003] According to some non-limiting embodiments or aspects, a method for processing a payment transaction via a proxy guarantor includes: using at least one processor to receive a transaction request associated with a payment transaction for a transaction amount, wherein the payment transaction is associated with a user, and the transaction request includes: payment device data, which is associated with the user's payment device, and the payment device is associated with a debit account; and guarantor data, which identifies a guarantor associated with a credit account; using at least one processor to transmit a hold request to an issuer system associated with the credit account, so that the issuer system associated with the credit account holds the credit account for at least a portion of the transaction amount; and using at least one processor to transmit an authorization request to the issuer system associated with the debit account.

[0004] In some non-limiting embodiments or aspects, the guarantor data may include at least one of payment device data associated with a payment device associated with the credit account and contact data associated with the guarantor. The method may further include: transmitting, using at least one processor, a message to a computing device of the guarantor based on the guarantor data; and receiving, using at least one processor, a response message from the computing device of the guarantor, wherein the response message includes the payment device data associated with the payment device associated with the credit account. The message may include user identification data associated with the user and may cause the computing device of the guarantor to generate the response message. The method may further include: receiving, using at least one processor, an authorization response from the issuer system associated with the debit account, wherein the authorization response includes an authorization approval; and transmitting, using at least one processor, a hold release message to the issuer system associated with the credit account, wherein the hold release message is configured to cause the issuer system associated with the credit account to release the hold on the credit account. During settlement of the payment transaction, the transaction amount may be transferred from the debit account to an account of a merchant associated with the payment transaction.

[0005] In some non-limiting embodiments or aspects, the method may include: receiving, using at least one processor, an authorization response from the issuer system associated with the debit account, wherein the authorization response includes an authorization denial; and transmitting, using at least one processor, a second authorization request to the issuer system associated with the credit account. During settlement of the payment transaction, the transaction amount may be transferred from the credit account to an account of a merchant associated with the payment transaction.

[0006] According to some non-limiting embodiments or aspects, a system for processing payment transactions via an agent guarantor, the system comprising at least one processor programmed or configured to: receive a transaction request associated with a payment transaction for a transaction amount, wherein the payment transaction is associated with a user, the transaction request comprising: payment device data associated with a payment device of the user, the payment device associated with a debit account; and guarantor data identifying a guarantor associated with a credit account; transmit a hold request to an issuer system associated with the credit account so that the issuer system associated with the credit account holds the credit account for at least a portion of the transaction amount; and transmit an authorization request to the issuer system associated with the debit account.

[0007] In some non-limiting embodiments or aspects, the guarantor data may include at least one of payment device data associated with the payment device associated with the credit account and contact data associated with the guarantor. The at least one processor may also be programmed or configured to: transmit a message to the guarantor's computing device based on the guarantor data; and receive a response message from the guarantor's computing device, wherein the response message includes the payment device data associated with the payment device associated with the credit account. The message may include user identification data associated with the user and may cause the guarantor's computing device to generate the response message. The at least one processor may also be programmed or configured to: receive an authorization response from the issuer system associated with the debit account, wherein the authorization response includes authorization approval; and transmit a hold release message to the issuer system associated with the credit account, wherein the hold release message is configured to cause the issuer system associated with the credit account to release the hold on the credit account. During settlement of the payment transaction, the transaction amount may be transferred from the debit account to an account of a merchant associated with the payment transaction.

[0008] In some non-limiting embodiments or aspects, the at least one processor may be further programmed or configured to: receive an authorization response from the issuer system associated with the debit account, wherein the authorization response includes an authorization denial; and transmit a second authorization request to the issuer system associated with the credit account. During settlement of the payment transaction, the transaction amount may be transferred from the credit account to an account of a merchant associated with the payment transaction.

[0009] According to some non-limiting embodiments or aspects, a computer program product for processing payment transactions via an agent guarantor, the computer program product comprising at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium comprising one or more instructions that, when executed by at least one processor, causes the at least one processor to: receive a transaction request associated with a payment transaction for a transaction amount, wherein the payment transaction is associated with a user, the transaction request comprising: payment device data associated with a payment device of the user, the payment device being associated with a debit account; and guarantor data identifying a guarantor associated with a credit account; transmit a hold request to an issuer system associated with the credit account so that the issuer system associated with the credit account holds the credit account for at least a portion of the transaction amount; and transmit an authorization request to the issuer system associated with the debit account.

[0010] In some non-limiting embodiments or aspects, the guarantor data may include at least one of payment device data associated with a payment device associated with the credit account and contact data associated with the guarantor. The one or more instructions may cause the at least one processor to: transmit a message to the guarantor's computing device based on the guarantor data; and receive a response message from the guarantor's computing device, wherein the response message includes the payment device data associated with the payment device associated with the credit account. The message may include user identification data associated with the user and may cause the guarantor's computing device to generate the response message. The one or more instructions may cause the at least one processor to: receive an authorization response from the issuer system associated with the debit account, wherein the authorization response includes authorization approval; and transmit a hold release message to the issuer system associated with the credit account, wherein the hold release message is configured to cause the issuer system associated with the credit account to release the hold on the credit account. During settlement of the payment transaction, the transaction amount may be transferred from the debit account to an account of a merchant associated with the payment transaction.

[0011] In some non-limiting embodiments or aspects, the one or more instructions may cause the at least one processor to: receive an authorization response from the issuer system associated with the debit account, wherein the authorization response includes an authorization denial; and transmit a second authorization request to the issuer system associated with the credit account. During settlement of the payment transaction, the transaction amount may be transferred from the credit account to an account of a merchant associated with the payment transaction.

[0012] Additional embodiments or aspects are set forth in the following numbered clauses:

[0013] Clause 1: A method for processing a payment transaction via a proxy guarantor, comprising: receiving, using at least one processor, a transaction request associated with a payment transaction for a transaction amount, wherein the payment transaction is associated with a user, the transaction request comprising: payment device data associated with a payment device of the user, the payment device associated with a debit account; and guarantor data identifying a guarantor associated with a credit account; transmitting, using at least one processor, a hold request to an issuer system associated with the credit account so that the issuer system associated with the credit account places a hold on the credit account for at least a portion of the transaction amount; and transmitting, using at least one processor, an authorization request to the issuer system associated with the debit account.

[0014] Clause 2: The method of clause 1, wherein the sponsor data comprises at least one of payment device data associated with a payment device associated with the credit account and contact data associated with the sponsor.

[0015] Clause 3: The method according to clause 1 or 2 further includes: using at least one processor to transmit a message to the computing device of the guarantor based on the guarantor data; and using at least one processor to receive a response message from the computing device of the guarantor, wherein the response message includes payment device data associated with the payment device associated with the credit account.

[0016] Clause 4: The method of clauses 1 to 3, wherein the message includes user identification data associated with the user and causes the computing device of the sponsor to generate the response message.

[0017] Clause 5: The method according to any one of clauses 1 to 4 further includes: using at least one processor to receive an authorization response from the issuer system associated with the debit account, wherein the authorization response includes an authorization approval; and using at least one processor to transmit a hold release message to the issuer system associated with the credit account, wherein the hold release message is configured to cause the issuer system associated with the credit account to release the hold on the credit account.

[0018] Clause 6: The method of any one of clauses 1 to 5, wherein during settlement of the payment transaction, the transaction amount is transferred from the debit account to an account of a merchant associated with the payment transaction.

[0019] Clause 7: The method of any one of clauses 1 to 6 further comprising: receiving, using at least one processor, an authorization response from the issuer system associated with the debit account, wherein the authorization response includes an authorization rejection; and transmitting, using at least one processor, a second authorization request to the issuer system associated with the credit account.

[0020] Clause 8: The method of any one of clauses 1 to 7, wherein during settlement of the payment transaction, the transaction amount is transferred from the credit account to an account of a merchant associated with the payment transaction.

[0021] Clause 9: A system for processing payment transactions via an agent guarantor, the system comprising at least one processor programmed or configured to: receive a transaction request associated with a payment transaction for a transaction amount, wherein the payment transaction is associated with a user, the transaction request comprising: payment device data associated with a payment device of the user, the payment device associated with a debit account; and guarantor data identifying a guarantor associated with a credit account; transmit a hold request to an issuer system associated with the credit account to cause the issuer system associated with the credit account to hold the credit account for at least a portion of the transaction amount; and transmit an authorization request to the issuer system associated with the debit account.

[0022] Clause 10: The system of clause 9, wherein the sponsor data comprises at least one of payment device data associated with a payment device associated with the credit account and contact data associated with the sponsor.

[0023] Clause 11: A system according to clause 9 or 10, wherein the at least one processor is further programmed or configured to: transmit a message to a computing device of the guarantor based on the guarantor data; and receive a response message from the computing device of the guarantor, wherein the response message includes payment device data associated with a payment device associated with the credit account.

[0024] Clause 12: The system of clauses 9 to 11, wherein the message includes user identification data associated with the user and causes the computing device of the sponsor to generate the response message.

[0025] Clause 13: A system according to any one of clauses 9 to 12, wherein the at least one processor is further programmed or configured to: receive an authorization response from the issuer system associated with the debit account, wherein the authorization response includes an authorization approval; and transmit a hold release message to the issuer system associated with the credit account, wherein the hold release message is configured to cause the issuer system associated with the credit account to release the hold on the credit account.

[0026] Clause 14: The system of any one of clauses 9 to 13, wherein during settlement of the payment transaction, the transaction amount is transferred from the debit account to an account of a merchant associated with the payment transaction.

[0027] Clause 15: A system according to any one of clauses 9 to 14, wherein the at least one processor is further programmed or configured to: receive an authorization response from the issuer system associated with the debit account, wherein the authorization response includes an authorization denial; and transmit a second authorization request to the issuer system associated with the credit account.

[0028] Clause 16: The system of any one of clauses 9 to 15, wherein during settlement of the payment transaction, the transaction amount is transferred from the credit account to an account of a merchant associated with the payment transaction.

[0029] Clause 17: A computer program product for processing a payment transaction via an agent guarantor, the computer program product comprising at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium comprising one or more instructions that, when executed by at least one processor, cause the at least one processor to: receive a transaction request associated with a payment transaction for a transaction amount, wherein the payment transaction is associated with a user, the transaction request comprising: payment device data associated with a payment device of the user, the payment device being associated with a debit account; and guarantor data identifying a guarantor associated with a credit account; transmit a hold request to an issuer system associated with the credit account to cause the issuer system associated with the credit account to hold the credit account for at least a portion of the transaction amount; and transmit an authorization request to the issuer system associated with the debit account.

[0030] Clause 18: The computer program product of Clause 17, wherein the sponsor data comprises at least one of payment device data associated with a payment device associated with the credit account and contact data associated with the sponsor.

[0031] Clause 19: A computer program product according to clause 17 or 18, wherein the one or more instructions cause the at least one processor to: transmit a message to a computing device of the guarantor based on the guarantor data; and receive a response message from the computing device of the guarantor, wherein the response message includes payment device data associated with a payment device associated with the credit account.

[0032] Clause 20: The computer program product of any of clauses 17 to 19, wherein the message includes user identification data associated with the user and causes the computing device of the sponsor to generate the response message.

[0033] Clause 21: A computer program product according to any one of clauses 17 to 20, wherein the one or more instructions cause the at least one processor to: receive an authorization response from the issuer system associated with the debit account, wherein the authorization response includes an authorization approval; and transmit a hold release message to the issuer system associated with the credit account, wherein the hold release message is configured to cause the issuer system associated with the credit account to release the hold on the credit account.

[0034] Clause 22: The computer program product of any one of clauses 17 to 21, wherein during settlement of the payment transaction, the transaction amount is transferred from the debit account to an account of a merchant associated with the payment transaction.

[0035] Clause 23: A computer program product according to any one of clauses 17 to 22, wherein the at least one processor is further programmed or configured to: receive an authorization response from the issuer system associated with the debit account, wherein the authorization response includes an authorization denial; and transmit a second authorization request to the issuer system associated with the credit account.

[0036] Clause 24: The computer program product of any one of clauses 17 to 23, wherein during settlement of the payment transaction, the transaction amount is transferred from the credit account to an account of a merchant associated with the payment transaction.

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

[0038] Additional advantages and details of the present disclosure are explained in more detail below with reference to non-limiting exemplary embodiments shown in the accompanying schematic drawings, in which:

[0039] Figure 1 A schematic diagram illustrating a system for processing payment transactions via a proxy guarantor according to some non-limiting embodiments or aspects;

[0040] Figure 2A graphical user interface illustrating a merchant website payment interface according to some non-limiting embodiments or aspects;

[0041] Figure 3 A graphical user interface illustrating a proxy checkout interface on a merchant website according to some non-limiting embodiments or aspects;

[0042] Figure 4 a graphical user interface illustrating a sponsor authorization interface according to some non-limiting embodiments or aspects;

[0043] Figure 5 A process flow diagram illustrating a method for processing a payment transaction via a proxy guarantor according to some non-limiting embodiments or aspects;

[0044] Figure 6 A process flow diagram illustrating a method for processing a payment transaction via a proxy guarantor according to some non-limiting embodiments or aspects;

[0045] Figure 7 A schematic diagram illustrating a system for settling payment transactions initiated through a proxy guarantor according to some non-limiting embodiments or aspects; and

[0046] Figure 8 A diagram illustrating steps of a method for processing a payment transaction via a proxy guarantor, according to some non-limiting embodiments or aspects. DETAILED DESCRIPTION

[0047] For the purposes of the description hereinafter, the terms "end," "upper," "lower," "right," "left," "vertical," "horizontal," "top," "bottom," "lateral," "longitudinal," and their derivatives shall refer to the present disclosure as it is oriented in the accompanying drawings. However, it should be understood that the present disclosure may employ various alternative variations and step sequences, unless expressly specified to the contrary. It should also be understood that the specific devices and processes illustrated in the drawings and described in the following description are merely exemplary embodiments or aspects of the present disclosure. Accordingly, specific dimensions and other physical characteristics related to the embodiments or aspects disclosed herein should not be considered limiting.

[0048] As used herein, the term "account data" refers to any data about one or more accounts of one or more users. Account data may include, for example, one or more account identifiers, user identifiers, transaction history, balances, credit limits, issuer institution identifiers, etc.

[0049] As used herein, the term "account identifier" may include one or more types of identifiers associated with a user account (e.g., PAN, primary account number, card number, payment card number, token, etc.). In some non-limiting embodiments, an issuing institution may provide a user with an account identifier (e.g., PAN, token, etc.) that uniquely identifies one or more accounts associated with the user. The account identifier may be embodied on a payment device (e.g., a portable payment instrument, payment card, credit card, debit card, etc.) and / or may be electronic information transmitted to the user that the user may use to make electronic payments. In some non-limiting embodiments, the account identifier may be an original account identifier, which is provided to the user when the account associated with the account identifier is created. In some non-limiting embodiments, the account identifier may be an account identifier provided to the user after the original account identifier is provided to the user (e.g., a supplemental account identifier). For example, if the original account identifier is forgotten, stolen, etc., the supplemental account identifier may be provided to the user. In some non-limiting embodiments, the account identifier may be directly or indirectly associated with the issuing institution, such that the account identifier may be a token mapped to a PAN or other type of identifier. The account identifier may be any combination of alphanumeric characters, symbols, and / or symbols, etc. The issuer institution may be associated with a bank identification number (BIN) that uniquely identifies the issuer institution.

[0050] As used herein, the term "acquirer" may refer to an entity that is authorized and / or approved by a transaction service provider to initiate transactions (e.g., payment transactions) using a payment device associated with the transaction service provider. Transactions that an acquirer may initiate may include payment transactions (e.g., purchases, original letter of credit transactions (OCTs), account funding transactions (AFTs), etc.). In some non-limiting embodiments, an acquirer may be a financial institution, such as a bank. As used herein, the term "acquirer system" may refer to one or more computer systems, computer devices, software applications, etc., operated by or on behalf of an acquirer.

[0051] As used herein, the term "card-present transaction" may refer to a payment transaction initiated using a payment device, wherein the cardholder physically presents the payment device when initiating the payment transaction using the payment device. A non-limiting example of a card-present transaction is a payment transaction initiated at a brick-and-mortar retail store with a physical POS system, during which the cardholder physically presents the payment device to the merchant.

[0052] As used herein, the term "card-not-present transaction" or "CNP transaction" may refer to a payment transaction initiated using a payment device where the cardholder does not physically have or will not present the payment device when initiating the payment transaction using the payment device. Non-limiting examples of CNP transactions include transactions initiated by mail, fax, or over the telephone or the internet.

[0053] As used herein, the terms "communication" and "transmission" may refer to the reception, acceptance, transmission, transfer, provision, etc. of information (e.g., data, signals, messages, instructions, commands, etc.). When a unit (e.g., a device, a system, a component of a device or system, a combination thereof, etc.) communicates with another unit, it 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, etc.) that is wired and / or wireless in nature. In addition, although the information sent can 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 (e.g., a third unit located between the first unit and the second 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. In some non-limiting embodiments, a message may refer to a network packet (e.g., a data packet, etc.) comprising data. It will be appreciated that many other arrangements are possible.

[0054] 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, and the like. A computing device may be a mobile device. As examples, a mobile device may include a cellular phone (e.g., a smartphone or a standard cellular phone), a portable computer, a wearable device (e.g., a watch, glasses, lenses, clothing, etc.), a personal digital assistant (PDA), and / or other similar devices. A computing device may also be a desktop computer or other form of non-mobile computer.

[0055] As used herein, the term "issuer institution" may refer to one or more entities, such as a bank, that provide accounts to customers for conducting transactions (e.g., payment transactions), such as initiating credit and / or debit payments. For example, an issuer institution may provide customers with account identifiers, such as a primary account number (PAN), that uniquely identify one or more accounts associated with the customer. The account identifier may be implemented on a payment device, such as a physical financial instrument, such as a payment card, and / or may be electronic and used for electronic payments. The term "issuer system" refers 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 system may include one or more authorization servers for authorizing transactions.

[0056] As used herein, the term "merchant" may refer to a person or entity that provides goods and / or services, or the right to use goods and / or services, to a customer based on a transaction, such as a payment transaction. The term "merchant" or "merchant system" may also refer to one or more computer systems operated by or on behalf of a merchant, such as a server computer that executes one or more software applications. As used herein, the term "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 customers, including one or more card readers, near field communication (NFC) receivers, 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.

[0057] As used herein, the term "payment device" may refer to 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 data, a keychain device or fob, an RFID transponder, a retailer discount or loyalty card, a cellular phone, an electronic wallet mobile application, a personal digital assistant (PDA), a pager, a security card, a computer, an access card, a wireless terminal, a transponder, etc. In some non-limiting embodiments, a payment device may include volatile or non-volatile memory that stores information (e.g., an account identifier, an account holder's name, etc.).

[0058] 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 that provides payment services (e.g., transaction service provider payment services, payment processing services, etc.) to one or more merchants (e.g., transaction service provider payment services, payment processing services, etc.). The payment services may be associated with the use of a payment 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.

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

[0060] 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 an issuer institution. 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 computer systems 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 server may include one or more processors and, in some non-limiting embodiments, may be operated by or on behalf of a transaction service provider.

[0061] 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.).

[0062] Non-limiting embodiments or aspects of the present disclosure relate to a method, system, and computer program product for processing payment transactions via a proxy guarantor. The non-limiting embodiments or aspects enable users without a credit account to use their debit account to initiate payment transactions with merchants that only accept credit accounts. By providing a proxy guarantor with a credit account, users can use their debit account to initiate payment transactions, and have the debit account become the account from which funds are transferred for the transaction amount during settlement. The non-limiting embodiments or aspects of the present disclosure utilize unconventional messages sent to a guarantor device during the processing of a payment transaction, which enable the guarantor to view the details of the payment transaction, enter payment device data associated with their credit account, authorize the payment transaction as a guarantor, and / or decline the transaction as a guarantor. Various transaction messages transmitted between systems involved in processing payment transactions described herein can be modified to include an indicator that the payment transaction is being processed as a proxy guarantor payment transaction (also interchangeably referred to herein as a "proxy payment transaction" or "proxy transaction"), wherein the indicator causes the payment transaction to be processed via a proxy guarantor payment transaction protocol (also referred to herein as a "proxy transaction protocol"). Non-limiting embodiments or aspects enable a hold to be placed on a guarantor's credit account during the processing of a payment transaction, allowing the transaction to be first attempted using a bank account associated with the user's debit account. With this new arrangement, the debit account can be used to pay the transaction amount even with merchants that only accept credit cards. In response to the successful processing of the payment transaction using the user's debit account, the hold on the guarantor's credit account can be released. If the processing via the bank account associated with the user's debit account fails, non-limiting embodiments or aspects enable the user's credit account to be used to pay for the transaction.

[0063] refer to Figure 1, illustrates a system 10 for processing payment transactions via a proxy guarantor, according to some non-limiting embodiments or aspects. System 10 may include a user device 12 associated with a user (e.g., a consumer), which communicates with a merchant system 14 (e.g., a merchant POS system) operated by or on behalf of a merchant providing goods and / or services. User device 12 may communicate with merchant system 14 to initiate a payment transaction between the user and the merchant. User device 12 may include a computing device capable of initiating a payment transaction with merchant system 12. In some non-limiting embodiments or aspects, a user may initiate a payment transaction with merchant system 14 by physically presenting a payment device (e.g., a debit card) to the merchant. The payment device may include payment device data associated with the user's payment device associated with a debit account to be used to process the payment transaction, such as an account identifier (e.g., PAN), a card verification value (CVV) code, a PIN number, an expiration date, etc. Payment transactions may be card-present transactions (e.g., initiated via a merchant website or merchant application) or card-not-present transactions.

[0064] refer to Figure 1-4 The payment transaction may be a payment via proxy transaction executed in accordance with a proxy transaction protocol. In some non-limiting embodiments or aspects, a merchant may only accept credit accounts to initiate a payment transaction and / or may not accept payment devices associated with debit accounts. The proxy transaction protocol allows a user without a credit account to initiate a payment transaction with the merchant using their debit account and a guarantor with a credit account.

[0065] refer to Figure 2 During initiation of a payment transaction, the user may indicate that the payment transaction is to be made via a proxy transaction, so that the system 10 processes the payment transaction according to the proxy transaction protocol. In some non-limiting embodiments or aspects, during initiation of a payment transaction, the user may be prompted to select a payment method. Figure 2A non-limiting example is shown in which a user initiating a payment transaction on a merchant website (or a user interface of a merchant application or a merchant POS device, as other non-limiting examples) is prompted to select a payment method on a checkout user interface 30. The checkout user interface 30 may include user data 32 associated with the user, such as the user's name, user contact data (e.g., residential address, shipping address, telephone number, fax number, email address, social media handle, etc.), etc. The checkout user interface 30 may include order data 34 associated with an order associated with the payment transaction. The order data 34 may include merchant data (e.g., merchant name, merchant contact data, merchant category code, etc.), prices associated with the merchant's goods and / or services, shipping and handling charges, taxes, total price, data associated with the goods (e.g., product type, product name, UPC code associated with the goods, quantity of goods, etc.), etc. The checkout user interface 30 may include a selectable option 36 to allow the user (e.g., via the user device 12 and / or merchant POS device, etc.) to indicate that the payment transaction is to be processed as a payment via a proxy transaction. Enabling the user to process a payment via a proxy transaction Figure 2 The illustrated arrangement of the checkout user interface 30 for proxy transaction initiated payment is exemplary only and may take many different forms.

[0066] refer to Figure 3 , in response to the user accessing the checkout user interface 30 ( Figure 2 ) selects payment via the proxy selectable option 36 on the user device 12 or other computing device (e.g., a merchant POS device), the proxy checkout interface 40 may display the proxy checkout interface 40. The proxy checkout interface 40 may display at least a portion of the user data 32. The proxy checkout interface 40 may enable the user to provide payment device data 42 associated with the user's payment device (e.g., a debit card) associated with the user's debit account. The proxy checkout interface 40 may allow the user to provide guarantor data 44. The guarantor data 44 may be any data capable of identifying a guarantor associated with a credit account (e.g., an individual with a credit account). The guarantor data 44 may include the guarantor's name, guarantor contact data (e.g., a residential address, a telephone number, a fax number, an email address, a social media handle, etc.), etc. In some non-limiting embodiments or aspects, the proxy checkout interface 40 may enable the user to provide payment device data associated with the guarantor's credit account. The user may submit the data provided to the proxy checkout interface 40 to initiate the payment transaction.

[0067] In some non-limiting embodiments or aspects, in order to process a payment transaction as a proxy transaction, the user may be prompted to authenticate their identity using an authentication method. The authentication method may include a two-factor authentication method, such as a one-time password (OTP) two-factor authentication process. The user's authentication may ensure that the proxy transaction was not fraudulently initiated.

[0068] Reference again Figure 1 In response to a payment transaction initiated between a user and a merchant, the merchant system 14 may generate a message (hereinafter referred to as a "transaction request") and transmit the transaction request to a payment gateway system 16 operated by or on behalf of a payment gateway associated with the merchant. The transaction request may include payment device data associated with the user's payment device associated with the debit account. The transaction request may also include guarantor data identifying a guarantor associated with the credit account. The transaction request may include other data for processing the payment transaction in accordance with the proxy transaction protocol. The transaction request may include data indicating that the payment transaction is a proxy transaction, which causes the transaction to be processed in accordance with the proxy transaction protocol.

[0069] In response to receiving the transaction request, the payment gateway system 16 may generate a message (hereinafter referred to as a "guarantor request") and transmit the guarantor request to a guarantor device 18 associated with the guarantor. The guarantor may be an individual or entity designated by the user, and the guarantor request may be transmitted to the guarantor device 18 using contact information provided by the user. The guarantor device 18 may be a computing device. The guarantor request may be based on the guarantor data in the transaction request. Figure 1 The non-limiting example shows payment gateway system 16 generating and transmitting a guarantor request and subsequently receiving a guarantor response from guarantor device 18; however, the guarantor request may be generated and transmitted by one or more other components of system 10, and the guarantor response received by one or more other components of the system, such as merchant system 14, acquirer system 20, transaction processing system 22, issuer system 24 of the user's payment device, issuer system 26 of the guarantor's payment device, or some combination of these system components.

[0070] refer to Figure 4In response to receiving the guarantor request, guarantor device 18 may display a guarantor authorization interface 50. Guarantor authorization interface 50 may display at least a portion of guarantor data 44 and / or enable the guarantor to provide guarantor data 44. Guarantor authorization interface 50 may display requestor data 52 associated with the payment transaction. Requestor data 52 may include at least a portion of user data 32, so that the guarantor is informed of who is requesting guaranty for the payment transaction. Requestor data 52 may also include details associated with the payment transaction, such as at least a portion of order data 34, so that the guarantor is informed of relevant details associated with the payment transaction.

[0071] The guarantor authorization interface 50 may enable the guarantor to provide payment device data 54 associated with the guarantor's payment device (e.g., a credit card) associated with the guarantor's credit account. Payment device data 54 may include an account identifier associated with the payment device (e.g., PAN), a CVV code, an expiration date, etc. Payment device data 54 may include data to be used to process a payment transaction as a credit transaction using the guarantor's payment device.

[0072] The guarantor authorization interface 50 may include an authorize option 56 to authorize the use of the guarantor's payment device to conduct the payment transaction as a proxy transaction and initiate further processing according to the proxy transaction protocol. The guarantor authorization interface 50 may include a reject option 58 to reject the use of the guarantor's payment device to conduct the payment transaction as a proxy transaction and terminate further processing according to the proxy transaction protocol.

[0073] refer to Figure 1 and 4 In some non-limiting embodiments or aspects, the guarantor's selection of the decline option 58 may cause the guarantor device 18 to generate a message and transmit the message to the payment gateway system 16 (hereinafter referred to as the "guarantor response"). The guarantor response may include an indicator that the guarantor declines to process the payment transaction in accordance with the proxy transaction protocol and may cause the payment transaction to be terminated. The payment gateway system 16 may transmit a notification message of the guarantor's decline of the payment transaction to the merchant system 14 and / or the user device 12, causing the payment transaction to be terminated.

[0074] refer to Figure 1 and 4 In some non-limiting embodiments or aspects, the guarantor providing payment device data 54 and selecting the authorization option 56 may cause the guarantor device 18 to generate a message (hereinafter referred to as the "guarantor response") and transmit the message to the payment gateway system 16. The guarantor response may include the payment device data 54 associated with the guarantor's payment device associated with the credit account. The guarantor response may include an indicator that the guarantor authorizes processing of the payment transaction in accordance with the proxy transaction protocol.

[0075] In some non-limiting embodiments or aspects, in order to process a payment transaction as a proxy transaction, a guarantor may be prompted to authenticate his / her identity using an authentication method. The authentication method may include a two-factor authentication method, such as a one-time password (OTP) two-factor authentication process. Authentication by the guarantor may ensure that the proxy transaction was not fraudulently initiated.

[0076] Continue to refer Figure 1 In response to the guarantor's response including authorization to continue processing the proxy transaction, the payment gateway system 16 may generate and transmit a message (hereinafter referred to as a "processing message") to cause the proxy transaction to be processed in accordance with the proxy transaction agreement by an acquirer system 20 associated with the merchant or operated on behalf of the acquirer, a transaction processing system 22 operated by a transaction service provider associated with the user and / or the guarantor's payment device or operated on behalf of the transaction service provider, an issuer system 24 operated by the issuer of the user's payment device or operated on behalf of the issuer, and / or an issuer system 26 operated by the issuer of the guarantor's payment device or operated on behalf of the issuer.

[0077] The processing message may include a hold request to be transmitted to the issuer system 26 associated with the guarantor's payment device, the hold request causing the issuer system 26 to place a hold on the guarantor's credit account for the transaction amount associated with the payment transaction, as described below. The hold request may include the requested length of time the hold on the guarantor's credit account is to be held. In some non-limiting embodiments or aspects, the hold may be automatically released upon expiration of the hold length. In some non-limiting embodiments or aspects, upon expiration of the hold length, the system 10 may process the proxy payment transaction using the guarantor's credit account. The processing message may include an authorization request causing the issuer system 24 of the user's payment device and / or the issuer system 26 of the guarantor's payment device to determine an authorization decision associated with the payment transaction, as described below. The processing message may include an indicator that the payment transaction is a proxy transaction processed in accordance with a proxy transaction protocol.

[0078] Continue to refer Figure 1, the payment gateway system 16 may transmit the processing message to the relevant acquirer system 20 associated with the merchant. The acquirer system 20 may generate a message (hereinafter referred to as the "second processing message") and transmit the message to the relevant transaction processing system 22. The transaction processing system 22 may be a transaction processing system associated with the user's payment device and / or a transaction processing system associated with the guarantor's payment device. In some non-limiting embodiments, the user's payment device and the guarantor's payment device may be associated with the same transaction processing system or separate transaction processing systems. The second processing message may include at least a portion of the processing message. The second processing message may include an indicator that the payment transaction is a proxy transaction processed in accordance with the proxy transaction protocol.

[0079] Continue to refer Figure 1 , the transaction processing system 22 may transmit a message (hereinafter referred to as a "hold request") to the issuer system 26 of the guarantor's payment device. The hold request may cause the issuer system 26 of the guarantor's payment device to place a hold on the guarantor's credit account for at least a portion of the transaction amount. The hold request may include an indicator that the payment transaction is a proxy transaction processed in accordance with a proxy transaction protocol. In some non-limiting embodiments or aspects, the hold request may cause the issuer system 26 of the guarantor's payment device (e.g., associated with a credit account) to determine an initial authorization decision (also an example of an alternate authorization decision as described below) associated with the payment transaction for the transaction amount. The initial authorization decision may be to approve the transaction, deny the transaction, and / or at least partially approve the transaction. In some non-limiting embodiments, denying the authorization decision or at least partially denying the transaction may result in terminating the processing of the payment transaction. In some non-limiting embodiments, approving the authorization decision may result in allowing the proxy payment transaction to proceed to completion (e.g., authorization, clearing, and settlement). In some non-limiting embodiments, the initial authorization decision is not determined by the issuer system 26 of the guarantor's payment device in response to the hold request.

[0080] The issuer system 26 of the guarantor's payment device may transmit a message generated in response to placing a hold on the guarantor's credit account (hereinafter referred to as a "hold response") to the transaction processing system 22. The hold response may include an indicator that a hold has been placed on the guarantor's credit account for at least a portion of the transaction amount. The hold response may include an initial authorization decision.

[0081] Continue to refer Figure 1In response to receiving the hold response and / or simultaneously transmitting the hold request, the transaction processing system 22 may transmit a message (hereinafter referred to as an "authorization request") to the issuer system 24 of the user's payment device. The authorization request may include an indicator that the payment transaction is a proxy transaction processed in accordance with the proxy transaction protocol. The authorization request may enable the issuer system 24 of the user's payment device (e.g., associated with a debit account) to determine an authorization decision associated with the payment transaction for the transaction amount. The authorization decision may be used to approve the transaction, deny the transaction, and / or at least partially approve the transaction. The authorization decision may be determined based on the transaction amount and the funds available in the user's debit account (e.g., funds in the user's account sufficient to cover the transaction amount). The issuer system 24 of the user's payment device may transmit a message (hereinafter referred to as an "authorization response") to the transaction processing system 22. The authorization response may include the authorization decision. The transaction processing system 22 may continue to process the proxy transaction in accordance with the proxy transaction protocol based on the authorization response.

[0082] In response to the issuer system 24 of the user's payment device approving the payment transaction for the transaction amount, the transaction processing system 22 may continue to process the payment transaction using the user's payment device. The transaction processing system 22 may generate a message (hereinafter referred to as a "hold release message") and transmit the message to the issuer system 26 of the guarantor's payment device, causing the issuer system 26 of the guarantor's payment device to release the hold on the guarantor's credit account for a portion of the transaction amount. The transaction processing system 22 may transfer funds for the transaction amount from the user's debit account to the merchant's account to settle the payment transaction.

[0083] In response to the issuer system 24 of the user's payment device rejecting the payment transaction for the transaction amount, the transaction processing system 22 may continue to process the payment transaction using the guarantor's payment device. The transaction processing system 22 may generate a message (hereinafter referred to as the "alternative authorization message") and transmit the message to the issuer system 26 of the guarantor's payment device so that the issuer system 26 of the guarantor's payment device determines an alternative authorization decision for the transaction amount of the payment transaction. The alternative authorization decision may be used to approve the transaction, reject the transaction, and / or at least partially approve the transaction. The issuer system 26 of the guarantor's payment device may transmit a message (hereinafter referred to as the "alternative authorization response") to the transaction processing system 22. The alternative authorization response may include an alternative authorization decision. In response to the alternative authorization decision approving the payment transaction, the transaction processing system 22 may transfer funds for the transaction amount from a credit account associated with the guarantor (e.g., an account of the guarantor's creditor) to the merchant's account to settle the payment transaction.

[0084] In some non-limiting embodiments or aspects, the transaction processing system 22 may transfer funds for the transaction amount from a credit account associated with the guarantor (e.g., an account of the guarantor's creditor) to an account of the merchant to settle the payment transaction without transmitting a substitute authorization message and a substitute authorization response between the transaction processing system 22 and the issuer system 26 of the guarantor's payment device. This may occur in response to the issuer system 26 of the guarantor's payment device constituting a substitute authorization decision to approve the transaction. In this manner, the issuer system 26 of the guarantor's payment device may pre-authorize the payment transaction for the transaction amount before sending an authorization request to the issuer system 24 of the user's payment device in response to the issuer system 24 of the user's payment device rejecting the payment transaction.

[0085] In response to the issuer system 24 of the user's payment device approving only a portion of the payment transaction for the transaction amount, the transaction processing system 22 may continue to process the payment transaction for the portion of the transaction amount using the user's payment device and process the payment transaction for the remaining portion of the transaction amount using the guarantor's payment device. The transaction processing system 22 may generate a hold release message and transmit the hold release message to the issuer system 26 of the guarantor's payment device, causing the issuer system 26 of the guarantor's payment device to release the hold on the guarantor's credit account for the portion of the transaction amount covered by the user's payment device. The transaction processing system 22 may transfer funds for the transaction amount covered by the user's payment device from the user's debit account to the merchant's account to settle the payment transaction. As previously described, the remaining portion of the transaction amount may be covered by the guarantor's credit account, allowing the transaction processing system 22 to transfer funds for the remaining portion of the transaction amount covered by the guarantor's payment device from a credit account associated with the guarantor (e.g., an account of the guarantor's creditor) to the merchant's account to settle the payment transaction.

[0086] Continue to refer Figure 1 , the transaction processing system 22 may transmit a message (hereinafter referred to as a "processing response") to the acquirer system 20. The processing response may include data associated with processing the payment transaction. The processing response may include an authorization decision from the issuer system 24 of the user's payment device and / or an authorization decision from the issuer system 26 of the guarantor's payment device. The processing response may include data that identifies or can be used to determine whether to use the user's payment device, the guarantor's payment device, or some combination of the user's and guarantor's payment devices to complete the payment transaction.

[0087] Continue to refer Figure 1, the acquirer system 20 may transmit a message (hereinafter referred to as the "second processing response") to the payment gateway system 16. The second processing response may include at least a portion of the processing response. The payment gateway system 16 may transmit a notification message to the merchant system 14, the user device 12, and / or the guarantor device 18, wherein the notification message may include at least a portion of the processing response to inform the merchant, the guarantor, and / or the user how the proxy transaction was processed to completion, including settlement.

[0088] Continue to refer Figure 1 , in a non-limiting example of a system 10 for processing payment transactions via a proxy guarantor, a payment gateway system 16, an acquirer system 20, and a transaction processing system 22 are shown. In some non-limiting embodiments or aspects, any functionality described as being performed by one of the payment gateway system 16, the acquirer system 20, and / or the transaction processing system 22 may alternatively be performed by another of these components. Furthermore, in some non-limiting embodiments or aspects, one of the payment gateway system 16, the acquirer system 20, and the transaction processing system 22 may be omitted from the system, and the functionality associated with such omitted component may be performed by another of the components that are not omitted. In some non-limiting embodiments or aspects, the acquirer system 20 and the payment gateway system 16 may be omitted, such that the transaction processing system 22 performs the functionality described as being associated with the acquirer system 20 and the payment gateway system 16.

[0089] refer to Figure 5 , illustrates a method 60 for processing a payment transaction via a proxy guarantor using a user's payment device, according to some non-limiting embodiments or aspects. At step S1, a user device 12 may initiate a proxy guarantor payment transaction with a merchant system 14 by providing the user's payment device having payment device data associated with a debit account stored thereon. The user may specify guarantor data identifying a guarantor with a credit account for processing proxy payment transactions to initiate a proxy payment transaction with the merchant system 14. At step S2, the merchant system 14 may generate a transaction request and transmit the transaction request to the payment gateway system 16.

[0090] At step S3, the payment gateway system 16 may generate a guarantor request and transmit the guarantor request to the guarantor device 18. At step S4, the guarantor device 18 may generate a guarantor response and transmit the guarantor response to the payment gateway system 16, and the guarantor response may include payment device data associated with the guarantor's credit account.

[0091] At step S5, the payment gateway system 16 may transmit a processing message to the acquirer system 20. At step S6, the acquirer system 20 may transmit a second processing message to the transaction processing system 22.

[0092] At step S7, the transaction processing system may transmit the hold request to the issuer system 26 of the guarantor's payment device, so that the issuer system 26 of the guarantor's payment device places a hold on the guarantor's credit account for at least a portion of the transaction amount. At step S8, the issuer system 26 of the guarantor's payment device may place a hold on the guarantor's credit account for a portion of the transaction amount, generate a hold response, and transmit the hold response to the transaction processing system 22.

[0093] At step S9, the transaction processing system 22 may transmit the authorization request to the issuer system 24 of the user's payment device so that the issuer system 24 of the user's payment device determines the authorization decision associated with the proxy payment transaction. At step S10, the issuer system 24 of the user's payment device may determine that the authorization decision is to approve the proxy payment transaction for the transaction amount, generate an authorization response including the approval authorization decision, and transmit the authorization response to the transaction processing system 22.

[0094] At step S11 , the transaction processing system 22 may transmit a hold release message to the issuer system 26 of the guarantor's payment device, so that the issuer system 26 of the guarantor's payment device releases the hold on the guarantor's credit account for part of the transaction amount.

[0095] At step S12, the transaction processing system 22 may transmit the processing response to the acquirer system 20. At step S13, the acquirer system 20 may transmit the second processing response to the payment gateway system 16.

[0096] At step S14, payment gateway system 16 may transmit a message to merchant system 14 to notify merchant system 14 that the proxy payment transaction has been approved. The message may notify merchant system 14 that the proxy payment transaction is being processed using the user's debit account.

[0097] At step S15, the merchant system 14 may transmit a message to the user device 12 to notify the user device 12 that the proxy payment transaction has been approved. The message may notify the user device 12 that the proxy payment transaction is being processed using the user's debit account. In some non-limiting embodiments or aspects, the payment gateway system 16 may notify the user device 12 via the merchant system 14.

[0098] At step S16, payment gateway system 16 may transmit a message to guarantor device 18 to notify guarantor device 18 that the proxy payment transaction has been approved. The message may notify guarantor device 18 that the proxy payment transaction is being processed using the user's debit account.

[0099] refer to Figure 6, showing a method 70 for processing a payment transaction via a proxy guarantor using a guarantor's payment device according to some non-limiting embodiments or aspects. With respect to steps P1-P9, each step is respectively combined with Figure 5 Each of the steps S1-S9 described is the same.

[0100] At step P10, the issuer system 24 of the user's payment device may determine that the authorization decision is to decline the proxy payment transaction for the transaction amount, and generate an authorization response including the declined authorization decision and transmit the authorization response to the transaction processing system 22. The declined authorization decision may be based on the user's debit account not having sufficient funds to cover the transaction amount.

[0101] At step P11, the transaction processing system 22 may transmit a substitute authorization message to the issuer system 26 of the guarantor's payment device, so that the issuer system 26 of the guarantor's payment device determines the authorization decision associated with the proxy payment transaction. At step P12, the issuer system 26 of the guarantor's payment device may determine that the authorization decision is to approve the proxy payment transaction for the transaction amount, generate a substitute authorization response including the approval authorization decision, and transmit the substitute authorization response to the transaction processing system 22. In some non-limiting embodiments or aspects, steps P11 and P12 may be performed before and / or after the issuer system 24 of the user's payment device determines that its authorization decision is to deny the proxy payment transaction (in steps P9-P10). In some non-limiting embodiments or aspects, steps P11 and P12 may be performed simultaneously with steps P7 and P8.

[0102] At step P13, the transaction processing system 22 may transmit the processing response to the acquirer system 20. At step P14, the acquirer system 20 may transmit the second processing response to the payment gateway system 16.

[0103] At step P15, payment gateway system 16 may transmit a message to merchant system 14 to notify merchant system 14 that the proxy payment transaction has been approved. The message may notify merchant system 14 that the proxy payment transaction is being processed using the guarantor's credit account.

[0104] At step P16, merchant system 14 may transmit a message to user device 12 to notify user device 12 that the proxy payment transaction has been approved. The message may notify user device 12 that the proxy payment transaction is being processed using the guarantor's credit account. In some non-limiting embodiments or aspects, payment gateway system 16 may notify user device 12 via merchant system 14.

[0105] At step P17, payment gateway system 16 may transmit a message to guarantor device 18 to notify guarantor device 18 that the proxy payment transaction has been approved. The message may notify guarantor device 18 that the proxy payment transaction is being processed using the guarantor's credit account.

[0106] refer to Figure 7 , illustrates a system 80 for settling payment transactions initiated using a proxy guarantor, according to some non-limiting embodiments or aspects. System 80 may include a settlement processor 82 operated by or on behalf of at least one of a payment gateway, an acquirer, a transaction service provider, and the issuer of a user's and / or guarantor's payment device. In some non-limiting embodiments or aspects, settlement processor 82 may communicate with at least one of payment gateway system 16, acquirer system 20, transaction processing system 22, the issuer system 24 of the user's payment device, and the issuer system 26 of the guarantor's payment device, and receive messages from at least one of these systems to cause settlement processor 82 to settle the proxy payment transaction. In some non-limiting embodiments or aspects, at least one of merchant system 14, payment gateway system 16, and acquirer system 20 may transmit settlement documents (directly or indirectly) to settlement processor 82 to cause the proxy payment transaction to be settled according to a proxy transaction agreement.

[0107] The settlement processor 82 can communicate with a merchant account 84 associated with a merchant in a proxy payment transaction, a user account 86 associated with a user in a proxy payment transaction (e.g., a debit account of the user), and / or a guarantor account 88 associated with a guarantor in a proxy payment transaction (e.g., an account of the guarantor's creditor) to enable funds to be transferred to and / or from the merchant account 84, the user account 86, and / or the guarantor account 88 to effectuate a funds transfer (e.g., to settle the proxy payment transaction).

[0108] Continue to refer Figure 7In some non-limiting embodiments or aspects where a proxy payment transaction is processed using a user's payment device, settlement processor 82 may communicate with user account 86 and merchant account 84 to transfer funds for the transaction amount from user account 86 to merchant account 84 to settle the payment transaction. In some non-limiting embodiments or aspects where a proxy payment transaction is processed using a guarantor's payment device, settlement processor 82 may communicate with guarantor account 88 and merchant account 84 to transfer funds for the transaction amount from guarantor account 88 to merchant account 84 to settle the payment transaction. In some non-limiting embodiments or aspects where a proxy payment transaction is processed using the user's payment device for a portion of the transaction amount and the guarantor's payment device for the remainder of the transaction amount, settlement processor 82 may communicate with user account 86, guarantor account 88, and merchant account 84 to transfer funds for a portion of the transaction amount from user account 86 to merchant account 84 and transfer funds for the remainder of the transaction amount from guarantor account 88 to merchant account 84 to settle the payment transaction.

[0109] Continue to refer Figure 7 In some non-limiting embodiments or aspects, in response to a user requesting that a payment transaction be processed according to the proxy transaction protocol and / or in response to successfully processing a payment transaction according to the proxy transaction protocol, settlement processor 82 may transfer additional proxy transaction processing fees (in excess of the transaction amount) from user account 86 to at least one of guarantor account 88 and merchant account 84.

[0110] refer to Figure 8 , illustrates a method 90 for processing a payment transaction via a proxy guarantor, according to some non-limiting embodiments or aspects. At step 92, the payment gateway system 16, the acquirer system 20, and / or the transaction processing system 22 may receive a transaction request associated with a payment transaction for a transaction amount. The payment transaction may be associated with a user. The transaction request may include payment device data associated with the user's payment device and debit account, and guarantor data identifying a guarantor associated with a credit account.

[0111] At step 94 , the payment gateway system 16 , the acquirer system 20 , and / or the transaction processing system 22 may transmit a message (guarantor request) to the guarantor device 18 based on the guarantor data.

[0112] At step 96, payment gateway system 16, acquirer system 20, and / or transaction processing system 22 may receive a response message (guarantor response) from guarantor device 18. The guarantor response may include payment device data associated with the payment device associated with the guarantor's credit account.

[0113] At step 98, the payment gateway system 16, the acquirer system 20, and / or the transaction processing system 22 may transmit a hold request to the issuer system 26 of the guarantor's payment device to cause the issuer system 26 of the guarantor's payment device to place a hold on the guarantor's credit account for at least a portion of the transaction amount.

[0114] At step 100 , the payment gateway system 16 , the acquirer system 20 , and / or the transaction processing system 22 may transmit an authorization request to the issuer system 24 of the user's payment device.

[0115] In another non-limiting embodiment or aspect, a computer program product for processing payment transactions via a proxy guarantor includes at least one non-transitory computer-readable medium including program instructions that, when executed by at least one processor, cause the at least one processor to perform one of the methods previously described. The at least one processor may include at least one of: a merchant system 14, a payment gateway system 16, an acquirer system 20, a transaction processing system 22, an issuer system 24 of a user's payment device, and an issuer system 26 of a guarantor's payment device.

[0116] Although the present disclosure has been described in detail for purposes of illustration based on what are presently considered to be the most practical and preferred embodiments, it should be understood that such details are intended for that purpose only and that the present disclosure is not limited to the disclosed embodiments, but on the contrary is intended to cover modifications and equivalent arrangements within the spirit and scope of the appended claims. For example, it should be understood that the present disclosure contemplates that, to the extent possible, one or more features of any embodiment can be combined with one or more features of any other embodiment.

Claims

1. A method for processing a payment transaction via a proxy guarantor, comprising: Receiving, using at least one processor, a transaction request associated with a payment transaction for a transaction amount, wherein the payment transaction is associated with a user, the transaction request comprising: payment device data associated with a payment device of the user, the payment device being associated with a debit account; and guarantor data identifying a guarantor associated with the credit account and different from the user; communicating, using at least one processor, a hold request to an issuer system associated with the credit account to cause the issuer system associated with the credit account to place a hold on the credit account for at least a portion of the transaction amount; and transmitting, using at least one processor, an authorization request to an issuer system associated with the debit account, The method further comprises: transmitting, using at least one processor, a message to a computing device of the sponsor based on the sponsor data, wherein the message includes user identification data associated with the user and causes the computing device of the sponsor to generate a response message; and The response message is received from the computing device of the sponsor using at least one processor, wherein the response message includes payment device data associated with a payment device associated with the credit account. 2 . The method of claim 1 , wherein the guarantor data comprises at least one of payment device data associated with a payment device associated with the credit account and contact data associated with the guarantor.

3. The method according to claim 1, further comprising: receiving, using at least one processor, an authorization response from the issuer system associated with the debit account, wherein the authorization response includes an authorization approval; as well as A hold release message is transmitted, using at least one processor, to the issuer system associated with the credit account, the hold release message being configured to cause the issuer system associated with the credit account to release the hold on the credit account.

4. The method of claim 3, wherein during settlement of the payment transaction, the transaction amount is transferred from the debit account to an account of a merchant associated with the payment transaction.

5. The method according to claim 1, further comprising: receiving, using at least one processor, an authorization response from the issuer system associated with the debit account, wherein the authorization response includes an authorization denial; as well as A second authorization request is communicated, using at least one processor, to the issuer system associated with the credit account.

6. The method of claim 5, wherein during settlement of the payment transaction, the transaction amount is transferred from the credit account to an account of a merchant associated with the payment transaction.

7. A system for processing payment transactions via a proxy guarantor, the system comprising at least one processor programmed or configured to: receiving a transaction request associated with a payment transaction for a transaction amount, wherein the payment transaction is associated with a user, the transaction request comprising: payment device data associated with a payment device of the user, the payment device being associated with a debit account; as well as guarantor data identifying a guarantor associated with the credit account and different from the user; transmitting a hold request to an issuer system associated with the credit account to cause the issuer system associated with the credit account to place a hold on the credit account for at least a portion of the transaction amount; and transmitting an authorization request to the issuer system associated with the debit account, Wherein, the at least one processor is further programmed or configured to: transmitting a message to a computing device of the sponsor based on the sponsor data, wherein the message includes user identification data associated with the user and causes the computing device of the sponsor to generate a response message; and The response message is received from the computing device of the sponsor, wherein the response message includes payment device data associated with a payment device associated with the credit account.

8. The system of claim 7, wherein the sponsor data comprises at least one of payment device data associated with a payment device associated with the credit account and contact data associated with the sponsor.

9. The system of claim 7, wherein the at least one processor is further programmed or configured to: receiving an authorization response from the issuer system associated with the debit account, wherein the authorization response includes an authorization approval; and A hold release message is transmitted to the issuer system associated with the credit account, the hold release message being configured to cause the issuer system associated with the credit account to release the hold on the credit account.

10. The system of claim 9, wherein during settlement of the payment transaction, the transaction amount is transferred from the debit account to an account of a merchant associated with the payment transaction.

11. The system of claim 7, wherein the at least one processor is further programmed or configured to: receiving an authorization response from the issuer system associated with the debit account, wherein the authorization response includes an authorization denial; and A second authorization request is transmitted to the issuer system associated with the credit account.

12. The system of claim 11, wherein during settlement of the payment transaction, the transaction amount is transferred from the credit account to an account of a merchant associated with the payment transaction.

13. A computer program product for processing a payment transaction via a proxy guarantor, the computer program product comprising at least one non-transitory computer-readable medium comprising one or more instructions that, when executed by at least one processor, cause the at least one processor to: receiving a transaction request associated with a payment transaction for a transaction amount, wherein the payment transaction is associated with a user, the transaction request comprising: payment device data associated with a payment device of the user, the payment device being associated with a debit account; as well as guarantor data identifying a guarantor associated with the credit account and different from the user; transmitting a hold request to an issuer system associated with the credit account to cause the issuer system associated with the credit account to place a hold on the credit account for at least a portion of the transaction amount; and transmitting an authorization request to the issuer system associated with the debit account, wherein the one or more instructions cause the at least one processor to: transmitting a message to a computing device of the sponsor based on the sponsor data, wherein the message includes user identification data associated with the user and causes the computing device of the sponsor to generate a response message; as well as The response message is received from the computing device of the sponsor, wherein the response message includes payment device data associated with a payment device associated with the credit account.

14. The computer program product of claim 13, wherein the sponsor data comprises at least one of payment device data associated with a payment device associated with the credit account and contact data associated with the sponsor.

15. The computer program product of claim 13, wherein the one or more instructions cause the at least one processor to: receiving an authorization response from the issuer system associated with the debit account, wherein the authorization response includes an authorization approval; and A hold release message is transmitted to the issuer system associated with the credit account, the hold release message being configured to cause the issuer system associated with the credit account to release the hold on the credit account.

16. The computer program product of claim 15, wherein during settlement of the payment transaction, the transaction amount is transferred from the debit account to an account of a merchant associated with the payment transaction.

17. The computer program product of claim 13, wherein the one or more instructions cause the at least one processor to: receiving an authorization response from the issuer system associated with the debit account, wherein the authorization response includes an authorization denial; and A second authorization request is transmitted to the issuer system associated with the credit account.

18. The computer program product of claim 17, wherein during settlement of the payment transaction, the transaction amount is transferred from the credit account to an account of a merchant associated with the payment transaction.

Images