SE2150228A1

SE2150228A1 - Payment service provider interoperability for offline digital payments

Info

Publication number: SE2150228A1
Application number: SE2150228A
Authority: SE
Inventors: Joachim Samuelsson; Paul Cronholm
Original assignee: Crunchfish Digital Cash Ab
Priority date: 2021-02-12
Filing date: 2021-03-01
Publication date: 2022-03-08
Also published as: SE544227C2

Abstract

Payment service provider interoperability for offline digital payments is obtained by a computerized method (100) of performing a digital payment of a payment amount (Amount) between a payer (P1) and a payee (P2). The payer (P1) uses a payer communication device (PD1) and is associated with a computerized first payment service provider (PSP1) that handles a payer account (account_P1) of the payer (P1). The payee (P2) uses a payee communication device (PD2) and is associated with a computerized second payment service provider (PSP2) that handles a payee account (account_P2) of the payee (P2) The method has an offline settlement stage (110) during which the payer communication device (PD1) and payee communication device (PD2) communicates (1 12) by short-range data communication to generate payment transaction data (Transaction Data) being digitally signed (1 14) by the payer communication device (PD1). The generated payment transaction data (Transaction Data) is validated (1 16) by the payee communication device (PD2). The method further has an online settlement stage (130) during which the payment transaction data (Transaction Data) is communicated (132) to a computerized payment network switch (NW). The computerized payment network switch (NW) validates (136) the payment transaction data (Transaction Data), and communicates (142) at least with the first payment service provider (PSP1) to cause a deduction of funds from the payer account (account_P1) of the payer (P1) and an addition of funds to the payee account (account_P2) of the payee (P2), the deduction and addition corresponding to the payment amount (Amount).

Description

PAYMENT SERVICE PROVIDER INTEROPERABILITYFOR OFFLINE DIGITAL PAYMENTS TECHNICAL FIELD The present invention generally relates to the field of digital payments. Moreparticularly, the present invention relates to technical improvements for digitalpayments between payers and payees that are physically proXimate to each other, e.g.that appear or meet at a physical place such as, for instance, a shop, restaurant, theatre,sport arena, Workshop, or basically any place where humans can meet to perform adigital payment. Even more particularly, the present invention relates to a digitalpayment system that enables payment service provider interoperability for ofﬂine digitalpayments between such proximate users, and to an associated computerized method.Moreover, the invention relates to associated communication devices, cloud-based computing resources, computer program products and computer readable media.

BACKGROUND As everybody knows, there has been an overwhelrr1ing market penetration formobile communication devices such as smart phones and tablets at least during the lastdecade. Long gone are the days when mobile communication devices were primarilyused for voice calls. Typically, mobile communication devices are enabled for wide-area network, WAN, communication (broadband RF communication) with remoteentities, for instance via cellular radio systems like 5G, UMTS or GSM, or via wirelesslocal area network, WLAN, access for routing IP traffic to and from such remoteentities. In addition, mobile communication devices are often enabled for short-rangewireless data communication, such as Bluetooth, with other devices nearby. Such anearby device may for instance be an accessory or peripheral device, like a wirelessheadset or wireless speakers.

Thanks to their ability for WAN communication, users of mobile communi-cation devices may enjoy a plethora of digital services that involve communication withcloud-based resources. A very popular type of such digital services is digital payments.A special kind of digital payments is the digital proXimity payment that allows a user ofa mobile communication device to make a digital payment when being physicallyproximate to another entity at a physical place such as, for instance, a shop, restaurant,theatre, sport arena, workshop, or basically any place where a human may want toperform a digital payment. The other entity may be another communication device which is controlled by a human user (such as a smart phone, tablet, point-of-sales terminal, payment terminal, checkout counter, etc.), or another communication devicethat operates more autonomously (such as a service terminal, vending machine, ticketmachine, access control system, etc.).

At the same time, it is recalled that enormous volumes of digital payments aremade by using smart cards (or smart chips) at the payer side.

Throughout this document, the term “digital payment” is to be construedbroadly to embrace any kind of transfer of economic value in digital form on behalf ofor between people of any types, roles etc. ln the digital payment systems of today, interoperability between paymentservices is hard to achieve due to payments being settled in a single online step.

The present applicant is a technical pioneer within digital payments withDigital Cash that settles payments in two steps, first ofﬂine and then online. Thisenables payments that always work and can also be made with preserved integrity.Digital Cash is extremely flexible and complements all types of payment schemes, bothon cards and mobiles. Reference is for instance made to applicant°s international patentapplication PCT/SE2020/051251, the contents of which are incorporated herein by reference.

SUMMARY The present document discloses technical improvements which make digitalpayment services interoperable, on a national level or even on an intemational level,through the issuing of a digital certificate structure that may reach global scope.Payment in other countries also becomes possible through handling of exchange ratesofﬂine. These improvements may be extremely valuable from an internationalperspective, as payment schemes - cards, real-time payments, closed-loop wallets,CBDC (Central Bank Digital Currency, i.e. a digital currency (a.k.a. e-currency) issuedby a central bank) and crypto currency - can be used over international borders. Anational interoperability between different payment schemes is also important, forinstance to accelerate the implementation of CBDC. The improvements allow, amongmany other things, a payer to perform a digital payment to a payee even when the payercommunication device is operated in a foreign area (for instance abroad), where thepayer communication device has no wide area network access (including cellularnetwork access), for instance because the payer does not hold any valid subscription for such services in the foreign area, or because of technical incompliance.

Applicant°s two-tier settlement of payments, first offline and then online, iswhat enables smooth interoperability of the world's payment services, both cross-borderand cross-schemes. The payee verifies that the transaction is legitimate by being able tocheck the payer's Certificate and thereby trust that the payment can be settled online at alater stage. Root certification may be established for Digital Cash services on a globalbasis that verifies ofﬂine payments when the payer and the payee use different paymentservices or different types of payment rails. An exchange table in the payer°s paymentapp means that the offline balance can also be debited for ofﬂine payments in a foreigncurrency. Any currency differences may be adjusted at the point of online settlement bydebiting or crediting the payer's account In line with the observations above, the present inventors have made valuabletechnical insights. These insights will be presented as inventive aspects below as well asin the attached independent claims. The list of inventive aspects is not to be seen aseXhaustive but rather a summary of particularly beneficial inventive aspects. Theinventive aspects will be eXemplified by reference to disclosed embodiments which areshown in the enclosed drawings. The inventive aspects are not as such limited to thedisclosed embodiments, as the skilled reader will understand.

A first inventive aspect is a digital payment system enabling payment serviceprovider interoperability for offline digital payments between proXimate users. Thesystem comprises a computerized payment network switch, a computerized firstpayment service provider that handles a payer account of a payer and has a firstpayment service provider digital certificate being verifiable with the payment networkswitch digital certificate, and a computerized second payment service provider thathandles a payee account of a payee. The system further comprises a payercommunication device for use by the payer and having a payer communication devicedigital certificate being verifiable with the first payment service provider digitalcertificate, and a payee communication device for use by a payee. The functionality ofthe system and the entities comprised therein is defined in the attached independentsystem claim, with further refinements thereof in possible (but non-lin1iting)embodiments being defined in the dependent claims.

A second inventive aspect is a computerized method of performing a digitalpayment of a payment amount between a payer and a payee according to the attachedindependent method claim. The computerized method may further comprise any or allof the functionality performed by the payment network switch, the first payment service provider, the second payment service provider, the payer communication device and the payee communication device in the digital payment system according to the firstinventive aspect.

A third inventive aspect is a cloud-based computing resource configured toperform the functionality of the payment network switch in the digital payment systemaccording to the first inventive aspect.

A fourth inventive aspect is a cloud-based computing resource configured toperform the functionality of the first payment service provider in the digital paymentsystem according to the first inventive aspect.

A fifth inventive aspect is a cloud-based computing resource configured toperform the functionality of the second payment service provider in the digital paymentsystem according to the first inventive aspect.

A siXth inventive aspect is a communication device configured to perform thefunctionality of the payer communication device in the digital payment systemaccording to the first inventive aspect. The communication device may, for instance, bea mobile communication device, a mobile phone, a smart phone, a tablet computer, apersonal digital assistant, a portable computer, smart glasses, a smart wearable, a smartwatch, a smart bracelet, a smart card or a smart chip.

A seventh inventive aspect is a communication device configured to performthe functionality of the payee communication device in the digital payment systemaccording to the first inventive aspect. The communication device may, for instance, bea mobile communication device, a mobile phone, a smart phone, a tablet computer, apersonal digital assistant, a portable computer, smart glasses, a smart watch, a smartcard, a smart bracelet, a smart wearable, a payment terminal, a service terminal, a point-of-sales terminal, a checkout counter, a delivery pickup point, a vending machine, aticket machine, a dispensing machine, or an access control system.

An eighth inventive aspect is a computer program product comprisingcomputer code for performing the functionality of the payment network switch in themethod according to the second inventive aspect when the computer program code iseXecuted by a processing device.

A ninth inventive aspect is a computer program product comprising computercode for performing the functionality of the first payment service provider in themethod according to the second inventive aspect when the computer program code iseXecuted by a processing device.

A tenth inventive aspect is a computer program product comprising computer code for performing the functionality of the second payment service provider in the method according to the second inventive aspect When the computer program code iseXecuted by a processing device.

An eleventh inventive aspect is a computer program product comprisingcomputer code for performing the functionality of the payer communication device inthe method according to the second inventive aspect when the computer program codeis eXecuted by a processing device.

A twelfth inventive aspect is a computer program product comprising computercode for performing the functionality of the payee communication device in the methodaccording to the second inventive aspect when the computer program code is executedby a processing device.

A thirteenth inventive aspect is a computer readable medium having storedthereon a computer program comprising computer program code for performing thefunctionality of the payment network switch in the method according to the secondinventive aspect when the computer program code is eXecuted by a processing device.

A fourteenth inventive aspect is a computer readable medium having storedthereon a computer program comprising computer program code for performing thefunctionality of the first payment service provider in the method according to the secondinventive aspect when the computer program code is eXecuted by a processing device.

A fifteenth inventive aspect is a computer readable medium having storedthereon a computer program comprising computer program code for performing thefunctionality of the second payment service provider in the method according to thesecond inventive aspect when the computer program code is eXecuted by a processingdevice.

A siXteenth inventive aspect is a computer readable medium having storedthereon a computer program comprising computer program code for performing thefunctionality of the payer communication device in the method according to the secondinventive aspect when the computer program code is eXecuted by a processing device.

A seventeenth inventive aspect is a computer readable medium having storedthereon a computer program comprising computer program code for performing thefunctionality of the payee communication device in the method according to the secondinventive aspect when the computer program code is eXecuted by a processing device.

As used in this document, the term “short-range data communication” includesany form of proXin1ity-based device-to-device communication, unidirectional orbidirectional. This includes radio-based short-range wireless data communication suchas, for instance, Bluetooth, BLE (Bluetooth Low Energy), RFID, WLAN, WiFi, mesh communication or LTE Direct, without lirr1itation. lt also includes non-radio-basedshort-range wireless data communication such as, for instance, magnetic communi-cation (such as NPC), audio communication, ultrasound communication, or opticalcommunication (such as QR, barcode, IrDA).

As used in this document, the term “wide area network communication”(abbreviated as “WAN communication”) includes any form of data networkcommunication with a party which may be remote (e. g. cloud-based), including cellularradio communication like W-CDMA, GSM, UTRAN, HSPA, LTE, LTE Advanced or5G, possibly communicated as TCP/IP traffic, or via a WLAN (WiFi) access point,without lirr1itation. Moreover, the terms “long-range data communication” and“broadband data communication” are considered as synonyms of “wide-area networkcommunication”.

Expressions like “[entity] is configured for... [performing activity]” or“[entity] is configured to [perform activity]” will include typical cases where acomputerized entity (having one or more controllers, processing units, programmablecircuitry, etc.) eXecutes software or firmware installed in the computerized entity,wherein the eXecution occurs in order to perform the activity in question.

Other aspects, objectives, features and advantages of the inventive aspects willappear from the following detailed disclosure, from the attached dependent claims aswell as from the drawings. Generally, all terms used in the claims are to be interpretedaccording to their ordinary meaning in the technical field, unless eXplicitly definedotherwise herein.

All references to "a/an/the [element, device, component, means, step, etc.]" areto be interpreted openly as referring to at least one instance of the element, device,component, means, step, etc., unless eXplicitly stated otherwise. The steps of anymethod disclosed herein do not have to be performed in the exact order disclosed, unless eXplicitly stated.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a schematic diagram of a digital payment system that enablespayment service provider interoperability for offline digital payments betweenproximate users.

Figure 2A illustrates a first part, namely an ofﬂine settlement stage, of aschematic ﬂowchart diagram of a computerized method of performing a digital payment of a payment amount between a payer and a payee.

Figure 2B illustrates a second part, namely an online settlement stage, of theschematic ﬂowchart diagram of the computerized method of performing a digitalpayment of a payment amount between a payer and a payee.

Figure 3 is a schematic block diagram of a communication device that mayimplement a payer communication device suitable for use in the digital payment systemand computerized method.

Figure 4 is a schematic block diagram of a communication device that mayimplement a payee communication device suitable for use in the digital payment systemand computerized method.

Figure 5 is a schematic illustration of a computer-readable medium in oneexemplary embodiment, capable of storing a computer program product.

Figure 6 is a schematic signal diagram illustrating distribution of digitalcertificates in one embodiment of the digital payment system according to the presentdisclosure.

Figure 7 is a schematic signal diagram illustrating distribution of foreignexchange rates in one embodiment of the digital payment system according to thepresent disclosure.

Figure 8 is a schematic signal diagram illustrating digital cash replenishment ofthe payer' s digital Wallet in one embodiment of the digital payment system according tothe present disclosure.

Figure 9 is a schematic signal diagram illustrating ofﬂine settlement of a digitalpayment in one embodiment of the digital payment system according to the presentdisclosure.

Figures 10A and 10B together are a schematic signal diagram illustratingonline settlement of a digital payment in one embodiment of the digital payment system according to the present disclosure.

DETAILED DESCRIPTION The disclosed embodiments will now be described more fully hereinafter withreference to the accompanying drawings, in which certain embodiments of the inventionare shown. This invention may, however, be embodied in many different forms andshould not be construed as limited to the embodiments set forth herein; rather, theseembodiments are provided by way of example so that this disclosure will be thoroughand complete, and will fully convey the scope of the invention to those skilled in the art.

Like drawings references refer to like elements throughout, particularly such that an element being referred to as “ynn” in a second drawing is to be understood as the sameas or the equivalent of an element being referred to as “Xnn” in a first drawing, where Xand y are single-digit numbers and nn is a double-digit number. When the samedrawings reference is used for an element that appears in multiple drawings, suchelement is to be understood as being the same or at least equivalent throughout suchmultiple drawings. Elements illustrated as hatched boXes are generally to be seen as optional in the particular drawing in which they appear.

Core embodiments Figure l shows a digital payment system l that enables payment serviceprovider interoperability for offline digital payments between proXimate users, here inthe form of a payer Pl and payee P2.

The digital payment system l in Figure l comprises a computerized paymentnetwork switch NW that has a payment network switch digital certificate cert _pub_nw.The digital payment system l further comprises a computerized first payment serviceprovider PSPl that handles a payer account acc0unt_PI of the payer Pl and has a firstpayment service provider digital certificate cert _pub _pspl which is verifiable with thepayment network switch digital certificate cert _pub_nw. Moreover, a computerizedsecond payment service provider PSP2 that handles a payee account acc0unt_P2 of thepayee P2 is also provided in the digital payment system l. There may be additionalcomputerized payment service provider PSPn in the digital payment system l, as can beseen in Figure l. The first and second payment service providers PSPl and PSP2 (andany additional computerized payment service provider PSPn) are typically differentpayment service providers selected, for instance, among Swish, Klarna, Google Pay,Samsung Pay, Apple Pay and PayPM, without limitation. ln addition, the digital payment system l comprises a payer communicationdevice PDl for use by the payer Pl. The payer communication device PDl has a payercommunication device digital certificate cert _pub_cust which is verifiable with the firstpayment service provider digital certificate cert _pub _pspl . The digital payment systeml moreover comprises a payee communication device PD2 for use by the payee P2.

Figures 2A and 2B together illustrate a computerized method 100 ofperforming a digital payment of a payment amount between a payer and a payee,typically performed in and by the digital payment system l between the aforementionedpayer Pl and payee P2. As can be seen from these two latter drawings, the digital payment is performed in two stages. First, an ofﬂine settlement ll0 takes place, as can be seen particularly in Figure 2A. Then, an online settlement 130 occurs which can beseen particularly in Figure 2B.

The offline settlement stage 110 takes place when the payer communicationdevice PD1 and payee communication device PD2 are in proXimity 10 of each other. Atthe ofﬂine settlement stage 110, the payer communication device PD1 is thusconfigured for generating, for a desired digital payment of a payment amount Amountfrom the payer P1 to the payee P2, payment transaction data Transaction Data whichare being signed with a private cryptographic key priv_key_cust which is associatedwith the payer communication device digital certificate cert _pub_cust. The paymenttransaction data Transaction Data includes the payer communication device digitalcertificate cert _pub_cust, the first payment service provider digital certificatecert _pub _pspl , and the payment amount Amount. The payer communication devicePD1 is further configured for communicating the payment transaction data TransactionData to the payee communication device PD2 by short-range data communication.

Still at the ofﬂine settlement stage 110, the payee communication device PD2is correspondingly configured for receiving the payment transaction data TransactionData from the payer communication device PD1 by short-range data communication.The payee communication device PD2 is moreover configured for validating thepayment transaction data Transaction Data to verify the payer communication device' sPD1 signature of the payment transaction data Transaction Data by means of the digitalcertificate cert _pub_cust of the payer communication device PD1.

The payee communication device PD2 is moreover configured, uponsuccessful validation, for accepting the digital payment and buffering the paymenttransaction data Transaction Data in local storage, the digital payment thereby beingsettled offline between the payer P1 and payee P2.

Then, during the online settlement stage 130, the payee communication devicePD2 is configured for subsequently communicating the buffered payment transactiondata Transaction Data to the second payment service provider PSP2 by wide areanetwork communication.

During the online settlement stage 130, the computerized payment networkswitch NW is configured for receiving the payment transaction data Transaction Datafrom the second payment service provider PSP2, and for validating the paymenttransaction data Transaction Data to verify the payer communication device' s PD1signature of the payment transaction data Transaction Data by means of the digital certificate cert _pub_cust of the payer communication device PD1.

Upon successful validation, the computerized payment network switch NW isconfigured for causing the digital payment to be settled online between the payer P1 andpayee P2 as follows. From the payment transaction data Transaction Data, thecomputerized payment network switch NW first determines a payer identifierid_cust@pspl.nw representing the payer P1, a payee identifier id_merch @psp2.nwrepresenting the payee P2, and the payment amount Amount.

The computerized payment network switch NW then sends a debit instructionto the first payment service provider PSP1 to cause a deduction of funds from the payeraccount account_PI of the payer P1, wherein the deduction corresponds to the paymentamount Amount. The computerized payment network switch NW moreover sends acredit instruction to the second payment service provider PSP2 to cause an addition offunds to the payee account account_P2 of the payee P2, the addition corresponding tothe payment amount Amount.

The functionality described above can be summarized by the aforementionedcomputerized method 100 shown in Figures 2A and 2B. It is recalled that thecomputerized method 100 is a method of performing a digital payment of a paymentamount Amount between a payer P1 and a payee P2. It is also recalled that the payer P1is provided with a payer communication device PD1 and is associated with acomputerized first payment service provider PSP1 that handles a payer accountaccount_PI of the payer P1, whereas the payee P2 is provided with a payeecommunication device PD2 and is associated with a computerized second paymentservice provider PSP2 that handles a payee account account_P2 of the payee P2.

During the ofﬂine settlement stage 110 of the computerized method 100, thepayer communication device PD1 and payee communication device PD2 communicateat 112 by short-range data communication to generate payment transaction dataTransaction Data. The payment transaction data Transaction Data is digitally signed at114 by the payer communication device PD1 and comprises the payment amountAmount as well as digital certificates cert _pub_cust, cert _pub _pspl of the payercommunication device PD1 and the first payment service provider PSP1.

The generated payment transaction data Transaction Data is validated at 116by the payee communication device PD2 to verify the payer communication device' sPD1 signature of the payment transaction data Transaction Data by means of the digitalcertificate cert _pab_cust of the payer communication device PD1.

During the online settlement stage 130 of the computerized method 100, the payee communication device PD2 communicates at 132 the payment transaction data ll Transaction Data to the second payment service provider PSP2 by wide area networkcommunication. The second payment service provider PSP2 communicates at 134 thepayment transaction data Transaction Data to the computerized payment networkswitch NW.

The computerized payment network switch NW validates at 136 the paymenttransaction data Transaction Data to verify the payer communication device' s PD1signature of the payment transaction data Transaction Data by means of the digitalcertificate cert _pab_cast of the payer communication device PD1.

Upon successful validation, see 138, the computerized payment network switchNW determines at 140 from the payment transaction data Transaction Data a payeridentifier id_cast@pspl.nw representing the payer P1, a payee identifierid_merch @psp2.nw representing the payee P2, and the payment amount Amoant.

The computerized payment network switch NW then, at 142, communicates atleast with the first payment service provider PSP1 to cause a deduction of funds fromthe payer account accoant_PI of the payer P1 and an addition of funds to the payeeaccount accoant_P2 of the payee P2.

The deduction and addition correspond to the payment amount Amoant. lnsome embodiments, the deduction and the addition are equal to the payment amountAmoant (i.e., the payment amount Amoant is subtracted from the balance of the payeraccount accoant_PI and is added to the balance of the payee account accoant_P2). lnsome embodiments, a fee may be charged to the payer account accoant_PI and/orpayee account accoant_P2, wherein the deduction and/or addition may not be exactlyidentical to the payment amount Amoant. In some embodiments, there is a currencyconversion at the payer side, as will be described in more detail in a later section of this document.

In some embodiments, the computerized payment network switch NW isconfigured for causing the digital payment to be settled online between the payer P1 andpayee P2 by sending a debit instruction to the first payment service provider PSP1 tocause the deduction of funds from the payer account accoant_PI of the payer P1, andby sending a credit instruction to the second payment service provider PSP2 to cause anaddition of funds to the payee account accoant_P2 of the payee P2. The debitinstruction will typically contain at least the payer identifier id_cast@pspl.nw and thepayment amount Amoant. The credit instruction will typically contain at least the payee identifier id_merch @psp2.nw and the payment amount Amoant. 12 In other embodiments, the computerized payment network switch NW isconfigured for causing the digital payment to be settled online between the payer P1 andpayee P2 by sending a settlement instruction to the first payment service provider PSP1,wherein the settlement instruction will typically contain the payer identifierid_cust@pspl.nw, the payee identifier id_merch @psp2.nw and the payment amountAmount.

In such embodiments, the first payment service provider PSP1 is configured forreceiving the settlement instruction and making the deduction of funds from the payeraccount acc0unt_PI of the payer P1. Furthermore, in such embodiments, the firstpayment service provider PSP1 is configured for sending a credit instruction to thesecond payment service provider PSP2 to cause the addition of funds to the payeeaccount account_P2 of the payee P2.

Reference is now being made to Figure 3 and the communication device 300illustrated therein. The communication device 300 may implement a payercommunication device, like the aforementioned PD1, suitable for use in the digitalpayment system 1 and computerized method 100. To this end, the communicationdevice 300 comprises a processing device 302, local storage including a memory 304, ashort-range data communication interface 306, a wide area network communicationinterface 308 and a user interface 310.

The processing device 302 acts as a controller of the communication device300 and may be implemented in any known controller technology, including but notlimited to microcontroller, processor (e. g. PLC, CPU, DSP), FPGA, ASIC or any othersuitable digital and/or analog circuitry capable of performing the intended functionality.

The memory 304 may be implemented in any known memory technology,including but not limited to ROM, RAM, SRAM, DRAM, CMOS, FLASH, DDR,SDRAM or some other memory technology. In some embodiments, the memory orparts thereof may be integrated with or internal to the processing device 302. Thememory may store program instruction for eXecution by the processing device 302 (alsosee the description of Figure 5 below), as well as temporary and permanent data for useby the processing device 302.

The short-range data communication interface 306 may be configured forBluetooth communication, or any other radio-based short-range wireless datacommunication such as, for instance, Bluetooth Low Energy, RFID, WLAN, WiFi, mesh communication or LTE Direct, without limitation, or any non-radio-based short- 13 range wireless data communication such as, for instance, magnetic communication(such as NPC), (ultra)sound communication, or optical communication (such as IrDA)without lirnitation. ln some embodiments, the short-range data communication interface306 comprises equipment and functionality for presenting or scanning a QR code.

The wide area network communication interface 308 may be configured forwide area network communication compliant with, for instance, one or more of W-CDMA, GSM, UTRAN, HSPA, LTE, LTE Advanced or 5G, and TCP/IP, and/orWLAN (WiFi), without limitation.

The user interface 310 may comprise an input device and a presentation device,as is generally known per se. In some embodiments, the input device and thepresentation device are constituted by one common physical device, such as for instancea touch screen (touch- sensitive display screen), implemented in for instance resistivetouch technology, surface capacitive technology, projected capacitive technology,surface acoustic wave technology or infrared technology.

The communication device 300 may further comprise a trusted eXecutionenvironment TEE, such as a secure element, i.e. a tamper-resistant hardware or virtualplatform. ln the latter case, the trusted eXecution environment TEE may be implementedin software and may reside in the local storage or even the memory 304. The trustedeXecution environment TEE is capable of securely hosting applications and storingconfidential and cryptographic data and therefore provides a trusted environment foreXecution of such applications, a.k.a. secure runtime. Advantageously, some of the dataand functionality in embodiments of the invention may be stored in and performed bythe trusted eXecution environment TEE, as will be clear from subsequent sections of thisdocument.

The communication device 300 may hence be configured to perform thefunctionality of the payer communication device PD1 as defined in and described abovefor the method 100 and any or all of its embodiments. The payer communication devicePD1 may thus be implemented by the communication device 300 in the form of, forinstance, a mobile communication device, a mobile phone, a smart phone, a tabletcomputer, a personal digital assistant, a portable computer, smart glasses, a smartwearable, a smart watch, a smart bracelet, a smart card or a smart chip.

Figure 4 illustrates a communication device 400 which may implement a payeecommunication device, like the aforementioned PD2, suitable for use in the digitalpayment system 1 and computerized method 100. To this end, the communication device 400 comprises a processing device 402, local storage including a memory 404, a 14 short-range data communication interface 406, a wide area network communicationinterface 408 and a user interface 410.

The processing device 402 acts as a controller of the communication device400 and may be implemented in much the same way as the processing device 302referred to above. The memory 404 may be implemented in much the same way as thememory 404 referred to above and may store program instruction for eXecution by theprocessing device 402 (also see the description of Figure 5 below), as well as temporaryand permanent data for use by the processing device 402.

The short-range data communication interface 406 and the wide area networkcommunication interface 408 may be implemented in much the same way as the short-range data communication interface 306 and the wide area network communicationinterface 308 referred to above. The same may apply to the user interface 410 withrespect to the user interface 310.

The communication device 400 may hence be configured to perform thefunctionality of the payee communication device PD2 as defined in and described abovefor the method 100 and any or all of its embodiments. The payee communication devicePD2 may thus be implemented by the communication device 400 in the form of, forinstance, a mobile communication device, a mobile phone, a smart phone, a tabletcomputer, a personal digital assistant, a portable computer, smart glasses, a smart watch,a smart card, a smart bracelet, a smart wearable, a payment terminal, a service terminal,a point-of- sales terminal, a checkout counter, a delivery pickup point, a vendingmachine, a ticket machine, a dispensing machine, or an access control system.

Figure 5 is a schematic illustration of a computer-readable medium 500 in oneexemplary embodiment, capable of storing a computer program product 510. Thecomputer-readable medium 500 in the disclosed embodiment is a portable memorydevice, such as a Universal Serial Bus (USB) stick. The computer-readable medium 500may however be embodied in various other ways instead, as is well-known per se to theskilled person. The portable memory device 500 comprises a housing 530 having aninterface, such as a connector 540, and a memory chip 520. In the disclosedembodiment, the memory chip 520 is a ﬂash memory, i.e. a non-volatile data storagethat can be electrically erased and re-programmed. The memory chip 520 stores thecomputer program product 510 which is programmed with computer program code(instructions) that when loaded into a processing device, such as a CPU, will performany of the functionalities listed in the next paragraph. The processing device may, for instance, be the aforementioned processing device 302 or 402. The portable memory device 500 is arranged to be connected to and read by a reading device for loading theinstructions into the processing device. lt should be noted that a computer-readablemedium can also be other media such as compact discs, digital video discs, hard drivesor other memory technologies commonly used. The computer program code(instructions) can also be downloaded from the computer-readable medium via awireless interface to be loaded into the processing device.ln one embodiment, therefore, the computer program product 5 l0 comprises computer code for performing the functionality of the payer communication device PDlin the method l00 as described herein when the computer program code is eXecuted bythe processing device. In another embodiment, the computer program product 5 l0comprises computer code for performing the functionality of the payee communicationdevice PD2 in the method l00 as described herein when the computer program code iseXecuted by the processing device. In still other embodiments, the computer programproduct 5l0 comprises computer code for performing the functionality of the paymentnetwork switch, the first payment service provider or the second payment serviceprovider in the method l00 as described herein when the computer program code is eXecuted by the processing device.

Refined embodiments ln some embodiments, the first payment service provider PSPl is configured,upon deduction of the funds from the payer account accoant_PI of the payer Pl, tosend an online settlement completion report to the payer communication device PDl.The online settlement completion report will thus indicate the deducted funds and serveas useful feedback information to the payer Pl. ln some embodiments, each of the payee communication device PD2 and thecomputerized payment network switch NW is configured for validating the paymenttransaction data Transaction Data to verify the payer communication device' s PDlsignature of the payment transaction data Transaction Data in the following manner.First, the first payment service provider digital certificate cert _pub _pspl is verified bymeans of the payment network switch digital certificate cert _pub_nw. Then, the payercommunication device digital certificate cert _pnb_cust is verified by means of theverified first payment service provider digital certificate cert _pub _pspl. Finally, thepayer communication device°s PDl signature of the payment transaction dataTransaction Data is verified by means of the verified payer communication device digital certificate cert_pub_cust. 16 Such embodiments offer a high level of data integrity and trust for theparticipating parties of the digital payment system 1, thanks to the hierarchy of digitalcertificates from the leaf level (payer communication device PD1) and upwards, whichcan be successively verified by the digital certificates of the entities at the respectivenext levels.

Certificate distribution ln some embodiments, the digital payment system 1 even comprises acomputerized certificate authority CA at a root level, which may be global (see Figure1). The certificate authority CA has a certificate authority digital certificatecert _pub_ca, by means of which the payment network switch digital certificatecert _pub_nw can be verified. The certificate authority CA may, for instance, be acentral bank, a trusted intemational organization, or a trusted private enterprise. Theprovision of the certificate authority CA root level in the digital payment system 1 mayalso allow additional computerized payment network switches (NW2. . .NWn (seeFigure 1), each having a respective payment network switch digital certificate which isverifiable with the certificate authority digital certificate cert _pub_ca of the certificateauthority CA.

For further details, reference is being made to Figure 6 which illustrates thedistribution of digital certificates in one embodiment 600 of the digital payment system1. Figure 6 shows the payer communication device PD1 being provided with a customerapplication 601 for use by the payer (customer) P1. The customer application 601 willhave access to certain data 602, which includes the aforementioned payer identifierid_cust@pspl.nw, as well as some of the digital certificates described above. Thecustomer application 601 may be implemented by software stored in the memory 304and eXecuted by the processing device 302 of the communication device 300 in Figure3. The data 602 may be stored in the memory 304.

The customer application 601 interacts with a customer secure element 603which may be implemented in or by the aforementioned trusted eXecution environmentTEE (cf. Figure 3). The customer secure element 603 securely stores data 604, includingthe aforementioned private cryptographic key priv_key_cust which is associated withthe payer communication device digital certificate cert _pub_cust, and the same digitalcertificates as the customer application 601.

Figure 6 furthermore shows the payee communication device PD2 beingprovided with a merchant application 605 for use by the payee (merchant) P2. The merchant application 605 will have access to certain data 606, which includes the 17 aforementioned payee identifier id_merch @ps2.nw, as Well as some of the digitalcertificates described above.

The first payment service provider PSP1 will have access to certain data 607,including a private cryptographic key priv_key_pspl which is associated with theaforementioned first payment service provider digital certificate cert _pub _pspl , as wellas a corresponding public cryptographic key pub_key_pspl. The data 607 also includesan identifier pspl @nw of the first payment service provider PSP1, as well as a list ofusers (one of which being the payer P1) and their corresponding accounts (one of whichbeing the payer account accounLPl ).

Correspondingly, the second payment service provider PSP2 will have accessto certain data 608, including a private cryptographic key priv_key_psp2 which isassociated with the aforementioned second payment service provider digital certificatecert _pub _psp2 , as well as a corresponding public cryptographic key pub_key_psp2. Thedata 608 also includes an identifier psp2 @nw of the second payment service providerPSP2, as well as a list of users (one of which being the payee P2) and theircorresponding accounts (one of which being the payee account acc0unt_P2).

The payment network switch NW will have access to certain data 609,including a private cryptographic key priv_key_nw which is associated with theaforementioned payment network switch digital certificate cert _pub_nw, as well as acorresponding public cryptographic key pub_key_nw. The data 609 also includes anidentifier id_nw of the payment network switch NW, as well as a list of payment serviceproviders (including the first and second payment service providers PSP1, PSP2).

The certificate authority CA will have access to certain data 610, including aprivate cryptographic key priv_key_ca which is associated with the aforementionedcertificate authority digital certificate cert _pub_ca, as well as the certificate itself and/ora corresponding public cryptographic key pub_key_ca. The data 610 also includesinformation on the payment network switch NW, or a list of payment network switchesNW, NW2, ..., in case there are more than one of them in the digital payment system.

The distribution procedure in Figure 6 starts at 620 with the payment networkswitch NW sending a certificate signing request 620 to the certificate authority CA, therequest including the public cryptographic key pub_key_nw and the identifier id_nw ofthe payment network switch NW. At 622, the certificate authority CA generates thepayment network switch digital certificate cert _pub_nw by signing the receivedpub_key_nw and id_nw using the private cryptographic key priv_key_ca, and delivering the generated payment network switch digital certificate cert _pub_nw in a certificate 18 signing response 624 to the payment network switch NW. Upon receipt, the paymentnetwork switch NW stores at 626 the payment network switch digital certificatecert _pnb_nw in the data 609.

At 628, the second payment service provider PSP2 sends a certificate signingrequest to the payment network switch NW. The request includes the publiccryptographic key pnb_key_psp2 and the identifier psp2 @nw of the second paymentservice provider PSP2. At 630, the payment network switch NW generates the secondpayment service provider digital certificate cert _pnb _psp2 by signing the receivedpub_key_psp2 and psp2 @nw using the private cryptographic key priv_key_nw, anddelivering the generated second payment service provider digital certificatecert _pub _psp2 in a certificate signing response 632 to the second payment serviceprovider PSP2. The network switch digital certificate cert _pub_nw is also included inthe response 632.

Upon receipt, as seen at 634, the second payment service provider PSP2verifies the signature of the received second payment service provider digital certificatecert _pub _psp2 using the network switch digital certificate cert _pub_nw. lf theverification is successful, cert _pub _psp2 and cert _pnb_nw are stored in the data 608.

At 636-642, the first payment service provider PSP1 retrieves the first paymentservice provider digital certificate cert _pub _pspl from the payment network switch NWand stores it together with the network switch digital certificate cert _pnb_nw in the data607, in much the same way as has been described above for the second payment serviceprovider PSP2.

The payee communication device PD2 will then, at 644, retrieve its digitalcertificate cert _pnb_merch together with the second payment service provider digitalcertificate cert _pub _psp2 and the network switch digital certificate cert _pnb_nw fromthe second payment service provider PSP2, for storing in the data 606.

Correspondingly, at 646, the payer communication device PD1 will retrieve itsdigital certificate cert _pnb_cust together with the first payment service provider digitalcertificate cert _pub _pspl and the network switch digital certificate cert _pnb_nw fromthe first payment service provider PSP1, for storing in the data 602-604.

Payer identifier ln some embodiments, the computerized payment network switch NW isconfigured for deterrnining the payer identifier id_cust@pspl.nw, that represents thepayer P1, from the payer communication device digital certificate cert _pub_cust in the payment transaction data Transaction Data. The payer identifier is therefore protected 19 from manipulation since it is contained in a verifiable digital certificate, namely thepayer communication device digital certificate cert _pab_cast. Again, a high level ofdata integrity and trust is offered.

Payee certificate Further enhanced data integrity and trust may be obtained in someembodiments by the following provisions. It is recalled that the computerized secondpayment service provider PSP2 has its second payment service provider digitalcertificate cert _pab _psp2 which is verifiable with the payment network switch digitalcertificate cert _pab_nw. Moreover, the payee communication device PD2 has its payeecommunication device digital certificate cert _pab_merch which is verifiable with thesecond payment service provider digital certificate cert _pab _psp2. The payeecommunication device digital certificate cert _pab_merch is included in the paymenttransaction data Transaction Data being signed by the payer communication devicePD1. ln effect, this makes the Transaction Data addressed to the intended receiver, i.e.the payee P2.

Payee identifier Advantageously, in such embodiments, the computerized payment networkswitch NW is configured for determining the payee identifier id_merch @psp2.nw, thatrepresents the payee P2, from the payee communication device digital certificatecert _pab_merch in the payment transaction data Transaction Data. The payee identifieris therefore protected from manipulation since it is contained in a verifiable digitalcertificate, namely the payee communication device digital certificate cert _pab_merch.Once again, a high level of data integrity and trust is obtained.

Double sided buffering of transaction data and initiation of online settlement ln some embodiments, the payer communication device PD1 is configured forbuffering the generated payment transaction data Transaction Data in local storage atthe ofﬂine settlement stage 110, and for subsequently communicating the bufferedpayment transaction data Transaction Data to the first payment service provider PSP1by wide area network communication at the online settlement stage 130 (i.e., much likethe payee communication device PD2 does).

The computerized payment network switch NW is configured for receiving thepayment transaction data Transaction Data from the first payment service providerPSP1, and for validating the payment transaction data Transaction Data to verify the payer communication device°s PD1 signature of the payment transaction data Transaction Data by means of the digital certificate cert _pab_cast of the payercommunication device PD1.

The computerized payment network switch NW is further configured, uponsuccessful Validation and unless the digital payment has already been settled online, forcausing the digital payment to be settled online between the payer P1 and payee P2 bydeterrnining from the payment transaction data Transaction Data a payer identifierid_cast@pspl.nw that represents the payer P1, a payee identifier id_merch @psp2.nwthat represents the payee P2, and the payment amount Amoant. The computerizedpayment network switch NW then communicates at least with the first payment serviceprovider PSP1 to cause a deduction of funds from the payer account acc0ant_PI of thepayer P1 and an addition of funds to the payee account account_P2 of the payee P2, thededuction and addition corresponding to the payment amount Amoant.

This may involve the computerized payment network switch NW sending adebit instruction to the first payment service provider PSP1 to cause the deduction offunds from the payer account acc0ant_PI of the payer P1, as well as sending a creditinstruction to the second payment service provider PSP2 to cause the addition of fundsto the payee account account_P2 of the payee P2.

Alternatively, it may involve the computerized payment network switch NWsending a settlement instruction to the first payment service provider PSP1, wherein thesettlement instruction will typically contain the payer identifier id_cast@pspl.nw, thepayee identifier id_merch @psp2.nw and the payment amount Amoant. The firstpayment service provider PSP1 will receive the settlement instruction and make thededuction of funds from the payer account acc0ant_PI of the payer P1. In addition, thefirst payment service provider PSP1 will send a credit instruction to the second paymentservice provider PSP2 to cause the addition of funds to the payee account account_P2 ofthe payee P2.

Such embodiments will be beneficial in that redundancy is added to the digitalpayment system 1; if the payee communication device PD2 is incapable of wide areanetwork communication with the second payment service provider PSP2 for the timebeing (for any technical reason), a resulting delay of the online settlement stage 130 canbe avoided since the payer communication device PD1 may take care of the part of theonline settlement stage 130 that would norrnally have been performed by the payee communication device PD2. 21 Embodiments With local digital Wallet Advantageously, the payer communication device PD1 comprises a digitalWallet DW Which is stored in local storage, preferably in the hardWare-based orsoftWare-based trusted execution environment TEE (e. g. secure element). The payercommunication device PD1 is configured to verify that a current balance Balance of thedigital Wallet DW is sufficient for the payment amount Amoant of the desired digitalpayment, and, upon successful verification, update the balance Balance of the digitalWallet DW to reﬂect the payment amount Amount of the desired digital payment.

More specifically, in some embodiments the payer communication device PD1is configured to verify that the current balance Balance of the digital Wallet DW issufficient for the payment amount Amount of the desired digital payment by verifyingthat the payment amount Amoant does not exceed the current balance Balance of thedigital Wallet DW. The payer communication device PD1 is furthermore configured toupdate the balance Balance of the digital Wallet DW to reﬂect the payment amountAmount of the desired digital payment by deducting the payment amount Amount fromthe current balance of the digital Wallet DW. ln addition to this, the payer communication device PD1 may be configured toverify that the desired digital payment complies With a risk lin1it profile of the digitalWallet DW. The risk limit profile may be applied by the first payment service providerPSP1 and may, for instance, define one or more of the folloWing constraints: 0 a total spending lin1it for digital payments that have not yet been settled; 0 a maximum payment amount for each digital payment; 0 a maximum accumulated payment amount for digital payments, and/or amaximum number of digital payments, perforrnable until communicating thecontents of the transaction log to the first payment service provider PSP1(for embodiments Where the payer communication device PD1, too, bufferspayment transactions as described above); 0 a maximum accumulated payment amount for digital payments perforrnableduring a certain time (such as a day, Week, month, etc.); 0 a maximum number of digital payments performable during a certain time(such as a day, Week, month, etc.); 0 a definition of payment receivers that the payer P1 is alloWed to make digitalpayments to; and 0 a definition of payment receivers that the payer P1 is not alloWed to make digital payments to. 22 Digital wallet replenishment The payer P1 may request a top-up of the digital Wallet DW from the firstpayment service provider PSP1. Accordingly, the payer communication device PD1 isconfigured to generate an ofﬂine Wallet replenishment request comprising a requestedreplenishment amount and the payer communication device digital certificatecert _pab_cust, sign the ofﬂine Wallet replenishment request using the privatecryptographic key priv_key_cast associated with the payer communication devicedigital certificate cert _pab_cast, and send the ofﬂine Wallet replenishment request to thefirst payment service provider PSP1.

This activity can be seen at 810-818 in Figure 8. Figure 8 illustrates a digitalpayment system 800, being an embodiment of the digital payment system 1. Thecustomer application 801 and its data 802, the customer secure element 803 and its data804, the merchant application 805 and its data 806, the data 807 of the first paymentservice provider PSP1, the data 808 of the second payment service provider PSP2, thedata 809 of the payment network switch NW and the data 810 of the certificateauthority CA, may all be substantially the same as has been described above for entities601-610 in conjunction with Figure 6, except when described otherwise in the followingsections of this document.

The replenishment activity in Figure 8 starts with the payer P1 requesting areplenishment amount at 811. The customer application 801 communicates with thecustomer secure element 803 at 812 and 816 to request and retrieve signed transactiondata STID at 814, being signed using the private cryptographic key priv_key_cast (alsoreferred to as SK in Figure 8). The signed transaction data STID represents therequested replenishment as a transaction between the payer communication device PD1and the first payment service provider PSP1. The customer application 801 sends anofﬂine wallet replenishment request 818, including the signed transaction data STID,the payer communication device digital certificate cert _pab_cast (also referred to as PCin Figure 8) and the requested amount, to the first payment service provider PSP1.

The first payment service provider PSP1 is configured to validate, at 820, theofﬂine wallet replenishment request 818 by verifying the payer communication devicedigital certificate cert _pab_cast by means of the verified first payment service providerdigital certificate cert _pab _pspl , and then verifying the payer communication device°sPD1 signature of the payment transaction data Transaction Data by means of the verified payer communication device digital certificate cert _pab_cast. The first 23 payment service provider PSP1 is also configured to validate the signed transaction dataSTID using the payer communication device digital certificate cert _pub_cust.

The first payment service provider PSP1 is furthermore configured, uponsuccessful validation, to reserve or deduct a granted replenishment amount in or fromthe payer account accounLPl of the payer P1, Wherein the granted replenishmentamount is equal to or less than the requested replenishment amount (depending on, forinstance the risk lin1its granted to the payer P1). This, too, can be seen at 820 in Figure8.

The first payment service provider PSP1 sends an ofﬂine Wallet replenishmentresponse 830 to the payer communication device PD1. The ofﬂine Wallet replenishmentresponse 830 comprises the granted replenishment amount and is signed by a privatecryptographic key priv_key_pspl associated With the first payment service providerdigital certificate cert _pub _pspl . The ofﬂine Wallet replenishment response 830 mayfurther comprise an updated risk lin1it profile, if applicable.

The payer communication device PD1 is configured to receive the ofﬂineWallet replenishment response 830 from the first payment service provider PSP1 at 840-842. As seen at 844, the payer communication device PD1 validates the ofﬂine Walletreplenishment request 830 by verifying the first payment service provider°s PSP1signature of the ofﬂine Wallet replenishment response by means of the first paymentservice provider digital certificate cert _pub _pspl . Upon successful validation, the payercommunication device PD1 updates the balance Balance of the digital Wallet DW toreflect the granted replenishment amount, and updates the risk limit profile if applicable,The procedure concludes With some affirmative status communication at 850 and 852, eventually notifying the payer P1 of the outcome of the requested top-up.

Offline settlement - exemplarv details A detailed example of hoW the ofﬂine settlement stage 110 may be performedWill noW be presented With reference to Figure 9. Figure 9 illustrates a digital paymentsystem 900, being an embodiment of the digital payment system 1. The customerapplication 901 and its data 902, the customer secure element 903 and its data 904, themerchant application 905 and its data 906, the data 907 of the first payment serviceprovider PSP1, the data 908 of the second payment service provider PSP2, the data 909of the payment netWork sWitch NW and the data 910 of the certificate authority CA,may all be substantially the same as has been described above for entities 601-610 inconjunction With Figure 6, or entities 801-810 of Figure 8. 24 At 912, the merchant application 905 presents the amount to the paid, Amount.A payment request 917 is then generated at 914. The payment request includes thesecond payment service provider digital certificate cert _pub _psp2 , an identifier ID forthe local offline communication between the devices PD1 and PD, the payee identifierid_merch @psp2.nw (included in the payee communication device digital certificatecert _pub_merch or as separate data), and optionally some additional data.

The payment request 917 is sent to the payer communication device PD1 byshort-range data communication. As seen at 916-918, the customer application 901 inthe payer communication device PD1 may obtain authorization from the payer P1 in theform of authorization data PIN, Which may be a passcode, biometric information, etc.

The customer application 901 and the customer secure element 903 thengenerate the aforementioned payment transaction data Transaction Data and sends it tothe payee communication device PD2 in steps 920-928. As seen at 920, this includesverifying the authorization data PIN, checking and updating the current balance,Balance, of the digit Wallet DW, signing the payment transaction data Transaction Data(see S in Figure 9) using the private cryptographic key priv_key_cust (SK), andbuffering the generated payment transaction data Transaction Data in local storage (it isrecalled that this may not take place at the payer communication device PD1 in everyembodiment of the invention). lt is recalled that the payment transaction dataTransaction Data includes the payer communication device digital certificatecert _pub_cust (PC), the first payment service provider digital certificate cert _pub _pspl ,and the payment amount, Amount.

The generated payment transaction data Transaction Data is communicated tothe payee communication device PD2 by short-range data communication in steps 926and 928. Upon receipt, the merchant application 905 in the payee communication devicePD2 Will validate the payment transaction data Transaction Data to verify the payercommunication device°s PD1 signature of the payment transaction data TransactionData by means of the digital certificate cert _pub_cust (PC) of the payer communicationdevice PD1. Upon successful validation, the merchant application 905 Will accept thedigital payment and log the payment transaction by buffering the payment transactiondata Transaction Data in local storage. The digital payment has then been settled ofﬂinebetween the payer P1 and payee P2. The merchant application 905 may have a dialogueWith the payee P2 at this stage, as can be seen at 930 and 934.

Online settlement - exemplarv details A detailed example of how the online settlement stage 130 may be performedWill now be presented with reference to Figures 10A and 10B. Figures 10A and 10Billustrate a digital payment system 1000, being an embodiment of the digital paymentsystem 1. The customer application 1001 and its data 1002, the customer secure element1003 and its data 1004, the merchant application 1005 and its data 1006, the data 1007of the first payment service provider PSP1, the data 1008 of the second payment serviceprovider PSP2, the data 1009 of the payment network switch NW and the data 1010 ofthe certificate authority CA, may all be substantially the same as has been describedabove for entities 601-610 in conjunction with Figure 6, entities 801-810 of Figure 8 orentities 901-910 of Figure 9.

Figure 10A illustrates the online settlement when being initiated by the payercommunication device PD1. lt is recalled that this is merely an optional functionalitythat does not have to be available in every embodiment of the invention. Figure 10Billustrates the online settlement when being initiated by the payee communicationdevice PD2.

Starting with Figure 10A, the online settlement activity may be initiated incooperation with the payer P1 (see 1012), or alternatively in an automatic manner (e. g.according to a schedule, when the first opportunity arises, or upon demand from the firstpayment service provider PSP1). The payer communication device PD1 retrieves anybuffered payment transaction data and compiles it into a transaction block. Thetransaction block may thus contain buffered payment transaction data for one or moredigital payments. At 1014, the payer communication device PD1 communicates thetransaction block with the buffered payment transaction data Transaction Data to thefirst payment service provider PSP1 by wide area network communication.

Optionally, at 1016, the first payment service provider PSP1 may verify thepayer communication device°s PD1 signature S of the payment transaction dataTransaction Data (for each transaction in the received transaction block) by verifyingthe first payment service provider digital certificate cert _pub _pspl by means of thepayment network switch digital certificate cert _pub_nw, verifying the payercommunication device digital certificate cert _pub_cust (PC) by means of the verifiedfirst payment service provider digital certificate cert _pub _pspl , and verifying the payercommunication device°s PD1 signature of the payment transaction data Transaction Data by means of the verified payer communication device digital certificate 6 cert _pnb_cust (PC). ln case of a failed verification, the first payment service providerPSP1 may then refuse to process the payment transaction any further.

At 1018, the first payment service provider PSP1 communicates the receivedtransaction block with the buffered payment transaction data Transaction Data to thecomputerized payment network switch NW by wide area network communication.

The computerized payment network switch NW receives the transaction blockwith the payment transaction data Transaction Data from the first payment serviceprovider PSP1. The computerized payment network switch NW validates, at 1020, thepayment transaction data Transaction Data for each payment transaction in the receivedtransaction block so as to verify the payer communication device°s PD1 signature of thepayment transaction data Transaction Data by means of the digital certificatecert _pub_cust of the payer communication device PD1.

More specifically, in the disclosed embodiment, this involves verifying the firstpayment service provider digital certificate cert _pab _pspl by means of the paymentnetwork switch digital certificate cert _pnb_nw, verifying the payer communicationdevice digital certificate cert _pub_cast (PC) by means of the verified first paymentservice provider digital certificate cert _pub _pspl , and verifying the payercommunication device°s PD1 signature of the payment transaction data TransactionData by means of the verified payer communication device digital certificatecert _pnb_cust (PC). ln case of a failed verification, the computerized payment networkswitch NW may then refuse to process the payment transaction any further.

Upon successful validation, the computerized payment network switch NWmakes sure, at 1022, that the payment transaction in question has not already beensettled, and causes the digital payment between the payer P1 and payee P2 to be settledonline as follows. As previously described, from the payment transaction dataTransaction Data, the computerized payment network switch NW detern1ines the payeridentifier id_cnst@pspl.nw representing the payer P1, the payee identifierid_merch @psp2.nw representing the payee P2, and the payment amount Amount.

At 1024, the computerized payment network switch NW sends a debitinstruction to the first payment service provider PSP1 to cause a deduction of fundsfrom the payer account acconnt_PI of the payer P1 at 1026, with confirmation beinggiven at 1028.

The computerized payment network switch NW moreover sends a credit instruction at 1030 to the second payment service provider PSP2 to cause an addition of 27 funds to the payee account account_P2 of the payee P2 at 1032, with confirmationbeing given at 1034.

The computerized payment network switch NW then provides respectivesett1ement responses 1038 and 1044 to the first and second payment service providersPSP1 and PSP2. The sett1ement responses wi11 be propagated to the payercommunication device PD1 and payee communication device PD2, as seen at 1040(being an on1ine sett1ement comp1etion report), 1042 and 1046.

Reference is now being made to with Figure 10B. The on1ine sett1ementactivity may be initiated in cooperation with the payee P2 (see 1062), or a1ternative1y inan automatic manner (e. g. according to a schedu1e, when the first opportunity arises, orupon demand from the first payment service provider PSP1). The payee communicationdevice PD2 retrieves any buffered payment transaction data and compi1es it into atransaction block. Just 1ike in Figure 10A, the transaction b1ock may contain bufferedpayment transaction data for one or more digita1 payments. At 1064, the payeecommunication device PD2 communicates the transaction b1ock with the bufferedpayment transaction data Transaction Data to the second payment service providerPSP2 by wide area network communication.

Optiona11y, at 1066, the second payment service provider PSP1 may verify thepayer communication device°s PD1 signature S of the payment transaction dataTransaction Data (for each transaction in the received transaction b1ock) by verifyingthe first payment service provider digita1 certificate cert _pub _pspl by means of thepayment network switch digita1 certificate cert _pub_nw, verifying the payercommunication device digita1 certificate cert _pub_cust (PC) by means of the verifiedfirst payment service provider digita1 certificate cert _pub _pspl , and verifying the payercommunication device°s PD1 signature of the payment transaction data TransactionData by means of the verified payer communication device digita1 certificatecert _pub_cust (PC). In case of a fai1ed verification, the second payment service providerPSP2 may then refuse to process the payment transaction any further.

At 1068, the second payment service provider PSP2 communicates thereceived transaction b1ock with the buffered payment transaction data Transaction Datato the computerized payment network switch NW by wide area networkcommunication.

The computerized payment network switch NW receives the transaction b1ockwith the payment transaction data Transaction Data from the second payment service provider PSP2. The computerized payment network switch NW va1idates, at 1070, the 28 payment transaction data Transaction Data for each payment transaction in the receivedtransaction block so as to verify the payer communication device°s PD1 signature of thepayment transaction data Transaction Data by means of the digital certificate cert _pub_cust of the payer communication device PD1. Like in Figure 10A, this mayspecifica11y invo1ve verifying the first payment service provider digita1 certificate cert _pub _pspl by means of the payment network switch digita1 certificate cert _pub_nw,verifying the payer communication device digita1 certificate cert _pub_cust (PC) bymeans of the verified first payment service provider digita1 certificate cert _pub _pspl ,and verifying the payer communication device°s PD1 signature of the paymenttransaction data Transaction Data by means of the verified payer communication devicedigita1 certificate cert _pub_cust (PC). In case of a fai1ed verification, the computerizedpayment network switch NW may refuse to process the payment transaction any further.

Upon successfu1 va1idation, the computerized payment network switch NWmakes sure, at 1082, that the payment transaction in question has not a1ready beensett1ed, and causes the digita1 payment between the payer P1 and payee P2 to be sett1edon1ine in the corresponding way as in Figure 10A. The computerized payment networkswitch NW deterrnines the payer identifier id_cust@pspl.nw representing the payer P1,the payee identifier id_merch @psp2.nw representing the payee P2, and the paymentamount Amount from the payment transaction data Transaction Data.

At 1074, the computerized payment network switch NW sends a debitinstruction to the first payment service provider PSP1 to cause a deduction of fundsfrom the payer account account_PI of the payer P1 at 1076, with confirmation beinggiven at 1078.

The computerized payment network switch NW moreover sends a creditinstruction at 1080 to the second payment service provider PSP2 to cause an addition offunds to the payee account account_P2 of the payee P2 at 1082, with confirmationbeing given at 1084.

The computerized payment network switch NW then provides respectivesett1ement responses 1088 and 1094 to the first and second payment service providersPSP1 and PSP2. The sett1ement responses wi11 be propagated to the payercommunication device PD1 and payee communication device PD2, as seen at 1090 (being an on1ine sett1ement comp1etion report) and 1096. 29 Multi-currency supportBeneficial embodiments of the digital payment system 1 has multi-currency support that alloWs the payer P1 to make a digital payment to the payee P2, even Whenthe payer' s P1 digital Wallet OW uses one currency and the payee P2 is only prepared toaccept payments in another currency.

Hence, in these beneficial embodiments of the digital payment system 1, thedigital Wallet DW of the payer communication device PD1 has a payer currency being abase currency for the balance of the digital Wallet DW as Well as for the payer accountacc0unt_PI of the payer P1 handled by the first payment service provider PSP1. Thepayer communication device PD1 is configured to keep an exchange rate list FXl inlocal storage, see data 902 and 1002 in Figures 9 and 10A. The payment amountAmount of the desired digital payment is defined in a payee currency, different from thepayer currency. The payee currency is a base currency of the payee communicationdevice PD2.

During offline settlement 110, the payer communication device PD1 isconfigured to determine Whether the payee currency is represented in the exchange ratelist FXl kept in local storage. See item 2 in box 922 in Figure 9. Upon successfuldetern1ination, the payer communication device PD1 is configured to establish a firstconverted amount by converting the payment amount Amount of the desired digitalpayment into the base currency of the digital Wallet DW using an exchange rate betWeenthe payee currency and the payer currency specified in the exchange rate list FXl keptin local storage.

The payer communication device PD1 is further configured to use the firstconverted amount for verifying that the current balance Balance of the digital WalletDW is sufficient for the payment amount Amount of the desired digital payment (seeitem 3 in box 922), and to use the first converted amount for updating the balanceBalance of the digital Wallet DW to reflect the payment amount Amount of the desireddigital payment by deducting the first converted amount from the current balance of thedigital Wallet DW (see item 4 in box 922). The payer communication device PD1 ismoreover configured to include the payment amount Amount of the desired digitalpayment, the payee currency and a timestamp in the generated payment transaction dataTransaction Data.

During online settlement 130, the computerized payment netWork sWitch NWis further configured, When causing the digital payment to be settled online betWeen the payer P1 and payee P2, to determine the payee currency and the timestamp from the payment transaction data Transaction Data, and include the deterrnined payee currencyand the timestamp in the debit instruction (or, in alternative embodiments, thesettlement instruction) sent to the first payment service provider PSP1. See 1024 inFigure 10A and 1074 in Figure 10B.

The first payment service provider PSP1 is configured to establish a secondconverted amount by converting the payment amount Amount of the desired digitalpayment into the base currency of the payer account acc0unt_PI of the payer P1 usingan exchange rate between the payee currency and the base currency applicable at amoment in time indicated by the timestamp, and deduct the second converted amountfrom the payer account accounLPl of the payer P1. See 1026 in Figure 10A and 1076in Figure 10B.

The first payment service provider PSP1 may be further configured todetermine an amount deviation between the first converted amount and secondconverted amount, see 1036 in Figure 10A and 1086 in Figure 10B. The determinedamount deviation may be included in the online settlement completion report 1040 sentto the payer communication device PD1. The payer communication device PD1 may beconfigured to receive the online settlement completion report 1040 sent by the firstpayment service provider PSP1, and notify the payer P1 (see 1042 in Figure 10A) of theamount deviation as included in the received online settlement completion report.

Figure 7 illustrates distribution of foreign exchange rates in one embodiment700 of the digital payment system 1 according to the present disclosure, suitable for usewith the multi-currency embodiments referred to above. The customer application 701and its data 702, the customer secure element 703 and its data 704, the merchantapplication 705 and its data 706, the data 707 of the first payment service providerPSP1, the data 708 of the second payment service provider PSP2, the data 709 of thepayment network switch NW and the data 710 of the certificate authority CA, may allbe substantially the same as has been described above for entities 601-610 inconjunction with Figure 6, entities 801-810 of Figure 8, entities 901-910 of Figure 9 orentities 1001-1010 of Figures 10A and 10B.

As can be seen at steps 720-736, the payer communication device PD1communicates with the first payment service provider PSP1 by wide area networkcommunication to retrieve current exchange rates ExchangeRatesI. The retrievedcurrent exchange rates ExchangeRatesI are used for the purpose of updating theexchange rate list FX1 in the payer communication device°s PD1 local storage. This functionality may, for instance, be performed upon request from the payer P1, according 31 to a schedule, When the first opportunity arises, in connection with online settlement130, or upon demand from the first payment service provider PSP1.

The currencies referred to in this document may be official monetarycurrencies like, for instance, SEK, EUR, USD, etc., digital currencies like CBDC(Central Bank Digital Currency) or crypto currencies (blockchain-based distributedledger technology), or combinations thereof. ln one aspect, the invention is considered to be particularly well suited forimplementing CBDC. Central banks in numerous countries are eXperimenting withdigital currency using “tokenized value instruments” that represent physical banknotesin digital form. The present invention, in contrast, uses “tokenized transactioninstruments”, which may be compared to banker°s cheques. Whereas a banknote is arepresentation of “money”, a banker°s cheque represents a “money transfer” betweentwo parties.

Thanks to the present invention, it can be foreseen that digitizing “moneytransfers” instead of “money” will simplify CBDC implementations tremendously, aswill not require any additional architectures. The “tokenized transaction instrument”approach suggested by the present Applicant in and by this document will provide allnecessary properties of physical cash; robustness, ease of use and preservation of thepayer°s integrity in relation to banks. To issue its fiat currency. the central bank maysimply deposit it into a centrally held bank account and invite commercial banks (likethe payment service provides PSP1, PSP2, ...) to access and distribute it by means of regular transactions on the existing digital rails.

Concluding remarksThe cloud-based computing resources as referred to in this document may for instance be implemented as one or more physical server computers or computersystems, or one or more distributed networks of computing resources.

The digital certificates referred to in this document may, for instance, be DER-encoded X.509-based certificates which comprise public cryptographic keys for therespective entities of the digital payment system 1, as described above.

When reference in this document is being made to a private cryptographic keywhich is associated with a particular digital certificate, this includes a case where theparticular digital certificate comprises a public cryptographic key, and where the private (secure) cryptographic key and the public cryptographic key together constitute a 32 cryptographic key pair as is generally known for asymmetric data encryptíon and decryptíon.

Claims

1. A digital payment system (1) enabling payment service providerinteroperability for ofﬂine digital payments between proXimate users, the systemcomprising: a computerized payment network switch (NW) having a payment networkswitch digital certificate (cert_pub_nw); a computerized first payment service provider (PSP1) handling a payer account(account_P1) of a payer (P1) and having a first payment service provider digitalcertificate (cert_pub_psp1) being verifiable with the payment network switch digitalcertificate (cert_pub_nw), a computerized second payment service provider (PSP2) handling a payeeaccount (account_P2) of a payee (P2); a payer communication device (PD1) for use by the payer (P1) and having apayer communication device digital certificate (cert_pub_cust, PC) being verifiable withthe first payment service provider digital certificate (cert_pub_psp1); and a payee communication device (PD2) for use by a payee (P2), wherein: the payer communication device (PD1), upon being in proXimity (10) of thepayee communication device (PD2), is configured for: 0 generating, for a desired digital payment of a payment amount (Amount)from the payer (P1) to the payee (P2), payment transaction data(Transaction Data) being signed with a private cryptographic key(priv_key_cust, SK) associated with the payer communication devicedigital certificate (cert_pub_cust, PC), wherein the payment transactiondata (Transaction Data) includes the payer communication devicedigital certificate (cert_pub_cust, PC), the first payment serviceprovider digital certificate (cert_pub_psp1), and the payment amount(Amount); and 0 communicating the payment transaction data (Transaction Data) to thepayee communication device (PD2) by short-range datacommunication; the payee communication device (PD2) is configured for: 0 receiving the payment transaction data (Transaction Data) from the payer communication device (PD1) by short-range data communication; 0 validating the payment transaction data (Transaction Data) to verify thepayer communication device°s (PD1) signature of the paymenttransaction data (Transaction Data) by means of the digital Certificate(cert_pub_cust, PC) of the payer communication device (PD1); 0 upon successful validation, accepting the digital payment and bufferingthe payment transaction data (Transaction Data) in local storage, thedigital payment thereby being settled ofﬂine between the payer (P1)and payee (P2); and 0 subsequently communicating the buffered payment transaction data(Transaction Data) to the second payment service provider (PSP2) bywide area network communication; the computerized payment network switch (NW) is configured for: 0 receiving the payment transaction data (Transaction Data) from thesecond payment service provider (PSP2); 0 validating the payment transaction data (Transaction Data) to verify thepayer communication device°s (PD1) signature of the paymenttransaction data (Transaction Data) by means of the digital certificate(cert_pub_cust, PC) of the payer communication device (PD1); 0 upon successful validation, causing the digital payment to be settledonline between the payer (P1) and payee (P2) by: o deterrnining from the payment transaction data (TransactionData) a payer identifier (id_cust@pspl.nw) representing thepayer (Pl), a payee identifier (id_merch@psp2.nw) representingthe payee (P2), and the payment amount (Amount); and o communicating at least with the first payment service provider(PSP1) to cause a deduction of funds from the payer account(account_Pl) of the payer (P1) and an addition of funds to thepayee account (account_P2) of the payee (P2), the deduction and addition corresponding to the payment amount (Amount).

2. The digital payment system (1) according to claim 1, wherein each of thepayee communication device (PD2) and the computerized payment network switch(NW) is configured for validating the payment transaction data (Transaction Data) toverify the payer communication device°s (PD1) signature of the payment transaction data (Transaction Data) by: 0 verifying the first payment service provider digital certificate(cert_pub_psp1) by means of the payment network switch digitalcertificate (cert_pub_nw); 0 verifying the payer communication device digital certificate(cert_pub_cust, PC) by means of the verified first payment serviceprovider digital certificate (cert_pub_psp1); and 0 verifying the payer communication device°s (PD1) signature of thepayment transaction data (Transaction Data) by means of the verified payer communication device digital certificate (cert_pub_cust, PC).

3. The digital payment system (1) according to claim 1 or 2, wherein thecomputerized payment network switch (NW) is configured for determining the payeridentifier (id_cust@ psp1.nw) representing the payer (P1) from the payercommunication device digital certificate (cert_pub_cust, PC) in the payment transaction data (Transaction Data).

4. The digital payment system (1) according to any preceding claim, whereinthe computerized payment network switch (NW) is configured for causing the digitalpayment to be settled online between the payer (P1) and payee (P2) by: 0 sending a debit instruction to the first payment service provider (PSP1) tocause a deduction of funds from the payer account (account_Pl) of thepayer (Pl), the deduction corresponding to the payment amount(Amount); and 0 sending a credit instruction to the second payment service provider(PSP2) to cause an addition of funds to the payee account (account_P2)of the payee (P2), the addition corresponding to the payment amount(Amount).

5. The digital payment system (1) according to any of claims 1-3,wherein the computerized payment network switch (NW) is configured forcausing the digital payment to be settled online between the payer (P1) and payee (P2)by:0 sending a settlement instruction to the first payment service provider (PSP1), the settlement instruction containing the payer identifier (id_cust@psp1.nw), the payee identifier (id_merch@psp2.nw) and thepayment amount (Amount); andwherein the first payment service provider (PSP1) is configured for: 0 receiving the sett1ement instruction; 0 making a deduction of funds from the payer account (account_P1) of thepayer (P1), the deduction corresponding to the payment amount(Amount); and 0 sending a credit instruction to the second payment service provider(PSP2) to cause an addition of funds to the payee account (account_P2)of the payee (P2), the addition corresponding to the payment amount(Amount).

6. The digital payment system (1) according to any preceding c1aim, wherein: the computerized second payment service provider (PSP2) has a secondpayment service provider digita1 certificate (cert_pub_psp2) being verifiab1e with thepayment network switch digita1 certificate (cert_pub_nw); the payee communication device (PD2) has a payee communication devicedigita1 certificate (cert_pub_merch, PC2) being verifiab1e with the second paymentservice provider digita1 certificate (cert_pub_psp2); and the payee communication device digita1 certificate (cert_pub_merch, PC2) isinc1uded in the payment transaction data (Transaction Data) being signed by the payer communication device (PD1).

7. The digita1 payment system (1) according to c1aim 6, wherein thecomputerized payment network switch (NW) is configured for determining the payeeidentifier (id_merch@psp2.nw) representing the payee (P2) from the payeecommunication device digita1 certificate (cert_pub_merch, PC2) in the payment transaction data (Transaction Data).

8. The digita1 payment system (1) according to any preceding c1aim,wherein the payer communication device (PD1) is configured for:0 buffering the generated payment transaction data (Transaction Data) in 1oca1 storage; and 0 subsequently communicating the buffered payment transaction data(Transaction Data) to the first payment service provider (PSP1) by widearea network communication; and wherein the computerized payment network switch (NW) is configured for: 0 receiving the payment transaction data (Transaction Data) from the firstpayment service provider (PSP1); 0 validating the payment transaction data (Transaction Data) to verify thepayer communication device°s (PD1) signature of the paymenttransaction data (Transaction Data) by means of the digital certificate(cert_pub_cust, PC) of the payer communication device (PD1); 0 upon successful validation and unless the digital payment has alreadybeen settled online, causing the digital payment to be settled onlinebetween the payer (P1) and payee (P2) by: o deterrnining from the payment transaction data (TransactionData) a payer identifier (id_cust@pspl.nw) representing thepayer (Pl), a payee identifier (id_merch@psp2.nw) representingthe payee (P2), and the payment amount (Amount); and o communicating at least with the first payment service provider(PSP1) to cause a deduction of funds from the payer account(account_Pl) of the payer (P1) and an addition of funds to thepayee account (account_P2) of the payee (P2), the deduction and addition corresponding to the payment amount (Amount).

9. The digital payment system (1) according to any preceding claim, wherein the first payment service provider (PSP1) is configured, upon deduction of the fundsfrom the payer account (account_Pl) of the payer (P1), to send an online settlementcompletion report to the payer communication device (PD1), the online settlement completion report indicating the deducted funds.

10. The digital payment system (1) according to any preceding claim, wherein the payer communication device (PD1) comprises a digital wallet (DW) stored in localstorage (TEE; 304), preferably in a hardware-based or software-based trusted eXecutionenvironment (TEE) such as a Secure Element, and wherein the payer communication device (PD1) is configured to: verify that a current balance (Balance) of the digital Wallet (DW) is sufficientfor the payment amount (Amount) of the desired digital payment; and, upon successfulVerification: update the balance (Balance) of the digital Wallet (DW) to reflect the payment amount (Amount) of the desired digital payment.

11. The digital payment system (1) according to claim 10,Wherein the payer communication device (PD1) is configured to: o generate an ofﬂine Wallet replenishment request comprising a requestedreplenishment amount and the payer communication device digitalcertificate (cert_pub_cust, PC); o sign the ofﬂine Wallet replenishment request using the privatecryptographic key (priv_key_cust, SK) associated With the payercommunication device digital certificate (cert_pub_cust, PC); and o send the ofﬂine Wallet replenishment request to the first payment serviceprovider (PSPl); Wherein the first payment service provider (PSP1) is configured to: o validate the ofﬂine Wallet replenishment request by: I verifying the payer communication device digital certificate(cert_pub_cust, PC) by means of the verified first paymentservice provider digital certificate (cert_pub_psp1); and I verifying the payer communication device°s (PD1) signature ofthe payment transaction data (Transaction Data) by means of theverified payer communication device digital certificate(cert_pub_cust, PC); and o upon successful validation: I reserve or deduct a granted replenishment amount in or from thepayer account (account_Pl) of the payer (Pl), the grantedreplenishment amount being equal to or less than the requestedreplenishment amount; and I send an ofﬂine Wallet replenishment response to the payercommunication device (PD1), the ofﬂine Wallet replenishmentresponse comprising the granted replenishment amount and being signed by a private cryptographic key (priv_key_psp1) associated With the first payment service provider digital certificate(cert_pub_psp1); andWherein the payer communication device (PD1) is further configured to: o receive the ofﬂine Wallet replenishment response from the first paymentservice provider (PSP 1); o validate the ofﬂine Wallet replenishment request by verifying the firstpayment service provider°s (PSP1) signature of the ofﬂine Walletreplenishment response by means of the first payment service providerdigital certificate (cert_pub_psp1); and o upon successful validation, update the balance (Balance) of the digital Wallet (DW) to reﬂect the granted replenishment amount.

12. The digital payment system (1) according to claim 10 or 11, Wherein the payer communication device (PD1) is configured to verify that thecurrent balance (Balance) of the digital Wallet (DW) is sufficient for the paymentamount (Amount) of the desired digital payment by verifying that the payment amount(Amount) does not eXceed the current balance (Balance) of the digital Wallet (DW); and Wherein the payer communication device (PD1) is configured to update thebalance (Balance) of the digital Wallet (DW) to reﬂect the payment amount (Amount) ofthe desired digital payment by deducting the payment amount (Amount) from thecurrent balance of the digital Wallet (DW).

13. The digital payment system (1) according to claim 10 or 11, the digitalWallet (DW) of the payer communication device (PD1) having a payer currency being abase currency for the balance of the digital Wallet (DW) and the payer account(account_P1) of the payer (P1) handled by the first payment service provider (PSP1),Wherein: the payer communication device (PD1) is configured to keep an exchange ratelist (FXl) in local storage; the payment amount (Amount) of the desired digital payment is defined in apayee currency, different from the payer currency, the payee currency being a basecurrency of the payee communication device (PD2); and the payer communication device (PD1) is configured to: o determine Whether the payee currency is represented in the exchange ratelist (FXl) kept in local storage; and P116080059 o upon successful detern1ination: o establish a first converted amount by converting the paymentamount (Amount) of the desired digital payment into the basecurrency of the digital Wallet (DW) using an exchange ratebetween the payee currency and the payer currency specified inthe exchange rate list (FXl) kept in local storage; o use the first converted amount for verifying that the currentbalance (Balance) of the digital Wallet (DW) is sufficient for thepayment amount (Amount) of the desired digital payment; o use the first converted amount for updating the balance(Balance) of the digital Wallet (DW) to reﬂect the paymentamount (Amount) of the desired digital payment by deductingthe first converted amount from the current balance of thedigital Wallet (DW); and o include the payment amount (Amount) of the desired digitalpayment, the payee currency and a timestamp in the generated payment transaction data (Transaction Data).

14. The digital payment system (1) according to claim 13,Wherein the computerized payment netWork sWitch (NW) is further configured,When causing the digital payment to be settled online betWeen the payer (P1) and payee(P2), to:o determine the payee currency and the timestamp from the paymenttransaction data (Transaction Data); ando include the detern1ined payee currency and the timestamp in the debitinstruction or settlement instruction sent to the first payment serviceprovider (PSPl); andWherein the first payment service provider (PSP1) is configured to:o establish a second converted amount by converting the payment amount(Amount) of the desired digital payment into the base currency of thepayer account (account_Pl) of the payer (P1) using an exchange ratebetWeen the payee currency and the base currency applicable at amoment in time indicated by the timestamp; ando deduct the second converted amount from the payer account(account_Pl) of the payer (P1).

15. The digital payment system (1) according to c1aim 9 and 14,wherein the first payment service provider (PSP1) is further configured to:o determine an amount deviation between the first converted amount andsecond converted amount; ando inc1ude the deterrnined amount deviation in the on1ine sett1ement comp1etion report sent to the payer communication device (PD1).

16. The digital payment system (1) according to c1aim 15, wherein the payercommunication device (PD1) is configured to: receive the on1ine sett1ement comp1etion report sent by the first paymentservice provider (PSP1); and notify the payer (P1) of the amount deviation as inc1uded in the received on1ine sett1ement comp1etion report.

17. The digita1 payment system (1) according to any preceding c1aim, furthercomprising a computerized certificate authority (CA) having a certificate authoritydigita1 certificate (cert_pub_ca), the payment network switch digita1 certificate(cert_pub_nw) being verifiab1e with the certificate authority digita1 certificate(cert_pub_ca) .

18. A computerized method (100) of performing a digita1 payment of apayment amount (Amount) between a payer (P1) and a payee (P2), the payer (P1) beingprovided with a payer communication device (PD1) and being associated with acomputerized first payment service provider (PSP1) that hand1es a payer account(account_P1) of the payer (P1), the payee (P2) being provided with a payeecommunication device (PD2) and being associated with a computerized second paymentservice provider (PSP2) that hand1es a payee account (account_P2) of the payee (P2),the method invo1ving: an ofﬂine sett1ement stage (110) during which: the payer communication device (PD1) and payee communication device(PD2) communicate (112) by short-range data communication to generate paymenttransaction data (Transaction Data), the payment transaction data (Transaction Data) being digita11y signed (114) by the payer communication device (PD1) and comprising the payment amount (Amount) as well as digital certificates (cert_pub_cust, PC;cert_pub_psp1) of the payer communication device (PD1) and the first payment serviceprovider (PSP1), the generated payment transaction data (Transaction Data) beingvalidated (116) by the payee communication device (PD2) to verify the payercommunication device°s (PD1) signature of the payment transaction data (TransactionData) by means of the digital certificate (cert_pub_cust, PC) of the payercommunication device (PD1); and an online settlement stage (130) during which: the payee communication device (PD2) communicates (132) the paymenttransaction data (Transaction Data) to the second payment service provider (PSP2) bywide area network communication; the second payment service provider (PSP2) communicates (134) the paymenttransaction data (Transaction Data) to a computerized payment network switch (NW); the computerized payment network switch (NW) validates (136) the paymenttransaction data (Transaction Data) to verify the payer communication device°s (PD1)signature of the payment transaction data (Transaction Data) by means of the digitalcertificate (cert_pub_cust, PC) of the payer communication device (PD1); and the computerized payment network switch (NW), upon successful validation (138): o determines (140) from the payment transaction data (Transaction Data) apayer identifier (id_cust@psp1.nw) representing the payer (P1), a payeeidentifier (id_merch@psp2.nw) representing the payee (P2), and thepayment amount (Amount); and o communicating (142) at least with the first payment service provider(PSP1) to cause a deduction of funds from the payer account(account_P1) of the payer (P1) and an addition of funds to the payeeaccount (account_P2) of the payee (P2), the deduction and addition corresponding to the payment amount (Amount).

19. The computerized method (100) according to claim 18, further comprisingany or all of the functionality performed by the payment network switch (NW), the firstpayment service provider (PSP1), the second payment service provider (PSP2), thepayer communication device (PD1) and the payee communication device (PD2) in the digital payment system (1) as defined by any of claims 1-17.

20. A cloud-based computing resource configured to perform the functionalityof the payment network switch (NW) in the digital payment system (1) as defined by any of claims 1-17.

21. A cloud-based computing resource configured to perform the functionalityof the first payment service provider (PSP1) in the digital payment system (1) asdefined by any of claims 1-17.

22. A cloud-based computing resource configured to perform the functionalityof the second payment service provider (PSP2) in the digital payment system (1) asdefined by any of claims 1-17.

23. A communication device (300) configured to perform the functionality ofthe payer communication device (PD1) in the digital payment system (1) as defined by any of claims 1-17.

24. The communication device (300) as defined in claim 23, wherein thecommunication device is one of the following: a mobile communication device; amobile phone; a smart phone; a tablet computer; a personal digital assistant; a portablecomputer; smart glasses; a smart wearable; a smart watch; a smart bracelet; a smart card; and a smart chip.

25. A communication device (400) configured to perform the functionality ofthe payee communication device (PD2) in the digital payment system (1) as defined by any of claims 1-17.

26. The communication device (4) as defined in claim 25, wherein thecommunication device is one of the following: a mobile communication device; amobile phone; a smart phone; a tablet computer; a personal digital assistant; a portablecomputer; smart glasses; a smart watch; a smart card; a smart bracelet; a smartwearable; a payment terminal, a service terminal; a point-of-sales terminal; a checkoutcounter; a delivery pickup point; a vending machine; a ticket machine; a dispensing machine; and an access control system.

27. A computer program product comprising computer code for performing thefunctionality of the payment network switch (NW) in the method according to any of c1aims 18- 19 when the computer program code is eXecuted by a processing device.

28. A computer program product comprising computer code for performing thefunctiona1ity of the first payment service provider (PSP1) in the method according toany of c1aims 18-19 when the computer program code is eXecuted by a processing device.

29. A computer program product comprising computer code for performing thefunctiona1ity of the second payment service provider (PSP2) in the method according toany of c1aims 18-19 when the computer program code is eXecuted by a processing device.

30. A computer program product comprising computer code for performing thefunctiona1ity of the payer communication device (PD1) in the method according to any of c1aims 18-19 when the computer program code is eXecuted by a processing device.

31. A computer program product comprising computer code for performing thefunctiona1ity of the payee communication device (PD2) in the method according to any of c1aims 18-19 when the computer program code is eXecuted by a processing device.

32. A computer readab1e medium having stored thereon a computer programcomprising computer program code for performing the functiona1ity of the paymentnetwork switch (NW) in the method according to any of c1aims 18-19 when the computer program code is eXecuted by a processing device.

33. A computer readab1e medium having stored thereon a computer programcomprising computer program code for performing the functiona1ity of the first paymentservice provider (PSP1) in the method according to any of c1aims 18-19 when the computer program code is eXecuted by a processing device.

34. A computer readab1e medium having stored thereon a computer program comprising computer program code for performing the functiona1ity of the second payment service provider (PSPZ) in the method according to any of c1aims 18-19 When the computer program code is executed by a processing device.

35. A computer readab1e medium having stored thereon a computer programcomprising computer program code for performing the functionality of the payercommunication device (PD2) in the method according to any of c1aims 18-19 When the computer program code is eXecuted by a processing device.

36. A computer readab1e medium having stored thereon a computer programcomprising computer program code for performing the functionality of the payeecommunication device (PD2) in the method according to any of c1aims 18-19 When the computer program code is eXecuted by a processing device.