Systems and methods for approving electronic payments

Abstract

This disclosure relates to a method for conducting interbank payment transactions, the method comprising: generating an electronic consent token, which is cryptographically signed and indicates at least the payment amount and / or payment period, by a consumer device; transmitting the electronic consent token to a recipient device (202) via a payment platform (210); transmitting a payment authorization request, which includes the electronic consent token, to a consumer PSP server (208) via the payment platform (210); initiating one or more interbank payments by the recipient device (202) or a recipient settlement service provider (PSP) server (206); and approving or not approving the payment authorization request by the consumer PSP server (208) based on the payment amount and / or payment period indicated in the electronic consent token.

Description

Technical Field

[0001] The present disclosure generally relates to non-card payment methods based on account numbers such as IBAN (International Bank Account Number), and particularly to non-card payments initiated by or through a payee.

Background Art

[0002] In a card payment environment, payment is initiated by authentication of the card owner at the point of sale. An acquirer is used to initiate a payment approval request sent to the card issuer. The card issuer determines the result (approval) of the transaction. The position of the acquirer makes it difficult for a seller to engage in improper conduct because a malicious seller can be excluded from the system at the beginning of the approval process. Further, since the seller's account information is managed by the acquirer, which is also responsible for settling funds based on the accounts stored in the system, it also makes it more difficult for improper conduct here.

[0003] Non-card payments that support rapid bank transfers between accounts are an alternative to card payments. SEPA (Single Euro Payments Area) is an EU settlement integration concept aimed at simplifying bank transfers between euro-denominated accounts. SEPA transfers are based on IBAN (International Bank Account Number) information that identifies the accounts of payment service users. Two SEPA bank account transfer mechanisms known as SCT (SEPA Credit Transfer) and SCT Inst (SEPA Instant Credit Transfer) are available. The SCT settlement mechanism provides a relatively rapid transfer, while SCT Inst provides an immediate credit from one account to another, usually in less than 10 seconds and in exceptional situations in less than 20 seconds.

Summary of the Invention

Problems to be Solved by the Invention

[0004] SEPA Request to Pay (SRTP) is a payment protocol that enables a payee to initiate a payment request to a payer.

[0005] While SRTP promises to provide a rapid non-card payment solution, implementing a payment system based on this protocol presents technical challenges. Specifically, a mechanism is needed where each payment transaction can be authorized by the payer, but such a mechanism could place a relatively heavy burden on payment network infrastructure in terms of energy consumption and processing resources. Furthermore, payments should be executed in a clear manner so that parties can trust information indicating whether or not a payment has been made; however, current solutions do not adequately address this issue because SRTP, at least partially, does not address the execution of payments themselves, but only the confirmation or rejection of payment requests. A further drawback of SRTP solutions is their lack of versatility; for example, they cannot handle certain complex transaction types where payer confirmation and one or more payments themselves are temporally separated.

[0006] Therefore, improvements to payment methods and systems are necessary for non-card payments. [Means for solving the problem]

[0007] According to one embodiment, a method is provided for executing an interbank payment transaction, the method comprising: receiving one or more consent requests for payment, indicating at least a payment amount and / or payment period, from a recipient device via a payment platform; requesting consumer consent for one or more payments via a consumer device; generating an electronic consent token, cryptographically signed and indicating at least a payment amount and / or payment period, by the consumer device in response to the consumer consent; transmitting the electronic consent token to the recipient device via the payment platform; and transmitting a payment authorization request, including the electronic consent token, to a consumer payment service provider (PSP) server via the payment platform, thereby initiating one or more interbank payments by the recipient device or a consumer payment service provider (PSP) server; and approving or not approving the payment authorization request by the consumer PSP server based on the payment amount and / or payment period indicated in the electronic consent token.

[0008] According to one embodiment, the consumer PSP server is configured to approve or disapprove a payment based on a comparison of the payment amount in the payment approval request with the payment amount indicated in the electronic consent token, and / or verification of whether the payment period has elapsed, and / or verification of whether the payment can proceed, for example, by taking into account the available funds in the consumer's account.

[0009] According to one embodiment, the electronic consent token is stored in the memory of the payment platform.

[0010] According to one embodiment, the method further allows a consumer device or recipient device to request modification or revocation of an electronic consent token in a memory storage device.

[0011] According to one embodiment, a wallet application on a consumer device, or a remote wallet application accessible from the consumer device, is configured to cryptographically sign the electronic consent token using the private key of a public / private key pair, and the consumer PSP server is configured to verify the signature of the electronic consent token using the public key of the public / private key pair.

[0012] According to one embodiment, each of one or more inter-account payments is executed using a two-step method, which includes a first step of the recipient PSP server obtaining a payment authorization response message from the consumer PSP server, signifying a guarantee of payment from the consumer PSP server, and a second step of the recipient PSP server sending a payment capture request command to the consumer PSP server requesting the execution of the payment in response to the receipt of the payment authorization response message.

[0013] According to one embodiment, the method further requires consumer consent for one or more payments and authenticates the consumer via a consumer device before generating an electronic consent token.

[0014] According to one embodiment, when initiating one or more inter-account payments, a first inter-account payment is initiated by the recipient device or recipient settlement service provider server by sending a first payment authorization request including an electronic consent token to the consumer PSP server via the payment platform, and the consumer PSP server approves or disapproves the first payment authorization request based on the payment amount and / or payment period indicated in the electronic consent token; a second inter-account payment is initiated by the recipient device or recipient settlement service provider (PSP) server by sending a second payment authorization request including an electronic consent token to the consumer PSP server via the payment platform, and the consumer PSP server approves or disapproves the second payment authorization request based on the payment amount and / or payment period indicated in the electronic consent token.

[0015] According to one embodiment, the recipient device is the device of the recipient of the payment transaction, and the electronic consent token has one or more elements that link the electronic consent token to the recipient's bank account.

[0016] In a further embodiment, a payment system is provided for executing interbank payment transactions, comprising: a payment platform configured to receive from a recipient device one or more consent requests for payments indicating at least a payment amount and / or payment period; and a consumer device configured to obtain the consumer's consent for one or more payments and, in accordance with the consumer's consent, generate an electronic consent token that is cryptographically signed indicating at least a payment amount and / or payment period, and further configured to transmit the electronic consent token directly to the recipient device or via the payment platform, wherein the recipient device or a recipient settlement service provider (PSP) server of the payment system is further configured to initiate one or more interbank payments by transmitting a payment authorization request including the electronic consent token to the consumer settlement service provider (PSP) server, for example, via the payment platform, and the consumer PSP server is configured to approve or disapprove the payment authorization request based on the payment amount and / or payment period indicated in the electronic consent token.

[0017] According to one embodiment, the consumer PSP server is configured to approve or disapprove a payment based on a comparison of the payment amount in the payment approval request with the payment amount indicated in the electronic consent token, and / or verification of whether the payment period has elapsed, and / or verification of whether the payment can proceed, for example, by taking into account the available funds in the consumer's account.

[0018] According to one embodiment, the consumer device or recipient device is further configured to request modification or revocation of an electronic consent token in a memory storage device.

[0019] According to one embodiment, the payment platform has a memory for storing electronic consent tokens.

[0020] According to one embodiment, a wallet application on a consumer device, or a remote wallet application accessible from the consumer device, is configured to cryptographically sign the electronic consent token using the private key of a public / private key pair, and the consumer PSP server is configured to verify the signature of the electronic consent token using the public key of the public / private key pair.

[0021] According to one embodiment, each of one or more inter-account payments is executed using a two-step method, which includes a first step of the recipient PSP server obtaining a payment authorization response message from the consumer PSP server, signifying a guarantee of payment from the consumer PSP server, and a second step of the recipient PSP server sending a payment capture request command to the consumer PSP server requesting the execution of the payment in response to the receipt of the payment authorization response message.

[0022] According to one embodiment, the consumer device is further configured to authenticate the consumer after requesting the consumer's consent for one or more payments, but before generating an electronic consent token.

[0023] According to one embodiment, when a recipient device or recipient settlement service provider server initiates one or more inter-account payments, a first inter-account payment is initiated by sending a first payment authorization request, including an electronic consent token, to a consumer PSP server via the payment platform, and the consumer PSP server is configured to approve or disapprove the first payment authorization request based on the payment amount and / or payment period indicated in the electronic consent token. A second inter-account payment is initiated by the recipient device or recipient settlement service provider server by sending a second payment authorization request, including an electronic consent token, to the consumer PSP server via the payment platform, and the consumer PSP server is configured to approve or disapprove the second payment authorization request based on the payment amount and / or payment period indicated in the electronic consent token.

[0024] According to a further aspect, a method for performing an inter-account payment transaction, comprising: transmitting a payment approval request including a payment amount and an electronic consent token defining a payment period and / or a payment limit approved by a payer, to a payment platform by a payee payment service provider (PSP) server; transmitting the payment approval request to a consumer PSP server by the payment platform; verifying by the consumer PSP server whether the payment can be accepted; if it is determined that the payment can be accepted, indicating that the payment can be accepted and transmitting a payment approval response meaning a guarantee of payment from the consumer PSP server to the payment platform; in response to the payment approval response, transmitting a payment capture request for requesting execution of the payment, from the payee PSP server to the consumer PSP server via the payment platform; and verifying by the consumer PSP server that the payment is in progress and responding to the payment capture request. A method is provided.

[0025] According to one embodiment, the electronic consent token is cryptographically signed, and when verifying whether the payment can be accepted by the consumer PSP server, the signature of the electronic consent token is verified, and if the signature is invalid, the payment is rejected.

[0026] According to one embodiment, when verifying whether the payment can be accepted by the consumer PSP server, the payment period and / or the payment limit defined by the electronic consent token are verified, and / or it is verified that there is sufficient funds in the consumer's account.

[0027] According to one embodiment, the electronic consent token is stored in the memory of the payment platform.

[0028] According to one embodiment, a wallet application of a consumer device, or a remote wallet application accessible from the consumer device, is configured to cryptographically sign an electronic consent token using a private key of a public key / private key pair, and a consumer PSP server is configured to verify the signature of the electronic consent token using the public key of the public key / private key pair.

[0029] According to one embodiment, the electronic consent token is stored in a memory storage device of the payment platform.

[0030] According to one embodiment, the recipient device is the device of the recipient of an inter-account payment transaction, and the electronic consent token has one or more elements that associate the electronic consent token with the recipient's bank account.

[0031] In a further aspect, there is provided a payment system for performing an inter-account payment transaction, comprising a recipient payment service provider (PSP) server configured to send a payment approval request including a payment amount and an electronic consent token that defines a payment period and / or a payment limit approved by the payer to a payment platform, a payment platform configured to send the payment approval request to a consumer PSP server, and a consumer PSP server configured to verify whether a payment can be accepted, which means a guarantee of payment from the consumer PSP server. If it is determined that the payment can be accepted, the consumer PSP server is configured to send a payment approval response indicating that the payment can be accepted to the payment platform. The recipient PSP server is configured to send a payment capture request command to the consumer PSP server via the payment platform in response to the payment approval response. The consumer PSP server is further configured to respond to the payment capture request by confirming that the payment is in progress.

[0032] According to one embodiment, the consumer PSP server is configured to verify whether a payment is acceptable by verifying the payment period and / or payment limit specified in the electronic consent token, and / or verifying that there are sufficient funds in the consumer's account.

[0033] According to one embodiment, the electronic consent token is cryptographically signed, and when the consumer PSP server verifies whether payment is acceptable, it verifies the signature of the electronic consent token and rejects the payment if the signature is invalid.

[0034] According to one embodiment, the electronic consent token is stored in the memory of the payment platform.

[0035] According to one embodiment, a wallet application on a consumer device, or a remote wallet application accessible from the consumer device, is configured to cryptographically sign the electronic consent token using the private key of a public / private key pair, and the consumer PSP server is configured to verify the signature of the electronic consent token using the public key of the public / private key pair.

[0036] According to one embodiment, the payment system further comprises a memory storage device of the payment platform, which is configured to store electronic consent tokens.

[0037] According to one embodiment, the recipient device is the recipient's device for an interbank payment transaction, and the electronic consent token has one or more elements that link the electronic consent token to the recipient's bank account. [Brief explanation of the drawing]

[0038] The features and advantages described above and other features are described in detail in the following specific embodiments, which are given as examples not limiting the present invention with reference to the accompanying drawings.

[0039] [Figure 1]This diagram shows an account-to-account payment procedure involving payee devices and payers, as proposed in accordance with the SEPA Request to Pay mechanism. [Figure 2A] This figure shows an e / m commerce inter-account payment transaction initiated by the payer through the payee, involving a recipient device and a consumer device according to an exemplary embodiment of the present disclosure. [Figure 2B] This figure shows a seller-initiated interbank payment transaction applicable to both electronic or mobile (E / M) commerce and PoS (Point of Sale) payments, involving a recipient device and a consumer payment service provider, according to an exemplary embodiment of the present disclosure. [Figure 2C] This figure shows a PoS payment transaction initiated by the payer through the payee, involving a recipient device and a consumer device, according to a further exemplary embodiment of the present disclosure. [Figure 3] These figures show in more detail a consumer device of exemplary embodiments of the present disclosure, as shown in Figures 2A to 2C. [Figure 4] Figures 2A to 2C show examples of servers implementing the payment platform according to exemplary embodiments of this disclosure. [Figure 5] This flowchart shows the operation of a payment method with a consent token according to an exemplary embodiment of this disclosure. [Figure 6] This flowchart shows the operation of a payment method including the execution of a two-step payment according to an exemplary embodiment of the present disclosure. [Modes for carrying out the invention]

[0040] In various figures, similar features are indicated by the same reference numerals. In particular, structural and / or functional features common to various embodiments may have the same reference numerals and may have the same structural, dimensional, and material properties.

[0041] For clarity, only the operations and elements useful for understanding the embodiments described herein are shown and described in detail. In particular, algorithms and circuits for implementing asymmetric encryption are not described in detail, and those skilled in the art will know how such algorithms and circuits can be implemented.

[0042] Unless otherwise specified, when referring to two elements connected together, this means a direct connection with no intermediate elements other than conductors, and when referring to two elements connected together, this means that these two elements are connectable or can be connected via one or more other elements.

[0043] In the following disclosures, unless otherwise specified, when referring to absolute positions such as "front," "back," "up," "down," "left," and "right," or relative positions such as "upward," "downward," "high," and "low," or orientations such as "horizontal" and "vertical," these terms refer to the orientation of the drawing.

[0044] Unless otherwise specified, the expressions “approximately,” “roughly,” “substantially,” and “to the extent” refer to a range of 10%, preferably 5%, of the value in question.

[0045] Figure 1 shows a non-card payment procedure based on the SRTP protocol, involving a payee device 102 and a payer device 104.

[0046] Non-card payments may be further referred to herein as interbank payments or direct debits, and mean that payments are made from the payer's bank account to the payee's bank account (sometimes, sometimes, through an intermediary recipient known as a “payment processor”) based on the account information of the payer’s account and the account information of the payee’s account, without relying on any payment processing as in the case of card payments.

[0047] The recipient device 102 is configured to communicate with a recipient SRTP provider, represented for example by a recipient PSP 106 for simplification, via, for example, one or more wireless and / or wired networks. The recipient PSP 106 is implemented, for example, by a server associated with the recipient bank.

[0048] The payer device 104 is configured to communicate with a payer SRTP provider, represented for example by a payer PSP 108 for simplification, via, for example, one or more wireless and / or wired networks. The payer PSP 108 is implemented, for example, by a server associated with the payer's bank.

[0049] Figure 1 shows an example of a first payment transaction (Payment 1) between a payee and a payer. The payee device 102 is configured to generate a payment request message REQ TO PAY, which is sent to the payee PSP 106 in transmit 111. This message indicates, for example, the transaction details, including the payment amount, and identifies the payer using a payer identifier. For example, the payer identifier may be the payer's account details, such as an IBAN (International Bank Account Number), or another type of identifier.

[0050] The payee PSP 106 processes the request and sends it to the payer PSP 108 via transmission 112.

[0051] The payer PSP 108 identifies the payer's contact details based, for example, on the payer identifier, and sends a payer approval request message, REQ PAYER APPROVAL, to the payer device 104 in transmit 113. This message includes, for example, at least the transaction details and may further include the payee identifier. The payer is prompted, for example, to provide a response to the approval request, and once the payer approves the transaction, the payer approval message, PAYER APPROVAL, is sent back to the payee PSP 106, for example, in transmits 114 and 115, and finally sent to the payee device 102 in message 116.

[0052] Although outside the scope of the SRTP mechanism, in normal practice, the payer PSP 108 responds by initiating settlement of the underlying payment to the payee PSP 106.

[0053] Figure 1 further illustrates an example of a second payment transaction (Payment 2) initiated by the payee between the payee and the payer. The transaction is carried out in a similar manner to payment transaction (Payment 1), for example, by sending messages 111-116 and a similar series of messages 121-126, respectively, and is not described in detail here.

[0054] The first payment transaction (Payment 1) and the second payment transaction (Payment 2) may be separated by seconds, hours, days, or months, but target the same payee and payer, placing a relatively large load on the settlement network infrastructure, particularly the payee PSP 106 and payer PSP 108, in terms of energy consumption and processing resources. A further drawback of the solution in Figure 1 is that once a payment request is sent by the payee device 102, the payment status remains uncertain until a payment confirmation is received. If a delay or communication error occurs between the payee device 102 and the payer device 104, the confirmation may be received late or not at all, potentially causing the payee device 102 to send a new request and creating a risk of double payment. A further drawback of the solution in Figure 1 is its lack of versatility; for example, it cannot implement certain complex transaction types.

[0055] Figure 2A illustrates an account-to-account payment transaction initiated by the payer through the payee between a recipient device 202, which is the device receiving the payment, and a consumer device 204, which is the device making the payment, according to an exemplary embodiment of the present disclosure.

[0056] The recipient device 202 is, for example, a seller's device such as a point-of-sale (POW) device. In one embodiment, the recipient device 202 is a portable device such as a smartphone, tablet computer, or laptop computer that can communicate wirelessly using a cellular network or the like. Alternatively, the recipient device 202 may be, for example, a PC (personal computer) or desktop computer that is connected to a communication network and can access the internet.

[0057] The consumer device 204 is, for example, a customer device. In one embodiment, the consumer device 204 is a portable device such as a smartphone, tablet computer, or laptop computer that can communicate wirelessly using a cellular network or the like. Alternatively, the consumer device 204 may be, for example, a PC (personal computer) or desktop computer that is connected to a communication network and can access the internet.

[0058] The transaction in Figure 2A is, for example, an e-commerce transaction or a mobile commerce (m-commerce) transaction. For example, in an e-commerce transaction, the consumer device 204 is a computer such as a laptop computer or tablet computer (but some parts of the transaction, such as user consent, may be implemented by the consumer's mobile device), and in an m-commerce transaction, the consumer device 204 is a mobile device such as a mobile phone or smartphone. In either case, the recipient device 202 is, for example, a computer or server hosting the recipient's online shop.

[0059] The recipient device 202 is associated with the recipient PSP 206, and the consumer device 204 is associated with the consumer PSP 208. The recipient PSP 206 and the consumer PSP 208 are each configured to communicate with, for example, the payment platform 210. The recipient device 202 communicates with the recipient PSP 206, for example, via the gateway 212. In addition, once authorized by the recipient PSP 206, the recipient device 202 can communicate directly with the payment platform 210 via the gateway 212. Furthermore, the recipient PSP 206 may, for example, act as an account management settlement service provider (ASPSP), or may be performed by a specific element ASPSP 214. The ASPSP is responsible for processing payments to recipients of instant bank transfers (e.g., recipient accounts). The gateway 212 represents a technical link between the recipient and the recipient PSP 206, and in alternative embodiments, it may be implemented as part of the recipient device 202, the recipient PSP 206, or a third party.

[0060] Consumer device 204 stores a wallet application 216 (WALLET APP), which is a secure application that can provide a secure environment for managing payment transactions, in the consumer device's memory. If consumer device 204 is a mobile communication device, the wallet application is a mobile application that runs in the consumer device's secure environment, for example, a trusted execution environment (TEE). If consumer device 204 is a computing device that does not have a secure environment, the wallet application 216 is a web application that runs on a remote server or backend server (not shown), for example.

[0061] Figure 2A shows an example of signal transmission between various elements of a payment system. These transmissions can be performed by direct transmission of corresponding digital data over an intermediate network, or by retrieval of corresponding digital data as a download from a server or the like, and those skilled in the art will understand that any form of data transmission is included in the embodiments described.

[0062] Interbank payments are executed in three stages, for example: the first consent request stage (CONSENT REQ), the subsequent payment request stage (PAYMENT REQ), which is a tiered payment, and finally, the settlement and reconciliation stage (STLMT+RECON), where settlement takes place and / or a reconciliation report is generated.

[0063] The consent request stage includes, for example, the sending 221 from the consumer device 204 to the recipient device 202 of a message that triggers a transaction by the consumer. For example, the sending 221 occurs when the consumer uses the consumer device 204 to visit the recipient's online shop and clicks to pay by bank transfer to purchase goods or services.

[0064] The recipient device 202 responds to transmission 221 by accessing the payment platform 210 via gateway 212 to generate a consent request, as represented by transmission 222 from recipient device 202 to gateway 212 and transmission 223 from gateway 212 to payment platform 210.

[0065] In response to this, a Consent Request (CONSENT REQ) is generated on the payment platform 210 and sent to the gateway 212, for example, along with a redirect link, as represented in transmission 224. The Consent Request is an electronic message that identifies the recipient, for example, using a recipient identifier, which may be an account number such as an IBAN, or an alias of an account number, or another identifier of the recipient. The Consent Request further indicates, for example, a payment plan specifying at least the payment amount and / or payment period. The payment plan is, for example, multipurpose, and for example, in particular, - One-time payment (The payment plan will indicate the payment amount, whether the payment will be made immediately or at a later date, and optionally, a description of the products and / or services purchased by payment.) - Two installments (the payment plan will, for example, show the amount of the down payment to be paid immediately, the difference to be paid later, and a description of the products and / or services to be purchased by payment at your discretion), - Regular payments made periodically over a specified period, for example, monthly payments over 12 months (the payment plan will specify the payment interval, e.g., weekly, monthly; the subscription period, e.g., a 3-month subscription or a 2-year subscription; the payment amount; and optionally, a description of the products and / or services purchased by payment). - Regular and continuous payments (the payment plan will specify the payment interval, e.g., weekly or monthly, the payment amount, or the payment limit if the payment amount is variable, and optionally a description of the products and / or services purchased by the payment). You may indicate one of the types of payment.

[0066] As shown by the dashed line 225 in Figure 2A, the redirect link provided between the gateway 212 and the consumer device 204 along with the consent request is activated by the recipient 202's online shop to guide the consumer to the wallet application 216 stored on the consumer device 204. For example, the wallet application 216 opens automatically on the consumer device 204.

[0067] The wallet application 216 is configured, for example, to display a payment plan on the display screen of the consumer device 204, and the consumer is prompted to agree to the payment plan using their device. In addition, the wallet application 216 is configured to authenticate the consumer using, for example, a strong authentication procedure. In one embodiment, this authentication procedure includes biometric authentication, such as verification of the payer's fingerprint or facial ID using the consumer device 204. For example, authentication may include a Strong Customer Authentication (SCA) process or similar process that includes multi-factor authentication.

[0068] Upon consumer approval, the wallet application 216 is configured to generate, for example, a signed consent token. For example, the digital signature of the consent token protects the integrity of the consent token, proves its authenticity, and supports its high availability by being independently verifiable in each subscriber system.

[0069] In the case of a mobile wallet application, the signed consent token is generated based on one or more locally stored cryptographic signing keys stored on the consumer device 204, for example. In this case, the association between the secret signing key and the consumer's other cryptographic keys is protected by a trusted enclave and / or biometric encryption based on hardware such as a trusted execution environment on the consumer device. Access to the signing key is protected by strong customer authentication, for example.

[0070] In the case of a web wallet application, the signed consent token is generated by the remote / backend server based on one or more cryptographic signing keys stored by the remote / backend server, for example.

[0071] For example, the signature is based on asymmetric encryption using a public / private key pair. The private key is known only to the secure element of, for example, consumer device 204. For example, consumer device 204 or a remote / backend server stores the private key in the secure memory of, for example, the secure element and uses this private key to sign the consent token. The public key is provided to other entities, for example, payment platform 210, recipient PSP 206, and consumer PSP 208. Thus, this signature can be verified by other entities using the public key. In this way, a consent token, which proves the consumer's consent to a payment plan, can be shared across multiple systems by its public key. For example, the consent token may be shared with the systems of recipient PSP 206, consumer PSP 207, recipient, and possibly a technical service provider. In one embodiment, the consent token includes protective measures such as the use of a secure communication channel and / or encryption when it is in transit between these systems and when it is stored on the systems. To ensure the integrity, confidentiality, reliability, and availability of consent tokens are protected, for example, multiple redundant security controls are used.

[0072] For example, a consent token is an electronic data token generated by, for example, a wallet application 216, based on a set of rules used to incorporate payment plan information into the consent token. For example, the wallet application 216 implements a rule engine configured to generate payment consent tokens based on a set of rules. For example, the rule set defines the minimum information of the payment plan to be included in the electronic consent token, such as the payment amount or payment limit, and the validity period of the electronic consent token, such as the end of the payment period. In one embodiment, the electronic consent token has the consumer's account number and the recipient's account number, for example, in the form of an IBAN or an alias of the account number.

[0073] A signed consent token means that, for example, it is associated with a recipient, and only the recipient who triggered the generation of the consent request can use the consent token. For example, if an electronic consent token contains the recipient's account number, since the contents of the electronic consent token are immutable, this account number cannot be changed, and the signed consent token can only be used to make one or more payments to this recipient's account.

[0074] The signed consent token is supplied to the payment platform 210, for example, as represented in transmission 226, and stored in the memory of the payment platform 210. The recipient device 202 is then notified, for example, in transmission 227 to gateway 212 that consent has been successfully given, and the signed consent token is further transmitted, for example, to gateway 212.

[0075] The transmission or sharing of consent tokens between elements of a payment system is, for example, at least: - Consumer mobile wallet applications 216, and possibly other similar applications stored on other consumer devices. - Payment platform 210, - Recipient PSP 206 and Consumer PSP 208, and - Other devices such as recipient device 202 and consumer device 204 This is performed, for example, by connecting to multiple layers of security controls within a closed ecosystem formed by it.

[0076] At the transport layer, to ensure confidentiality, integrity, and reliability, all connections are, for example, fully encrypted and protected by Mutual Transport Layer Security (mTLS). At the application level, sessions between systems are protected by, for example, mandatory cryptographic authentication. Certain critical connections between members of the organization are further protected by, for example, virtual private networks (VPNs) and physically isolated direct connections.

[0077] The payment platform 210, for example, stores all consent tokens in memory and allows consumers to request a centralized modification or cancellation of existing consent tokens, which applies to any payment request that has not yet been approved based on the consent tokens. For example, the electronic wallet application 216 of the consumer device 204 further stores a copy of the consumer's payer consent tokens, and the payer can request a modification or cancellation of these consents by verifying the payment consents valid at a given time, generating an electronic request, and sending it to the payment platform 210.

[0078] In one embodiment, the recipient device 202 is further configured to store consent tokens so that they are ready to be included in a payment authorization request, as described below. In any case, in transactions where payment is temporally separated from the time consent is obtained, such as in the case of pre-approval or recurring payments, consent may be renewed by the consumer, so the recipient device 202 is configured to always request the most recent consent token from the payment platform 210, for example, before initiating a payment authorization request.

[0079] During the payment execution phase, one or more payments are executed based on consent tokens. These payments are authorized and executed based on consent tokens signed by the consumer PSP 208, and no further authorization from the consumer is sought. Furthermore, each payment is executed according to a two-step procedure including a payment request step (PAYMENT REQ) and a payment instruction step (PAYMENT INST), as described in more detail.

[0080] Figure 2A shows an example of a single payment based on a consent token obtained during the consent phase.

[0081] A payment request is initiated by the gateway 212, for example, represented by the transmission of a payment authorization request 228 to the recipient PSP 206, which aims to obtain a guarantee of payment from the consumer PSP 208. This payment authorization request, for example, specifies at least the payment amount and is attached, for example, a signed consent token.

[0082] As represented in transmission 229 from recipient PSP 206 to payment platform 210, recipient PSP 206 forwards, for example, a payment authorization request to payment platform 210. Payment platform 210 is configured to, for example, verify the signature of the consent token and confirm whether the requested payment complies with the payment rules contained in the consent token. For example, through consumer authentication at consent, these payment rules are dynamically associated with the payment use case specific details of payment platform 210 accepted by the consumer, in accordance with, for example, PSD2 (the amended Payment Services Directive published on March 13, 2018, pursuant to Council Decision (EU) 2018 / 385 of October 16, 2017), and therefore these payment rules restrict legitimate payment requests based on the consent token.

[0083] When verifying the signature, for example, the consent token is decrypted, the signature is decrypted using the public key of the payment platform 210, and it is verified that the decrypted signature corresponds to the payload of the consent token. If the signature is invalid, the transaction is rejected, for example, and an electronic message notifying this is sent to the recipient PSP 206, for example.

[0084] When verifying whether a payment complies with payment rules, for example, it is verified that the payment amount does not exceed the amount or limit specified in the consent token. In addition, or separately, the payment period is verified to ensure that the payment period specified in the consent token or the consent token has not expired. In some embodiments, the payment platform 210 is further configured to generate a fraud score indicating the risk that the payment request is fraudulent and to verify whether the fraud score exceeds an acceptable limit. If any of these verifications fail, the payment is rejected, for example, and an electronic message notifying the recipient PSP 206 is sent to that effect.

[0085] If the payment platform 210 determines that the requested payment complies with the consent token's payment rules and verifies that the fraud score does not exceed the acceptable limit, the payment platform 210 is configured to forward a payment authorization request to the consumer PSP 208 via transmission 230, for example. The payment authorization request may, for example, specify at least the payment amount and have, for example, a signed consent token attached.

[0086] Therefore, authentication and verification can be performed at a relatively low level of synchronous coupling between the payment platform and the consumer PSP, thereby enabling decentralized payment processing.

[0087] The consumer PSP 208 is configured, for example, to perform a payment authorization procedure and determine whether the payment should be authorized. Similar to the payment platform 210, the consumer PSP 208 is configured, for example, to verify the signature of the consent token and to verify whether the requested payment complies with the payment rules contained in the consent token. For example, the consumer PSP 208 verifies that the consent token has not expired. In addition, the consumer PSP 208 may verify that the payment does not exceed the payment limit set by the payment rules. In one embodiment, the payment platform 210 is further configured to generate a fraud score. The consumer PSP 208 further verifies, for example, whether sufficient funds are available in the consumer's account.

[0088] Assuming that Consumer PSP 208 can authorize the payment, this means a guarantee of payment from Consumer PSP 208 to the recipient account indicated in the consent token, Consumer PSP 208 responds with a payment authorization response, for example, as represented in transmission 231, the payment authorization response is transmitted to, for example, Payment Platform 210, and then forwarded by Payment Platform 210 to Recipient PSP 206.

[0089] While the recipient's payment account may be immutable, in one embodiment, the consent token is loosely coupled to a given payment method in the consumer's wallet, meaning the consumer can switch between inter-account payment methods, for example, by specifying an alternative account from which the funds will be withdrawn.

[0090] The payment recipient PSP 206 is configured to notify the recipient device 202 of the success of the payment via the gateway 212, for example, as shown in transmissions 233 and 234 in Figure 2A. This notification informs the recipient, for example, that the payment to the recipient's bank account has been authorized and that processing will proceed once an execution command has been sent, so that the recipient can take action in response to this notification, for example, by delivering the goods to the payer or renewing a license or subscription. Furthermore, the recipient PSP 206 is configured to initiate a payment capture request and send this request to the payment platform 210, for example, as shown in transmission 235 in Figure 2A. This payment capture request, for example, requests the execution of a payment and includes the payment amount. Furthermore, the payment capture request includes, for example, a consent token which may be associated with a payment authorization response.

[0091] The payment platform 210 is configured to forward the payment capture request to the consumer PSP 208, for example, as represented in transmission 236. The payment capture request is successful because the consent token and payment details have already been verified and the payment authorization response is positive. Thus, the consumer PSP 208 returns a capture confirmation message to the payment platform 210, for example, as represented in transmission 237, and the payment platform 210 forwards this message to the recipient PSP 206, for example, as represented in transmission 238, so that the recipient PSP 206 can record the confirmation of the success of the payment capture request, which means that the payment has been settled or is settled by the consumer PSP 208.

[0092] In some embodiments, settlement is triggered asynchronously by a payment capture request, so that, as shown in transmission 239, consumer PSP 208 triggers settlement in relation to the payment capture request received in transmission 236, for example. This settlement is made from consumer PSP to ASPSP 214, which is configured, for example, to deposit the received settlement into recipient PSP. Furthermore, as shown in transmission 240, payment platform 210 receives notification of the settlement result, for example. In some embodiments, settlement is performed by an SCT Inst operation. It should be noted that in the example of Figure 2A, the settlement of the payment is not performed by recipient PSP 206 but by ASPSP 214. In alternative embodiments, the settlement of the payment is performed by recipient PSP 206. Furthermore, the recipient of the funds is not necessarily the recipient itself (e.g., the seller), but can be recipient PSP 206 or a collecting PSP sometimes referred to as a “payment processor”. In either case, the recipient of the funds is not the recipient themselves, for example, the funds are configured to be deposited into the recipient's account.

[0093] In one embodiment, the payment platform 210 is configured to provide the consumer PSP 208 and / or recipient PSP 206 with periodic reports, such as daily reports on transaction status and settlement, as shown in transmissions 241 and 242. This allows the recipient PSP 206 and / or consumer PSP 208 to verify the transaction status maintained by the payment platform 210. These reports are based on settlement results reported by the consumer PSP 208 to the payment platform 210 for each payment, as shown in transmission 240.

[0094] Although not shown in Figure 2A, according to the embodiments described herein, multiple payments can be executed based on the same consent token without requiring further consumer approval. Furthermore, the two-stage payment execution partially eliminates ambiguity regarding the outcome of a payment request. In fact, if the recipient device 202 or gateway 212 does not receive a response after the initiation of a payment request, as represented in transmission 228, the payment request can be repeated without the risk of double payment, as it merely triggers verification that the payment is feasible and can be guaranteed by the consumer PSP 208. Moreover, gateway 212 sends a payment capture request only once in response to a payment approval response message, as represented in transmission 235, which means that there is a valid communication link between gateway 212 and consumer PSP 208 via payment platform 210.

[0095] For example, the recipient PSP 206, the consumer PSP 208, and other recipient and consumer PSPs that operate with the payment platform 210 have specific APIs (Application Programming Interfaces) to allow connections to the payment platform 210, such as to request and / or update consent tokens.

[0096] In a centralized model, all services, including payment request services that have both creditor and debtor aspects, form part of a single software on, for example, the payment platform 210. In this centralized approach, recipient PSPs and consumer PSPs still host some services, for example. For example, a recipient PSP hosts only minimal creditor services, allowing it to review, record, and route messages between the recipient and the payment platform 210. The recipient PSP can further reject payment requests suspected of being fraudulent. A consumer PSP hosts debtor services, for example, notifying the payment platform 210 whether a payment has been approved or rejected, and confirming when the payment was settled.

[0097] Further decentralization of services from the payment platform 210 to consumer PSPs and recipient PSPs is possible, for example, - Management of consent tokens in persistent storage, - Management of the private key lifecycle and public key distribution in combination with client-side signing functionality, and / or - Routing between recipient PSP creditor services and consumer PSP debtor services. This allows for the decentralization of services.

[0098] Figure 2B illustrates a seller-initiated cross-account payment transaction, for example, that includes the same elements as the transaction in Figure 2A. For example, based on operations 221 to 227 corresponding to the consent request stage CONSENT REQ as described in relation to Figure 2A, a consent token is obtained, for example, as described above. This consent request stage is not described in detail again. The consent token authorizes one or more future payments, which may be triggered directly by the seller's bank, for example.

[0099] In one embodiment, an interbank payment transaction initiated by a seller is initiated by the recipient PSP 206 obtaining a consent token currently held by the payment platform 210, as represented by transmission 250. For example, this consent token may have been updated by the consumer via consumer device 204 since its initial generation, and the recipient PSP 206 may not have the updated version. Transmission 250 corresponds to an electronic message requesting a consent token, which may be executed, for example, via a web interface. As represented by transmission 251, the payment platform 210 responds, for example, by providing the current consent token held by the payment platform.

[0100] Alternatively, if recipient PSP 206 already possesses a valid consent token, the payment request may be triggered directly by recipient PSP 206 based on this consent token. However, if payment platform 210 determines that the consent token has expired, for example because the consent token has been updated by the consumer, payment platform 210 may, for example, reject the payment authorization request and notify recipient PSP 206 accordingly. Recipient PSP 206 then obtains, for example, an updated consent token as described above.

[0101] When recipient PSP 206 obtains the latest consent token, it executes the same process again, including some or all of the less detailed transmissions 229 to 242, for example, as described in relation to Figure 2A.

[0102] Figure 2C illustrates a PoS (Point of Sale) cross-account payment transaction initiated by the payer through the payee, which includes, for example, the same elements as the transaction in Figure 2A. For example, in this example, the recipient device 202 is a PoS device located at the checkout counter of a retail store or other store selling goods and / or services. The PoS device could also be a vending machine, for example.

[0103] In the example in Figure 2C, the consent request stage is initiated not by transmission 221 in Figure 2A, but by transmission 222 from recipient device 202 to gateway 212 and transmission 223 from gateway 212 to payment platform 210, for example, when recipient device 202 directly requests the generation of a consent request. The consent is then signed using the same process as described in relation to Figure 2A, including, for example, some or all of transmissions 224 to 242, which are not described in detail again, and then the transaction is executed. However, in this case, a redirect link is provided to consumer device 204, for example, as a QR code (registered trademark), and by following the redirect link, consumer device 204 is redirected to the wallet application 216 stored in consumer device 204, for example, in a similar manner to the method described in relation to Figure 2A.

[0104] Figure 3 provides a more detailed schematic representation of the consumer device 204 shown in Figures 2A to 2C, according to an embodiment in which the consumer device 204 is a portable device.

[0105] As shown in Figure 3, the portable device 204 can, for example, perform wireless communication. For example, the portable device 204 includes a contactless front-end integrated circuit (CLF) 302, referred to herein as an NFC router. The NFC router 302 is connected to an NFC antenna 304, and together the NFC router 302 and the NFC antenna 304 provide an NFC circuit for emulating the operation of an NFC transponder. The NFC router 302 is further connected to, for example, the host processing device (P) 306 of the portable device 204.

[0106] The processing device 306 has, for example, one or more processors under the control of instructions stored in memory (MEM) 308. The memory 308 further stores, for example, one or more applications of the portable device 204, including a payment wallet application 216.

[0107] The NFC router 302 is further connected to a secure element (SE) 310, which is, for example, an embedded SE (eSE), and / or a SIM or universal SIM circuit 312.

[0108] The processing device 306 is further connected to, for example, an antenna 314 that enables long-distance communication within a cellular network, an antenna 315 that enables WiFi (Wireless Fidelity) communication, and / or an antenna 316 that enables ultra-wideband (UWB) RF communication. In some embodiments, the portable device 204 may comprise only one or some of the antennas 314, 315, and 316. The portable device 204 further comprises a display 318 connected to the processing device 306, the display being, for example, a touchscreen that provides a user interface for the portable device.

[0109] The portable device 204 further comprises an image acquisition device 320 having, for example, an image sensor for capturing digital images. For example, the image acquisition device 320 can capture machine-readable codes such as QR codes, and the portable device 204 stores appropriate software applications for interpreting machine-readable codes. Furthermore, in some embodiments, the image acquisition device 320 or another image sensor can capture biological samples such as fingerprints, facial images, finger vein scans, or retinal scans.

[0110] In some embodiments, the mobile device 204 includes a trusted execution environment (TEE) 322, which includes, for example, a memory device 324 for storing one or more software applications, and the allocation of processing resources of a processing device 306 for executing software applications separately from the execution of other software applications stored in instruction memory. For example, the trusted execution environment 322 is used for executing sensitive software applications such as a mobile wallet application 216 and / or an application for PIN (Personal Identification Number) input, and / or for the capture of biological samples. In addition, or separately, the trusted execution environment 322 is used for cryptographic operations described herein, such as generating public / private key pairs and generating signatures of consent tokens using private keys. The trusted execution environment 322 further includes a secure storage unit for securely storing private keys, for example, so that private keys are never loaded into the system memory of the mobile device 204. The memory device 324 and / or the trusted execution environment 322 are used, for example, to securely store consent tokens. For example, consent tokens and associated data, such as the associated public key, are securely stored at all times using access controls that ensure proper authentication and authorization. The location where the public key is stored is protected, for example, to prevent the malicious insertion of a fake public key.

[0111] As will be described in more detail below, the portable device 204 is a connected portable device having some or all of the following characteristics: - It is portable and does not require constant connection to any type of cable, including power or data cables. For example, authentication can be performed based on one or more of the following: user biometric data, such as images of the user's face or fingerprints, and user secrets, such as a PIN (Personal Identification Number) or password. - Payment plan data can be displayed. - Users can register their acceptance or consent to the payment plan.

[0112] Figure 4 shows an example of a server 400 implementing the payment platform 210 of Figures 2A-2C according to an exemplary embodiment of the present disclosure. The recipient PSP 206 and consumer PSP 208 are implemented, for example, by similar servers.

[0113] The server 400 includes a processing device 402 which may have one or more processors under the control of instructions stored in, for example, instruction memory 404. A memory storage device 406 is further connected to the processing device 402 and stores, for example, consent tokens. For example, consent tokens and associated data, such as associated public keys, are stored securely at all times using access control to ensure correct authentication and authorization. The storage location of the public keys is protected, for example, to prevent malicious insertion of false public keys.

[0114] Each consent token defines at least some parameters relating to a payment between the corresponding payee and the corresponding payer, so that the server 400 can facilitate payments between, for example, many payers and many payees. The processing device 402 is further connected to a communication interface 408, which enables communication with, for example, a recipient device 202 via a recipient PSP 206, and with, for example, a consumer device 204 via a consumer PSP 208, over a wired and / or wireless network. The server 400 can process, for example, requests to modify or revoke consent tokens from a payer device or a payee device.

[0115] In one embodiment, the server 400 has a secure processing environment 410, which has a secure microprocessor 412 under the control of an instruction memory 414 that stores one or more software applications that can be executed independently of the execution of other software applications stored in the instruction memory 404.

[0116] The consent token stored in the memory storage device 406 can be modified by the consumer, for example, through the consumer's mobile wallet application 216. For example, through the mobile wallet application 216, the consumer can perform the following consent management tasks related to future payments. i) A consumer may change the payment method associated with the consent token, for example. In this case, the mobile digital wallet 216 is configured to send the new version of the consent token to the payment platform 210, for example, in the form of a sub-resource of the same consent resource as the original consent token. ii) The recipient PSP 206 is configured to require, for example, a consent update for each transaction, in order to ensure that the correct and most up-to-date sub-resources are used in the approval request. iii) When a new version of the consent token is received by the payment platform 210, the payment platform 210 is configured to invalidate the previous consent token, for example. Thus, a consent resource may have multiple consent tokens, for example, but only the most recent consent token is valid. iv) The signature and payload of the new consent token are verified by the payment platform 210, for example, to ensure that the consent token is compatible with the consent resource. v) The consumer may revoke their consent via the mobile wallet application 216. In this case, for example, a notification indicating the consent token to be revoked is sent from the consumer device 204 to the payment platform 210, and the payment platform 210 is configured to invalidate this stored consent token, for example.

[0117] Figure 5 is a flowchart illustrating the operation of a payment method with consent tokens according to an exemplary embodiment of the present disclosure. The method in Figure 5 is implemented, for example, by a payment system corresponding to the payment platform 210, recipient device 202, recipient PSP 206, consumer PSP 208, and consumer device 204 in Figures 2A-2C. In particular, the method is executed, for example, by a processing device of each element of the payment system under the control of instructions stored in the instruction memory of each element of the payment system, for example, by software.

[0118] In operation 501, for example, a consent request is received from the recipient device 202 for one or more payments based on a payment plan.

[0119] In operation 502, following operation 501, consumer consent is requested from the consumer via the consumer device 204. This step authenticates the consumer, for example, to confirm that they are a consumer who has agreed to the payment plan. For example, authentication may include SCA processing, including multi-factor authentication, or similar processing.

[0120] In operation 503, following operation 502, a consent token is generated, for example, by a wallet application running on a consumer device or a web wallet application accessible from the consumer device. The consent token is based on a payment plan accepted by the payer and is cryptographically signed. The consent token includes one or more elements, for example, the recipient's account number, which links the consent token to the recipient.

[0121] In operation 504, following operation 503, the signed consent token is sent to the recipient device 202, for example, via the payment platform 210.

[0122] In operation 505 following operation 504, at least one cross-account payment authorization request is received from recipient PSP 206 as part of the payment transaction and authorized by consumer PSP 208 based on the consent token. In one embodiment, the payment transaction is a two-step transaction as shown in Figure 6, having a payment request that seeks authorization to obtain payment guarantee and a subsequent payment capture request.

[0123] Figure 6 is a flowchart illustrating the operation of a payment method, including a payment request initiated by the payee and a two-stage payment execution, according to an exemplary embodiment of the present disclosure. Similar to the method in Figure 5, the method in Figure 6 is implemented by a payment system corresponding, for example, the payment platform 210, recipient device 202, recipient PSP 206, consumer PSP 208, and consumer device 204 in Figures 2A-2C. In particular, the method is executed, for example, by a processing device of each element of the payment system, under the control of instructions stored in the instruction memory of each element of the payment system, for example, by software.

[0124] In operation 601, a payment request is sent from the recipient device 202 to the payment platform 210, and the payment request includes the payment amount and a consent token that defines the payment period and / or payment limit. For example, prior to operation 601, the consent request may be initiated, for example, by the recipient, and authorization may be granted by the consumer so that a consent token can be generated.

[0125] In operation 602 following operation 601, the payment platform 210 is configured to notify the consumer PSP 208 of a payment authorization request, for example, based on a signed consent token and the payment amount.

[0126] In operation 603 following operation 602, the consumer PSP 208 performs several verifications, including, for example, verification of the consent token, verification of whether the payment request is permitted based on the conditions set forth in the consent token, and implementation of several checks on the consumer side, such as verification of whether the IBAN is valid and / or verification of whether the consumer's account has sufficient funds. If any of these verifications indicate that the payment should be refused, the consumer PSP 208 sends, for example, an electronic message indicating refusal to the payment platform 210. For example, if the signature on the electronic consent token is invalid and / or if the payment limit and / or payment period set forth in the electronic consent token has been exceeded, the payment is refused. Assuming that the verification is completed successfully, the consumer PSP 208 stores, for example, information indicating that the payment associated with the transaction identifier can be guaranteed, and the payment platform 210 receives, for example, a payment approval response message from the consumer PSP 208.

[0127] In operation 604, following operation 603, a payment capture request is sent, for example, to the consumer PSP 208. The payment capture request includes a consent token. The consumer PSP 208 is configured to verify, for example, that the payment is guaranteed based on the consent token, and if guaranteed, to execute the payment. The payment platform 210 and / or recipient PSP 206 receive a capture confirmation message from the consumer PSP 208 confirming that the payment has been executed.

[0128] The advantage of the payment solutions described herein, based on consent tokens, is that they reduce the burden on the payment network infrastructure in terms of energy consumption and processing resources by reducing the number of messages sent to the consumer device 204. In particular, since the consumer is only asked to perform one consent action, multiple payment transactions can be executed without needing to seek further approval from the consumer. In fact, consent tokens provide a secure and effective way to verify that the necessary consumer consent has been obtained. In contrast, according to the SRTP mechanism, the payer needs to verify the payment request associated with each payment. Furthermore, the use of consent tokens enables decentralized methods because consent tokens can be verified by any entity in the chain, without relying on a token service provider.

[0129] A further advantage of the consent system is that user authentication and user consent to the payment plan are separated from the actual payment execution by providing payment initiation processing following the consent process. This allows for flexible use of consent tokens, making it easy to handle various use cases, such as subscriptions, event-dependent payments, down payments, and future deductions, in a single, unified pattern. All of these use cases can be provided based on the same two message steps following the consent request, since the use case itself is part of the consent.

[0130] The advantage of the two-stage payment execution method described herein is that it provides a technical solution to address the technical challenge of ambiguity in the payment status between the time the recipient device initiates a payment request and the time it receives payment confirmation. In particular, the two-stage method allows for verification of payment terms before payment is executed, and the payee PSP sends a payment execution command after receiving confirmation that the payment is approved (payment approval response message), thus ensuring that the payment is executed by the payment execution command.

[0131] Various embodiments and modifications are described. Those skilled in the art will understand that certain features of these embodiments can be combined, and other modifications will be readily conceivable to those skilled in the art. In particular, while an example of SRTP payment is described, it will be apparent to those skilled in the art that the payment solutions described herein are not limited to SCT payments.

[0132] Furthermore, in some embodiments, the payment procedure processing may further support partial authorization processing. This option ensures that if the payer's account does not have sufficient funds, the issuer will guarantee at least a portion of the amount requested for authorization. Moreover, in some embodiments, the recipient may request further authorization based on the initial agreement, with a modified guarantee amount. If authorization is denied, the initial guarantee amount remains valid, for example. Furthermore, payment request capture may deviate from the standard as an option by requiring only partial capture. For example, multiple partial captures are possible up to the amount initially requested and authorized.

[0133] Finally, the actual implementation of the embodiments and modifications described herein is within the scope of the skills of those skilled in the art based on the functional representations given above.

Claims

1. A method for executing interbank payment transactions, The payment platform (210) receives one or more payment consent requests from the recipient device (202) indicating at least the payment amount and / or payment period, The consumer consent for one or more of the aforementioned payments is requested via the consumer device (204), In accordance with the consumer's consent, the consumer device generates an electronic consent token that is cryptographically signed and indicates at least the payment amount and / or the payment period, and transmits the electronic consent token to the recipient device (202) via the payment platform (210). The electronic consent token is stored in the memory storage device (406) of the payment platform (210). One or more interbank payments are initiated by the recipient device (202) or the recipient payment service provider (PSP) server (206) by sending a payment authorization request including the electronic consent token to the consumer payment service provider (PSP) server (208) via the payment platform (210). A method by which the consumer PSP server (208) approves or disapproves the payment approval request based on the payment amount and / or payment period indicated in the electronic consent token.

2. The aforementioned consumer PSP server (208) is Comparison of the payment amount in the aforementioned payment authorization request with the payment amount indicated in the aforementioned electronic consent token, and / or Verification of whether the aforementioned payment period has elapsed, and / or For example, verifying whether the payment can proceed by considering the available funds in the consumer's account. The method according to claim 1, wherein the payment is approved or not approved based on the above.

3. The method according to claim 1 or 2, wherein the modification or cancellation of the electronic consent token in the memory storage device (406) is requested by the consumer device (206) or the recipient device (202).

4. The wallet application of the consumer device (204), or a remote wallet application accessible from the consumer device (204), is configured to cryptographically sign the electronic consent token using the private key of a public / private key pair. The method according to any one of claims 1 to 3, wherein the consumer PSP server (208) is configured to verify the signature of the electronic consent token using the public key of the public key / private key pair.

5. The method according to any one of claims 1 to 4, wherein each of the one or more inter-account payments is performed using a two-step method, the first step being that the recipient PSP server (206) receives a payment acknowledgment response message from the consumer PSP server (208) signifying a guarantee of payment from the consumer PSP server (208), and the second step being that the recipient PSP server (206) sends a payment capture request command to the consumer PSP server (208) requesting the execution of the payment in response to the receipt of the payment acknowledgment response message.

6. The method according to any one of claims 1 to 5, wherein the consumer consent is requested for one or more of the aforementioned payments, and the consumer is authenticated via the consumer device (204) before the electronic consent token is generated.

7. When initiating payments between one or more accounts, The first interbank payment is initiated by the recipient device (202) or recipient settlement service provider (PSP) server (206) by sending the first payment authorization request, including the electronic consent token, to the consumer PSP server (208) via the payment platform (210). Based on the payment amount and / or payment period indicated in the electronic consent token, the consumer PSP server (208) approves or rejects the first payment approval request. The second interbank payment is initiated by the recipient device (202) or recipient settlement service provider (PSP) server (206) by sending the second payment authorization request, including the electronic consent token, to the consumer PSP server (208) via the payment platform (210). The method according to any one of claims 1 to 6, wherein the consumer PSP server (208) approves or disapproves the second payment approval request based on the payment amount and / or payment period indicated in the electronic consent token.

8. The recipient device (202) is the recipient's device for the inter-account payment transaction, The method according to any one of claims 1 to 7, wherein the electronic consent token has one or more elements that link the electronic consent token to the recipient's bank account.

9. A payment system for executing inter-account payment transactions, A payment platform (201) configured to receive one or more payment consent requests from a recipient device (202) indicating at least the payment amount and / or payment period, A memory storage device (406) of the payment platform (210) is configured to store electronic consent tokens, A consumer device (204) is configured to obtain the consumer's consent for one or more payments and, in accordance with the consumer's consent, generate an electronic consent token that is cryptographically signed to indicate at least the payment amount and / or the payment period, and to transmit the electronic consent token directly to the recipient device (202) or via the payment platform (210). It is equipped with, A payment system wherein the recipient device (202) or the recipient settlement service provider (PSP) server (206) of the payment system is further configured to initiate one or more interbank payments by sending a payment authorization request including the electronic consent token to a consumer settlement service provider (PSP) server (208) via the payment platform (210), and the consumer PSP server (208) is configured to approve or disapprove the payment authorization request based on the payment amount and / or payment period indicated in the electronic consent token.

10. The aforementioned consumer PSP server (208) is Comparison of the payment amount in the payment authorization request with the payment amount indicated in the electronic consent token, and / or Verification of whether the aforementioned payment period has elapsed, and / or For example, verifying whether the payment can proceed by considering the available funds in the consumer's account. The payment system according to claim 9, configured to approve or disapprove the payment based on the above.

11. The payment system according to claim 9 or 10, wherein the consumer device (206) or the recipient device (202) is further configured to request modification or revocation of an electronic consent token in the memory storage device (406).

12. The wallet application of the consumer device (204), or a remote wallet application accessible from the consumer device (204), is configured to cryptographically sign the electronic consent token using the private key of a public / private key pair. The payment system according to any one of claims 9 to 11, wherein the consumer PSP server (208) is configured to verify the signature of the electronic consent token using the public key of the public key / private key pair.

13. A payment system according to any one of claims 9 to 12, which performs each of the one or more inter-account payments using a two-step method, the first step being that the recipient PSP server (206) receives a payment acknowledgment response message from the consumer PSP server (208) signifying a guarantee of payment from the consumer PSP server (208), and the second step being that, in response to receiving the payment acknowledgment response message, the recipient PSP server (206) sends a payment capture request command to the consumer PSP server (208) requesting the execution of the payment.

14. The payment system according to any one of claims 9 to 13, wherein the consumer device (204) is further configured to authenticate the consumer after requesting the consumer's consent for the one or more payments but before generating the electronic consent token.

15. When the recipient device (202) or the recipient settlement service provider (PSP) server (206) initiates one or more inter-account payments, A first cross-account payment is initiated by sending a first payment authorization request, including the electronic consent token, to a consumer PSP server (208) via the payment platform (210), and the consumer PSP server (208) is configured to approve or disapprove the first payment authorization request based on the payment amount and / or payment period indicated in the electronic consent token. A payment system according to any one of claims 9 to 14, wherein a second interbank payment is initiated by the recipient device (202) or recipient settlement service provider (PSP) server (206) by sending a second payment authorization request, including the electronic consent token, to a consumer PSP server (208) via the payment platform (210), and the consumer PSP server (208) is configured to approve or not approve the second payment authorization request based on the payment amount and / or payment period indicated in the electronic consent token.

Images