WO2022216216A1

WO2022216216A1 - Method and system for offline electronic card payments

Info

Publication number: WO2022216216A1
Application number: PCT/SE2022/050356
Authority: WO
Inventors: Joachim Samuelsson; Paul CRONHOLM
Original assignee: Crunchfish Digital Cash Ab
Priority date: 2021-04-08
Filing date: 2022-04-08
Publication date: 2022-10-13

Abstract

A method of performing an offline electronic payment of a type which involves a payer device (PD) and a point-of-sales device (POS) is presented. The payer device is a holder of a payment card (PC) issued by a card issuer (CI). The point-of-sales device is operative to receive (22) signed transaction data (STD) representing approval of the electronic payment, in an amount to be paid, from the payer device (PD) by local point-to-point communication (LP2PC) during an offline clearing procedure (OCP). The point-of-sales device is further operative to request (30) online settlement (OS) of the electronic payment in a payment service network (PSN) to cause transfer (46) of funds from an issuer account (IA) associated with the payer device (PD) to an acquirer account (AA) associated with the point-of-sales device (POS). The payer device (PD) comprises a local digital wallet (LDW) which defines a balance (BAL) available for offline payments, and a risk limit profile (RL) that represents constraints for offline electronic payments performable by the payer device (PD). During the offline clearing procedure (OCP), the payer device (PD) assesses (52) whether the amount to be paid complies with the balance (BAL) and the risk limit profile (RL) of the local digital wallet (LDW). In case of compliance, the payer device (PD) provides (56) the signed transaction data (STD) to the point-of-sales device (POS), thereby permitting completion of the offline clearing procedure (OCP). In case of non-compliance, the payer device (PD) refrains (58) from providing the signed transaction data (STD) to the point-of-sales device (POS), thereby preventing completion of the offline clearing procedure (OCP).

Description

METHOD AND SYSTEM FOR OFFLINE ELECTRONIC CARD PAYMENTS

TECHNICAL FIELD

The present invention relates to the field of electronic (or digital) payments of the type commonly referred to as credit card payments or, simply, card payments. More particularly, the present invention relates to a method of performing an offline electronic payment of such a type, as well as a system for offline electronic payments, with technical provisions for risk management. Furthermore, the present invention relates to an associated electronic device for use in such a system, as well as an associated computer program product and an associated non-volatile computer readable medium.

BACKGROUND

Card payments are of course immensely popular in everyday life. EMV (Europay, Mastercard and VISA) payments is a well-known example of card payments. A common situation for card payments is when a payer (such as a customer) and a payee (such as a merchant) are physically proximate to each other, i.e. appear or meet at a physical place such as, for instance, a shop, restaurant, theatre, sport arena, workshop, or basically any place where people can meet to perform a card payment. To carry out the card payment, the payer uses a payer device, such as a smart card or a mobile device, in local communication with a point-of-sales device, such as a point-of-sales terminal. In turn, the point-of-sales device communicates with a remote payment service network to verify and settle the card payment. The verification by the remote payment service network is important: as with any data application, data security and integrity is crucial in order to avoid fraud and other malicious use. There are however situations in which the point-of-sales device is presently incapable of accessing the payment service network. This calls for support for offline electronic payments which do not require momentary contact with the payment service network, but which nevertheless has technical provisions for fraud prevention. Figure 1 illustrates a typical architecture of a prior art system for handling offline electronic card payments in such situations. The system comprises a payer device PD configured to act as a holder of a payment card PC issued by a computerized card issuer Cl. The payer device PD may, for instance, be a smart card or a mobile device. The payment card PC is an electronic entity which is embodied physically by the payer device PD, as can be seen by the association 10 in Figure 1. The payment card PC is associated 12 with an issuer account IA belonging to a user U1 of the payer device PD and being controlled by the computerized card issuer CL To this end, the payment card PC may be represented by a permanent account number, PAN.

The system in Figure 1 further comprises a point-of-sales device POS configured to receive 22 signed transaction data STD representing approval of the electronic payment, in an amount to be paid, from the payer device PD by local point- to-point communication LP2PC, such as NFC, during an offline clearing procedure OCP. The point-of-sales device POS is further configured to request 30 online settlement OS of the electronic payment in a payment service network PSN to cause transfer 46 of funds from the issuer account IA associated with the payer device PD to an acquirer account AA associated with the point-of-sales device POS. The request 30 is made by wide area network communication and conveys a transaction block TB which includes the signed transaction data STD. The online settlement OS involves the computerized card issuer Cl, a computerized payment acquirer PA and a computerized payment rail PR, which for instance may be an EMV payment rail. The computerized payment acquirer PA controls or otherwise administers the acquirer account A A.

As can be seen in Figure 1, the offline clearing procedure OCP comprises a plurality of steps 20 that precede the generation of the signed transaction data STD by the payer device PD, as received at 22 by the point-of-sales device POS. These steps typically involve one or more of the following: agreeing upon a payment application (or payment scheme) to be used for the electronic payment, exchanging payment application data, verifying card expiry date etc., authorizing payment by the user U1 in the form of a PIN or biometric sample, etc. Because of the offline nature of the electronic payment, the point-of-sales device POS (and its user U2) cannot verify the payment by way of wide area network communication with the payment service network PSN at that stage. This poses a risk to the payee. To mitigate this risk, in one of the steps 20 of the offline clearing procedure OCP, the point-of-sales device POS makes a risk assessment of the electronic payment to be performed, based upon the local payment data available. Typically, the risk assessment involves comparing the payment amount to a floor limit, and declining the payment if the floor limit is exceeded. A different kind of electronic payments are those which are made by use of a digital wallet in the payer device. Currently, from a risk management perspective, those kind of electronic payments are technically incompatible with offline electronic card payments of the kind described above.

The present inventors have realized that there is room for improvements in this regard. The present inventors have conceived and developed novel and inventive approaches to offline electronic card payments, as will be explained in the remainder of this document. SUMMARY

In line with the observations above, the present inventors have hence made valuable technical insights. These insights will be presented as inventive aspects below as well as in the detailed description section, the claims and the drawings. The list of inventive aspects is not to be seen as exhaustive but rather a summary of particularly beneficial inventive aspects.

In a nutshell, the present invention presents a risk management improvement by making a risk assessment at the payer side rather than the payee side, as in the prior art. Hence, a decision not to proceed with an ongoing offline electronic payment will therefore be made by the payer device based on this risk assessment. This will relieve the payee of the conventional risk of accepting an offline electronic card payment. In fact, in some embodiments the point-of-sales device may even dispense with its own risk assessment at the payee side. At the same time, the present invention provides a technical solution to the incompatibility problem described in the background section above.

The inventive aspects will be exemplified by reference to disclosed embodiments which are shown in the enclosed drawings. The inventive aspects are not as such limited to the disclosed embodiments, as the skilled reader will understand.

The term “payment” is, as such, to be construed broadly to embrace any kind of transfer of economic value in electronic (digital) form between people and entities of any types, roles etc.

A first inventive aspect is a method of performing an offline electronic payment of a type which involves a payer device and a point-of-sales device. The payer device acts as a holder of a payment card issued by a card issuer. The point-of-sales device acts to receive signed transaction data representing approval of the electronic payment, in an amount to be paid, from the payer device by local point-to-point communication during an offline clearing procedure. The point-of-sales device further acts to request online settlement of the electronic payment in a payment service network to cause transfer of funds from an issuer account associated with the payer device to an acquirer account associated with the point-of-sales device. The payer device comprises a local digital wallet, the local digital wallet defining a balance available for offline payments, and a risk limit profile representing constraints for offline electronic payments performable by the payer device.

In the method, during the offline clearing procedure, the payer device assesses whether the amount to be paid complies with the balance and the risk limit profile of the local digital wallet. In case of compliance, the payer device provides the signed transaction data to the point-of-sales device, thereby permitting completion of the offline clearing procedure. On the other hand, in case of non-compliance, the payer device refrains from providing the signed transaction data to the point-of-sales device, thereby preventing completion of the offline clearing procedure.

A second inventive aspect is a system for offline electronic payments, comprising a payer device configured to act as a holder of a payment card issued by a card issuer, and a point-of-sales device configured to receive signed transaction data representing approval of an electronic payment, in an amount to be paid, from the payer device by local point-to-point communication during an offline clearing procedure and to request online settlement of the electronic payment in a payment service network to cause transfer of funds from an issuer account associated with the payer device to an acquirer account associated with the point-of-sales device. The payer device comprises a local digital wallet, the local digital wallet defining a balance available for offline payments, and a risk limit profile representing constraints for offline electronic payments performable by the payer device. In this system, the payer device is configured for, during the offline clearing procedure, assessing whether the amount to be paid complies with the balance and the risk limit profile of the local digital wallet. The payer device is configured for, in case of compliance, providing the signed transaction data to the point-of-sales device, thereby permitting completion of the offline clearing procedure, and, in case of non-compliance, refraining from providing the signed transaction data to the point-of-sales device, thereby preventing completion of the offline clearing procedure.

A third inventive aspect is an electronic device which is configured for performing the functionality of the payer device in the method according to the first aspect or the system according to the second aspect. A fourth inventive aspect is a computer program product comprising computer program code for performing the functionality of the payer device in the method according the first inventive aspect when the computer program code is executed by a processing device.

A fifth inventive aspect is a non-volatile computer readable medium having stored thereon a computer program comprising computer program code for performing the functionality of the payee communication device in the method according the first inventive aspect when the computer program code is executed by a processing device.

Expressions like “[entity] is configured for... [performing activity]” or “[entity] is configured to ... [perform activity]” will include typical cases where a computerized entity (having one or more controllers, processing units, programmable circuitry, 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 will appear from the following detailed disclosure as well as from the claims and the drawings. Generally, all terms used herein are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a/an/the [element, device, component, means, step, etc.]" are to 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 any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure l is a schematic block diagram of a prior art system for handling offline electronic card payments.

Figure 2 is a schematic block diagram of a system for offline electronic payments, the drawing also depicting a schematic flowchart diagram illustrating a method of performing an offline electronic payment, generally in accordance with preferred embodiments of the present invention.

Figure 3 is a schematic block diagram of one embodiment of an electronic device capable of acting as a payer device in the system of Figure 2. Figure 4 is a schematic block diagram of another embodiment of an electronic device capable of acting as a payer device in the system of Figure 2.

Figure 5A is a detailed flowchart and signal diagram illustrating how to increase the balance of a local digital wallet in the payer device according to one embodiment. Figure 5B is a detailed flowchart and signal diagram illustrating how to increase the balance of a local digital wallet in the payer device according to another embodiment.

Figure 6 is a detailed flowchart and signal diagram illustrating how to perform an offline clearing procedure between the payer device and a point-of-sales device according to one embodiment.

Figure 7 is a detailed flowchart and signal diagram illustrating how to request and perform online settlement in a payment service network according to one embodiment.

Figure 8 is a schematic illustration of a computer-readable medium in one exemplary embodiment, capable of storing a computer program product. DETAILED DESCRIPTION OF EMBODIMENTS

Embodiments of the invention will now be described with reference to the accompanying drawings. The invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

The terminology used in the detailed description of the particular embodiments illustrated in the accompanying drawings is not intended to be limiting of the invention. In the drawings, like reference signs refer to like elements. Reference is now made to Figure 2, which illustrates an improvement pursuant to the invention over the conventional system in Figure 1. Identical reference signs represent identical or at least similar elements in these two drawings.

Figure 2 discloses a system 1 for offline electronic payments. The system 1 comprises a payer device PD configured to act as a holder of a payment card PC which is issued by a card issuer Cl. The system 1 moreover comprises a point-of-sales device POS which is configured to receive 22 signed transaction data STD that represent approval of an electronic payment, in an amount to be paid, from the payer device PD by local point-to-point communication LP2PC during an offline clearing procedure OCP. The point-of-sales device POS is further configured to request 30 online settlement OS of the electronic payment in a payment service network PSN to cause transfer 46 of funds from an issuer account IA associated with the payer device PD to an acquirer account AA associated with the point-of-sales device POS.

Unlike the prior art system in Figure 1, in the system 1 of Figure 2, the payer device PD comprises a local digital wallet LDW. The local digital wallet defines a balance BAL available for offline payments, and a risk limit profile RL representing constraints for offline electronic payments performable by the payer device PD.

During the offline clearing procedure OCP, as seen at 50, the payer device PD is configured for assessing 52 whether the amount to be paid complies with the balance BAL and the risk limit profile RL of the local digital wallet LDW. In case of compliance (see Yes branch at 54 in Figure 2), the payer device PD permits completion of the offline clearing procedure OCP by providing 56 the signed transaction data STD to the point-of-sales device POS (i.e. in the same way as it was done at 22 in Figure 1). The payer device PD will also decrease the balance BAL of the local digital wallet LDW with the amount to the paid. However, in case of non-compliance (see No branch at 54 in Figure 2), the payer device PD refrains 58 from providing the signed transaction data STD to the point-of-sales device POS, thereby preventing completion of the offline clearing procedure OCP. In this latter case, therefore, the payer device PD in effect aborts the ongoing offline clearing procedure OCP, and the offline electronic payment will not be performed (i.e., no STD will be included in the transaction block TB). The decision not to proceed with the offline electronic payment will therefore be based on a risk assessment being made at the payer side rather than the payee side, as in Figure 1. This will relieve the payee of the conventional risk of accepting an offline electronic card payment. In fact, the point-of-sales device POS may even dispense with the aforementioned risk assessment at the payee side.

As is clear from the above, Figure 2 also discloses a computerized method of performing an offline electronic payment of a type which involves a payer device PD and a point-of-sales device POS, the payer device acting as a holder of a payment card PC issued by a card issuer Cl and the point-of-sales device acting to receive 22 signed transaction data STD representing approval of the electronic payment, in an amount to be paid, from the payer device PD by local point-to-point communication LP2PC during an offline clearing procedure OCP. The point-of-sales device further acts to request 30 (by wide area network communication LP2PC) online settlement OS of the electronic payment in a payment service network PSN to cause transfer 46 of funds from an issuer account IA associated with the payer device PD to an acquirer account AA associated with the point-of-sales device POS. It is recalled that the payer device PD comprises a local digital wallet LDW, the local digital wallet defining a balance B AL available for offline payments, and a risk limit profile RL representing constraints for offline electronic payments performable by the payer device PD.

The method disclosed in Figure 2 further involves, during the offline clearing procedure OCP, the payer device PD assessing 52 whether the amount to be paid complies with the balance BAL and the risk limit profile RL of the local digital wallet LDW. The method then involves, in case of compliance, the payer device PD providing 56 (22) the signed transaction data STD to the point-of-sales device POS, thereby permitting completion of the offline clearing procedure OCP, and, in case of non- compliance, the payer device PD refraining 58 from providing the signed transaction data STD to the point-of-sales device POS, thereby preventing completion of the offline clearing procedure OCP.

The offline electronic payment may typically be an EMV - Europay,

Mastercard and VISA - payment. In some embodiments, the payer device PD is a smart card SC. One such embodiment is shown in Figure 4 and will be described in more detail later on in this document.

In other embodiments, the payer device PD is a mobile device, such as a mobile communication device, a mobile phone, a smart phone, a tablet computer, a personal digital assistant, a portable computer, smart glasses, a smart card or a smart wearable (e.g. smart watch or smart bracelet). The mobile device may, for instance, be configured to act as the holder of the payment card PC by way of host card emulation, HCE, functionality. One such embodiment of such a mobile device is shown in Figure 3 and will be described in more detail later on in this document.

In some embodiments, the point-of-sales device POS is a point-of-sales terminal, such as a card payment terminal, a service terminal, an electronic checkout counter, an electronic delivery pickup point, a vending machine, a ticket machine, a dispensing machine, or an access control system. In other embodiments, the point-of- sales device POS is a mobile device, such as a mobile communication device, a mobile phone, a smart phone, a tablet computer, a personal digital assistant, a portable computer, smart glasses, a smart card or a smart wearable (e.g. smart watch or smart bracelet). The mobile device may, for instance, be configured to operate by way of point-of sales terminal emulation functionality. In advantageous embodiments, the assessing 52 by the payer device PD during the offline clearing procedure OCP of whether the amount to be paid complies with the balance BAL and the risk limit profile RL of the local digital wallet LDW in effect eliminates the need for a risk assessment of the offline electronic payment by the point- of-sales device POS. The risk limit profile RL may, for instance, define one or more of the following: i) A total spending limit for offline electronic payments that have not yet been settled online ii) A maximum payment amount for each offline electronic payment iii) A maximum accumulated payment amount for offline electronic payments performable until the point-of-sales device POS requests 30 online settlement OS of the electronic payment in the payment service network PSN. iv) A maximum accumulated payment amount for offline electronic payments performable during a certain time (such as a day, week, month, etc.) v) a maximum number of offline electronic payments performable until the point-of-sales device POS requests 30 online settlement OS of the electronic payment in the payment service network PSN. vi) a maximum number of offline electronic payments performable during a certain time (such as a day, week, month, etc.) vii) A definition of payment receivers that a user U1 of the payer device PD is allowed to make offline electronic payments to. viii) A definition of payment receivers that the user U1 of the payer device PD is not allowed to make offline electronic payments to.

In some embodiments, during the offline clearing procedure OCP, the payer device PD receives the amount to be paid as well as a currency thereof from the point- of-sales device. Here, in assessing 52 whether the amount to be paid complies with the balance BAL and the risk limit profile RL of the local digital wallet LDW, the payer device PD verifies as a further requisite for compliance that the currency of the amount to be paid is a currency supported by the payer device PD. In embodiments without such currency handling, the payer device PD may receive only the amount to be paid from the point-of-sales device POS during the offline clearing procedure OCP. In some embodiments, the payer device PD communicates with the computerized card issuer Cl by wide area network communication to request an increase of the balance BAL of the local digital wallet LDW. Some implementation examples of which can be seen in Figures 5A and 5B, where the computerized card issuer Cl is a payment service provider, PSP. The card issuer CI/PSP will determine a granted increase being equal to or less than the requested increase, cause a transfer of funds corresponding to the granted increase from an account associated with a user U1 of the payer device PD to the issuer account IA, and communicate, by wide area network communication, the granted increase to the payer device PD. The payer device PD will receive the granted increase (by wide area network communication) and update the balance BAL of the local digital wallet LDW accordingly.

Advantageously, in this connection the card issuer CI/PSP determines one or more risk parameters of the risk limit profile RL and communicates the determined one or more risk parameters together with the granted increase to the payer device PD by wide area network communication. The payer device PD will receive, by wide area network communication, the one or more risk parameters with the granted increase and update the risk limit profile RL of the local digital wallet LDW accordingly.

In some embodiments, the local point-to-point communication LP2PC involves Near Field Communication, NFC. Hence, the local point-to-point communication LP2PC as referred to in this document may, for instance, be in accordance or compliance with the requirements of an NFC Forum Tag or of another NFC Forum

Device, or in accordance or compliance with ISO/IEC 14443 Type A standard, ISO/IEC 14443 Type B standard, ISO/IEC 15693 standard, ISO/IEC 18092 standard or JIS-X 6319-4 standard, without limitation.

Alternatively, the local point-to-point communication LP2PC may involve serial communication via electric contact between the payer device and the point-of- sales device. This may particularly be the case when the payer device is a (physical) smart card.

Alternatively, the local point-to-point communication LP2PC may involve short-range wireless data communication. This may particularly be the case when the payer device is a mobile device. As used in this document, the term “short-range data communication” includes any form of proximity-based device-to-device communi cation, unidirectional or bidirectional. This includes radio-based short-range wireless data communication such as, for instance, Bluetooth, BLE (Bluetooth Low Energy), RFID, WLAN, WiFi, mesh communication or LTE Direct, without limitation. It also includes non-radio-based short-range wireless data communication such as, for instance, magnetic/inductive communication, audio communication, ultrasound communication, or optical communication (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 network communication with a party which may be remote (e.g. cloud-based), including cellular radio communication like W-CDMA, GSM, UTRAN, HSPA, LTE, LTE Advanced or 5G, possibly communicated as TCP/IP traffic, or via a WLAN (WiFi) access point, without limitation. Moreover, the terms “long-range data communication” and “broadband data communication” are considered as synonyms of “wide-area network communication”.

Figure 3 illustrates an electronic device in the form of a mobile device MD which may implement the payer device PD in embodiments thereof. The mobile device MD has an interface WAN I/F for wide area network data communication. The mobile device MD further has an interface S-R I/F for short-range wireless data communication and an interface NFC I/F for local point-to-point communication. Any or both of the interfaces S-R I/F and NFC I/F may be used for local point-to-point communication LP2PC with a point-of-sales device POS. The mobile device MD further comprises a local digital wallet LDW.

In the disclosed embodiment, the local digital wallet LDW is accommodated in a trusted execution environment TEE (other embodiments may however be possible for which sufficient data security and integrity is obtained by other measures). The trusted execution environment TEE can be referred to as a secure element, i.e. a tamper- resistant hardware or virtual platform. The trusted execution environment TEE is configured to securely host applications, i.e. trusted applications, and to store confidential and cryptographic data and therefore provide a trusted environment for execution of such applications. This is commonly referred to as secure runtime. Advantageously, at least some of the data and functionality in embodiments of the invention may be stored in and performed by the trusted execution environment TEE of the payer device PD.

The trusted execution environment TEE may be configured according to any hardware-based computer architecture scheme known in the art, including but not limited to Samsung TEEGRIS, Qualcomm TEE, Huawei iTrustee, Trustonic Kinibi, Google Open Source Trusty, Open Portable TEE, Nvidia’s Trusted Little Kernel for Tegra, Sierra TEE, ProvenCore TEE, Trusty TEE for Android, or TrustKernel T6. Moreover, the trusted execution environment TEE may be adapted to protect hardware resource of the payer device PD by implementing any hardware support technologies known in the art, including but not limited to Arm’s TrustZone, MultiZone Security, AMD Platform Security Processor, Intel Software Guard Extensions, Apple’s Secure Enclave Processor, or Google’s Titan M. The trusted execution environment TEE may alternatively be configured according to any software-based computer architecture scheme known in the art, a.k.a. a virtual execution environment.

Moreover, the mobile device MD further comprises a controller Ctrl, one or more memories Mem and a user interface UI. The controller Ctrl comprises one or more processing devices or units. The controller Ctrl may be implemented in any known controller technology, including but not limited to microcontroller, processor (e.g. PLC, CPU, DSP), FPGA, ASIC or any other suitable digital and/or analog circuitry capable of performing the intended functionality. The memory/memories Mem 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/memories Mem, or parts thereof, may be integrated with or internal to the controller Ctrl. The memory/memories Mem may store program instruction for execution by the controller Ctrl, as well as temporary and permanent data.

When the trusted execution environment TEE is a software-based computer architecture scheme (virtual execution environment) as referred to above, it may be implemented in software stored locally in the controller Ctrl or the memory/memories Mem. The user interface UI may comprise an input device and a presentation device, as is generally known per se. In some embodiments, the input device and the presentation device are constituted by one common physical device, such as for instance a touch screen (touch-sensitive display screen), implemented in for instance resistive touch technology, surface capacitive technology, projected capacitive technology, surface acoustic wave technology or infrared technology.

Figure 4 illustrates an electronic device in the form of a smart card SC which may implement the payer device PD in embodiments thereof. The smart card SC has secure electronic circuitry SEC accommodating a local digital wallet LDW, and an interface NFC I/F for local point-to-point communication LP2PC with a point-of-sales device POS. The smart card SC further has a controller Ctrl and one or more memories Mem, as is well known per se in the field of electronic card payments; reference is, for instance, made to the ISO/IEC 14443, ISO/IEC 15693 and ISO/IEC 7816 standard families.

Hence, one aspect of the invention is an electronic device that comprising a local digital wallet LDW, the local digital wallet defining a balance BAL available for offline electronic payments, and a risk limit profile RL representing constraints for offline electronic payments performable by the electronic device PD. The electronic device PD is configured to act on behalf of a payer U1 by participating in an offline clearing procedure OCP which involves local point-to-point communication LP2PC with a point-of-sales device POS. More specifically, the payer device PD is configured, during the offline clearing procedure OCP, to assess 52 whether an amount to be paid complies with the balance BAL and the risk limit profile RL of the local digital wallet LDW. The payer device PD is configured, in case of compliance, to provide 56 the signed transaction data STD to the point-of-sales device POS, thereby permitting completion of the offline clearing procedure OCP. The payer device PD is configured, in case of non-compliance, to refrain 58 from providing the signed transaction data STD to the point-of-sales device POS, thereby preventing completion of the offline clearing procedure OCP. The electronic device may moreover be configured for performing the functionality of the payer device PD in any of the embodiments of the method of performing an offline electronic payment as described in this document. As was described with reference to Figures 3 and 4 above, the electronic device PD may typically be a mobile device MD or a smart card SC.

Implementation examples of the system and method as described above and shown in Figure 2 are provided in Figures 5A, 5B, 6 and 7.

Figure 5 A discloses a first implementation example of increasing the balance BAL of the local digital wallet LDW in the payer device PD. This implementation example is suitable for embodiments where the payer device PD is a smart card SC, as well embodiments where the payer device PD is a mobile device MD. The payer device PD stores, in the TEE (Figure 3) or SEC (Figure 4) and in addition to the balance BAL (seen as balance in the drawing) and the risk limits RL, a digital certificate cert key card which comprises a public cryptographic key associated with a private cryptographic key priv key card in a public key infrastructure, PKI, configuration. This can be seen at 504. Correspondingly, the point-of-sales device POS stores a digital certificate cert key j>os which comprises a public cryptographic key associated with a private cryptographic key priv key _j>os in a PKI configuration. This can be seen at 502. Shown in Figure 5 A is, furthermore, a payment service provider PSP which is the same as or corresponds to the aforementioned computerized card issuer Cl in Figures 1 and 2, or alternative is another computerized entity associated with the computerized card issuer Cl in the payment service network PSN. The payment service provider PSP stores a digital certificate cert key j>sp which comprises a public cryptographic key pub key j>sp associated with a private cryptographic key priv key psp in a PKI configuration. The public cryptographic key pub key psp is available also to the point-of-sales device POS and the payer device PD, as seen at 502 and 504. Moreover, the payment service provider PSP keeps record of a balance, balance user, of a bank account, or similar account, associated with the user U1. This can be seen at 506.

A digital wallet topup procedure 510 involves the following. A user U1 of the payer device PD requests topup of the local digital wallet LDW in a certain topup amount at 512-514, and interacts with the point-of-sales device POS at 516 by tapping or dipping the payer device PD. A user U2 receives the request from the user U1 (for instance by verbal communication) and enters the topup amount on the point-of-sales device POS at 518. In the illustrated example, the user U1 may be a customer and the user U2 a merchant.

The point-of-sales device POS and the payer device PD establish local point- to-point communication LP2PC and check capabilities at 520-522. Optional steps of authenticating the user U1 by e.g. biometrics or PIN code may occur at 524-530.

At 532, the payer device PD generates a data set comprising the topup amount, the digital certificate cert key card of the payer device PD and a transaction identifier TID. The payer device PD signs the data set using the private cryptographic key priv key card, resulting in a digital signature S. The signed data set is communicated by LP2PC to the point-of-sales device POS at 534. The point-of-sales device POS authorizes the requested topup at 536. This involves verifying the signature S using the public cryptographic key comprised in cert key card. Upon successful verification, the point-of-sales device POS sends a secure HTTPS topup request at 538 to the payment service provider PSP by wide area network communication. The HTTPS topup request includes the requested topup amount, TID and cert key pos.

At 540, the PSP (Cl) checks that the user U1 has sufficient funds in the account User Account , and if so transfers the requested topup amount from User Account to the issuer account IA (cf. Figures 1 and 2), which in Figure 5 A is denoted Digital Cash Account. The PSP then generates a data set comprising the topup amount, TID and cert key pos, and signs the data set using the private cryptographic key priv key jsp. This results in a digital signature S2, as seen at 542. The payment service provider PSP sends a secure HTTPS topup response at 544 to the point-of-sales device POS by wide area network communication. The HTTPS topup response includes S2, the requested topup amount, TID, cert key pos and an affirmative status indication. The point-of-sales device POS forwards the contents of the HTTPS topup response to the payer device PD by LP2PC at 546.

At 548, the payer device PD verifies the signature S2 using the public cryptographic key pub key _psp. Upon successful verification, the payer device PD executes the topup locally by increasing the balance BAL of the local digital wallet LDW by the topup amount. A confirmation is sent by LP2PC to the point-of-sales device POS at 550. The point-of-sales device POS presents a status update of the successfully performed topup at 552, for instance by presenting on a display a message readable by the users U1 and U2. Figure 5B discloses a second implementation example of increasing the balance BAL of the local digital wallet LDW in the payer device PD. The main difference from Figure 5A is that in Figure 5B, the point-of-sales device POS is not involved in the topup procedure 560. The implementation example in Figure 5B is, therefore, particularly suitable for embodiments where the payer device PD is a mobile device MD. The payer device PD stores, in the TEE (Figure 3) and in addition to the balance BAL (seen as balance in the drawing) and the risk limits RL, a digital certificate cert key app which comprises a public cryptographic key associated with a private cryptographic key priv key app in a PKI configuration. This can be seen at 554.

As seen at 556 in Figure 5B and corresponding to 506 in Figure 5A, the payment service provider PSP stores the digital certificate cert key psp which comprises the public cryptographic key pub key j>sp associated with the private cryptographic key priv key jsp in a PKI configuration. The public cryptographic key pub key _j>sp is available also to the payer device PD, as seen at 554. Moreover, the payment service provider PSP keeps record of the balance, balance user, of the bank account, or similar account, associated with the user U 1.

The digital wallet topup procedure 560 in Figure 5B involves the following. The user U1 of the payer device PD requests topup of the local digital wallet LDW in a certain topup amount at 562-564. Optional steps of authenticating the user U1 by e.g. biometrics or PIN code may occur at 566-570. At 572, the payer device PD generates a data set comprising the topup amount, the digital certificate cert key app of the payer device PD and a transaction identifier LTD. The payer device PD signs the data set using the private cryptographic key priv key app, resulting in a digital signature S. The signed data set is communicated in a secure HTTPS topup request at 574 to the payment service provider PSP by wide area network communication. The HTTPS topup request includes the requested topup amount, TID and cert key app. At 576, the PSP (Cl) checks that the user U1 has sufficient funds in the account User Account , and if so transfers the requested topup amount from User Account to the issuer account IA, which in Figure 5B, too, is denoted Digital Cash Account. The PSP then generates a data set comprising the topup amount, 7ZD and cert key app, and signs the data set using the private cryptographic key priv key psp. This results in a digital signature S2, as seen at 578. The payment service provider PSP sends a secure HTTPS topup response at 580 to the payer device PD by wide area network communication.

The HTTPS topup response includes S2, the requested topup amount, TID, cert key app and an affirmative status indication. The payer device PD verifies the signature S2 using the public cryptographic key pub key _psp. Upon successful verification, the payer device PD executes the topup locally at 582 by increasing the balance BAL of the local digital wallet LDW by the topup amount. The payer device PD present a status update of the successfully performed topup at 584-586, for instance by presenting on a display of the payer device PD a message readable by the user U 1.

Figure 6 discloses an implementation example of performing the offline clearing procedure OCB between the payer device PD and the point-of-sales device POS, in the form of an offline payment procedure 610. This implementation example is suitable for embodiments where the payer device PD is a smart card SC, as well embodiments where the payer device PD is a mobile device MD. The user Ul, for instance a customer, interacts with the point-of-sales device POS at 612 by tapping or dipping the payer device PD. As a result, the point-of-sales device POS and the payer device PD establish local point-to-point communication LP2PC. At 614, the user U2, for instance a merchant, specifies an amount to be paid and enters it into the point-of- sales device POS.

Then commences a chain of functionality 620-638 pursuant to the EMV transaction flow which involves LP2PC communication between the payer device PD and the point-of-sales device POS, collectively being referred to as 20 in Figures 1 and 2. In step 640, the payer device PD checks that the EMV transaction flow 20 has proceeded well, and accordingly generates a transaction certificate TC, which corresponds to the signed transaction data STD in Figures 1 and 2.

As seen at 50 in Figure 6, the payer device PD then assesses (cf. 52 in Figure 2) whether the amount to be paid complies with the balance BAL and the risk limit profile RL of the local digital wallet LDW. This includes checking whether the payment is permissible in view of the amount to be paid in the sense that it does not violate the risk limits RL, as well as checking whether, as such, the amount to be paid is covered by the balance BAL (referred to as balance in Figure 6) of the local digital wallet LDW. In case of compliance (cf. 56 in Figure 2), the payer device PD provides at 22 the signed transaction data STD/transaction certificate TC to the point-of-sales device POS, thereby permitting completion of the offline clearing procedure OCP. In case of non- compliance, the payer device PD refrains (cf. 58 in Figure 2) from providing the signed transaction data STD/transaction certificate TC to the point-of-sales device POS, thereby preventing completion of the offline clearing procedure OCP.

If the procedure 50 at the payer device PD was successful (i.e., the amount to be paid was found to comply with the balance BAL and the risk limit profile RL), the point-of-sales device POS accordingly receives the signed transaction data STD/ transaction certificate TC, verifies it pursuant to the EMV transaction flow and stores it in an EMV transaction block at 644 (cf. transaction block TB in Figures 1 and 2). A message is presented by the point-of-sales device POS at 646 to the users Ul, U2 to inform that the offline electronic payment has been performed successfully (or about the failure in case procedure 50 was aborted). Figure 7 discloses an implementation example of requesting and performing the online settlement OS in the payment service network PSN. The online settlement procedure 710 thus involves the point-of-sales device POS retrieving the EMV transaction block, with the aforementioned signed transaction data STD/transaction certificate TC stored therein (cf. the description of step 644 above), and sending the EMV transaction block in step 30 (cf. Figure 2) to a payment service provider PSP which is the same as or corresponds to the aforementioned computerized payment acquirer PA in Figures 1 and 2, or alternative is another computerized entity associated with the computerized payment acquirer PA in the payment service network PSN. With reference back to Figure 2, the point-of-sales device POS thus requests 30 online settlement OS of the electronic payment in the payment service network PSN to cause transfer 46 of funds from the issuer account IA (. Digital Cash Account in Figure 7) associated with the payer device PD to the acquirer account AA {Merchant Account in Figure 7) associated with the point-of-sales device POS, i.e. by debiting the former and crediting the latter. Figure 8 is a schematic illustration of a computer-readable medium 800 in one exemplary embodiment, capable of storing a computer program product 810. The computer-readable medium 800 in the disclosed embodiment is a portable memory device, such as a Universal Serial Bus (USB) stick. The computer-readable medium 800 may however be embodied in various other ways instead, as is well known per se to the skilled person. The portable memory device 800 comprises a housing 830 having an interface, such as a connector 840, and a memory chip 820. In the disclosed embodiment, the memory chip 820 is a flash memory, i.e. a non-volatile data storage that can be electrically erased and re-programmed. The memory chip 820 stores the computer program product 810 which is programmed with computer program code (instructions) that when loaded into a processing device, such as a CPU, will perform any of the functionalities listed in the next paragraph. The processing device may, for instance, be the aforementioned controller Ctrl as described with reference to Figure 2. The portable memory device 800 is arranged to be connected to and read by a reading device for loading the instructions into the processing device. It should be noted that a computer-readable medium can also be other media such as compact discs, digital video discs, hard drives or other memory technologies commonly used. The computer program code (instructions) can also be downloaded from the computer-readable medium via a wireless interface to be loaded into the processing device.

In one embodiment, therefore, the computer-readable medium 800/computer program product 810 comprises computer program code for performing the functionality of the payer device PD in the method of performing an offline electronic payment as described herein when the computer program code is executed by the processing device.

The invention has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims.

Claims

1. A method of performing an offline electronic payment of a type which involves a payer device (PD) and a point-of-sales device (POS), the payer device acting as a holder of a payment card (PC) issued by a card issuer (Cl) and the point-of-sales device acting to receive (22) signed transaction data (STD) representing approval of the electronic payment, in an amount to be paid, from the payer device (PD) by local point- to-point communication (LP2PC) during an offline clearing procedure (OCP) and to request (30) online settlement (OS) of the electronic payment in a payment service network (PSN) to cause transfer (46) of funds from an issuer account (IA) associated with the payer device (PD) to an acquirer account (AA) associated with the point-of- sales device (POS), wherein the payer device (PD) comprises a local digital wallet (LDW), the local digital wallet defining a balance (BAL) available for offline payments, and a risk limit profile (RL) representing constraints for offline electronic payments performable by the payer device (PD); and wherein, during the offline clearing procedure (OCP), the payer device (PD):

• assesses (52) whether the amount to be paid complies with the balance

(BAL) and the risk limit profile (RL) of the local digital wallet (LDW);

• in case of compliance, provides (56) the signed transaction data (STD) to the point-of-sales device (POS), thereby permitting completion of the offline clearing procedure (OCP); and

• in case of non-compliance, refrains (58) from providing the signed transaction data (STD) to the point-of-sales device (POS), thereby preventing completion of the offline clearing procedure (OCP).

2. The method according to claim 1, wherein the offline electronic payment is an EMV - Europay, Mastercard and VISA - payment.

3. The method according to any preceding claim, wherein the payer device (PD) is a smart card (SC).

4. The method according to any preceding claim, wherein the payer device (PD) is a mobile device (MD), such as a mobile communication device, a mobile phone, a smart phone, a tablet computer, a personal digital assistant, a portable computer, smart glasses, a smart card or a smart wearable (e.g. smart watch or smart bracelet). The mobile device may, for instance, be configured to act as the holder of the payment card (PC) by way of host card emulation, HCE, functionality.

5. The method according to any preceding claim, wherein the point-of-sales device (POS) is a point-of-sales terminal, such as a card payment terminal, a service terminal, an electronic checkout counter, an electronic delivery pickup point, a vending machine, a ticket machine, a dispensing machine, or an access control system.

6. The method according to any of claims 1-4, wherein the point-of-sales device (POS) is a mobile device, such as a mobile communication device, a mobile phone, a smart phone, a tablet computer, a personal digital assistant, a portable computer, smart glasses, a smart card or a smart wearable (e.g. smart watch or smart bracelet). The mobile device may, for instance, be configured to operate by way of point-of sales terminal emulation functionality.

7. The method according to any preceding claim, wherein the assessing (52) by the payer device (PD) during the offline clearing procedure (OCP) of whether the amount to be paid complies with the balance (BAL) and the risk limit profile (RL) of the local digital wallet (LDW) eliminates the need for a risk assessment of the offline electronic payment by the point-of-sales device (POS).

8. The method according to any preceding claim, wherein the risk limit profile (RL) defines one or more of the following:

• a total spending limit for offline electronic payments that have not yet been settled online;

• a maximum payment amount for each offline electronic payment;

• a maximum accumulated payment amount for offline electronic payments performable until the point-of-sales device (POS) requests (30) online settlement (OS) of the electronic payment in the payment service network (PSN);

• a maximum accumulated payment amount for offline electronic payments performable during a certain time (such as a day, week, month, etc.);

• a maximum number of offline electronic payments performable until the point-of-sales device (POS) requests (30) online settlement (OS) of the electronic payment in the payment service network (PSN);

• a maximum number of offline electronic payments performable during a certain time (such as a day, week, month, etc.); • a definition of payment receivers that a user (Ul) of the payer device (PD) is allowed to make offline electronic payments to; and

• a definition of payment receivers that the user (Ul) of the payer device (PD) is not allowed to make offline electronic payments to.

9. The method according to any preceding claim, wherein, during the offline clearing procedure (OCP), the payer device (PD) receives the amount to be paid and a currency thereof from the point-of-sales device (POS); and wherein, in assessing (52) whether the amount to be paid complies with the balance (BAL) and the risk limit profile (RL) of the local digital wallet (LDW), the payer device (PD) verifies, as a further requisite for compliance, that the currency of the amount to be paid is a currency supported by the payer device (PD).

10. The method according to any preceding claim, wherein: the payer device (PD) communicates with the card issuer (Cl; PSP) to request an increase of the balance (BAL) of the local digital wallet (LDW); the card issuer (Cl; PSP) determines a granted increase being equal to or less than the requested increase, causes a transfer of funds corresponding to the granted increase from an account {User Account) associated with a user (Ul) of the payer device (PD) to the issuer account (IA; Digital Cash Account ), and communicates the granted increase to the payer device (PD); and the payer device (PD) receives the granted increase and updates the balance (BAL) of the local digital wallet (LDW) accordingly.

11. The method according to claim 10, wherein: the card issuer (Cl; PSP) determines one or more risk parameters of the risk limit profile (RL) and communicates the determined one or more risk parameters together with the granted increase to the payer device (PD); and the payer device (PD) receives the one or more risk parameters with the granted increase and updates the risk limit profile (RL) of the local digital wallet (LDW) accordingly.

12. The method according to any preceding claim, wherein the local point-to- point communication (LP2PC) involves Near Field Communication, NFC.

13. A system for offline electronic payments, comprising: a payer device (PD) configured to act as a holder of a payment card (PC) issued by a card issuer (Cl); and a point-of-sales device (POS) configured to receive (22) signed transaction data (STD) representing approval of an electronic payment, in an amount to be paid, from the payer device (PD) by local point-to-point communication (LP2PC) during an offline clearing procedure (OCP) and to request (30) online settlement (OS) of the electronic payment in a payment service network (PSN) to cause transfer (46) of funds from an issuer account (IA) associated with the payer device (PD) to an acquirer account (AA) associated with the point-of-sales device (POS), wherein the payer device (PD) comprises a local digital wallet (LDW), the local digital wallet defining a balance (BAL) available for offline payments, and a risk limit profile (RL) representing constraints for offline electronic payments performable by the payer device (PD); and wherein, during the offline clearing procedure (OCP), the payer device (PD) is configured for:

• assessing (52) whether the amount to be paid complies with the balance

(BAL) and the risk limit profile (RL) of the local digital wallet (LDW);

• in case of compliance, providing (56) the signed transaction data (STD) to the point-of-sales device (POS), thereby permitting completion of the offline clearing procedure (OCP); and

• in case of non-compliance, refraining (58) from providing the signed transaction data (STD) to the point-of-sales device (POS), thereby preventing completion of the offline clearing procedure (OCP).

14. The system according to claim 13, wherein the payer device (PD) is configured for performing the functionality of the payer device (PD) in the method according to any of claims 1-12.

15. The system according to claim 13 or 14, wherein the point-of-sales device (POS) is configured for performing the functionality of the point-of-sales device (POS) in the method according to any of claims 1-12.

16. An electronic device (PD) comprising a local digital wallet (LDW), the local digital wallet defining a balance (BAL) available for offline electronic payments, and a risk limit profile (RL) representing constraints for offline electronic payments performable by the electronic device (PD), wherein the electronic device (PD) is configured to act on behalf of a payer (Ul) by participating in an offline clearing procedure (OCP) which involves local point- to-point communication (LP2PC) with a point-of-sales device (POS); and wherein the payer device (PD) is configured, during the offline clearing procedure (OCP), to

• assess (52) whether an amount to be paid complies with the balance

(BAL) and the risk limit profile (RL) of the local digital wallet (LDW);

• in case of compliance, provide (56) the signed transaction data (STD) to the point-of-sales device (POS), thereby permitting completion of the offline clearing procedure (OCP); and

• in case of non-compliance, refrain (58) from providing the signed transaction data (STD) to the point-of-sales device (POS), thereby preventing completion of the offline clearing procedure (OCP).

17. The electronic device (PD) according to claim 16, configured for performing the functionality of the payer device (PD) in the method according to any of claims 1-12.

18. The electronic device (PD) according to claim 16 or 17, wherein the electronic device (PD) is a smart card (SC).

19. The electronic device (PD) according to claim 16 or 17, wherein the electronic device (PD) is a mobile device (MD).

20. A computer program product comprising computer program code for performing the functionality of the payer device (PD) in the method according to any of claims 1-12 when the computer program code is executed by a processing device.

21. A non-volatile computer readable medium having stored thereon a computer program comprising computer program code for performing the functionality of the payer device (PD) in the method according to any of claims 1-12 when the computer program code is executed by a processing device