Transaction settlement

Abstract

The present invention relates to methods and systems for processing a payment transaction, and particularly for providing settlement of payment transactions. There is provided a computer implemented method for processing a payment transaction. The method comprises: receiving, at an issuer (210; 310; 410; 510; 602), a payment authorisation request (212; 326; 610) for a payment transaction (204; 320) between a payer (202; 302; 402; 502) and a payee (206; 306; 406; 606) initiated via a card payment network (214; 314; 414; 514), the payment authorisation request (212; 326; 610) comprising real-time payment network details for a receiving party; comparing (332), at the issuer (210; 310; 410; 510; 602), payer real-time payment network details with the receiving party real-time payment network details, in order to determine if there is a common real-time payment network between the payer (202; 302; 402; 502) and receiving party; and, in the event that the common real-time payment network can be determined, instructing (420; 520) the payment to be settled via the common real-time payment network.

Description

[0001] TRANSACTION SETTLEMENT

[0002] CROSS REFERENCE TO RELATED APPLICATION

[0003] This application claims the benefit of, and priority to, United Kingdom Patent Application No. 2410191.7, filed on July 12, 2024. The entire disclosure of the above application is incorporated herein by reference.

[0004] TECHNICAL FIELD

[0005] The present invention relates to methods and systems for processing a payment transaction, and particularly for providing settlement of payment transactions.

[0006] BACKGROUND

[0007] When conducting transactions between a consumer and a merchant, there are three main stages that must occur: authorisation, clearing and settlement. A schematic diagram of the entities involved in a typical debit / credit card payment is shown in Figure 1 and discussed in further detail below.

[0008] While such card payments are well established and used ubiquitously for processing transactions, they are not without their limitations. In particular, the settlement stage of the payment process may place restrictions on the overall transaction process. The settlement stage is where funds are transferred from an issuer (a financial institution that issued the consumer’s card) to an acquirer (a financial institution that facilitates card payments on behalf of the merchant). The settlement process typically occurs the next working day, as transactions to the acquirer are usually bundled up over the course of a certain period (e.g., 24 hours or longer) and then settled in one payment. Additionally, the settlement process may require additional computational resources; transaction details must be stored until they are settled, and often repeated communication is required between parties to coordinate clearing and settlement. Additional third-parties (e.g., clearing houses) may be required to facilitate the settlement, providing further complexity and additional computational work. There is growing interest in using alternative payment methods to facilitate transactions. In recent years, many different real-time payment (RTP) network solutions have been proposed and started to be implemented. The solutions take a number of different forms. The RTP networks can use traditional currencies, where money is sent between banks, for example. Alternatively, RTP networks may use digital / crypto currencies, such as central bank digital currencies (CBDCs) or blockchain / distributed ledgerbased technologies.

[0009] Solutions such as these can allow for near real-time transfer of funds, with currency generally being transferred directly from a payer account or wallet to a payee account or wallet. However, existing RTP networks also have drawbacks. Presently, such payment networks are not particularly widespread; infrastructure facilitating their use is limited. In particular, digital currencies are not widely accepted or utilised amongst the general public, and digital currencies are rarely used for day-to-day consumer transactions, and. Additionally, RTP networks may provide less consumer protection and / or accountability, with often little to no authorisation taking place prior to the transfer between digital wallets.

[0010] It would be desirable to address at least some of these issues so that the processing of payment transactions can be improved, particularly with regard to the settlement of transactions.

[0011] SUMMARY

[0012] According to an aspect of the invention, there is provided a computer implemented method for processing a payment transaction. The method comprises receiving, at an issuer, a payment authorisation request for a payment transaction between a payer (also known as a consumer) and a payee (also known as a merchant) initiated via a card payment network, the payment authorisation request comprising real-time payment, RTP, network details for a receiving party. The method further comprises comparing, at the issuer, payer RTP network details with the receiving party RTP network details, in order to determine if there is a common RTP network between the payer and receiving party. The method further comprises, in the event that the common RTP network can be determined, instructing the payment to be settled via the common RTP network.

[0013] The use of an RTP network for the settlement of a payment transaction initiated via a card payment network may provide all or some of the advantages associated with both types of network. The initial payment transaction may comprise a conventional purchase. For example, a consumer may purchase an item in a shop, presenting a payment card (e.g., a credit / debit card or prepaid card) at a point-of-sale device belonging to a merchant. Such card payment networks are already widely available and ubiquitously used; the consumer may be able to use their existing payment card in an extensive number of shops. The authorisation procedures associated with said card payment networks are also well established. Any existing authorisation methods that are known may be used to verify and confirm the payment transaction, thereby providing the consumer and merchant with confidence that the payment will be handled securely (for example, by providing fraud-prevention checks). Additionally, said card payment networks may provide additional protection for consumers / merchants, for example the ability to process refunds or chargebacks.

[0014] The payment authorisation request may comprise all of the details that would be present in an authorisation request for a conventional payment made via the card payment network, thereby allowing all or some of the existing authorisation steps associated with the card payment transactions to be performed as normal. However, the payment authorisation request may contain additional fields that can be used to store RTP network details for the receiving party.

[0015] The RTP network details within the payment authorisation request may be the actual details of the RTP network of the receiving party (e.g., an account name / name associated with an RTP system or a digital wallet address). Alternatively, the RTP network details in the authorisation request may be alias RTP network details maintained by one of the involved parties (e.g., a payment network). The alias RTP network details are RTP network details that have no actual or real value and are only used in place of the real RTP network details. Each of the alias RTP network details may correspond to a real RTP network detail.

[0016] The alias RTP network details and each corresponding actual RTP network details may be stored in a database maintained by, for example, the payment network. Using the alias RTP network details, the corresponding real RTP network details may be retrieved and utilised. For example, a receiving party (e.g., merchant and / or acquirer) may include alias RTP network details comprising a ‘nickname’ or personal identification for an RTP system account or digital wallet (e.g., “Digital wallet 1”). The payment network may use this alias to retrieve the real RTP network details (e.g., the actual account / wallet associated with that party) that corresponds to the alias. The retrieved real RTP network details may then be utilised by the issuer. Utilising alias RTP network details may reduce the need to communicate real details between parties. The real RTP network details may have been validated by a third party. The ‘matching’ of alias RTP network details to the real RTP network details may be done in real-time (i.e., while the transaction is being processed) and may be facilitated via a real-time payment network. This may be the same payment network that is used to facilitate the authorisation / clearing of the transaction and / or may be performed via a third- party network / service.

[0017] The receiving party RTP network details may be added to these fields by the merchant and / or by the acquirer as the request is sent to the issuer. Thus, the issuer is provided with payer RTP network details as part of the payment authorisation request.

[0018] The issuer may retrieve RTP network details for the payer (i.e., the consumer) from a database. The issuer may be an issuing bank for the consumer’s card that was used to initiate the payment transaction, and thus have access to financial / banking details and / or RTP network details for the consumer / payer.

[0019] Instructing the payment to be settled via the common RTP network may provide for a faster settlement process when compared to a conventional settlement method (i.e., settlement of a conventional card payment). Once instructed, settlement via the common RTP network may be near instantaneous - the required funds are transferred from an account / wallet of the payer (i.e., the consumer) to an account / wallet of the receiving party (e.g., the payee / merchant or the acquirer). This is compared to conventional settlement methods that may take one working day or more for the funds to be transferred.

[0020] Settlement via the common RTP network may provide for a more computationally efficient settlement process. Typically, conventional settlement methods are performed on a batch-basis; transactions that need to be settled are usually batched together over a given time period (e.g., 24 hours) and then the necessary funds are transferred to the acquirer. Settlement via the common RTP network may reduce the storage requirements for such settlement information; each payment transaction may be settled on a purchase-by-purchase basis. This may reduce or eliminate the need to store settlement information for batch processing and / or the involvement of additional-third parties (e.g., clearing houses, which may collate and coordinate funds for the settlement). Settlement via the common RTP network may reduce the communication requirements for the settlement; fewer messages / communications may be needed to enact the settlement. Once the payment transaction has been authorised (e.g., using the conventional authorisation methods associated with the card payment network), the issuer may provide a single instruction for the payment to be settled via the common RTP network. The settlement funds may be transferred directly to a merchant’s account / wallet. Thus, the present invention may enable a reduced number of steps / communications involved in the settlement of the transaction. Using the methods described herein, settlement funds may be transferred from a consumer to a merchant directly. Conventional settlement methods may require funds to be moved from the consumer to the issuer, to a settlement agent / clearing house, to the acquirer, and finally to the merchant, for example. The reduced steps may enable reduced computational requirements (e.g., for storing the necessary data and / or facilitating the required communication / transfer of funds).

[0021] The real-time payment (RTP) network discussed herein may be any payment network that enables funds to be transferred directly between a payer and a payee, without the use of conventional, debit / credit card-based payment networks (discussed further below). The RTP network may comprise an RTP system; a payment system that provides for real-time payments between non-convention (i.e., non bank-based) accounts. Said RTP systems may be associated with a mobile application or other internet-enabled technology. The Faster Payments System (FPS) developed by Vocalink a Mastercard Company and the Immediate Payment Service (IMPS) developed by National Payments Corporation of India (NPCI) are examples of RTP payment systems. Network details for such RTP systems may be an identifier for an account on said systems. Accounts may be identified by a name, an account number, a telephone number or an email address for example. RTP systems may be used to transfer real currencies. Depending upon the RTP system in question, users may be able to transfer and hold multiple different currencies via the RTP system.

[0022] Additionally, or alternatively, the RTP network may comprise a digital currency network. The RTP network may comprise central bank digital currency (CBDC) systems or blockchain / distributed ledger-based technologies. The RTP network may not use traditional currencies, but may instead involve the transfer of digital / crypto currencies. Network details for such digital-currency based systems may be an identifier for an account / wallet on said systems. A digital currency wallet may be identified by a wallet address, for example. Digital currency wallets may be able to transfer and hold multiple different digital currencies.

[0023] The computer implemented method may further comprise, in the event that the common RTP network between the payer and receiving party cannot be determined, instructing the payment to be settled via a conventional settlement method.

[0024] As described above, where a common RTP network is determined (i.e., both the payer and receiving party have indicated that they may use the same RTP network), settlement may be performed via said common RTP network. However, where this is not possible, the settlement may be conducted using the conventional settlement method associated with the card payment network. This may be enabled by the use of a payment authorisation request that facilitates conventional card payments (while providing additional fields for RTP transactions). The conventional settlement method may provide a fallback settlement option, thereby increasing the reliability and resilience of the method for processing payment transactions. The conventional settlement method may be used, for example, where: at least one of the payer and receiving party RTP network details indicates that they do not want to use an RTP network to fulfil the transaction (e.g., they have provided no RTP account / digital wallet address or there is an indication to use only conventional settlement methods); or where both the payer and receiving party have provided sufficient RTP network details, but no common RTP network subsists between them.

[0025] The conventional settlement method may be regarded as any existing method / process for settling transactions. As will be understood by the skilled person, the exact steps / entities involved in settlement may vary depending on a number of factors (e.g., the payment networks that are used for the transaction). Generally, the conventional settlement method comprises the steps that are taken after authorisation and clearing (i.e., after the consumer / merchant have been told that the card payment has been accepted) whereby funds are transferred from the issuer (a financial institution / bank which acts on behalf of the consumer) to the acquirer (a financial institution / bank that acts on behalf of the merchant). Conventional settlement may be conducted via a third-party, such as a payment gateway provider or a clearing house. During settlement, the issuer’s bank account is debited the necessary transaction funds and the acquirer’s bank account is credited the respective transaction funds (perhaps with a settlement fee being taken during this process). The settlement may be scheduled to take place periodically, such as on the next business day. Where multiple payments have been made from / to the same issuers / acquirers, these may be bundled together. Following the settlement of funds between the issuer and acquirer, the acquirer will transfer the funds to the merchant’s own bank account.

[0026] Alternatively, or additionally, the computer implemented method may further comprise, in the event that the common RTP network between the payer and receiving party cannot be determined, instructing the payment to be settled via a RTP network route. Where a common RTP network has not been determined, the issuer may still instruct the payment to be settled via a RTP network based off of pre-existing information. For example, the payment authorisation request may not contain any receiving party RTP network details. Nonetheless, the issuer may know that the acquirer does indeed accept RTP network payments (based off of historical transactions, for example). Therefore, the issuer may compare the payer RTP network details to these alternative / pre-existing receiving party RTP network details, and instruct the settlement accordingly. This may enable the settlement to be performed more efficiently (compared to conventional settlement), even where the receiving party has not provided RTP network details.

[0027] The computer implemented method may further comprise sending, from the issuer to an acquirer, a payment authorisation response, the payment authorisation response comprising details of how the payment is to be settled. The method may further comprise receiving, at the issuer, a settlement indication sent from the acquirer, the settlement indication comprising an indication of whether the payment has been settled.

[0028] Similar to the payment authorisation request, the payment authorisation response may comprise all of the details that would be present in an authorisation response for a conventional payment made via the card payment network, thereby allowing all or some of the existing authorisation steps associated with the card payment transactions to be performed as normal. For example, the payment authorisation response may be used by the acquirer and / or merchant to provide a near real-time confirmation to the consumer and merchant that the payment has been successful. The payment authorisation response may comprise additional fields that may be used to communicate details of the settlement via the common RTP network. For example, the payment authorisation response may include an indication of what RTP network was used for the settlement. The acquirer may then check that the expected settlement funds have been received in the corresponding RTP account / wallet and send the settlement indication to the issuer indicating as such accordingly. The payment authorisation response / settlement indication may therefore be used to validate that the RTP network settlement was successful without the need to send additional messages (compared to a conventional settlement method). This may improve the reliability of the settlement and / or reduce the computational requirements associated with confirming the settlement. A settlement indication may be provided without checking for settlement at the time of sending the payment authorisation response. For example, the acquirer may automatically check whether settlement funds have been received at a predetermined time after sending the authorisation response and provide the settlement indication accordingly.

[0029] The computer implemented method may further comprise receiving, at the issuer, a clearing request. This step may be performed subsequent to receiving a payment authorisation request and prior to instructing the payment to be settled via the common RTP network. Such a method, wherein the clearing request is sent separate to the payment authorisation request may be regarded as a ‘dual message scheme’ .

[0030] Alternatively, the payment authorisation request may comprise a clearing request. I.e., the payment authorisation request and clearing request are comprised in the same request / message. Such a method may be regarded as a ‘single message scheme’ .

[0031] Generally, in existing methods for conducting payment transactions, two messages are sent from the receiving party (e.g., the acquirer) to the issuer. The first of these, a payment authorisation request, may be used to gain authorisation for a transaction (e.g., by checking that the payer’s details are correct and that they have sufficient funds in their account). The second of these, the clearing request, may be sent by the acquirer to the issuer when they want the funds to be cleared and the transaction settled. The clearing request may be provided some time after the physical transaction / authorisation, such as the next day when the acquirer has verified and collated pending transactions.

[0032] The use of the single message scheme may reduce the number of messages that are sent between the parties involved in the payment transaction. The single method scheme may also facilitate faster payments than the dual message scheme. As the authorisation / clearing requests are sent together, the issuer may be able to receive these requests, compare RTP network details, and instruct the settlement via the common RTP network in (near) real time. That is, funds may be transferred to the receiving party and the transaction settled almost immediately (e.g., while the payer is still at a point-of-sale terminal, where the payment transaction is made in person or if an online payment amount is known / final). The single message scheme may preferably be used where the payment transaction involves fixed payment amounts. For example, the single message scheme may be used when the payer is buying items in a store or online, the items having a predefined cost. As the costs are predefined (and unlikely to change during the course of the transaction) such a payment transaction may be settled in real time using the method described herein.

[0033] The dual message scheme may preferably be used where the payment transaction involves unfixed or variable payment amounts, in which case the merchant / acquirer may not wish to provide a clearing request immediately. For example: when buying fuel, the payment authorisation request may be provided beforehand but the cost may not be known until after the payer has finished refuelling; at a hotel, the payment authorisation request may be provided when the payer checks in or checks out, but additional charges may yet to be added to their bill; or when paying for transit, the payment authorisation request may be provided at the start of the payer’s journey, but the cost not known until the payer finishes travelling (e.g., depending upon where they ‘tap on’ and ‘tap off’ a metro system).

[0034] Nonetheless, the use of RTP networks for settlement, as described herein, may still reduce messaging requirements and / or enable faster settlement when a dual message scheme is used. Settlement may also be instructed / performed in (near) real time using the dual message scheme. Settlement may be instructed based off of receiving the payment authorisation request alone, rather than waiting for the separate clearing request also.

[0035] The single message and dual message schemes may be according to an internationally recognised standard (for example, ISO 8583 and ISO 20022 message standards). Where the single message scheme is used, the combined authorisation and clearing request may be regarded / considered to be a Financial Transaction Request - i.e., the combined message may be regarded as one which affects funds. Where the dual message scheme is used, the authorisation request may be regarded / considered to be an Authorisation Request - i.e., the request itself is non-financial.

[0036] The computer implemented method may further comprise, in the event that the issuer instructed the payment to be settled via the common RTP network and the settlement indication indicates that the payment has not been settled, instructing the payment to be settled via the conventional settlement method.

[0037] In addition to instances where the RTP network settlement method cannot be used (as described above), the conventional settlement method may provide a fallback settlement option in the case that the RTP network settlement is instructed but is unsuccessful. This may be used to improve the reliability of the settlement by reducing the risk of settlement failing due to issues with the RTP network (e.g., an incorrect account number or wallet address).

[0038] Instructing the payment to be settled via the common RTP network may comprise generating a specified settlement time limit. The computer implemented method may further comprise, in the event that no settlement indication is received at the issuer within the specified settlement time limit, instructing the payment to be settled via the conventional settlement method.

[0039] By generating and imposing a specified (e.g., a predetermined) settlement time limit, the issuer may be able to ensure that the settlement is performed promptly. As discussed above, settlement via the RTP network is expected to be near instantaneous (e.g., taking approximately the time required for funds to be transferred from the payer to the receiving party via the RTP network). If the settlement is not confirmed within the predetermined time limit (e.g., a few seconds), this may indicate an issue with the RTP transfer. The issuer may then automatically take additional steps to ensure that the settlement is completed. This may comprise verifying that the original settlement has been performed and that the necessary funds have left the consumer’s account / wallet. The issuer may attempt the settlement via another common RTP network (if another one subsists between the payer and receiving party) or the conventional settlement method where required to fulfil the settlement.

[0040] The computer implemented method may further comprise, prior to receiving at the issuer the payment authorisation request, in response to a purchase being made from a payee to the payer, generating and sending, from the payee to an acquirer, a preliminary authorisation request. The method may further comprise receiving, at the acquirer, the preliminary authorisation request, and modifying the preliminary authorisation request to include the RTP network details for the receiving party, thereby generating the payment authorisation request. The method may further comprise sending, from the acquirer to the issuer, the payment authorisation request.

[0041] The payment process prior to the issuer comparing the payer and receiving party RTP network details may be substantially the same as authorisation steps conducted for a normal transaction via the card payment network. The merchant and / or acquirer may perform their own authorisation checks to confirm that the transaction should go ahead. The acquirer may provide receiving party RTP network details (e.g., a merchant and / or acquirer RTP system account number or digital currency wallet address) by modifying an additional field of the payment authorisation request.

[0042] The receiving party may be the acquirer and the RTP network details for the receiving party may comprise RTP network details for at least the acquirer. The receiving party may be the payee and the RTP network details for the receiving party may comprise network details for at least the payee.

[0043] In the case that the receiving party is the payee / merchant, settlement funds may be transferred directly from the consumer’s RTP system account or digital currency wallet to the merchant’s RTP system account or digital currency wallet via the common RTP network. This may reduce the computing requirements for facilitating the settlement, as the settlement may be enacted using a single transfer. In the case that the receiving party is the acquirer, settlement funds may be transferred from the consumer’s RTP system account or digital currency wallet to the acquirer’s RTP system account or digital currency wallet via the common RTP network. This may allow settlement to be performed even where the merchant has opted out of RTP network transactions (e.g., has provided no account / address), thereby enabling more widespread use of RTP networks.

[0044] The computer implemented method may further comprise, where the receiving party is the acquirer, after the payment to the acquirer has been settled, forwarding funds relating to the settled payment from the acquirer to the payee. The funds may be forwarded via a non-RTP network, such as a conventional bank transfer (e.g., where the merchant is not associated with any RTP network). The bank transfer may be conducted using a real-time payment network. The funds may be forwarded via an RTP network, which may enable the merchant to receive funds faster (e.g., where the merchant is affiliated with an RTP network but not a common RTP network with the payer, or where the merchant has chosen to share RTP network details with the acquirer but not with the issuer / consumer).

[0045] The preliminary authorisation request may comprise RTP network details for the payee. The RTP network details for the receiving party included in the payment authorisation request may comprise the RTP network details for the payee.

[0046] The payee / merchant may provide receiving party RTP network details (e.g., a merchant RTP system account number or digital currency wallet address) by modifying an additional field of the preliminary authorisation request. These modifications may be used by the acquirer to provide the merchant RTP network details to the issuer via the payment authorisation request. This may enable direct transfers to the merchant.

[0047] The receiving party may comprise multiple parties, each of the multiple parties receiving a portion of funds transferred during settlement of the payment. For example, during settlement of the payment transaction, both the payee and the acquirer may be transferred a portion of the settlement funds. Additionally, or alternatively, a portion of the funds may be transferred to a third-party (i.e., an entity other than the payee / merchant or acquirer, such as a payment network provider or the issuer). By transferring settlement funds to multiple receiving parties, any fees or charges may be paid during settlement, without the need to initiate further transactions. For example, the majority of the settlement funds may be transferred directly to the payee / merchant, but a percentage or fixed amount may be transferred to the acquirer and / or payment network provider as a fee. All or some of the transfers may be facilitated using the aforementioned common RTP network, depending on what RTP network details have been provided. For example, funds may be transferred to the merchant using the common RTP network, but transferred to the acquirer using a conventional settlement method (where the acquirer has not provided RTP network details, for example). Said funds may be transferred via a third party intermediary (e.g., the card payment network), who may also receive a portion of the funds and / or withhold a portion as a fee.

[0048] Instructing the payment to be settled may comprise providing a programable instruction via the common RTP network. The programable instruction may be a smart contract, for example. The programable instruction may be any suitable digital asset or message that is communicated via the RTP network and contains information / instructions (other than purely the monetary funds). The programable instruction may be provided by the issuer - e.g., when instructing the settlement, the issuer may call or instruct a smart contract associated with the payer’s wallet that initiates the transfer of funds to the receiving party. This may allow the issuer to initiate the settlement payment that can be subsequently finalised.

[0049] Additionally, or alternatively, another party may provide programable instructions to initiate the settlement transactions. For example, a payment network provider may provide a smart contract that initiates the settlement from the payer to the receiving party. Where the programable instructions are provided by a third-party, the issuer may still be responsible for comparing RTP network details are valid and match, so that the smart contract can be enacted correctly and securely.

[0050] Programmable instructions, such as smart contracts, may be used to provide a preauthorisation of the settlement dependent upon completion of some external event, depending upon the content of the instructions. For example, settlement may be instructed by the issuer using a smart contract, wherein the smart contract stipulates that funds are only to be transferred following a predetermined time interval or completion of a service (e.g., following a hotel stay or a car rental period). Once the conditions of the smart contract are satisfied, the settlement funds may then be transferred from the payer to the receiving party. Such functionality may still provide real-time confirmation (the smart contract may still be exchanged at the point of the payment transaction, but with funds being related to another condition). This may be used to provide an escrow agreement. As well as binary conditions like those discussed above, programmable instructions may contain additional instructions that affect the transfer of settlement funds. For example, a smart contract could provide conditions under which only part of the funds are transferred (e.g., upon partial completion of the service).

[0051] The RTP network details for the payer may comprise a payer RTP account identifier or an indication of the lack thereof. The RTP payment network details for the receiving party may comprise a receiving party RTP account identifier or an indication of the lack thereof.

[0052] The RTP account identifier may comprise details for an account on an RTP system or a wallet in a digital currency -based system, depending upon the RTP network used. The merchant and / or acquirer (i.e., the receiving party) may provide an RTP account identifier that they wish to use for the payment transaction that is being initiated, by including said RTP account identifier in the payment authorisation request. The consumer (i.e., the payer) may have provided an RTP account identifier (e.g., an RTP system account name / number or a digital currency wallet address) to their issuing bank, such that their payment card is linked to said RTP account. The receiving party and payer RTP accounts may then be used to settle the payment transaction. Alternatively, the receiving party and payer may provide an indication that they do not want to participate in RTP network transaction. The indication may simply be a lack of RTP account identifiers being provided (in which case the payment authorisation request or the payer database may include a blank or a null). The indication may comprise a separate field which may indicate whether the payer / receiving party wishes to participate in RTP network transactions.

[0053] The RTP network details for the payer may comprise a plurality of payer RTP account identifiers. The RTP network details for the receiving party may comprise a plurality of receiving party RTP account identifiers. The comparison of the payer and receiving party RTp network details may comprise comparing each of the payer RTP account identifiers to each of the receiving party RTP account identifiers.

[0054] The receiving party may modify the payment authorisation request to include a list of one or more RTP account identifiers / RTP networks, indicating that any of said RTP accounts / networks may be used for the settlement. Likewise, the payer may provide one or more RTP account identifiers / RTP networks in the payer database, indicating that any of said RTP accounts / networks may be used for the settlement. Each element in the payer RTP network details may be compared to each of the corresponding elements in the receiving party RTP network details (e.g., comparing RTP networks indicated by the payer and receiving party) to determine one or more common RTP networks between the payer and receiving party. Where multiple common RTP networks are found, any of these may be used for the settlement. Which of the multiple common RTP networks is used may depend on a variety of factors, e.g., the reliability / ubiquity of the network, funds available in the payer’s wallet, a geographical location of the payment transaction / RTP network. Where multiple common RTP networks are determined, they may be used to provide a fallback in the case that settlement via one of these common RTP networks fails.

[0055] The RTP network details for the payer and / or the RTP network details for the receiving party may comprise a preferred RTP network indication. Determination of the common RTP network may be based at least partially upon the preferred RTP network indication.

[0056] The payer and / or receiving party may provide an indication of their preferred RTP network for the settlement (or RTP networks that they explicitly do not want to use). This preference indication may be a separate field in the payer database and / or the payment authorisation request. The preference indication may refer to one or more different RTP networks. The preference indication may include a ranking of a plurality of RTP networks in order of preference. The ranking may be provided in a separate field, or the RTP networks / wallet addresses may be ordered in their own field so as to provide an indication of preference (without a separate preference indication field). The comparison of the payer RTP network details with the receiving party RTP network details may comprise accounting for the indicated preferences, so that a most preferable RTP network is selected (where more than one common RTP networks are determined).

[0057] The RTP network details for the payer may comprise a payer accepted currency indication. The RTP network details for the receiving party may comprise a receiving party accepted currency indication.

[0058] The payer and / or the receiving party may provide an indication of which currencies that they accept. The accepted currencies may be provided in a separate field of the payment authorisation request and / or the payer database. The accepted currency information may be useful where the RTP network(s) supported by the payer / receiving party facilitate transactions using multiple different currencies. For example, having compared the payer and receiving party RTP network details, multiple common RTP networks may be determined, supporting transactions using a plurality of different currencies. However, the receiving party may wish to receive funds in only US dollar denominated digital currencies, for example. Thus, the accepted currency information may be used to impose further restrictions on the settlement transaction method. This may be particularly useful for merchants in countries with volatile or unstable currencies, enabling them to be paid in currencies denominated in more stable currencies. Depending upon the RTP network, the currency / currencies may be a real currency or a digital / crypto currency.

[0059] The RTP network details for the payer may comprise a plurality of payer accepted currency indications and / or the RTP network details for the receiving party may comprise a plurality of receiving party accepted currency indications. The comparison of the payer and receiving party RTP network details may comprise comparing each of the payer accepted currency indications to each of the payer accepted currency indications and identifying a common currency between the payer and receiving party.

[0060] The receiving party may modify the payment authorisation request to include a list of one or more accepted currencies, indicating that any of said currencies may be used for the settlement. Likewise, the payer may provide one or more accepted currencies in the payer database, indicating that any of said currencies may be used for settlement. The lists of accepted currencies provided by the payer and receiving party may be compared to one another to determine a suitable currency for the settlement, i.e., a currency that the payer and receiving party have in common. Where multiple common currencies are determined, they may be used to provide a fallback in the case that settlement via one of these common currencies fail.

[0061] The RTP network details for the payer and / or the RTP network details for the receiving party may comprise a preferred currency indication. Identifying the common currency may be based at least partially upon the preferred currency indication.

[0062] Similar to the preferred RTP network discussed above, the payer and / or receiving party may provide an indication of their preferred currency for the settlement (or currencies that they explicitly do not want to use). This preference indication may be a separate field in the payer database and / or the payment authorisation request. The preference indication may refer to one or more different currencies. The preference indication may include a ranking of a plurality of currencies in order of preference. The ranking may be provided in a separate field, or the accepted currencies may be ordered in their own field so as to provide an indication of preference (without a separate preference indication field). The comparison of the payer RTP network details with the receiving party RTP network details may comprise accounting for the indicated preferences, so that a most preferred currency is selected (where more than one common currencies are determined).

[0063] The RTP network details for the payer may be retrieved, by the issuer, from a payer database. The payment authorisation request received by the issuer may comprise the RTP network details for the payer.

[0064] The issuer receives the RTP network details for the receiving party via the payment authorisation request. These details may be provided by the merchant and / or the acquirer during the transaction / authorisation. However, in order to instruct the RTP network settlement, the issuer also requires RTP network details for the payer. The payer RTP network details could be retrieved from a payer database. The issuer, being the issuing bank for the payment card used by the consumer / payer, may have access to a payer database that comprises payer RTP network details. For example, the payer may have added RTP system account numbers and / or digital currency wallet addresses to their banking profile, such that said accounts / wallets are linked to their payment card. This may reduce the amount of information that needs to be transferred between the acquirer and issuer.

[0065] In addition to knowing the RTP network details for the payer, the issuer may also have the authority to instruct payments via the RTP network on behalf of the payer (so that the settlement funds can be transferred from the payer / consumer to the receiving party). This delegated authority may be achieved in a number of ways. The payer RTP account / digital wallet may be an account / wallet that the issuer has custody of (e.g., an account / wallet owned by the issuer and used by the payer). Alternatively, the payer may be the custodian of the account / wallet, but they have provided the issuer with appropriate permissions to initiate the settlement transaction. For example, the payer may have provided the issuer with access to the account / wallet’ s private keys or access may be granted programmatically (e.g., via the use of a smart contract). Alternatively, the issuer may instruct another party who does have sufficient authority over the payer RTP account / digital wallet to initiate the payment.

[0066] Alternatively, or additionally, the issuer may also receive the payer RTP network details via the payment authorisation request. For example, the payer’s payment card may store payer RTP network details (e.g., RTP system account numbers and / or digital wallet addresses) which may be forwarded to the merchant / acquirer during the card payment transaction for inclusion in the payment authorisation request.

[0067] The computer implemented method may further comprise verifying that the RTP network details for the receiving party match a receiving party identity and / or that the RTP network details for the payer match a payer identity.

[0068] Verifying that the payer / receiving party RTP network details match a corresponding payer / receiving party identity may reduce the likelihood of fraud or of settlement funds being incorrectly transferred to the wrong wallet. The verification may comprise checking that the payer and receiving party have control over an RTP system account and / or digital wallet address that they have provided for settlement. This may be done by comparing keys of the accounts / wallets, or by comparing details of previous transactions to / from the wallets. The verification may include comparing the digital credentials against a database that stores and actively manages verified credentials, i.e., by checking that the RTP network details that have been provided match known, verified RTP network details.

[0069] The common RTP network between the payer and receiving party may be one of a central bank digital currency, permissioned distributed ledger network, a permissionless distributed ledger network or a real-time payment system.

[0070] Although discussed herein as relating to RTP networks and transactions, the skilled person will recognise that any system that enables fast (i.e., transaction-by-transaction) transfers of funds between parties may be used to provide settlement of the card payment transaction. The common RTP network may comprise a digital currency network or real-time payment rail. The common digital currency network may comprise a blockchain-based payment network.

[0071] According to another aspect of the invention, there is provided a system for providing processing of a payment transaction. The system is configured to receive, at an issuer, a payment authorisation request for a payment transaction between a payer and a payee initiated via a card payment network, the payment authorisation request comprising RTP network details for the receiving party. The system is further configured to compare, at the issuer, payer RTP network details with the receiving party RTP network details, in order to determine if there is a common RTP network between the payer and receiving party. The system is further configured to, in the event that the common RTP network can be determined, instructing the payment to be settled via the common RTP network.

[0072] The system may be configured to perform a computer implemented method according to an aspect of the invention.

[0073] According to another aspect of the invention, there is provided a non-transitory computer-readable medium comprising instructions which, when executed by a computer, cause the computer to receive, at an issuer, a payment authorisation request for a payment transaction between a payer and a payee initiated via a card payment network, the payment authorisation request comprising RTP network details for the receiving party. The instructions further cause the computer to compare, at the issuer, payer RTP network details with the receiving party RTP network details, in order to determine if there is a common RTP network between the payer and receiving party. The instructions further cause the computer to, in the event that the common RTP network can be determined, instruct the payment to be settled via the common RTP network. The non-transitory computer-readable medium may comprise instructions which, when executed by a computer, cause the computer to carry out a computer implemented method according to an aspect of the invention.

[0074] According to a further aspect of the invention, there is provided a computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out a method for processing of a payment transaction, the method comprising receiving, at an issuer, a payment authorisation request for a payment transaction between a payer and a payee initiated via a card payment network, the payment authorisation request comprising RTP network details for the receiving party. The method further comprises comparing, at the issuer, payer RTP network details with the receiving party RTP network details, in order to determine if there is a common RTP network between the payer and receiving party. The method further comprises, in the event that the common RTP network can be determined, instructing the payment to be settled via the common RTP network.

[0075] The computer program product may comprise instructions which, when the program is executed by a computer, cause the computer to carry out the method according to an aspect of the invention.

[0076] DESCRIPTION OF FIGURES

[0077] Embodiments of the invention will be described, purely by way of example, with reference to the accompanying drawings, in which:

[0078] Figure 1 shows a schematic diagram of a conventional system for processing a payment transaction made using a card payment network;

[0079] Figure 2 shows a schematic diagram of a system for processing a payment transaction;

[0080] Figures 3 to 5 shows a schematic diagram of a method for processing a payment transaction;

[0081] Figure 6 shows a schematic diagram of an alternative method for processing a payment transaction;

[0082] Figure 7 shows a diagram illustrating information that may be received at, or sent from, an issuer as part of a method for processing a payment transaction using digital currencies; Figure 8 shows a diagram illustrating information that may be received at, or sent from, an issuer as part of a method for processing a payment transaction using a real-time payment system;

[0083] Figure 9 shows an example of a data processing device; and Figure 10 shows a flow diagram of a computer implemented method for processing a payment transaction.

[0084] DETAILED DESCRIPTION

[0085] Referring to Figure 1, a schematic diagram of a conventional system for processing a payment transaction 100 made using a card payment network is shown. The payment process generally consists of three main stages: authorisation; clearing and settlement.

[0086] At the start of the authorisation stage of the payment process, a consumer 102 (also known as a payer) initiates a purchase 104 from a merchant 106 (also known as a payee). The purchase 104 is made using a card associated with the card payment network, for example a debit or credit card. The purchase 104 may be made in person (e.g., in a shop, where the consumer 102 pays for items at a point-of-sale device using a chip and PIN or a contactless payment facility) or online (e.g., via the merchant’s website where the consumer 102 provides their card details), for example.

[0087] Having made the purchase 104, the merchant 106 sends a preliminary authorisation request 108 to an acquirer 110 (otherwise known as an acquiring bank or merchant bank). The acquirer 110 acts an intermediary between the merchant 106 and an issuer 118 (otherwise known as an issuing bank), the issuer 118 being a financial institution that has issued the payment card to the customer 102. The acquirer 110 may generally be understood to be a financial institution that facilitates card payments on behalf of the merchant 106 - e.g., by the providing physical point-of-sale devices used by the merchant 106 and acting to settle the transfer of funds between the issuer 118 the merchant 106.

[0088] Once the acquirer 110 is satisfied that the card payment may continue, the acquirer 110 sends a payment authorisation request 112 to the issuer 118. The payment authorisation request 112 may be sent via third-party intermediary, for example a card payment network provider 114 or a payment processor, in which case the card payment network provider 114 will forward 116 the payment authorisation request to the issuer 118. The preliminary authorisation request 108 may comprise details regarding the consumer 102 that have been established through the purchase 104 (e.g., the consumer’s card number, name or banking details). The acquirer 110 may provide corresponding details regarding the acquirer 110, which may be included in the authorisation request 112.

[0089] Once the payment authorisation request 112 has been received by the issuer 118, the issuer 118 may perform an acceptance process to determine if the card payment associated with the purchase 104 should proceed. This may comprise authenticating the details of the consumer 102, the merchant 106 and / or the acquirer 110, based on details that are provided via the payment authorisation request 112. The issuer 118 may retrieve details from a consumer database (not shown), which may be used to facilitate the card payment. For example, a consumer bank account associated with the consumer’s card may be retrieved, or additional checks may be conducted to establish the relevant parties’ identities. The acquirer 110 and / or the card payment network provider 114 may also perform their own authentication checks.

[0090] Once all of the stakeholders are satisfied that the card payment can proceed, the authorisation stage may be concluded. A payment authorisation response (not shown) may be sent from the issuer 118 to the merchant 106 (e.g., via the acquirer 110 and / or the payment network 114), the payment authorisation response comprising an indication that the purchase 104 has been successful. This indication may be displayed to the consumer 102 and / or the merchant 104, for example, via a point-of-sale device, thereby providing confirmation to the consumer 102 / merchant 106 that the purchase 104 has been completed.

[0091] Alongside the conclusion of the authorisation stage, the clearing stage of the payment process 100 may be conducted. Clearing may generally comprise funds being allocated from a consumer’s account in order to cover the purchase 104. Clearing may comprise the issuer 118 putting a ‘shadow charge’ on the card or associated account of the consumer 104. Whereas the authorisation and clearing may be performed on a purchase-by-purchase basis - i.e., the purchase 104 is verified and a shadow charge allocated against the consumer account, which may be performed in a few seconds - the settlement stage of the payment process 100 is typically performed on a batch basis, which may take one business day or more to be completed.

[0092] Following the authorisation and clearing stages, the issuer 118 provides instructions 120 for the payment to be settled. The settlement process of Figure 1 may be regarded as a ‘conventional settlement method / process’; this is the method by which settlement may be performed for a standard card payment (i.e., without the RTP network provisions described in the present application). The settlement may be conducted via a third-party intermediary, for example a clearing house 122. The clearing house 122 may, for example, hold sufficient funds in reserve until the payment is settled and all of the relevant funds have been cleared. Final settlement may only be performed on a periodic basis, e.g., at a predetermined time on business days only. The cleared funds that are associated with all purchases 104 during the relevant period may be batched together so that all payments are settled at the same time, thereby reconciling all of the acquirer’s 110 transactions that are yet to be settled.

[0093] Once the settlement stage has commenced, funds may be transferred from a bank account of the consumer 102 / issuer 118 to the acquirer’s account 124. The funds associated with the purchase 104 in question may then be forwarded 126 to the merchant’s account 128. At this point, the purchase 104 has been completed and fully settled / reconciled; the associated funds have been transferred from the consumer 102 to the merchant 106.

[0094] Referring to Figure 2, a schematic diagram of a system for processing a payment transaction 200 according to the present invention is shown. The authorisation and clearing stages of the payment process are similar to that of the conventional payment process described in relation to Figure 1 - e.g., entities / steps 202 to 218 may correspond to the same entities / steps 102 of 118 of Figure 1. A consumer 202 initiates a purchase 204 from a merchant 206 using a payment card. The merchant 206 sends a preliminary authorisation request 208 to an acquirer 210, who in turn sends a payment authorisation request 212 to an issuer 218. The payment authorisation request 212 may sent via a card payment network provider 214, who forwards 216 the payment authorisation request to the issuer 218. The issuer 218 may perform an acceptance process to determine if the purchase 204 should proceed. If the purchase can proceed, a payment authorisation response (not shown) may be sent from the issuer 218 to the merchant 106 (e.g., via the acquirer 210 and / or the payment network 214), the payment authorisation response comprising an indication that the purchase 204 has been successful. The issuer may then conduct the clearing stage, essentially allocating funds associated with the consumer 202 for the purchase 204. The authorisation and clearing stages may be conducted using the same card payment network as was used for the conventional payment process of Figure 1 - i.e., processes up until the settlement stage may be conducted using an existing card payment system (also known as an acceptance network). This may allow the method of processing payment tractions of the present invention to retain advantages associated with established card payment systems. For example: established fraud / authentication procedures may be utilised; said systems may be widely available (having already been ubiquitously used for facilitating card payments); and consumer / merchant protections may be retained (for example, providing for refunds or chargebacks).

[0095] However, the existing card payment systems that are used for authorisation and clearing stages may be modified to enable the settlement stage of the present invention. The payment authorisation request 212 comprises RTP network details for the receiving party. The RTP network details may comprise a RTP system account name / number (e.g., an account identifier for an application-based RTP system) and / or digital currency wallet address (e.g., an address for a digital wallet that may be used to store a central bank digital currency or a stablecoin) for the receiving party. For example, the preliminary authorisation request 208 may comprise a digital wallet address for the merchant, and / or the payment authorisation request 212 may comprise said digital wallet address for the merchant and / or a digital wallet address for the acquirer. These digital wallet addresses are contained in the payment authorisation request received by the issuer (where they are provided by the merchant / acquirer). In addition, or alternatively, to the digital wallet addresses, a name, number or other identifier associated with a RTP system may be used.

[0096] The RTP network details provided within the payment authorisation request 212, 216 may be an alias of the RTP network details of the receiving party. During the authorisation process, real RTP network details corresponding to the alias RTP network details be retrieved. For example, the payment authorisation request 212 provided by the acquirer may contain alias RTP network details. As the payment authorisation request 212 is sent via the payment network provider 214, the payment network provider 214 may retrieve the corresponding real RTP network details, and forward 216 said details to the issuer 218. In either case, the RTP network details for the receiving party (such as a username / account number for an RTP system or a digital wallet address) or the alias RTP network details may be included in the payment authorisation request 212 by either the merchant or the acquirer.

[0097] The receiving party is regarded as the entity / entities that receive funds from the issuer 218 via the settlement process; this may be the acquirer 210, the merchant 206, or a combination of both acquirer 210 and merchant 206, depending on the implementation. The receiving party may also comprise an additional party that receives some of the settlement funds. For example, a payment network provider may be a receiving party, whereby they receive a percentage of the transaction amount as a fee for facilitating the transaction.

[0098] Compared to the conventional payment process of Figure 1, the payment authorisation request 212 may comprise one or more additional fields that may be used to store the RTP network details for the receiving party. For example, the payment authorisation request 212 may comprise a field which may comprise one or more digital currency wallet addresses and / or RTP system account names / numbers for the receiving party and a field which may comprise one or more currencies accepted by the receiving party. Where the receiving party does not want to use RTP networks, the RTP network details may comprise an indication that no account / wallet has been provided, or said field may be left empty or be omitted.

[0099] The receiving party RTP network details are provided during the authorisation process, such that the payment authorisation request 212 received by the issuer 218 comprises the RTP network details for the receiving party. The acquirer 210 may modify the appropriate field of the payment authorisation request 212 to include a username / account number for an RTP system or a digital currency wallet address for the acquirer and / or a username / account number for an RTP system or a digital currency wallet address for the merchant, for example. Additionally, or alternatively, the merchant 206 may modify an appropriate field of the preliminary authorisation request 208 to include a username / account number for an RTP system or a digital currency wallet address for the merchant, said account number / address being included in the payment authorisation request 212.

[0100] Upon receipt of the payment authorisation request 212, the issuer compares the receiving party RTP network details (contained within the payment authorisation request 212), with RTP network details for the payer (i.e., the consumer 202). In the case where alias RTP network details are provided in place of the real RTP network details of the receiving party, the payment network 214 (or some other third-party entity, or the issuer themselves) may retrieve the real receiving party’s RTP network details from a database using the corresponding alias details in the payment authorisation request 212. The payment network 214 / third party may forward the real RTP network details to the issuer 218 in payment authorisation message 216 (and not the alias details), so that the RTP network details of the payer and receiving party can be compared, as described herein. For example, the alias RTP network details contained within the payment authorisation request 212 provided by the acquirer 210 may be swapped or supplemented with the corresponding real RTP network details for use by the issuer 218.

[0101] The issuer may retrieve the payer RTP network details from a payer database. For example, the card that is used by the consumer 202 for the purchase 204 may be linked to one or more RTP system accounts and / or digital currency wallets, which may be stored in a database of the consumer’s details. Upon receiving a payment authorisation request 212 initiated by a purchase 204 made by the consumer 202, the issuer 218 may retrieve the addresses for the linked accounts / wallets for the consumer / payer 202.

[0102] Alternatively, or additionally, payer RTP network details may be provided to the issuer 218 in the payment authorisation request 216. For example, one or more RTP system account usernames / numbers or digital currency wallet addresses for the consumer / payer 202 may be passed to the merchant 206 during the purchase 204 for inclusion in the preliminary authorisation request 208 and the payment authorisation request 212. The one or more currency wallet addresses for the consumer / payer 202 may be stored on the card that is used for the purchase 204. The issuer 218 may perform a validation or check of the received payer account details / wallet addresses in order to ensure that the payer’s details are correct / expected. For example, where the issuer 218 receives a payer digital currency wallet address (via the payment authorisation request 216) that is provided by the consumer 202 during the card purchase 204, this address may be validated against a database of known digital wallet addresses for the consumer 202, to ensure that settlement funds are taken from a digital wallet belonging to / controlled by the consumer 202.

[0103] During the comparison of the payer RTP network details and the receiving party RTP network details, the issuer will attempt to determine a common RTP network between the payer (i.e., the consumer 202) and the receiving party (i.e., the merchant 206 or the acquirer 210).

[0104] For example, the payer may have a first digital wallet address for a central bank digital currency X and a second digital wallet address for a stablecoin Y linked to their payment card / bank account. Meanwhile, the acquirer may have provided a digital wallet address for the central bank digital currency X for inclusion in the payment authorisation request 212 (said wallet belonging to the merchant or the acquirer themselves). Having compared the payer and receiving party digital currency networks details, the issuer 218 in this example may determine that digital wallet addresses for the central bank digital currency X have been provided by both the payer and receiving party. As such, this central bank digital currency network may be used for settlement of the payment process. The same process can be performed for RTP systems, where username / account details of the respective parties on the RTP system may be compared to determine a common RTP system.

[0105] On the other hand, if the issuer cannot determine a common RTP network between the payer and payer, a RTP network is not used for settlement. The issuer may instead instruct settlement to be performed in a conventional way, as per the method shown in Figure 1. This may occur where the RTP network details are mutually exclusive (e.g., the payer and receiving party do not have corresponding details for the same RTP system / digital currency) or where at least one of the payer / receiving party does not accept RTP network payments (e.g., the payment authorisation request 212 includes an indication that the payer has not provided a digital currency wallet address or an RTP system account name / number).

[0106] Where the issuer 218 is able to determine a common RTP network between the payer and receiving party, the issuer 218 may send instructions 219 for settlement to be performed via the common RTP network. The funds for the settlement are taken from the consumer / payer RTP account 222 (e.g., an account associated with an RTP system or a digital currency wallet) associated with the common RTP network. The issuer 218 may check that the consumer RTP account 222 has sufficient funds to cover the purchase 204 when sending the settlement instructions 219.

[0107] In the case that the receiving party RTP network details comprise a RTP account for the merchant 206 (or at least said merchant RTP account is associated with the common RTP network that is determined by the issuer 218), the settlement funds may be directly transferred 220a from the consumer RTP account 222 to the merchant RTP account 228a.

[0108] In the case that the receiving party RTP network details comprise an RTP account for the acquirer 210 (or at least said acquirer RTP account is associated with the common RTP network that is determined by the issuer 218), the settlement funds may be transferred 220b from the consumer RTP account 222 to the acquirer RTP account 224a. Following this initial settlement transfer 220b, the funds may be forwarded 226a to the merchant RTP account 228a (where the merchant 206 accepts RTP network payments and has provided a to the acquirer 210). Alternatively, where RTP transfers 226a are unavailable, the funds may be forwarded to a merchant bank account 228b using, for example, a conventional bank transfer.

[0109] During the transfer of settlement funds from the consumer RTP account 222, the settlement funds may be sent to multiple parties. Funds may be transferred 220a, 220b to both the acquirer RTP account 224a and the merchant RTP account 228a (e.g., where the acquirer is to receive a certain proportion of the transaction amount). The settlement funds may also be sent to a third-party in addition to the merchant 206 and / or acquirer 210 (for example, the payment network 214) where said third-party is to receive a fee for their facilitation of the transaction.

[0110] Referring to Figures 3 to 6, a computer implemented method for processing payment transactions according to the present invention is shown. It will be understood that the method shown in Figures 3 to 6 provides further details that may be implemented into the method described above in relation to Figure 2.

[0111] Figure 3 shows the method steps for authorisation and clearing stages 300 of the payment process. A purchase 320 is initiated between a consumer 302 and a merchant 306 and a preliminary authentication request 322 is sent from the merchant 306 to the acquirer 310. In the example of Figure 3, the acquirer 310 adds 324 receiving party RTP network details to the request (e.g., a field of the request may be updated to include a merchant RTP account details and / or an acquirer RTP account details - such as an RTP system username / account number or a digital currency wallet address). The merchant 306 may have also or alternatively added receiving party RTP network details to the request (not shown). The acquirer 310 then sends a payment authorisation request 326 comprising receiving party RTP network details to an issuer 318. The payment authorisation request may be forwarded 328 to the issuer by a third-party intermediary, such as a card payment network provider 314.

[0112] Upon receiving the payment authorisation request 326 comprising receiving party RTP network details, the issuer 318 may authorise 330 the transaction for the purchase 320. The authorisation 330 may comprise checking the identity of the consumer 302 and / or merchant 306, that the relevant card has not been flagged as stolen / lost, or ensuring that the consumer 302 has sufficient funds, for example. The issuer 318 compares 332 the RTP network details of the receiving party (those provided in the payment authorisation request 326) to those of the payer (which may be retrieved from a database based on what RTP network details of the consumer 302 are linked to the card used for the purchase 320). The comparison 332 is used determine a common RTP network between the payer and receiving party that may be used to settle the transaction, rather than using conventional settlement methods.

[0113] Once the transaction has been authorised by the issuer 318, a payment authorisation response 334 is sent from the issuer 318 to the acquirer 310. The payment authorisation response may be forwarded 336 to the acquirer by a third-party intermediary, such as the card payment network provider 314. Upon receiving the payment authorisation response 334, the acquirer 310 may send a final authorisation confirmation 338 to the merchant 306, who may in turn provide confirmation that the sale is complete 340 to the consumer 302.

[0114] A clearing request (not shown in Figure 3) may also be sent to the issuer 318 from the acquirer 310. The clearing request may comprise a request for the settlement of the payment. This clearing request may first be sent to the payment network 314. The payment network 314 may then forward the clearing request to the issuer 318.

[0115] The clearing request may be provided separately and subsequently to the illustrated payment authorisation request 326, in a dual message scheme. Following the authorisation being completed (e.g., at some time following the authorisation response 336 being received), the acquirer 310 may send a clearing request to the issuer 318. The sending of the additional clearing request may have similar structure to what is shown in Figure 3. That is, the clearing request may be sent to the issuer 318 similarly to the payment authorisation request 328 (perhaps via third party intermediaries). The issuer may then process the request and commence with instructing the settlement, as described further below. A clearing response (not shown) may then be sent from the issuer 318 to the acquirer 310 similarly to the payment authorisation response 334, thereby providing confirmation that the clearing request has been received and acted upon. In essence, a ‘delta-shaped flow’ like that shown in Figure 3 may be performed twice; once for authorisation and once for clearing. The clearing response may be omitted, such that the clearing messaging is one-way from the acquirer to the issuer. The settlement may be initiated by the issuer based upon the authorisation and the determination of a common RTP network, i.e., prior or regardless of the clearing message.

[0116] Alternatively, a single message scheme may be used, wherein the payment authorisation request and the clearing request are be sent together. In such a scenario, the payment authorisation request 326 shown in Figure 3 may comprise additional clearing information compared to the single message scheme. As such, the issuer 318 may be able to instruct settlement of transaction upon receipt of said single message. The payment authorisation response 334 provided by the issuer 318 may likewise comprise a clearing response.

[0117] Figures 4 and 5 show alternative method steps for the settlement stage 400, 500 of the payment process. The settlement stage is conducted subsequent to (or partially in conjunction with) the steps of the authorisation and clearing stages 300. The settlement stage 400, 500 can begin following the comparison 332 of the payer and receiving party RTP network details in Figure 3. The settlement stages of Figure 4 and 5 are both conducted subsequent to (or partially in conjunction with) the dual message payment process described above in relation to Figure 3.

[0118] Figure 4 shows the method steps for the settlement stage 400 where settlement is performed between a consumer’s RTP account and an acquirer’s RTP account (e.g., an account on an RTP system or a digital currency wallet). Following the determination that there is a common RTP network, the issuer 418 obtains the relevant receiving party RTP details (e.g., a RTP system account name / number or a digital currency wallet address for the acquirer 410) and instructs a transfer 420 of the necessary funds from the consumer’s RTP account to the acquirer’s RTP account for settlement of the transaction. The acquirer 410 may perform a check 422 to establish whether the transfer has been a success. For example, the acquirer 410 may perform a check that the funds have been received in the acquirer digital currency wallet a predetermined time period after they sent the payment authorisation request 326 to the issuer 418.

[0119] In the case that the transfer 420 was successful (option A in Figure 4), the acquirer 410 may send a settlement indication 424 to the issuer 418, the settlement indication 422 comprising an indication that the transfer 420 was successful. The acquirer 410 may forward 426 the funds to the merchant 406 so as to complete the settlement. The funds may be transferred to a merchant’s RTP account (where such details have been provided) or to a merchant’s bank account (via bank transfer, for example). The funds may also be transferred to both the merchant’s RTP account and merchant’s bank account simultaneously. A proportion of the funds may also be transferred to a third party, e.g., the payment network 414.

[0120] In the case that the transfer 420 was unsuccessful (option B in Figure 4), the acquirer 410 may send a message 428 to the issuer, the message 428 comprising an indication that the transfer 420 was unsuccessful (i.e., a negative or non-settlement indication). Where an unsuccessful transfer has occurred, the issuer 418 may: reattempt the transfer 420; attempt a transfer using different payer and / or receiving party RTP network details (e.g., where the payer and / or or receiving party have provided more than one RTP account); and / or proceed with the settlement using the conventional settlement method shown in Figure 1.

[0121] Figure 5 shows the method steps for the settlement stage 500 where settlement is performed directly between a consumer’s RTP account and a merchant’s RTP account (e.g., an RTP system account and / or a digital currency wallet). Following the determination that there is a common RTP network, the issuer 518 obtains the relevant receiving party RTP details (e.g., an RTP network account name / number or a digital currency wallet address for the merchant 506) and instructs a transfer 520 of the necessary funds from the consumer’s RTP account to the merchant’s RTP account for settlement of the transaction.

[0122] In the case that the transfer 520 was successful (option A in Figure 5), the merchant 506 may send an indication 522 to the acquirer 510 that the requisite funds have been received in merchant’s RTP account. Based on this indication, the acquirer may send a settlement indication 524 to the issuer 518, the settlement indication 524 comprising an indication that the transfer 520 was successful.

[0123] In the case that the transfer 520 was unsuccessful (option B in Figure 5), the merchant 506 may send an indication 526 to the acquirer 510 that the requisite funds have been not received in merchant’s RTP account and requesting that the settlement be fulfilled. Based on this indication, the acquirer 510 may send a message 528 to the issuer 518, the message 528 comprising an indication that the transfer 520 was unsuccessful (i.e., a negative or non-settlement indication). Where an unsuccessful transfer has occurred, the issuer 518 may: reattempt the transfer 520; attempt a transfer using different payer and / or receiving party RTP network details (e.g., where the payer and / or or receiving party have provided more than one RTP account); and / or proceed with the settlement using the conventional settlement method shown in Figure 1.

[0124] The above-mentioned method steps of Figures 4 and 5 are performed in conjunction with the dual message payment process discussed above. Figure 6 shows an alternative method for the settlement stage 600 of the single message payment process. The settlement stage 600 is conducted subsequent to (or partially in conjunction with) the steps of the single message payment process (i.e., combined authorisation and clearing).

[0125] Following the completion of the authorisation and clearing (via a single payment authorisation / clearing request), the required funds are transferred from the payer RTP account to the receiving party RTP account. Similar to Figures 4 and 5, the settlement funds may be sent to the RTP account (e.g., an account associated with an RTP system or a digital wallet) of the acquirer 610 or the merchant 606, depending on what RTP network details are provided (or a combination of the acquirer, merchant and / or other third parties). Following the determination that there is a common RTP network between the payer / consumer 602 and the acquirer 610, the issuer 618 obtains the relevant receiving party RTP network details (e.g., an RTP system account name / number and / or a digital currency wallet address for the acquirer 610) and instructs a transfer 620a of the necessary funds from the consumer’s RTP account to the acquirer’s RTP account for settlement of the transaction. Alternatively and / or additionally, following the determination that there is a common RTP network between the payer / consumer 602 and the merchant 606, the issuer 618 obtains the relevant receiving party RTP network details (e.g., an RTP system account name / number and / or a digital currency wallet address for the merchant 606) and instructs a transfer 620b of the necessary funds from the consumer’s RTP account to the merchant’s RTP account for settlement of the transaction. As with the examples described above, funds may be transferred to the merchant 606, acquirer 610 and / or other third-party entities (e.g., the payment network 614) simultaneously.

[0126] If it was found that the transfer 620 was successful (option A in Figure 6), no further action may be taken (at least with regard to the issuer 618). Where the transfer 620a involves the acquirer’s RTP account, the acquirer 610 may check 622 that the funds have been received in the indicated RTP account. The acquirer 610 may forward the funds to the merchant 606 so as to complete the settlement. The funds may be transferred to a merchant’s RTP account (where such details have been provided) or to a merchant’s bank account (via bank transfer, for example). Where the transfer 620b involves the merchant’s RTP account, the merchant 606 may similarly check that the funds have been received in the indicated RTP account (not shown in Figure 6).

[0127] In the case that the transfer 620 was unsuccessful (option B in Figure 6), the acquirer 610 may send a message 626 to a third-party intermediary (such as card payment network provider 614) or the issuer 618 directly, the message 626 comprising an indication that the transfer 620 was unsuccessful. The payment network provider 614 may then forward the message 628 to the issuer 618. The issuer 618 may then proceed to: reattempt the transfer 620a; attempt a transfer using different payer and / or receiving party RTP network details (e.g., where the payer and / or or receiving party have provided more than one RTP accounts); and / or proceed with the settlement using the conventional settlement method shown in Figure 1. These messages may be referred to as reconciliation messages, as they try to reconcile the settlement following authorisation and clearing. The issuer 618 and / or the payment network 614 may provide a response reconcile message 630 indicating that the settlement is being reattempted (and may include details of the method of this reattempted settlement, as discussed above). Although Figure 6 shows reconciliation being initiated by acquirer 610, the initial reconciliation message 626 may be provided by the merchant 606 in the instance that the transfer should have transferred funds to the merchant’s RTP account.

[0128] Referring to Figure 7, a schematic diagram of processes 700 undertaken at an issuer 702 during a computer implemented method for processing a payment transaction are shown.

[0129] The issuer 702 receives a payment authorisation request 710. The payment authorisation request 710 is received from an acquirer (perhaps via a third-party, e.g., a card payment network provider) and is generated in response to a consumer / payer initiating a payment transaction via a card payment network. For example, the consumer may have purchased an item in a shop using payment card through a merchant’s point-of-sale device. The payment authorisation request 710 comprises all of the necessary transaction data 712 that would be needed to process the transaction using an established card payment network. For example, the transaction data 712 may contain details regarding the transaction (e.g., monetary amount, time of transaction, location of transaction, etc.), details regarding the merchant and / or the acquirer (e.g., merchant banking details) and details regarding the consumer (e.g., details of the card used for the transaction, which may be obtained during the purchase). That is, the payment authorisation request 710 may be used to process the transaction using conventional authorisation, clearing and settlement methods.

[0130] However, the payment authorisation request 710 comprises as least one additional field that contains digital currency network details for a receiving party (which may be the merchant and / or the acquirer). Alternatively, as described above, the digital currency network details may be alias digital currency network details, the alias details corresponding to real digital currency network details that may be retrieved by the payment network provided, a third party or the issuer, for example. The digital currency network details may be added to the payment authorisation request 710 by the merchant and / or by the acquirer during authorisation of the transaction. In the example of Figure 7, two digital currency fields have been added. Sub-field 1 714 lists some digital currencies / networks that the receiving party is able / willing to use for settling the transaction - CBDCEUR (a central bank digital currency that is linked to Euros) and USD STABLECOIN (a US dollar denominated stablecoin). Sub-field 2 716 lists some digital currency wallet addresses controlled by the receiving party that may be used for one or more of the digital currency networks - the wallets in this case belong to a central bank digital currency network A and two different permissionless distributed ledger networks).

[0131] When the method is performed using a single message scheme (like that described in relation to Figure 6), the payment authorisation request 710 may comprise an additional clearing request. The authorisation request 710 may be identified as a combined authorisation and clearing message via a message type or indication. I.e., the authorisation request 710 may be identified as a Financial Transaction Request rather than just an Authorisation Request, and the issuer and / or third-party payment network may identify as such accordingly. The clearing request may be contained in an additional field and may contain details confirming the clearing, e.g., a transaction ID and a clearing / settlement method. The combined authorisation and clearing request may eliminate the need for a separate clearing request to be sent following authorisation.

[0132] After receiving the payment authorisation request 710, the issuer 702 requests and receives corresponding payer information from a payer database 720. The payer database 720 may comprise banking information 722 for the payer / consumer, the issuer 702 being an issuing bank for the card that was used by the consumer in the transaction. The card that was used by the consumer in the transaction may be linked to digital currency network details - for example, the consumer may have opted in to using digital currencies for purchases made using said card.

[0133] The payer information received by the issuer 702 contains digital currency network details for a payer. In the example of Figure 7, the payer details contain a list 724 of digital currencies / networks that payer has opted to use (CBDCGBP, CBDCEUR and EUR STABLECOIN (a central bank digital currency that is linked to pound sterling, a central bank digital currency that is linked to Euros, and a Euro denominated stablecoin respectively) and corresponding digital currency wallet addresses 726 controlled by the payer (central bank digital currency networks A and B, and a permissioned distributed ledger network).

[0134] Having received the digital currency network details for the payer and the receiving party, the issuer 702 compares said details to determine if there is a common digital currency network between the payer and receiving party. If there is, then the issuer 702 may instruct that the payment transaction be settled using said common digital currency network (via the wallet addresses 716, 726 provided by each party). If there is no common digital currency network, the issuer 702 may instruct that the payment transaction be settled using a conventional settlement mechanism as would be used for a normal transaction conducted via the card payment network. In this example, both the payer and receiving party have indicated that they can use the CBDCEUR currency network and have provided wallet addresses for CBDC network A. Therefore, the transaction may be settled using this digital currency.

[0135] The issuer 702 may generate and send a payment authorisation response 730 to the acquirer. The payment authorisation response 730 may contain details 732 indicating that the transaction has been authorised and how it has been settled. In particular, the payment authorisation response 730 may contain an additional field 734 that indicates the digital currency network that has been used for settlement (or that no common digital currency network could be found). In this example, one common digital currency network was found - CBDCEUR - and so the payment authorisation response 730 indicates that the settlement should be conducted using that digital currency. As no other common digital currency networks subsist between the payer and receiving party, the payment authorisation response 730 may indict that the settlement will otherwise be performed using the DEFAULT method (e.g., a conventional settlement mechanism for the card payment network in question). Having received the payment authorisation response 730, the acquirer may check that the settlement has been completed (e.g., check that the expected funds have been received in the digital currency wallet associated with the common digital currency network) and provide a clearing message to the issuer 702 comprising an indication of whether the payment has been settled or not. In the event that the common digital currency network can be determined, the issuer 702 instructs the that the settlement be performed using said common digital currency network. The issuer 702 may send settlement instructions 740 for initiating the settlement (which may comprise the issuer 702 initiating a payment from a payer’s digital wallet directly or via a third- party). The settlement instructions 740 comprise details 742 for the common digital currency network that are required for performing the digital currency transfer (e.g., a payer and payer digital currency wallet address and a payment amount). The settlement instructions 740 may comprise additional settlement data / instructions 744. For example, the additional data / instructions 744 may comprise further settlement instructions for use in the case that the first instructed digital currency settlement does not work - these additional instructions 744 may be for settlement using different digital currency network details (e.g., using a different network that was found to be in common between the payer and receiving party based upon the comparison of digital currency network details, or transferring funds from / to a different payer / payer digital currency wallet address) or instructions for settlement using a conventional settlement method. The settlement instructions 740 may comprise a settlement time limit - following the instruction of the settlement using the common digital currency network, a predetermined or specified period of time may be allowed to lapse. If a settlement indication is not received from the acquirer within said time period, indicating that the settlement has been completed, the settlement may instead be performed using the conventional settlement method.

[0136] Alternatively, or additionally, the settlement may be at least partially instructed by an entity other than the issuer, such as a payment network provider. In such cases, the payment network provider may leverage a programable instruction (e.g., a smart contract) that enables authorised parties to trigger instructions for the settlement. The programmable instruction may directly instruct the payer’s wallet to transfer funds to the receiving party.

[0137] Referring to Figure 8, a schematic diagram of processes 800 undertaken at an issuer 802 during a computer implemented method for processing a payment transaction are shown. The process 800 shows a similar process to that of Figure 7, with the above applying accordingly. The issuer 802 receives a payment authorisation request 810 comprising necessary transaction data 812. After receiving the payment authorisation request 810, the issuer 802 requests and receives corresponding payer information from a payer database 820 which may comprise banking information 822 for the payer / consumer. The issuer 802 may generate and send a payment authorisation response 830 to the acquirer. The payment authorisation response 830 may contain details 832 indicating that the transaction has been authorised and how it has been settled. Finally, the issuer 802 may send settlement instructions 840 for initiating the settlement. The settlement instructions 840 comprise details 842 for the common RTP network that are required for performing the transfer (e.g., a payer and payer RTP system account number and a payment amount). The settlement instructions 840 may comprise additional settlement data / instructions 844.

[0138] However, unlike Figure 7, which relates to digital currencies and digital current wallet details, the process 800 of Figure 8 relates to realtime payment (RTP systems). As discussed above, RTP systems may be used for settlement; funds can be transferred between a payer and a payee account on the RTP system, similarly to transferring digital currency funds between a payer and payee digital currency wallet. The fields shown in the requests / responses of Figure 8 show RTP system details accordingly. Fields may be provided for the digital currency details of Figure 7 and the RTP system details of Figure 8; the payer / payee may provide or accept both kids of RTP network payment.

[0139] The payment authorisation request 810 comprises a first subfield 1 814 that lists some RTP systems that the receiving party is able / willing to use for settling the transaction - RTP system X and RTP system Y could be two application-based RTP systems, for example. Sub-field 2 818 lists some details for accounts controlled by the receiving party that may be used for the RTP systems. The RTP accounts may be identified by an account number, a username or some other RTP account identifier (e.g., a phone number or email address), depending upon the RTP system in question. The payer details retrieved from the payer database 820 contain a list 824 of RTP systems that payer has opted to use (RTP systems X, Y and Z) and corresponding account details 826 for accounts controlled by the payer on said RTP systems.

[0140] The payment authorisation response 830 contains an additional field 834 that indicates the RTP system that has been used for settlement (or that no common RTP system could be found). In this example, two common RTP systems were found - RTP system X and RTP system Y - and so the payment authorisation response 830 indicates that the settlement should be conducted using either of said RTP systems. The authorisation request 810 or the payer database 820 may provide an indication of preference for which of the common RTP systems should be used.

[0141] It will be appreciated that any of the methods described herein, and any step of the methods, can be implemented by a computer. Such implementation may take the form of a processor executing instructions stored on a non-transitory computer-readable medium or media, wherein when executed the instructions cause the processor to perform any one or more steps of any of the methods described herein. Individual steps of any method may be implemented by different processors that are all collectively acting in accordance with computer-readable instructions stored on one or more storage media. The processor(s) may be component(s) of system, for example a processor of a device.

[0142] Similarly, any steps of any of the methods described herein may be performed by data processing devices. By way of example, Figure 9 shows, in schematic form, a data processing device 900 that is suitable for performing the method of processing a payment transaction, or any of the steps / processes therein. The data processing device 900 may automatically perform any of the methods described herein.

[0143] One or more such data processing devices 900 may be provided for implementing the method of the present invention. For example, each of a merchant device (for example, a point-of-sale terminal), an acquirer device, a card payment network device and an issuer device may comprise a data processing device 900. Distinct data processing devices 900 may be used for various steps / processes of the method described herein. Said devices may be networked together appropriately to enable any of the methods described herein.

[0144] Data processing device 900 includes a processor 903 for executing instructions. Instructions may be stored in a memory 901. Processor 903 may include one or more processing units (e.g., in a multi-core configuration) for executing instructions. The instructions may be executed within a variety of different operating systems on the data processing device 900, such as UNIX, LINUX, Microsoft Windows®, etc. More specifically, the instructions may cause various data manipulations on data stored in memory 901 (e.g., create, read, update, and delete procedures). It should also be appreciated that upon initiation of a computer-implemented method, various instructions may be executed during initialization. Some operations may be required to perform one or more methods described herein, while other operations may be more general and / or specific to a particular programming language (e.g., C, C#, C++, Java, or other suitable programming languages, etc.).

[0145] Processor 903 is operatively coupled to a communication interface 905 such that data processing device 900 can communicate with a remote device, such as another data processing device of the system. For example, communication interface 905 may receive communications from another member of the system.

[0146] Processor 903 may also be communicatively coupled to a storage device such as a database, depending on the function of data processing device 900 within the context of the system. The storage device is any computer-operated hardware suitable for storing and / or retrieving data, where in the case of a secure storage medium the data is stored and retrieved securely.

[0147] The storage database may, for example, store details of the payment transaction (e.g., the payment amount, the details of the card used in the transaction, the identities of each party involved in the payment process) and the digital currency network(s) in question (e.g., digital currency network details for the consumer, merchant and / or acquirer, such as digital currency wallet addresses), and it can be external to data processing device 900 and located remotely. Alternatively, it can be integrated in data processing device 900. For example, data processing device 900 may include memory 901 as one or more hard disk drives acting as a storage database. Alternatively, where the storage database is external to data processing device 900, it can comprise multiple storage units such as hard disks or solid-state disks in a redundant array of inexpensive disks (RAID) configuration. The storage database may include a storage area network (SAN) and / or a network attached storage (NAS) system. In some arrangements, the system and methods may be deployed in a cloud-based environment.

[0148] Processor 903 can be operatively coupled to the storage device (storage database) via a storage interface 907. Storage interface 907 is any component capable of providing processor 903 with access to the storage device. Storage interface 907 may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and / or any component providing processor 903 with access to the storage device.

[0149] Memory 901 may include, but is not limited to, RAM such as dynamic RAM (DRAM) or static RAM (SRAM), ROM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and non-volatile RAM (NVRAM). The above memory types are exemplary only and are not limiting as to the types of memory usable for storage of a computer program.

[0150] As used herein, the term "non-transitory computer-readable media / medium" is intended to be representative of any tangible computer- based device implemented in any method or technology for short-term and long-term storage of information, such as, computer-readable instructions, data structures, program modules and sub-modules, or other data in any device. The methods described herein may be encoded as executable instructions embodied in a tangible, non-transitory, computer readable medium, including, without limitation, a storage device, and / or a memory device. Such instructions, when executed by a processor, cause the processor to perform at least a portion of the methods described herein. Furthermore, as used herein, the term "non-transitory computer-readable media / medium" includes all tangible, computer-readable media, including, without limitation, non-transitory computer storage devices, including, without limitation, volatile and non-volatile media, and removable and non-removable media such as a firmware, physical and virtual storage, CD-ROMs, DVDs, and any other digital source such as a network or the Internet, as well as yet to be developed digital means, with the sole exception being a transitory, propagating signal.

[0151] As will be appreciated based on the specification herein, the above-described embodiments of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof. Any such resulting program, having computer-readable code means, may be embodied, or provided within one or more computer-readable media, thereby making a computer program product, i.e., an article of manufacture, according to the discussed embodiments of the disclosure. The article of manufacture containing the computer code may be made and / or used by executing the code directly from one medium, by copying the code from one medium to another medium, or by transmitting the code over a network.

[0152] While the disclosure has been described in terms of various embodiments, the person skilled in the art will recognise that the disclosure can be practiced with modification within the spirit and scope of the claims.

[0153] Referring to Figure 10, a flow diagram 1000 of a computer implemented method for processing a payment transaction is shown. Said method may be performed by the entities / payment networks described above in relation to Figures 2 to 6.

[0154] At step 1002, the method involves receiving, at an issuer, a payment authorisation request for a payment transaction between a payer (i.e., a consumer) and a payee (i.e., a merchant) initiated via a card payment network, the payment authorisation request comprising digital currency network details for a receiving party.

[0155] At step 1004, the method involves comparing, at the issuer, payer digital currency network details with the receiving party digital currency network details, in order to determine if there is a common digital currency network between the payer and receiving party. At step 1006, the method involves in the event that the common digital currency network can be determined, instructing the payment to be settled via the common digital currency network.

[0156] Although specific examples have been described, the skilled person will appreciate that variations are possible, within the scope of the invention, which should be determined with reference to the accompanying claims.

Claims

CLAIMS1. A computer implemented method for processing a payment transaction, the method comprising: receiving, at an issuer, a payment authorisation request for a payment transaction between a payer and a payee initiated via a card payment network, the payment authorisation request comprising real-time payment, RTP, network details for a receiving party; comparing, at the issuer, payer RTP network details with the receiving party RTP network details, in order to determine if there is a common RTP network between the payer and receiving party; and in the event that the common RTP network can be determined, instructing the payment to be settled via the common RTP network.

2. The computer implemented method of claim 1, further comprising, in the event that the common RTP network between the payer and receiving party cannot be determined, instructing the payment to be settled via a conventional settlement method.

3. The computer implemented method of claim 1 or claim 2, further comprising: sending, from the issuer to an acquirer, a payment authorisation response, the payment authorisation response comprising details of how the payment is to be settled; and / or receiving, at the issuer, a settlement indication sent from the acquirer, the settlement indication comprising an indication of whether the payment has been settled.

5. The computer implemented method of any preceding claim, wherein: the computer implemented method further comprises, subsequent to receiving a payment authorisation request and prior to instructing the instructing the payment to be settled via the common RTP network, receiving, at the issuer, a clearing request; orthe payment authorisation request comprises a clearing request.

6. The computer implemented method of any of claims 3 to5, further comprising, in the event that the issuer instructed the payment to be settled via the common RTP network and the settlement indication indicates that the payment has not been settled, instructing the payment to be settled via the conventional settlement method.

7. The computer implemented method of any of claims 3 to6, wherein instructing the payment to be settled via the common RTP network comprises generating a specified settlement time limit, and further comprising: in the event that no settlement indication is received at the issuer within the specified settlement time limit, instructing the payment to be settled via the conventional settlement method.

8. The computer implemented method of any preceding claim, further comprising, prior to receiving at the issuer the payment authorisation request: in response to a purchase being made from the payee to the payer, generating and sending, from the payee to an acquirer, a preliminary authorisation request; receiving, at the acquirer, the preliminary authorisation request, and modifying the preliminary authorisation request to include the RTP network details for the receiving party, thereby generating the payment authorisation request; and sending, from the acquirer to the issuer, the payment authorisation request.

9. The computer implemented method of claim 8, wherein: the receiving party is the acquirer and the RTP network details for the receiving party comprise RTP network details for at least the acquirer; and / orthe receiving party is the payee and the RTP network details for the receiving party comprise RTP network details for at least the payee.

10. The computer implemented method of claim 9, further comprising: where the receiving party is the acquirer, after the payment to the acquirer has been settled, forwarding funds relating to the settled payment from the acquirer to the payee.

11. The computer implemented method of any of claims 8 to10, wherein: the preliminary authorisation request comprises RTP network details for the payee; and the RTP network details for the receiving party included in the payment authorisation request comprise the RTP network details for the payee.

12. The computer implemented method of any of claims 8 to11, wherein the receiving party comprises multiple parties, each of the multiple parties receiving a portion of funds transferred during settlement of the payment.

13. The computer implemented method of any preceding claim, wherein instructing the payment to be settled comprises providing a programable instruction via the common RTP network.

14. The computer implemented method of any preceding claim, wherein: the RTP network details for the payer comprise a payer RTP account identifier or an indication of the lack thereof; and the RTP payment network details for the receiving party comprise a receiving party RTP account identifier or an indication of the lack thereof.

15. The computer implemented method of claim 14, wherein: the RTP network details for the payer comprise a plurality of payer RTP account identifiers and / or the RTP network details for the receiving party comprise a plurality of receiving party RTP account identifiers; and the comparison of the payer and receiving party RTP network details comprises comparing each of the payer RTP account identifiers to each of the receiving party RTP account identifiers.

16. The computer implemented method of claim 15, wherein the RTP network details for the payer and / or the RTP network details for the receiving party comprise a preferred RTP network indication, and wherein determination of the common RTP network is based at least partially upon the preferred RTP network indication.

17. The computer implemented method of any preceding claim, wherein: the RTP network details for the payer comprise a payer accepted currency indication; and the RTP network details for the receiving party comprise a receiving party accepted currency indication.

18. The computer implemented method of claim 17, wherein: the RTP network details for the payer comprise a plurality of payer accepted currency indications and / or the RTP network details for the receiving party comprise a plurality of receiving party accepted currency indications; and the comparison of the payer and receiving party RTP network details comprises comparing each of the payer accepted currency indications to each of the receiving party accepted currency indications and identifying a common currency between the payer and receiving party.

19. The computer implemented method of claim 18, wherein the RTP network details for the payer and / or the RTP network details for thereceiving party comprise a preferred currency indication, and wherein identifying the common currency is based at least partially upon the preferred currency indication.

20. The computer implemented method of any preceding claim, wherein: the RTP network details for the payer are retrieved, by the issuer, from a payer database; and / or the payment authorisation request received by the issuer comprises the payer RTP network details for the payer.

21. The computer implemented method of any preceding claim, further comprising verifying that the RTP network details for the receiving party match a receiving party identity and / or that the RTP network details for the payer match a payer identity.

22. The computer implemented method of any preceding claim, wherein the common RTP network between the payer and receiving party is one of a central bank digital currency, permissioned distributed ledger network, a permissionless distributed ledger network or a real-time payment system.

23. A system for providing processing of a payment transaction, wherein the system is configured to perform the method of any of claims 1 to 22.

24. A non-transitory computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the method of any claim 1 to 22.

25. A computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of any of claims 1 to 22.

Images