Alternative transaction settlement

Abstract

The present invention relates to methods and systems for processing a payment transaction, and particularly for providing settlement of payment transactions. The method comprises: receiving at a card payment network provider a payment authorisation request for a payment transaction between a payer and a payee initiated via a card payment network operated by the card payment network provider, the payment authorisation request comprising digital currency network details for a receiving party; comparing non-receiving party 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 non-receiving party and the receiving party, wherein the card payment network provider is authorised to utilise the non-receiving party digital currency network details to initiate a digital currency transaction; and in the event that the common digital currency network can be determined, instructing at the card payment network provider, the payment to be settled via the common digital currency network.

Description

[0001] ALTERNATIVE TRANSACTION SETTLEMENT

[0002] CROSS REFERENCE TO RELATED APPLICATION

[0003] This application claims the benefit of, and priority to, United Kingdom Patent Application No. 2500388.0, filed on January 13, 2025. 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 digital currencies to facilitate transactions. Digital currency networks, such as central bank digital currencies (CBDCs) or blockchain / distributed ledger-based technologies, can allow for near real-time transfer of funds, with digital currency being transferred directly from a payer wallet to a payee wallet. However, existing digital currency solutions also have drawbacks. Presently, digital currencies are not widely accepted or utilised amongst the general public; digital currencies are rarely used for day-to-day consumer transactions, and infrastructure facilitating their use is limited. Additionally, digital currencies may provide less consumer protection and / or accountability.

[0009] 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.

[0010] SUMMARY

[0011] According to an aspect of the invention, there is provided a computer implemented method for processing a payment transaction. The method comprises receiving, at a card payment network provider, a payment authorisation request for a payment transaction between a payer and a payee initiated via a card payment network operated by the card payment network provider, the payment authorisation request comprising digital currency network details for a receiving party. The method further comprises comparing non-receiving party 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 non-receiving party and the receiving party, wherein the card payment network provider is authorised to utilise the non-receiving party digital currency network details to initiate a digital currency transaction. The method further comprises, in the event that the common digital currency network can be determined, instructing, at the card payment network provider, the payment to be settled via the common digital currency network.

[0012] As discussed further below, the non-receiving party may be either the card payment network provider or the payer (i.e. consumer), dependingupon the scheme used to perform the settlement via the common digital currency network. The term ‘non-receiving party’ is used to refer to the party from who settlement funds are sent from to the receiving party (i.e., the merchant / payee or an acquirer). For example, where settlement funds are sent from a digital currency wallet of the card payment network provider to the merchant or acquirer, the card payment network provider will be regarded as the non-receiving party. Where settlement funds are sent from a digital currency wallet of the consumer to the merchant or acquirer, the consumer (also referred to as the payer) will be the non-receiving party. In either scenario, the settlement is instructed by the card payment network provider. Although referred to as a non-receiving party, said party may still receive some funds. For example, despite being the non-receiving party in some scenarios, the card payment network provider may still receive funds from the consumer / payer (said funds then being forwarded to the receiving party for settlement). The non-receiving party may also receive other funds from any of the parties involved in the payment transaction, for example fees for processing said payment transaction.

[0013] According to the various scenarios enabled by the present invention, instructing the settlement at the card payment network provider can provide (at least in some situations) for more efficient settlement of payments compared to utilising digital currency payments between the payer and payee directly. The card payment network provider is already a party to the payment transaction (because said payment transaction is initiated via the card payment network). Therefore, the card payment network provider may act as centralised party for coordinating the digital currency payment between the payer and the payee. This may reduce communication or storage requirements due to the centralised nature of the card payment network provider.

[0014] The use of a digital currency 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 (regardless of which specific settlement scheme of the present invention is utilised). The initial payment transaction may comprise a conventional purchase. Forexample, 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.

[0015] 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 digital currency network details for the receiving party.

[0016] The digital currency network details within the payment authorisation request may be the actual details of the currency network of the receiving party (e.g., a digital wallet address). Alternatively, the digital currency network details in the authorisation request may be alias digital currency network details maintained by one of the involved parties (e.g., the card payment network provider). The alias digital currency network details are digital currency network details that have no actual or real value and are only used in place of the real digital currency network details. Each of the alias digital currency network details may correspond to a real digital currency network detail.

[0017] The alias digital currency network details and each corresponding actual digital currency network details may be stored in a database maintained by, for example, the card payment network provider. Using the alias digitalcurrency network details, the corresponding real digital currency network details may be retrieved and utilised. For example, a receiving party (e.g., merchant and / or acquirer) may include alias digital currency network details comprising a ‘nickname’ or personal identification for a digital wallet (e.g., “Digital wallet 1”). The card payment network provider may use this alias to retrieve the real digital currency network details (e.g., the actual digital wallet address / network) that corresponds to the alias. The retrieved real digital currency network details may then be utilised to settle the transaction using the common digital currency network. Utilising alias digital currency network details may reduce the need to communicate real details between parties. The real digital currency network details may have been validated by a third party. The ‘matching’ of alias digital currency network details to the real digital currency 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.

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

[0019] The issuer may retrieve digital currency 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 digital wallet details for the consumer / payer.

[0020] Instructing the payment to be settled via the common digital currency 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 digital currency network may be near instantaneous - the required funds are transferred from a digitalcurrency wallet of the non-receiving party (i.e., the consumer or the card payment network provider) to a digital currency 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. In some examples, the settlement process may not be instantaneous. As discussed further below, a conventional currency bank transfer may be used to transfer funds from the issuer / consumer to the card payment network provider. This transfer may take some time to clear before the funds are then transferred to the receiving party via the common digital currency network. However, even when non-instantaneous, the methods of the present invention can still provide other advantageous discussed herein.

[0021] Settlement via the common digital currency 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 digital currency 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 digital currency 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 card payment network provider or issuer may provide a single instruction for the payment to be settled via the common digital currency network. The settlement funds may be transferred directly to a merchant’s digital currency 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 merchantdirectly using a digital currency. 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).

[0022] The non-receiving party may be the payer and the non-receiving digital currency network details may be digital currency network details for the payer. The card payment network provider may be granted authority to utilise the payer digital currency network details.

[0023] In one example of the computer implemented method, settlement is performed by transferring funds from the payer / consumer to the receiving party (e.g., between a consumer digital currency wallet and a merchant or acquirer digital currency wallet). This may allow existing digital currency network details for the payer, such as digital currency network details held by the issuer and / or linked to the payer’s payment card to be used for the settlement; the card network payment provider may not need their own digital currency network details. However, the settlement is still instructed via the card payment network provider. This may allow for greater coordination of the settlement and / or reduced computational resources, as the payment transaction at the settlement are both primarily handled centrally at the card payment network provider.

[0024] In order for the card payment network provider to instruct the settlement using the payer’s digital currency network details, the card payment network provider may be granted appropriate authority (e.g., permissions to initiate digital currency payments from the payer’s digital currency wallet). Authority may be granted by the payer themselves, or through a trusted financial institution such at the payer’s issuing bank or a third party that control the payer’s digital currency network details. Granting of the authority may comprise providing the card payment network provider with secure keys or other credentials, so that they are able to utilise the payer’s digital currency network details on behalf of the payer.The computer implemented method may further comprise sending, from the card payment network provider to an issuer, a digital currency network authorisation request comprising the receiving party digital currency network details. The computer implemented method may further comprise receiving, at the card payment network provider from the issuer, a digital currency network response comprising payer digital currency network details for the common digital currency network and an indication that the card payment network provider is authorised to utilise said payer digital currency network details for the common digital currency network.

[0025] After the payment authorisation request has been received at the card payment network provider, the card payment network provider may send a digital currency network authorisation request to the issuer. The digital currency network authorisation request may comprise an indication that the payer has initiated a payment transaction and that the receiving party has indicated that the payment may be settled using a digital currency network. Thus, the digital currency network authorisation request can be understood to be the card payment network provider requesting permission from the issuer to use digital currency network details of the payer. The issuer may perform verification steps before granting the card payment network provider said permission. For example, the issuer may check to see if the payer has sufficient funds (e.g., sufficient digital currency funds in a digital wallet) or to see if the payer has opted out of using digital currency payments. Once any verification by the issuer has been performed, the issuer may grant the card payment network provider with the necessary authority to instruct the settlement through the digital currency network response.

[0026] The comparison of the non-receiving party digital currency network details with the receiving party digital currency network details may be performed at the issuer. Said comparison may be between payer digital currency network details stored at the issuer and the receiving party digital currency network details sent from the card payment network provider.

[0027] Performing the comparison at the issuer may reduce the amount of data that needs to be transferred between the card payment network providerand the issuer. As discussed above, digital currency network details for the receiving party may be provided from the card payment network provider to the issuer in the digital currency network authorisation request. The issuer may already be in possession of the payer digital currency network details; these may be stored in an existing payer database along with other financial information for the payer. Hence the comparison of the non-receiving party (the payer) and the receiving party digital currency network details may be performed at the issuer. Following the comparison at the issuer, the determined common digital currency network details (where available) can then be sent from the issuer to the card payment network provider using the digital currency network response, such that the card payment network provider can continue with instructing the settlement. Where multiple common digital currency network details are determined, these may all be provided to the card payment network provider. The card payment network provider may select one of the common digital currency networks based on other criteria (e.g., previous transactions or any fees associated with the digital currency networks in question). Thus, using this scheme, the computer implemented method may only require the receiving party digital currency network details to be sent from the card payment network provider to the issuer and the determined common digital currency network details to be sent from the issuer to the card payment network provider.

[0028] The payer digital currency network details may be stored at the card payment network provider. The comparison of the payer digital currency network details with the receiving party digital currency network details may be performed at the card payment network provider. Said comparison may be between the payer digital currency network details stored at the card payment network provider and the receiving party digital currency network details received at the card payment network provider.

[0029] Alternatively, to the method discussed above, the comparison may be performed at the card payment network provider between payer digital currency network details stored at the card payment network provider and the receiving party digital currency network details received at the card paymentnetwork provider in the payment authorisation request. This alternative method may reduce the number of messages and / or the amount of data that must be sent between the card payment network provider and the issuer, depending upon the scenario involved, because the comparison and subsequent settlement instruction are both handled centrally at the card payment network provider.

[0030] The payer digital currency network details may be stored at the card payment network prior to the payment transaction being initiated. For example, the card payment network provider may already be in possession of digital currency network details for the payer because the payer has linked said digital currency network details to the payment card used in the transaction or following previous transactions that have used digital currency network details. Thus, the card payment network may just be able to receive said payer digital currency network details from a database.

[0031] The computer implemented method may further comprise, subsequent to determining the common digital currency network between the payer and the receiving party, sending, from the card payment network provider to an issuer, a digital currency network authorisation request comprising payer digital currency network details for the common digital currency network. The computer implemented method may further comprise receiving, at the card payment network provider from the issuer, a digital currency network response comprising an indication that the card payment network provider is authorised to utilise said payer digital currency network details for the common digital currency network.

[0032] Following the determination of the common digital currency network, the card payment network provider may request authorisation from the payer’s issuing bank to utilise payer details for said common digital currency network details. The issuer may perform verification checks on the common digital currency network details of the payer, for example to make sure that the payer has sufficient funds or that the payer has not declined to provide said details to the card payment network provider. If any such verification checks are passed, the issuer may provide authorisation to the card payment network provider to continue with instructing the settlement via the common digitalcurrency network.

[0033] The computer implemented method may further comprise receiving, at the issuer and prior to the comparison, the payer digital currency network details from a database, wherein the payer digital currency network details are retrieved from the database based upon payer identity details contained within the digital currency network authorisation request.

[0034] As discussed above, the issuer may already be in possession of the payer digital currency network details; these may be stored in an existing payer database along with other financial information for the payer. Following receipt of the payment authorisation request (which includes payer identity details identifying the payer, such as a card or account number), the card payment network provider may forward these details onto the issuer as part of the digital currency network authorisation request. Thus, the issuer may identify the payer and retrieve any associated digital currency network details that the issuer has stored.

[0035] The computer implemented method may further comprise receiving, at the card payment network provider and prior to the comparison, the payer digital currency network details from a database, wherein the payer digital currency network details are retrieved from the database based upon payer identity details contained within the payment authorisation request.

[0036] Likewise, and as discussed above, the payer digital currency network details may already be known to the card payment network provider (e.g., due to the digital currency network details being linked to the payment card used to initiate the payment transaction or from previous transactions) and stored at the card payment network provider in a database. Thus, the card payment network provider may identify the payer and retrieve any associated digital currency network details that have been stored based upon the payer identity details provided in the payment authorisation request.

[0037] Alternatively, the payer digital currency network details may not be available to the card payment network provider prior to payment transaction being initiated. Instead, following the receipt of the payment authorisation request, the card payment network provider may send a request to the issuer forany digital currency network details of the payee, the request including the payer identity details provided in the payment authorisation request. Following any verification steps at the issuer, the issuer may then send one or more payer digital currency network details to the card payment network provider. The issuer may retrieve payer digital currency network details from a database based upon the payer identity details, as discussed above. The retrieved payer digital currency network details may be stored at the card payment network provider and used in the comparison of the payer and receiving party digital currency network details as discussed above. Thus, the payer digital currency network details are stored and retrieved at the issuer, but the comparison is still performed at the card payment network provider. Thus, this example may still provide a centralised solution where the card payment network provider does not already have payer digital currency network details.

[0038] In this alternative example, the digital currency network digital currency network authorisation request may be sent as part of the request to the issuer for any digital currency network details of the payee, and the authorisation indication may be sent from the issuer to the card payment network provider alongside the one or more payer digital currency network details. In effect, the issuer may respond the card payment network providers request with one or more payer digital currency network details and authorisation to utilise any of them. Alternatively, the authorisation may be requested separately to the request to the issuer for any digital currency network details of the payee, following the determination of common digital currency network.

[0039] The non-receiving party may be the card payment network provider and the non-receiving digital currency network details may be digital currency network details for the card payment network provider. The card payment network provider may be capable of utilising the card payment network provider digital currency network details.

[0040] Compared to the examples discussed above where the nonreceiving party is the payer (i.e., settlement funds are transferred from the payer to the receiving party), the card payment network provider may instead operateas the non-receiving party. For example, settlement funds may be sent from a digital currency wallet owned and operated by the card payment network provider to a receiving party wallet. This can allow digital currency payments to be used for settlement even where the payer / consumer does not have a digital currency wallet, or at least does not share a common digital currency network with the receiving party. The card payment network provider may, in effect, act as a digital currency intermediary between the payer and the receiving party.

[0041] The card payment network provider may be capable of utilising the card payment network provider digital currency network details to the extent that the card payment network provider is able to use the digital currency network details independently, and without the authorisation of, an issuer. For example, the card payment network provider may have full control over a digital currency wallet, including the ability to initiate transfer of digital currency from said wallet. This may avoid the need for the card payment network to obtain authorisation from the issuer.

[0042] The computer implemented method may further comprise sending, from the card payment network provider to an issuer, an intermediary digital currency network authorisation request comprising the card payment network provider digital currency network details. The computer implemented method may further comprise receiving, at the card payment network provider from the issuer, an intermediary digital currency network response comprising confirmation that funds have been or will be transferred from the payer to the card payment network provider based upon the card payment network provider digital currency network details.

[0043] Where the card payment network provider is the non-receiving party, with settlement funds being transferred from the card payment network provider to the receiving party, the card payment network provider may act as an intermediary for the settlement funds between the payer and the receiving party. Digital currency may be transferred from the payer to the card payment network provider and then from the card payment network provider to the receiving party. This may be done sequentially as described. Or, digital currency may be transferred from the card payment network provider to thereceiving party in real time, with the transfer from the payer to the card payment network provider being done afterwards.

[0044] The computer implemented method may further comprise comparing, at the issuer, the card payment network provider digital currency network details with payer digital currency network details, in order to determine if there is a second common digital currency network between the card payment network provider and the payer. The computer implemented method may further comprise, in the event that the second common digital currency network can be determined, instructing, at the issuer, funds to be transferred from the payer to the card payment network provider via the second common digital currency network.

[0045] The comparison the determine the second common digital currency network may be performed in substantially the same manner as the comparison to determine the common digital currency network between the non-receiving party and the receiving party (also referred to as the primary common digital currency network). The second common digital currency network may not be the same network as the primary common digital currency network. This may allow the methods of the present invention to be utilised where the payer and the receiving party do not have a common digital currency network, but nonetheless the payer has a common digital currency network with the card payment network provider and the card payment network provider has a common digital currency network with the receiving party. I.e., funds may be transferred from the payer to the card payment network provider using a first digital currency network or digital currency, while funds are transferred from the card payment network provider to the receiving party using a second digital currency network or digital currency.

[0046] The intermediary digital currency network authorisation request may comprise a plurality of card payment network provider digital currency network details. Each of the card payment network provider digital currency network details may be compared to the payer digital currency network details at the issuer to determine the second common digital currency network details. The card payment network provider may own and operate wallets on manydifferent digital currency networks, whereas a typical consumer or merchant may only have one or two wallets. Thus, by providing a plurality of card payment network provider digital currency network details that may be used, the chances of their being a suitable intermediary digital currency wallet may be increased.

[0047] Alternatively, the comparison to determine the second common digital currency network may be performed at the card payment network provider. The card payment network provider may request any payer digital currency network details from the issuer (similar to as described above) and then compare these to the card payment network provider digital currency network details. This may be particularly advantageous where the card payment network provider has many digital currency wallets, so as to avoid having to send a large plurality of card payment network provider digital currency network details to the issuer.

[0048] The computer implemented method may further comprise sending, from the card payment network provider to an issuer, a conventional currency authorisation request, the conventional currency authorisation request comprising a request for the issuer to transfer funds from a bank account associated with the issuer to a bank account associated with the card payment network provider. The computer implemented method may further comprise receiving, at the card payment network provider from the issuer, a conventional currency authorisation response comprising confirmation that funds have been or will be transferred from the bank account associated with the issuer to the bank account associated with the card payment network provider.

[0049] Opposed to the alternative method above, where a second common digital currency network is found between the payer and the card payment network provider, a transfer of conventional currency may be used instead. This may be used where no second common digital currency network is found (following the comparison discussed above) or where the pay does not have any digital currency network details, thus allowing settlement to be performed using digital currency.

[0050] The computer implemented method may further comprise,subsequent to receiving the conventional currency authorisation response, converting conventional currency in the bank account associated with the card payment network provider to a digital currency for use with the common digital currency network.

[0051] Where funds are transferred from the issuer to the card payment network provider as a conventional currency (e.g., via a bank transfer), these funds may be converted into the appropriate digital currency at the card payment network provider. As with other methods discussed above, this may be done prior to the transfer of the digital currency settlement funds from the card payment network provider to the receiving party, or subsequent to this. The card payment network provider may have sufficient digital currency so that settlement can be completed without the need for the funds to be converted in advance.

[0052] The comparison of the card payment network provider digital currency network details with the receiving party digital currency network details may be performed at the card payment network provider. Said comparison may be between card payment network provider digital currency network details stored at the card payment network provider and the receiving party digital currency network details received at the card payment network provider.

[0053] Similar to other methods discussed above, the comparison may be performed at the card payment network provider between the non-receiving party (e.g., the card payment network provider) and the receiving party digital currency network details. Where either of the parties has multiple digital currency network details, all possible combinations may be compared to each other to determine one or more common digital currency network pair, as discussed herein. The card payment network provider may have many digital currency network details (e.g., many wallets on different digital currency networks) and these may be stored in a database so that the card payment network provider can use any of these as required.

[0054] The computer implemented method may further comprise, in the event that the common digital currency network between the non-receivingparty and receiving party cannot be determined, instructing the payment to be settled via a conventional settlement method.

[0055] As described above, where a common digital currency network is determined (i.e., both the non-receiving party and receiving party have indicated that they may use the same digital currency network), settlement may be performed via said common digital currency 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 digital currency 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 non-receiving party and receiving party digital currency network details indicates that they do not want to use digital currencies (e.g., they have provided no wallet address or there is an indication to use only conventional settlement methods); or where both the non-receiving party and receiving party have provided sufficient digital currency network details, but no common digital currency network subsists between them.

[0056] 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 thenecessary 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.

[0057] Alternatively, or additionally, the computer implemented method may further comprise, in the event that the common digital currency network between the payer and receiving party cannot be determined, instructing the payment to be settled via a digital network route. Where a common digital currency network has not be determined, the card payment network provider may still instruct the payment to be settled via a digital currency network based off of pre-existing information. For example, the payment authorisation request may not contain any receiving party digital network details. Nonetheless, the card payment network provider or issuer may know that the acquirer does indeed accept digital currency network payments (based off of historical transactions, for example). Therefore, the card payment network provider / issuer may compare the non-receiving party digital currency network details to these alternative / pre-existing receiving party digital currency 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 digital currency network details.

[0058] 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. The payment authorisation response and / or the settlement indication may be sent between the issuer and the acquirer via the card payment network provider. The card payment network provider may also verify that the payment authorisation response and / orsettlement indication have been sent.

[0059] 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 digital currency network. For example, the payment authorisation response may include an indication of what digital currency network was used for the settlement. The acquirer may then check that the expected settlement funds have been received in the corresponding digital currency wallet and send the settlement indication to the card payment network provider and / or the issuer indicating as such accordingly. The payment authorisation response / settlement indication may therefore be used to validate that the digital currency 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.

[0060] The computer implemented method may further comprise receiving, at the card payment network provider, 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 digital currency network. Such a method, wherein the clearing request is sent separate to the payment authorisation request may be regarded as a ‘dual message scheme’.The clearing request may be forwarded from the card payment network provider to the issuer.

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

[0062] 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.

[0063] 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 card payment network provider / issuer may be able to receive these requests, compare digital currency network details, and instruct the settlement via the common digital currency 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).

[0064] 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 and 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.

[0065] The dual message scheme may preferably be used where thepayment 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).

[0066] Nonetheless, the use of digital currency 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.

[0067] Settlement may be instructed based off of receiving the payment authorisation request alone, rather than waiting for the separate clearing request also.

[0068] 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.

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

[0070] In addition to instances where the digital currency network settlement method cannot be used (as described above), the conventional settlement method may provide a fallback settlement option in the case that thedigital currency 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 digital currency network (e.g., an incorrect wallet address).

[0071] Instructing the payment to be settled via the common digital currency 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 card payment network provider or issuer within the specified settlement time limit, instructing the payment to be settled via the conventional settlement method.

[0072] By generating and imposing a specified (e.g., a predetermined) settlement time limit, the card payment network provider may be able to ensure that the settlement is performed promptly. As discussed above, settlement via the digital currency payment is expected to be near instantaneous (e.g., taking approximately the time required for funds to be transferred from the nonreceiving party to the receiving party digital wallet). If the settlement is not confirmed within the predetermined time limit (e.g., a few seconds), this may indicate an issue with the digital currency transfer. The card payment network provider or 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 nonreceiving party’s wallet. The card payment network provider may attempt the settlement via another common digital currency network (if another one subsists between the non-receiving party and receiving party) or the conventional settlement method where required to fulfil the settlement.

[0073] The computer implemented method may further comprise, prior to receiving at the card payment network provider 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 digital currency network details for thereceiving party, thereby generating the payment authorisation request. The method may further comprise sending, from the acquirer to the card-payment network provider, the payment authorisation request.

[0074] The payment process prior to the card-payment network provider / issuer comparing the non-receiving party and receiving party digital currency 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 digital currency network details (e.g., a merchant and / or acquirer digital currency wallet address) by modifying an additional field of the payment authorisation request.

[0075] The receiving party may be the acquirer and the digital currency network details for the receiving party may comprise digital currency network details for at least the acquirer. The receiving party may be the payee and the digital currency network details for the receiving party may comprise digital currency network details for at least the payee.

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

[0077] 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 fromthe acquirer to the payee. The funds may be forwarded via a non-digital currency network, such as a conventional bank transfer (e.g., where the merchant is not associated with any digital currency network). The bank transfer may be conducted using a real time payment network. The funds may be forwarded via a digital currency network, which may enable the merchant to receive funds faster (e.g., where the merchant is affiliated with a digital currency network but not a common digital currency network with the nonreceiving party, or where the merchant has chosen to share digital currency network details with the acquirer but not with the card payment network provider or issuer / consumer).

[0078] The preliminary authorisation request may comprise digital currency network details for the payee. The digital currency network details for the receiving party included in the payment authorisation request may comprise the digital currency network details for the payee.

[0079] The payee / merchant may provide receiving party digital currency network details (e.g., a merchant 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 digital currency network details to the card payment network provider via the payment authorisation request. This may enable direct transfers to the merchant.

[0080] 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 the card 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 or retained by the acquirer and / or card payment network provider as a fee. All or some of the transfers maybe facilitated using the aforementioned common digital currency network, depending on what digital currency network details have been provided. For example, funds may be transferred to the merchant using the common digital currency network, but transferred to the acquirer using a conventional settlement method (where the acquirer has not provided digital currency network details, for example). Said funds may be transferred via a third party intermediary (e.g., the card payment network provider), who may also receive a portion of the funds and / or withhold a portion as a fee.

[0081] Instructing the payment to be settled may comprise providing a programable instruction via the common digital currency 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 digital currency network and contains information / instructions (other than purely the digital currency itself). The programable instruction may be provided by the card payment network provider - e.g., when instructing the settlement, the card payment network provider may call or instruct a smart contract associated with the non-receiving party’s wallet that initiates the transfer of funds to the receiving party. This may allow the card payment network provider to initiate the settlement payment that can be subsequently finalised.

[0082] 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 card payment network provider 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 non-receiving party 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 binaryconditions 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).

[0083] The digital currency payment network details for the nonreceiving party may comprise a non-receiving party digital currency wallet address or an indication of the lack thereof. The digital currency payment network details for the receiving party may comprise a receiving party digital currency wallet address or an indication of the lack thereof.

[0084] The merchant and / or acquirer (i.e., the receiving party) may provide a digital currency wallet address that they wish to use for the payment transaction that is being initiated, by including said wallet address in the payment authorisation request. The card payment network provider may have custody of one or more digital currency wallet address that the digital currency network provider can use for the digital currency-based settlement.

[0085] Additionally, or alternatively, the consumer may have provided a digital currency wallet address to their issuing bank, such that their payment card is linked to said digital wallet. The receiving party and non-receiving party digital wallets may then be used to settle the payment transaction. Alternatively, the receiving party and non-receiving party may provide an indication that they do not want to participate in digital currency network transaction. The indication may simply be a lack of digital currency wallet address being provided (in which case the payment authorisation request or a database may include a blank or a null). The indication may comprise a separate field which may indicate whether the non-receiving party / receiving party wishes to participate in digital currency network transactions.

[0086] The digital currency payment details for the non-receiving party may comprise a plurality of non-receiving party digital currency wallet addresses. The digital currency payment details for the receiving party may comprise a plurality of receiving party digital currency wallet addresses. The comparison of the non-receiving party and receiving party digital currency network details may comprise comparing each of the non-receiving party digitalwallet addresses to each of the receiving party digital wallet addresses.

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

[0088] The non-receiving party digital currency payment network details may comprise one or more digital currency network details (e.g., wallet addresses / networks) for both the card payment network provider and the payer / consumer. For example, the card payment network provider may make available a number of different wallet address across a plurality of networks. Meanwhile, the consumer may provide one or more digital wallet addresses, e.g., by having one or more digital wallet addresses linked to the payment card used to initiate the payment transaction. The card payment network provider may then choose to use the card payment network provider wallet or the consumer wallet according to the various schemes described herein. This decision may be influenced by a number of factors, such as whether either the card payment network provider or consumer has a common digital currencynetwork with the receiving party, the funds available in the various wallets, and / or preference of either non-receiving party. By being able to use either the card payment network provider wallet or consumer wallet as the non-receiving party, the present invention can provide greater compatibility and flexibility. E.g., the payment may still be settled via a digital currency network where one of the card payment network provider or consumer does not have or provide suitable digital currency network details.

[0089] The digital currency payment details for the non-receiving party and / or the digital currency payment details for the receiving party may comprise a preferred digital currency payment network indication.

[0090] Determination of the common digital currency network may be based at least partially upon the preferred digital currency payment network indication.

[0091] The non-receiving party and / or receiving party may provide an indication of their preferred digital currency network for the settlement (or digital currency networks that they explicitly do not want to use). This preference indication may be a separate field in a database and / or the payment authorisation request. The preference indication may refer to one or more different digital currency networks. The preference indication may include a ranking of a plurality of digital currency networks in order of preference. The ranking may be provided in a separate field, or the digital currency networks / digital currency 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 non-receiving party digital currency network details with the receiving party digital currency network details may comprise accounting for the indicated preferences, so that a most preferable digital currency network is selected (where more than one common digital currency networks are determined).

[0092] The digital currency payment network details for the nonreceiving party may comprise a non-receiving party accepted digital currency indication. The digital currency payment network details for the receiving party may comprise a receiving party accepted digital currency indication.

[0093] The non-receiving party and / or the receiving party may providean indication of which digital currencies that they accept. The accepted digital currencies may be provided in a separate field of the payment authorisation request and / or a database. The accepted digital currency information may be useful where the digital currency network(s) supported by the non-receiving party / receiving party facilitate transactions using multiple different digital currencies. For example, having compared the non-receiving party and receiving party digital currency network details, multiple common digital currency networks may be determined, supporting transactions using a plurality of different digital currencies. However, the receiving party may wish to receive funds in only US dollar denominated digital currencies, for example. Thus, the accepted digital 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 digital currencies denominated in more stable currencies.

[0094] The digital currency payment details for the non-receiving party may comprise a plurality of non-receiving party accepted digital currency indications and / or the digital currency payment details for the receiving party may comprise a plurality of receiving party accepted digital currency indications. The comparison of the non-receiving party and receiving party digital currency network details may comprise comparing each of the nonreceiving party payer accepted digital currency indications to each of the receiving party accepted digital currency indications and identifying a common digital currency between the non-receiving party and receiving party.

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

[0096] The digital currency payment details for the non-receiving party and / or the digital currency payment details for the receiving party may comprise a preferred digital currency indication. Identifying the common digital currency may be based at least partially upon the preferred digital currency indication.

[0097] Similar to the preferred digital currency network discussed above, the non-receiving party and / or receiving party may provide an indication of their preferred digital currency for the settlement (or digital currencies that they explicitly do not want to use). This preference indication may be a separate field in the database and / or the payment authorisation request. The preference indication may refer to one or more different digital currencies. The preference indication may include a ranking of a plurality of digital currencies in order of preference. The ranking may be provided in a separate field, or the accepted digital 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 non-receiving party digital currency network details with the receiving party digital currency network details may comprise accounting for the indicated preferences, so that a most preferred digital currency is selected (where more than one common digital currencies are determined).

[0098] The digital currency network details for the non-receiving party may be retrieved, from a database. The payment authorisation request received by the issuer may comprise the digital currency network details for the nonreceiving party where the non-receiving party is the payer.

[0099] The card payment network provider receives the digital currency 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 digital currency network settlement, the card payment network provider also requires digital currency network details for the non-receiving party.Where the non-receiving party is the card payment network provider, the non-receiving party digital currency network details may be retrieved from an internal database of the card payment network provider (e.g., a database of digital currency wallets over which the card payment network provider has custody). Where the non-receiving party is the payer, the nonreceiving party digital currency 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 digital currency network details. For example, the payer may have added digital currency wallet addresses to their banking profile, such that said wallets are linked to their payment card. This may reduce the amount of information that needs to be transferred.

[0100] In addition to knowing the digital currency network details for the payer, the issuer may also have the authority to instruct payments via the digital currency 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 digital wallet may be a digital wallet that the issuer has custody of (e.g., a digital wallet owned by the issuer and used by the payer). Alternatively, the payer may be the custodian of the digital 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 wallet’s private keys or access may be granted programmatically (e.g., via the use of a smart contract).

[0101] Alternatively, the issuer may instruct another party who does have sufficient authority over the payer digital wallet to initiate the digital currency payment.

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

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

[0104] The common digital currency network between the non-receiving party 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 network.

[0105] Although discussed herein as relating to ‘digital currency’ networks and transactions, the skilled person will recognise that any digital currency 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 digital currency network may comprise a digital currency or real-time payment rail. The common digital currency network may comprise a blockchain-based payment network.

[0106] 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 a card payment network provider, a payment authorisation request for a payment transaction between a payer and a payee initiated via a card payment network operated by the card payment network provider, the payment authorisation request comprising digital currency network details for a receiving party. The system is further configured to compare non-receiving party 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 non-receiving party and the receiving party, wherein the card payment network provider is authorised to utilise the non-receiving party digital currency network details to initiate a digital currency transaction. The system is further configured to, in the eventthat the common digital currency network can be determined, instruct, at the card payment network provider, the payment to be settled via the common digital currency network.

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

[0108] 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 a card payment network provider, a payment authorisation request for a payment transaction between a payer and a payee initiated via a card payment network operated by the card payment network provider, the payment authorisation request comprising digital currency network details for a receiving party. The system is further configured to compare non-receiving party 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 nonreceiving party and the receiving party, wherein the card payment network provider is authorised to utilise the non-receiving party digital currency network details to initiate a digital currency transaction. The system is further configured to, in the event that the common digital currency network can be determined, instruct, at the card payment network provider, the payment to be settled via the common digital currency network.

[0109] 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.

[0110] 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 a card payment network provider, a payment authorisation request for a payment transaction between a payer and a payee initiated via a card payment network operated by the card payment network provider, the payment authorisation request comprising digital currency network details for a receiving party. Themethod further comprises comparing non-receiving party 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 non-receiving party and the receiving party, wherein the card payment network provider is authorised to utilise the non-receiving party digital currency network details to initiate a digital currency transaction. The method further comprises, in the event that the common digital currency network can be determined, instructing, at the card payment network provider, the payment to be settled via the common digital currency network.

[0111] 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.

[0112] DESCRIPTION OF FIGURES

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

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

[0115] Figure 2 shows a schematic diagram of a system for processing a payment transaction according to an embodiment of the present invention;

[0116] Figure 3 shows a schematic diagram of a system for processing a payment transaction according an embodiment of the present invention;

[0117] Figure 4 shows a schematic diagram of a system for processing a payment transaction according an embodiment of the present invention;

[0118] Figures 5 to 9 shows a schematic diagram of a method for processing a payment transaction according to various embodiments;

[0119] Figure 10 shows a diagram illustrating information that may be received at, or sent from, a card payment network provider as part of a method for processing a payment transaction;

[0120] Figure 11 shows an example of a data processing device; and Figure 12 shows a flow diagram of a computer implemented method for processing a payment transaction.DETAILED DESCRIPTION

[0121] 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.

[0122] 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.

[0123] 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.

[0124] 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 correspondingdetails regarding the acquirer 110, which may be included in the authorisation request 112.

[0125] 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.

[0126] 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.

[0127] 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.

[0128] 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 becompleted.

[0129] 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 digital currency 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.

[0130] 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.

[0131] 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. The payment process illustrated in Figure 2 may be regarded as a first scheme wherein the payment network provider 214 is provided with authorisation or custody of a consumer wallet 222, as described further below.

[0132] 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 authorisationrequest 212 to a card payment network provider 214.

[0133] 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). Additionally, in the case that no receiving party digital current network details are provided, settlement may be conducted in the conventional way as described in Figure 1. I.e., the authorisation request may be forwarded from the card payment network provider 214 to the issuer 218 as normal for authorisation / settlement at the issuer.

[0134] However, the existing card payment systems that are used for authorisation and clearing stages may be modified to enable settlement according to the present invention. The payment authorisation request 212 comprises digital currency network details for the receiving party. The digital currency network details may comprise a digital currency wallet address for the receiving party (for example, an address for a digital wallet that may be used to store a central bank digital currency or a stablecoin). 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 212 received by the card payment network provider.

[0135] The receiving party is regarded as the entity / entities that receive funds from a non-receiving party via the settlement process. The receiving party may be the acquirer 210, the merchant 206, or a combination of both acquirer 210 and merchant 206, depending on the implementation.The digital currency network details provided within the payment authorisation request 208, 212 may be an alias of the digital currency network details of the receiving party. During the authorisation process, real digital currency network details corresponding to the alias digital currency network details be retrieved. For example, the payment authorisation request 212 provided by the acquirer 210 may contain alias digital currency network details. The card payment network provider 214 may retrieve actual digital currency network details from a database based on the alias digital currency network details. In either case, the digital currency network details for the receiving party (such as a digital wallet address) or the alias digital currency network details may be included in the payment authorisation request 212 by either the merchant or the acquirer.

[0136] 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 digital currency 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 for the receiving party and a field which may comprise one or more digital currencies accepted by the receiving party. Where the receiving party does not want to use digital currencies, the digital currency network details may comprise an indication that no wallet has been provided, or the field that corresponds to the one or more digital currency wallet addresses may be left empty or be omitted.

[0137] The receiving party digital currency network details are provided during the authorisation process, such that the payment authorisation request 212 received by the card payment network provider 214 comprises the digital currency network details for the receiving party. The acquirer 210 may modify the appropriate field of the payment authorisation request 212 to include a digital currency wallet address for the acquirer and / 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 digital currency wallet address for the merchant, said wallet address being included in the payment authorisation request 212.In the payment process scheme of the Figure 2, the non-receiving party is the consumer / payer 202 - i.e., settlement funds will ultimately be transferred from the consumer 202 to the receiving party. In such a scheme, the card payment network provider must have authority to conduct a settlement transaction using a consumer wallet 222. Following receipt of the payment authorisation request 212 at the card payment network provider 214, the card payment network provider sends a digital currency network authorisation request 216 to the issuer 218. The issuer 218 is an issuing bank that acts on behalf of the consumer 202 (e.g., being the bank that issued the consumer’s payment card). Therefore, the issuer 218 may be responsible for authorising the transaction and ensuring that the settlement process of the present invention can proceed. For example, the issuer 218 may perform a check 220 of the consumer wallet 222 to ensure that the consumer has sufficient digital currency to settle the transaction. The issuer 218 may subsequently receive an indication 224 that the consumer wallet 222 does have sufficient funds. Provided that the consumer wallet 222 does have sufficient funds, and the issuer 218 is otherwise satisfied that the payment can proceed, the issuer 218 sends a digital currency network response 226 to the card payment network provider 214. The digital currency network response 226 comprises an indication (e.g., an authorisation token or similar) that the card payment network provider 214 can proceed with the settlement process using the consumer wallet 222 as the non-receiving party to transfer settlement funds to the receiving party.

[0138] In order to carry out the settlement transaction via digital currency according to the present invention, the receiving party digital currency network details (contained in the payment authorisation request 212) are compared to digital currency network details for the non-receiving party (in this scheme, the consumer 202). The comparison may be performed at the card payment network provider 214 or the issuer 218, as discussed further below.

[0139] Upon receipt of the payment authorisation request 212, the card payment network provider 214 may store the receiving party digital currency network details contained therein, such that these details can subsequently be used by the card payment network provider 214 to perform the settlementtransaction.

[0140] The digital currency network authorisation request 216 may comprise a request for any / all digital currency network details for the consumer 202. The issuer 218 may retrieve the payer / consumer digital currency 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 digital currency wallets, which may be stored in a database of the consumer’s details. The issuer 218 may then provide the retrieved payer digital currency network details to the card payment network provider 214 via the digital currency network response 226, along with authorisation to use said payer digital currency network details.

[0141] Alternatively, or additionally, the payer digital currency network detail may be passed from the card payment network provider 214 to the issuer 218 via the digital current network authorisation request 216. The payer digital currency network details may be retrieved by the card payment network provider 214 from a database, similar to as described above. For example, the consumer 202 may have linked the consumer wallet 222 to their payment card or used the consumer wallet 222 in previous transactions, such that the card payment network provider 214 is able to retrieve the corresponding digital currency network details. Alternatively, or additionally, payer digital currency details may be provided to the card payment network provider 214 in the payment authorisation request 212. For example, one or more 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.

[0142] In either case, the payer digital currency network details are provided to the card payment network provider 214 without involvement of the issuer 218. The digital currency network authorisation request 216 there may contain said digital currency network details along with a request for the card payment network provider 214 to use said details. The issuer 218 may check220 the payer digital currency network details, similar to as discussed above, and provide the aforementioned authorisation via the digital currency network authorisation response 226.

[0143] Following the above, the card payment network provider 214 is in possession of the receiving party digital currency network details (provided in the payment authorisation request 212), the payer digital currency network details (provided in the payment authorisation request 212, retrieved by the card payment network provider 214, or retrieved by the issuer and provided in the digital currency network authorisation response 226), and authorisation to use said payer digital currency network details. The card payment network provider 214 can thus perform a comparison of the non-receiving party (i.e., the consumer / payer 202) and the receiving party (i.e., the merchant 206 or the acquirer 210) digital currency network details to determine a common digital currency network.

[0144] Alternatively, the comparison may be performed by the issuer 218. The receiving party digital currency network details may be passed from the card payment network provider 214 via the digital currency network authorisation request 216. The issuer 218 may obtain the non-receiving party / payer digital currency network details similar to as above. For example, the issuer 218 may retrieve the payer digital currency network details from the payer database. Or the card payment network provider 214 may retrieve the payer digital currency network details from a database or receive them via the payment authorisation request 212, with said payer digital currency network details also being passed from the card payment network provider 214 to the issuer 218 via the digital currency network authorisation request 216.

[0145] Following the comparison of the receiving party and non-receiving party digital currency network details, details of the determined common digital currency network are passed from the issuer 218 to the card payment network provider 214 via the digital currency network authorisation response 226, along with authorisation to use the payer digital currency network details of the determined common digital currency network.

[0146] The issuer 218 may perform additional validation checks of thepayer digital currency wallet addresses in order to ensure that the payer’s details are correct / expected and to ensure that the payer has sufficient funds. For example, where the issuer 218 receives a payer digital currency wallet address (via the digital currency network 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.

[0147] Whether performed at the card payment network provider 214 or the issuer 218, the comparison of the receiving party digital currency network details and the non-receiving party (the payer) digital currency network details may be substantially the same. 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.

[0148] 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, it may be determined 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 - i.e., the central bank digital currency network is determined to be a common digital currency network.

[0149] On the other hand, if the card payment network 214 / issuer 218 cannot determine a common digital currency network between the payer and receiving party, a digital currency network is not used for settlement.

[0150] Settlement may instead be performed in a conventional way, as per the method shown in Figure 1. This may occur where the digital currency network details are mutually exclusive (e.g., the payer and receiving party do not have wallet addresses for the same digital currency network) or where at least one of the payer / receiving party does not accept digital currency payments (e.g., the payment authorisation request 212 includes an indication that the merchant 206and acquirer 210 have not provided a digital currency wallet address).

[0151] However, assuming that a common digital currency network can be determined (using any of the processes) discussed above, the card payment network provider is in possession of receiving party and payer digital currency network details for the common digital currency network, along with authorisation to use the payer digital currency network details. The card payment network provider 214 may thus send settlement instructions 228 for settlement to be performed via the common digital currency network. The funds for the settlement are taken from the consumer / payer digital currency wallet 222 associated with the common digital currency network. The instructions 228 may comprise the payer digital currency network details and the receiving party digital network details, so that the settlement transaction can be initiated accordingly. Where the settlement transaction is handled by a third party (e.g., the provider of the common digital currency network), the instructions 228 may also comprise evidence that the card payment network provider has authorisation to utilise the consumer wallet 222.

[0152] Additionally, the card payment network provider may send a payment authorisation response 230a to the acquirer 210. The payment authorisation response 230a may comprise details of how the payment transaction is being settled (e.g., using the common digital currency network). Upon receiving the payment authorisation response 230a, the acquirer 210 may send a final authorisation confirmation 230b to the merchant 306, who may in turn provide confirmation that the sale is complete to the consumer 302 (e.g., via a payment terminal).

[0153] In the case that the receiving party digital currency network details comprise a digital currency wallet address for the merchant 206 (or at least said merchant digital currency wallet address is associated with the common digital currency network that has been determined), the settlement funds may be directly transferred 232a from the consumer digital currency wallet 222 to a merchant digital currency wallet 236a.

[0154] In the case that the receiving party digital currency network details comprise a digital currency wallet address for the acquirer 210 (or atleast said acquirer digital currency wallet address is associated with the common digital currency network that has been determined), the settlement funds may be transferred 232b from the consumer digital currency wallet 222 to an acquirer digital currency wallet 234. Following this initial settlement transfer 232b, the funds may be forwarded 238a to the merchant digital currency wallet 236a (where the merchant 206 accepts digital payments and has provided a digital wallet address to the acquirer 210). Alternatively, where digital currency transfers 238a are unavailable, the funds may be forwarded to a merchant bank account 236b using, for example, a conventional bank transfer 238b.

[0155] During the transfer of settlement funds from the consumer wallet 222, the settlement funds may be sent to multiple parties. Funds may be transferred 232a, 232b to both the acquirer wallet 234 and the merchant wallet 236a (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 card payment network provider 214) where said third-party is to receive a fee for their facilitation of the transaction.

[0156] Referring to Figure 3, a schematic diagram of a system for processing a payment transaction 300 according to the present invention is shown. The payment process illustrated in Figure 3 may be regarded as a second scheme wherein the payment network provider 314 utilises a card payment network provider wallet 342 for settling the transaction, as described further below. Unless discussed below, all entities and processes shown in Figure 3 are understood to be the same as those discussed in relation to Figure 2 - e.g., entities / steps 302 to 338b may correspond to the same entities / steps 202 to 238b of Figure 2.

[0157] In the payment process scheme of Figure 3, the non-receiving party is the card payment network provider 314 - i.e., settlement funds will be transferred from the card payment network provider 314 to the receiving party. The card payment network provider 314 may have ownership / custody of one or more card payment network provider digital currency wallets 342 from whichthe card payment network provider 314 is authorised to transfer funds.

[0158] Because in this scheme settlement funds are transferred from the card payment network provider wallet 342 (either to the merchant directly or via the acquirer, as discussed above), an intermediary digital currency transfer 340 may be used to transfer funds from the consumer wallet 332 to the card payment network provider wallet 342. This intermediary transfer 340 may be conducted prior to the settlement transfer 332a / 332b (so that the card payment network provider 314 has digital currency in the wallet 342 upfront) or this may be reconciled after settlement. In either instance, two comparisons (like the comparison discussed above) may be needed. A first comparison to determine a common digital currency network for transferring 332a / 332b the settlement funds from the non-receiving party (the card payment network provider 314 in this instance) to the receiving party (the merchant 306 or acquirer 310), and a second comparison to determine a second common digital currency network for transferring 340 funds from the consumer / payer 302 to the card payment network provider 314. The first and second common digital network details may be the same or different digital currency networks.

[0159] The first comparison may be performed at the card payment network provider 314 and may be substantially the same as the comparison of the receiving and non-receiving party digital currency network details discussed above for Figure 2. The card payment network provider 314 may receive receiving party digital currency network details via the payment authorisation request 312. These may be compared to card payment network provider digital currency details (e.g., details held by the card payment network provider 314 in a database of any / all digital currency wallets that the card payment network provider 314 owns). The comparison may therefore determine the common digital currency network that can be used for settlement, as discussed above.

[0160] In order to perform the intermediary digital currency transfer 340, the card payment network provider 314 may send an intermediary digital currency network authorisation request 316 to the issuer 318. The intermediary digital currency network authorisation request 316 may comprise card payment network provider details (e.g., details of one or more card payment networkprovider wallets). Similar to as described in Figure 2, the issuer 318 may retrieve payer digital currency network details from a payer database. The issuer 318 may then perform the second comparison between the received card payment network provider digital currency network details and the retrieved payer digital currency network details, in order to determine the second common digital currency network.

[0161] Alternatively, the second comparison may also be performed at the card payment network provider 314. As discussed in relation to Figure 2, the card payment network provider 314 may be able to retrieve the payer digital currency network details from a database (e.g., where the consumer / payer 302 has linked said details to their payment card) or these may be provided by the consumer 302 during the card purchase 304 and provided via the payment authorisation request 312. The card payment network provider 314 may then perform the second comparison between the card payment network provider digital currency network details and the payer digital currency network details and determine the second common digital currency network. Details of this (e.g., wallet addresses of the card payment network provider and the payer / consumer) may then be provided to the issuer via the intermediary digital currency network authorisation request 316.

[0162] In either case, the issuer 318 (having determined or been provided with the payer and card payment network payment provider digital currency network details for the common digital currency network) issues an instruction 320 to initiate the intermediary digital currency transfer 340 from the consumer / payer wallet 322 to the card payment network provider wallet 342. As before, the issuer 318 may before validation or checks of the consumer wallet 322 (e.g., to ensure that the consumer wallet 322 has sufficient funds or matches an expected consumer identity). Following the instruction 320, the issuer 318 may receive a response / indication that the intermediary transfer 340 has been successful or that the transfer 340 has been initiated. Accordingly, the issuer 318 may send an intermediary digital currency network response 326 comprising confirmation that funds have been or will be transferred from the payer / consumer wallet 322 to the card payment network provider wallet 342.This intermediary digital currency network response 326 may not comprise any authorisation, compared to the response 226 of Figure 2, because in this scheme the settlement from a wallet 342 owned by the card payment network provider 314 (i.e., the card payment network provider 314 does not need to be provided with authority to use the non-receiving party digital currency network details). The card payment network provider 314 may thus send settlement instructions 328 for settlement to be performed via the common digital currency network (determined as discussed above). The funds for the settlement are taken from the card payment network provider digital currency wallet 342 associated with the common digital currency network and transferred to the receiving party (the merchant or acquirer).

[0163] The payment process scheme of Figure 3, as discussed above, may be used where the payment process scheme of Figure 2 is not available or fails. For example, using the scheme of Figure 2, it may be determined that there is not a common digital currency network between the payer / consumer and the receiving party (the merchant or acquirer). In such situations, the scheme of Figure 3 may be utilised. The card payment digital currency wallet 342 may be used as an intermediary between the payer / consumer wallet 322 and the acquirer wallet 334 / merchant wallet 336a.

[0164] Although shown in Figure 3 as a single wallet, the card payment network provider 314 may own / have custody of a plurality of digital currency wallets 342 on a plurality of digital currency networks. Thus, funds may be transferred from the consumer wallet 322 to a first card payment network provider wallet (using a first digital currency network) and then transferred from a second card payment network provider wallet to the acquirer / merchant wallet 334 / 336a (using a second digital currency network). The card payment network provider 314 may undertake operations to balance the first and second wallet, e.g., converting digital currencies and transferring funds between their wallets as needed.

[0165] Although described as being the non-receiving party in this scheme, it will be understood that the card payment network provider 314 may still receive some funds. The card payment network provider 314 may retainsome of the funds of the intermediary digital currency transfer 340 as a fee for processing the settlement, for example.

[0166] Referring to Figure 4, a schematic diagram of a system for processing a payment transaction 400 according to the present invention is shown. The payment process illustrated in Figure 4 may be regarded as a third scheme wherein the payment network provider 414 utilises a card payment network provider wallet 442 for settling the transaction, as described further below. Unless discussed below, all entities and processes shown in Figure 4 are understood to be the same as those discussed in relation to Figures 2 and 3 -e.g., entities / steps 402 to 438b may correspond to the same entities / steps 202 to 238b of Figure 2 or entities / steps 302 to 338b of Figure 3.

[0167] As in Figure 3, in the payment process scheme of Figure 4 the non-receiving party is the card payment network provider 414 - i.e., settlement funds will be transferred from the card payment network provider 414 to the receiving party. However, unlike in Figure 3, funds are not transferred from a consumer / payer digital currency wallet. This scheme may be used where the consumer 402 does not have any digital currency network details or where the schemes of Figures 2 or 3 have been unable to identify any suitable common digital currency network for the consumer / payers digital currency network details.

[0168] Instead, the issuer 418 / consumer 402 only use conventional currency (e.g., currency stored in a bank account). As before, the card payment network provider 414 receives a payment authorisation request 412 and may store the receiving party digital currency network details contained therein. The card payment network provider 414 then sends a conventional currency authorisation request 416 to the issuer 418 - i.e., a request for the issuer to authorise clearing of the transaction utilising conventional currency funds. The issuer 418 may then check that the consumer 402 has sufficient funds for the clearing, e.g., by checking a consumer bank account that is associated with the card used for the payment transaction 404. Assuming that the consumer 402 has sufficient funds (and any other checks are validated, e.g., a consumer identity) the issuer 418 can send a conventional currency authorisation response 426 tothe card payment network provider 414, indicating that clearing is available. The card payment network provider 414 may then forward said indication to the acquirer 410 via a payment authorisation response 430a.

[0169] If the acquirer 410 wishes to proceed with the conventional currency authorisation-based scheme they can send a request 444a for funds to be transferred through clearing to the card payment network provider 414, who may in turn send an advisement 444b to the issuer 418. However, where a common digital currency is identified between the card payment network provider 414 (the non-receiving party) and the acquirer 410 (the receiving party), the acquirer 410 may not need to take any further action after sending the payment authorisation request 412. The card payment network provider 414 and the issuer 418 may communicate to enact the convention currency transfer (discussed further below), while the acquirer 410 (or the merchant 406) simply receives the digital currency settlement funds from the card payment network provider 414 in due course. For example, no request 444a may need to be sent from the acquirer 410; the payment network provider 414 may generate and send the advisement / presentment 444b in response to the conventional currency authorisation response 426. In effect, the receiving party (acquirer 410 or merchant 406) may simply send a payment authorisation request 412, similar to the other schemes shown in Figures 2 and 3.

[0170] With all necessary parties satisfied that the payment processing can proceed using this scheme, the issuer 418 provides an instruction 446 for funds to be transferred from the consumer 402 to the card payment network provider 414. This transfer of conventional currency may be facilitated by a third party, such as a settlement agent 450 that collates transactions. Although shown as going to the card payment network provider wallet 442, the conventional funds will be transferred 452 to a conventional currency storage of the card payment network provider 414 (e.g., the transfer 452 may be from a consumer or issuer bank account to a card payment network provider bank account). The transfer of convention funds 452 may take some time, meaning that in this example the final settlement may not be in real-time. Similar to in relation to Figure 3, the card payment network provider may then takeadditional operations to ensure digital currency funds are available for settlement, e.g., the received conventional currency may be converted to digital currency and deposited into the card payment network provider digital currency wallet 442. As described in Figure 3, the card payment network provider 414 may thus send settlement instructions 428 for settlement to be performed via the common digital currency network (determined as discussed above). The funds for the settlement are taken from the card payment network provider digital currency wallet 442 associated with the common digital currency network and transferred to the receiving party (the merchant or acquirer).

[0171] Again, although the card payment network provider 314 acts as the non-receiving party in this scheme (funds are transferred to the receiving party from the card payment network provider digital currency walled 442), the card payment network provider 414 may still receive / retain some funds. The card payment network provider 414 may retain some of the transferred 452 funds as a fee for converting conventional to digital currency, for example.

[0172] Referring to Figures 5 to 9, 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 5 to 9 provides further details that may be implemented into the method described above in relation to Figures 2 to 4.

[0173] Figure 5 shows the method steps for authorisation and clearing stages 500 of the payment process. A purchase 504 is initiated between a consumer 502 and a merchant 506 and a preliminary authentication request 508 is sent from the merchant 506 to the acquirer 510. In the example of Figure 5, the acquirer 510 adds 511 receiving party digital currency network details to the request (e.g., a field of the request may be updated to include a merchant digital currency wallet address and / or an acquirer digital currency wallet address). The merchant 506 may have also or alternatively added receiving party digital currency network details to the request (not shown). The acquirer 510 then sends a payment authorisation request 512 comprising receiving party digital currency network details to a card payment network provider 514. The card payment network provider may forward 514 an authorisation request to anissuer 518. The authorisation request sent from the card payment network provider 514 to the issuer 518 may be a digital currency network authorisation request, an intermediary digital currency network authorisation request or a conventional currency authorisation request, depending upon which scheme of the present invention is used (as discussed above in relation to Figures 2 to 4 respectively).

[0174] In the example of Figure 5, the payment authorisation request 514 comprises receiving party digital currency network details (as in the first scheme / Figure 2 above). Upon receiving the payment authorisation request 514 comprising receiving party digital currency network details, the issuer 518 may authorise 519a the transaction for the purchase 504. The authorisation 519a may comprise checking the identity of the consumer 502 and / or merchant 506, that the relevant card has not been flagged as stolen / lost, or ensuring that the consumer 502 has sufficient funds, for example. The issuer 518 may compare 519b the digital currency network details of the receiving party (those provided in the payment authorisation request 514) to those of the payer (which may be retrieved from a database based on what digital currency details of the consumer 502 are linked to the card used for the purchase 504). The comparison 519b is used determine a common digital currency network between the payer and receiving party that may be used to settle the transaction, rather than using conventional settlement methods. Alternatively, this comparison, as discussed above, may be performed at the card payment network provider 514. The payment authorisation request 514 may comprise details of the consumer 502 (e.g., details related to the payment card used by the consumer 502 to initiate the purchase 504). The issuer 518 may use said consumer / payer details to identify payer digital currency network details (e.g., by using the consumer / payer details to identify corresponding digital currency network details in a payer database) and provide these to the card payment network provider 514. Alternatively, the card payment network provider may also receive consumer / payer digital currency network details via the authorisation request 512 (where the consumer 502 provides these during the purchase transactions 504) or by similarly searching a database. In either case, the cardpayment network provider similar has both the receiving party and nonreceiving party (in this case the payer) digital currency network details so can perform the comparison. As discussed above, other schemes may instead utilise the card payment network provider 514 as the non-receiving party, in which case card payment network provider digital currency network details may be shared and compared accordingly.

[0175] In this example, once the transaction has been authorised by the issuer 518, a payment authorisation response 526 is sent from the issuer 518 to the card payment network provider 514. The card payment network provider 514 may utilise the response 526 to initiate instructions to settle the transactions according to the relevant schemes described herein and described further below. The card payment network provider 514 may also forward 530a the payment authorisation response 530a to the acquirer 510. Upon receiving the payment authorisation response 530a, the acquirer 510 may send a final authorisation confirmation 530b to the merchant 506, who may in turn provide confirmation that the sale is complete 531 to the consumer 502.

[0176] A clearing request (not shown in Figure 5) may also be sent to the card payment network provider 514 from the acquirer 510. The clearing request may comprise a request for the settlement of the payment where the transaction cannot be successfully filed via a common digital currency network, for example. In such a situation, the acquirer 510 may request settlement via conventional payment rails, thereby providing a fallback to the digital currencybased processes described herein. A clearing request that does not request settlement may otherwise be sent for information purposes only, e.g., providing details to the acquirer 510 of how the transaction has been settled.

[0177] The clearing request may be provided separately and subsequently to the illustrated payment authorisation request 512, in a dual message scheme. Following the authorisation being completed (e.g., at some time following the authorisation response 530a being received), the acquirer 510 may send a clearing request to the card payment network provider 514. The sending of the additional clearing request may have similar structure to what is shown in Figure 5. The card payment network provider 514 may then process the requestand commence with instructing the settlement, as described further below. A clearing response (not shown) may then be sent from the card payment network provider 514 to the acquirer 510 similarly to the payment authorisation response 530a, thereby providing confirmation that the clearing request has been received and acted upon. In essence, a ‘delta-shaped flow’ like that shown in Figure 5 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 510 to the card payment network provider 514. The settlement may be initiated by the card payment network provider 514 based upon the authorisation and the determination of a common digital currency network, i.e., prior or regardless of the clearing message.

[0178] 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 512 shown in Figure 5 may comprise additional clearing information compared to the dual message scheme. As such, the card payment network provider 514 may be able to instruct settlement of transaction upon receipt of said single message. The payment authorisation response 530a provided by the card payment network provider 514 may likewise comprise a clearing response.

[0179] Figures 6 to 9 show alternative method steps for the settlement stage 600, 700, 800, 900 of the payment process. The settlement stage is conducted subsequent to (or partially in conjunction with) the steps of the authorisation and clearing stages 500. The settlement stage 600, 700, 800, 900 can begin following the comparison of the non-receiving party and receiving party digital currency network details (whether said comparison is performed at the card payment network provider or issuer) and the determination of a common digital currency network that can be used for transferring settlement funds between said non-receiving and receiving party. In any case, if none of the digital currency -based settlement schemes can be used or are used successfully, conventional settlement (as discussed in relation to Figure 1) may be used instead.

[0180] Figure 6 shows a settlement process 600 in accordance with thefirst scheme, as described above in relation to Figure 2, wherein settlement is conducted using a consumer wallet 622. In the example of Figure 6, the card payment network provider 614 sends a request 622 to a primary account number (PAN) database 660 which stores details of the consumer / payers financial information. For example, the PAN database 660 may store the consumer’s card details as well as any digital currency wallets that the consumer possesses. Accordingly, based upon consumer details provided in the payment authorisation request (e.g., the card number used for the purchase transaction), consumer / payer digital currency network details may be retrieved. As well as requesting the details themselves, the card payment network provider 614 may also request authorisation (e.g.., from the issuer) to utilise said details, so that the card payment network provider can instruct the settlement transaction from the consumer wallet 622. Alternatively to what is shown in Figure 6, the payer / consumer digital currency network details may instead be provided via the issuer - e.g., following receiving a payment authorisation request comprising consumer detail, the issuer may instead request consumer / payer digital currency network details from a PAN or payer database.

[0181] In either case, the consumer / payer digital currency wallet details, along with the appropriate authorisation, are returned 664 to the card payment network provider 614. Once said payer digital currency network details are compared to receiving party digital currency network details to determine a common digital currency network (as discussed above), the card payment network provider 614 sends an instruction 628 for settlement the settlement to be performed using the digital currency network details of the payer / consumer on the common digital currency network. I.e., an instruction 628 is provided to debit the consumer wallet 622 (which in this scheme functions as the nonreceiving party wallet), thus causing the settlement funds to be transferred 632 to the receiving party wallet 635 (either the merchant directly or the acquirer, depending upon what receiving party digital currency network details are provided in the authorisation process).

[0182] Figure 7 shows a settlement process 700 in accordance with the second scheme, as described above in relation to Figure 3, wherein the finalsettlement is conducted using a card payment network provider wallet 742. As discussed above in relation to Figure 3, the settlement may be regarded as a two-step process. The issuer 718 provides an instruction 720 to initiate an intermediary digital currency transfer 740 - i.e., digital currency funds are transferred from a consumer digital currency wallet 722 to the card payment network provider wallet 742. The card payment network provider provides a separate instruction (not shown) to transfer the settlement funds from the card payment network provider wallet 742 (which in this scheme functions as the non-receiving party wallet) to the receiving party wallet 735.

[0183] Unlike as shown in Figure 7, the intermediary transfer 740 may be performed subsequent to the final settlement transfer 732. I.e., the transfer may be settled with the receiving party before card payment network provider has received the necessary funds. Additionally, or alternatively, the card payment network provider 742 may not be a single wallet. A first digital currency may be sent via a first digital currency network from the consumer wallet 722 to a first card payment network provider wallet, while a second digital currency may be sent via a second digital currency network from a second card payment network provider wallet to the receiving party wallet 735.

[0184] Figures 8 and 9 both show a settlement process 800, 900 in accordance with the third scheme, as described above in relation to Figure 4, wherein the final settlement is conducted using a card payment network provider wallet 842, 942 but funds are transferred to the card payment network provider 814, 914 using conventional currency transactions.

[0185] In the example of Figure 8, a dual message process 800 is used. In this process, a clearing presentment request 870 may be sent from the acquirer 810 to the card payment network provider 814 if settlement has not already been completed using the common digital currency network as discussed above. This in turn generates a further clearing presentment 872 that is sent from the card payment network provider 814 to the issuer 818, requesting settlement from the issuer 818 to the card payment network provider 814. In other words, the instruction to initiate the clearing is one-way, with the acquirer not receiving confirmation of this. Alternatively, in the example of Figure 9, asingle message process 900 is used. In this process, the card payment network provider 914 sends reconciliation files 974, 976 to both the acquirer 910 and the issuer 918, thus providing acknowledgment of the clearing.

[0186] In both examples, following receipt of instructions to continue with clearing, the issuer 818, 918 issues an instruction (not shown) to perform bank transfer 846, 946 of conventional currency funds to the card payment network provider 814, 914. The transfer may be made via an intermediary party, such as a settlement agent 850, 950 acting on behalf of the card payment network provider, in which case the funds are then forwarded 852, 952 to the card payment network provider. Although shown in Figures 8 and 9 as being a transfer to the card payment network provider wallet 842, 942, the conventional currency funds may be transferred to a bank account of the card payment network provider 814, 914 and then converted to digital currency in said wallet 842, 942. The card payment network provider then provides a separate instruction (not shown) to transfer the settlement funds from the card payment network provider wallet 842, 942 (which in this scheme functions as the nonreceiving party wallet) to the receiving party wallet 835, 935. Similar to above, the bank transfer 852, 952 may be performed after the settlement transfer 832, 932. This may allow for near-real-time settlement to be performed using the common digital currency network, while the conventional currency bank transfer may be completed at a later time.

[0187] Referring to Figure 10, a schematic diagram of processes 1000 undertaken at a card payment network provider 1002 during a computer implemented method for processing a payment transaction are shown.

[0188] The card payment network provider 1002 receives a payment authorisation request 1010. The payment authorisation request 1010 is received from an acquirer 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 1010 comprises all of the necessary transaction data 1012 that would be needed to process the transaction using an established card payment network. For example, thetransaction data 1012 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 1010 may be used to process the transaction using conventional authorisation, clearing and settlement methods.

[0189] However, the payment authorisation request 1010 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 card payment network provider, a third party or the issuer, for example. The digital currency network details may be added to the payment authorisation request 1010 by the merchant and / or by the acquirer during authorisation of the transaction. In the example of Figure 10, two digital currency fields have been added. Sub-field 1 1014 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 1016 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).

[0190] When the method is performed using a single message scheme (like that described in relation to Figure 9), the payment authorisation request 1010 may comprise an additional clearing request. The authorisation request 1010 may be identified as a combined authorisation and clearing message via a message type or indication. I.e., the authorisation request 1010 may be identified as a Financial Transaction Request rather than just an Authorisation Request, and the card payment network provider 1002 may identify as suchaccordingly. 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 eliminates the need for a separate clearing request to be sent following authorisation.

[0191] After receiving the payment authorisation request 1010, the card payment network provider 1002 may receive corresponding payer information from a payer database 1020. The card payment network provider 1002 may be able to request this information directly; e.g., the payer information may be shared with the card payment network provider due to the card used in the payment being linked to said payer information. Alternatively, an issuer may request and receive the payer information and pass this to the card payment network provider, as discussed above. In either case, the card payment network provider 1002 is provided with the necessary information. The payer database 1020 may comprise banking information 1022 for the payer / consumer. 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.

[0192] The payer information contains digital currency network details for a payer. In the example of Figure 10, the payer details contain a list 1024 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 1026 controlled by the payer (central bank digital currency networks A and B, and a permissioned distributed ledger network).

[0193] Having received the digital currency network details for the payer and the receiving party, the card payment network provider 1002 compares said details to determine if there is a common digital currency network between the payer and receiving party. Alternatively, the comparison may be performed at the issuer, with only the digital currency network details for the determined common digital currency network being provided to the card payment networkprovider 1002. If there is a common digital currency network, then the card payment network provider 1002 may instruct that the payment transaction be settled using said common digital currency network (via the wallet addresses 1016, 1026 provided by each party). The card payment network provider 1002 is provided with the necessary authority to utilise the payer digital currency network details to initiate the settlement transfer. If there is no common digital currency network, the card payment network provider 1002 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.

[0194] The above process, utilising the payer database 1020, may be used in the first scheme described above in relation to Figures 2 and 6, i.e., wherein the payer / consumer is the non-receiving party. However, a similar process may be used for the second and third scheme, discussed above in relation to Figures 3, 4, and 7 to 9. In said schemes, the card payment network provider 1002 is the non-receiving party. Accordingly, rather than searching a payer database, the card payment network provider 1002 may search a card payment network provider data which similarly comprises a list of digital currencies / networks that card payment network provider is able to use and corresponding digital currency wallet addresses. Thus, similar to above, the card payment network provider is able to compare the receiving party digital currency network details to the card payment network provider digital currency network details to determine a common digital currency network.

[0195] The card payment network provider 1002 may generate and send a payment authorisation response 1030 to the acquirer. The payment authorisation response 1030 may contain details 1032 indicating that the transaction has been authorised and how it has been settled. In particular, the payment authorisation response may contain an additional field 1034 that indicates the digital currency network that has been used for settlement (or that no common digital currencynetwork could be found). In this example, one common digital currency network was found - CBDCEUR - and so the payment authorisation response 1030 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 1030 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 1030, 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 card payment network provider 1002 comprising an indication of whether the payment has been settled or not.

[0196] In the event that the common digital currency network can be determined, the card payment network provider 1002 instructs the that the settlement be performed using said common digital currency network. The card payment network provider 1002 may send settlement instructions 1040 for initiating the settlement (which may comprise the card payment network provider 1002 initiating a payment from a payer’s digital wallet directly or from a card payment network provider wallet acting as an intermediary, as per the schemes of the present invention). The settlement instructions 1040 comprise details 1042 for the common digital currency network that are required for performing the digital currency transfer (e.g., a non-receiving party and receiving party digital currency wallet address and a payment amount). The settlement instructions 1040 may comprise additional settlement data / instructions 1044. For example, the additional data / instructions 1044 may comprise further settlement instructions for use in the case that the first instructed digital currency settlement does not work - these additional instructions 1044 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 non-receiving party and receiving party based upon the comparison of digital currency network details, or transferring funds from / to a differentpayer / payer digital currency wallet address) or instructions for settlement using a conventional settlement method. The settlement instructions 1040 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.

[0197] Alternatively, or additionally, the settlement may be at least partially instructed by an entity other than the card payment network provider 1002. In such cases, the third party 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.

[0198] 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.

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

[0200] One or more such data processing devices 1100 may be provided for implementing the method of the present invention. For example, each of amerchant 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 1100. Distinct data processing devices 1100 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.

[0201] Data processing device 1100 includes a processor 1103 for executing instructions. Instructions may be stored in a memory 1101. Processor 1103 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 1100, such as UNIX, LINUX, Microsoft Windows®, etc. More specifically, the instructions may cause various data manipulations on data stored in memory 1101 (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.).

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

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

[0204] The storage database may, for example, store details of the payment transaction (e.g., the payment amount, the details of the card used inthe 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 1100 and located remotely. Alternatively, it can be integrated in data processing device 1100. For example, data processing device 1100 may include memory 1101 as one or more hard disk drives acting as a storage database. Alternatively, where the storage database is external to data processing device 1100, 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.

[0205] Processor 1103 can be operatively coupled to the storage device (storage database) via a storage interface 1107. Storage interface 1107 is any component capable of providing processor 1103 with access to the storage device. Storage interface 1107 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 1103 with access to the storage device.

[0206] Memory 1101 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.

[0207] 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 methodsdescribed 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.

[0208] 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.

[0209] 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.

[0210] Referring to Figure 12, a flow diagram 1200 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 9.

[0211] At step 1202, the method involves receiving, at a card payment network provider, a payment authorisation request for a payment transactionbetween a payer and a payee initiated via a card payment network operated by the card payment network provider, the payment authorisation request comprising digital currency network details for a receiving party.

[0212] At step 904, the method involves comparing non-receiving party 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 non-receiving party and the receiving party, wherein the card payment network provider is authorised to utilise the non-receiving party digital currency network details to initiate a digital currency transaction.

[0213] At step 906, the method involves, in the event that the common digital currency network can be determined, instructing, at the card payment network provider, the payment to be settled via the common digital currency network.

[0214] 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 a card payment network provider, a payment authorisation request for a payment transaction between a payer and a payee initiated via a card payment network operated by the card payment network provider, the payment authorisation request comprising digital currency network details for a receiving party;comparing non-receiving party 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 non-receiving party and the receiving party, wherein the card payment network provider is authorised to utilise the non-receiving party digital currency network details to initiate a digital currency transaction; andin the event that the common digital currency network can be determined, instructing, at the card payment network provider, the payment to be settled via the common digital currency network.

2. The computer implemented method of claim 1, wherein: the non-receiving party is the payer and the non-receiving digital currency network details are digital currency network details for the payer; and the card payment network provider is granted authority to utilise the payer digital currency network details.

3. The computer implemented method of claim 2, further comprising:sending, from the card payment network provider to an issuer, a digital currency network authorisation request comprising the receiving party digital currency network details; andreceiving, at the card payment network provider from the issuer, a digital currency network response comprising payer digital currency networkdetails for the common digital currency network and an indication that the card payment network provider is authorised to utilise said payer digital currency network details for the common digital currency network.

4. The computer-implemented method of claim 3, wherein: the comparison of the non-receiving party digital currency network details with the receiving party digital currency network details is performed at the issuer; andsaid comparison is between payer digital currency network details stored at the issuer and the receiving party digital currency network details sent from the card payment network provider.

5. The computer implemented method of claim 2, wherein: the payer digital currency network details are stored at the card payment network provider; andthe comparison of the payer digital currency network details with the receiving party digital currency network details is performed at the card payment network provider; andsaid comparison is between the payer digital currency network details stored at the card payment network provider and the receiving party digital currency network details received at the card payment network provider.

6. The computer implemented method of claim 5, further comprising:subsequent to determining the common digital currency network between the payer and the receiving party, sending, from the card payment network provider to an issuer, a digital currency network authorisation request comprising payer digital currency network details for the common digital currency network; andreceiving, at the card payment network provider from the issuer, a digital currency network response comprising an indication that the card payment network provider is authorised to utilise said payer digital currencynetwork details for the common digital currency network.

7. The computer implemented method of claim 3 or claim 4, further comprising receiving, at the issuer and prior to the comparison, the payer digital currency network details from a database, wherein the payer digital currency network details are retrieved from the database based upon payer identity details contained within the digital currency network authorisation request; orthe computer implemented method of claim 5 or claim 6, further comprising receiving, at the card payment network provider and prior to the comparison, the payer digital currency network details from a database, wherein the payer digital currency network details are retrieved from the database based upon payer identity details contained within the payment authorisation request.

8. The computer implemented method of claim 1, wherein: the non-receiving party is the card payment network provider and the non-receiving digital currency network details are digital currency network details for the card payment network provider; andthe card payment network provider is capable of utilising the card payment network provider digital currency network details.

9. The computer implemented method of claim 8, further comprising:sending, from the card payment network provider to an issuer, an intermediary digital currency network authorisation request comprising the card payment network provider digital currency network details; andreceiving, at the card payment network provider from the issuer, an intermediary digital currency network response comprising confirmation that funds have been or will be transferred from the payer to the card payment network provider based upon the card payment network provider digital currency network details.

10. The computer implemented method of claim 9, further comprising:comparing, at the issuer, the card payment network provider digital currency network details with payer digital currency network details, in order to determine if there is a second common digital currency network between the card payment network provider and the payer;in the event that the second common digital currency network can be determined, instructing, at the issuer, funds to be transferred from the payer to the card payment network provider via the second common digital currency network.

11. The computer implemented method of claim 8, further comprising:sending, from the card payment network provider to an issuer, a conventional currency authorisation request, the conventional currency authorisation request comprising a request for the issuer to transfer funds from a bank account associated with the issuer to a bank account associated with the card payment network provider; andreceiving, at the card payment network provider from the issuer, a conventional currency authorisation response comprising confirmation that funds have been or will be transferred from the bank account associated with the issuer to the bank account associated with the card payment network provider.

12. The computer method of claim 11, further comprising: subsequent to receiving the conventional currency authorisation response, converting conventional currency in the bank account associated with the card payment network provider to a digital currency for use with the common digital currency network.

13. The computer implemented method of any of claims 8 to 12, wherein:the comparison of the card payment network provider digital currency network details with the receiving party digital currency network details is performed at the card payment network provider; andsaid comparison is between card payment network provider digital currency network details stored at the card payment network provider and the receiving party digital currency network details received at the card payment network provider.

14. The computer implemented method of any preceding claim, further comprising, in the event that the common digital currency network between the non-receiving party and the receiving party cannot be determined, instructing the payment to be settled via a conventional settlement method.

15. 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 payment to be settled via the common digital currency network, receiving, at the card payment network provider, a clearing request; orthe payment authorisation request comprises a clearing request.

16. The computer implemented method of any preceding claim, further comprising, prior to receiving at the card payment network provider 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 digital currency network details for the receiving party, thereby generating the payment authorisation request; andsending, from the acquirer to the card payment network provider,the payment authorisation request.

17. The computer implemented method of claim 16, wherein: the receiving party is the acquirer and the digital currency network details for the receiving party comprise digital currency network details for at least the acquirer; and / orthe receiving party is the payee and the digital currency network details for the receiving party comprise digital currency network details for at least the payee.

18. The computer implemented method of claim 17, 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.

19. The computer implemented method of any of claims 16 to 18, wherein:the preliminary authorisation request comprises digital currency network details for the payee; andthe digital currency network details for the receiving party included in the payment authorisation request comprise the digital currency network details for the payee.

20. The computer implemented method of any preceding claim, wherein:the digital currency payment network details for the non-receiving party comprise a non-receiving party digital currency wallet address or an indication of the lack thereof; andthe digital currency payment network details for the receiving party comprise a receiving party digital currency wallet address or an indication of the lack thereof.

21. The computer implemented method of claim 20, wherein: the digital currency payment details for the non-receiving party comprise a plurality of non-receiving party digital currency wallet addresses and / or the digital currency payment details for the receiving party comprise a plurality of receiving party digital currency wallet addresses; andthe comparison of the non-receiving party and receiving party digital currency network details comprises comparing each of the non-receiving party digital wallet addresses to each of the receiving party digital wallet addresses.

22. The computer implemented method of any preceding claim, wherein:the digital currency payment network details for the non-receiving party comprise a non-receiving party accepted digital currency indication; and the digital currency payment network details for the receiving party comprise a receiving party accepted digital currency indication.

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