WO2020076176A1

WO2020076176A1 - Method for automatically transmitting and storing financial and commercial receipts in electronic format

Info

Publication number: WO2020076176A1
Application number: PCT/RO2019/000024
Authority: WO
Inventors: Răzvan TROIE
Original assignee: Troie Razvan
Priority date: 2018-10-12
Filing date: 2019-10-10
Publication date: 2020-04-16
Also published as: RO133219A3; RO133219A0; WO2020076176A4

Abstract

Method for the determination of the electronic addresses of destination and for the transmission of electronic receipts of financial and / or commercial transactions for which payment is performed with payment instruments such as bank cards, comprising: taking at least one identification date of the payment instrument; computing an electronic address of destination of the electronic receipts, independently of querying of any server, only on the basis of data contained in a memory of the payment instrument and / or in a memory of the payment terminal; receiving an electronic message comprising an electronic receipt at an electronic receipt server; identifying a user account associated with the payment instrument identified by an identifier comprised in the electronic message received and, if that user account does not already exist, creating it on the spot; depositing the electronic receipt in the respective user account; authenticating and accessing, by the holder of the payment instrument, of the content of his electronic receipt deposit account.

Description

METHOD FOR AUTOMATICALLY TRANSMITTING AND STORING FINANCIAL AND COMMERCIAL RECEIPTS IN ELECTRONIC FORMAT

The present invention is applicable in the field of electronic financial transactions carried out with payment instruments of the type of bank cards at specialized terminals and through virtual stores in online shopping over the Internet.

According to the specifications of the regulations of the international card organizations MasterCard and Visa for payment transactions made with bank cards at terminals of type Electronic Funds Transfer Point of Sales (hereinafter referred to as EFTPOS), payment receipts must be issued that present a minimum data set identifying the electronic payment made. Also, in the case of Automated Teller Machine (ATM) or other self-service equipment, they must be able to issue a receipt for a transaction if the customer chooses to receive a receipt.

At the same time, legal regulations in the fiscal domain in some countries mandate that the economic agents selling goods or services must use electronic fiscal cash registers. In some countries, fiscal authorities organize games such as fiscal receipts lottery periodically and / or occasionally. Most businesses equipped with electronic fiscal cash registers also use EFTPOS payment terminals for payments by bank cards. In many of these implementations, an EFTPOS terminal is interconnected with the electronic cash register (ECR) through a local data interface in order to simplify the clerk’s operation at the time of transaction through the transmission of specific commands and data between the two devices, ECR and EFTPOS.

In order to increase the payment transaction speed and to reduce paper consumption or to solve even the problem of not having the technical possibility to issue paper receipts in case of payments made with lightweight mobile EFTPOS terminals, also called mPOS, which usually are not equipped with embedded printers, EFTPOS integrators usually implement solutions for transmitting receipts electronically.

Several methods of sending electronic receipts to electronic addresses of cardholders are known. All the methods known so far for the transmission of electronic receipts to their destination addresses depend either on an online query to a remote server about the expressions of the respective electronic addresses of destination or depend on reading a specific personal contact data that had been previously written in a card memory, at the card personalization phase. For this reason, known solutions entail at least one of the following problems: either they are not applicable in cases where payment terminals operate offline, temporarily disconnected from a data network through which they would query a remote server about the users’ electronic addresses where electronic receipts should be transmitted, such as, for example, in the case of financial transactions that get authorized offline, based on EMV rules and security specifications, which is highly applicable for instance in environments with weak or nonexistent connections to the internet or to private data networks; or those solutions are neither applicable for the immense mass of banking cards and other similar payment instruments that have been already issued in the market nor in the case of new cards to be issued, which do not have in their memory any information about an electronic receipt aimed at transmission of electronic receipts.

A known method for transmitting receipts in electronic format is that presented in the patent application of the applicant FLEXRECEIPTS INC., published with the number US2016/0350739 Al , which is aimed only at payment instruments emulated on a smart portable device such as a mobile smartphone or the like, provided with a wireless interface, for example NFC, through which the mobile smart device communicates with a payment system equipped with a compatible wireless reader. The method provides that at the end of each payment transaction for which a customer requests an electronic receipt, the local application of the payment terminal launches a user identification module that requests, through the NFC interface of the payment terminal, a user ID from a client application that runs on the respective mobile smart device. This requires a second tapping of the mobile phone onto the NFC reader of the payment terminal, after the user first tapped the mobile phone to carry out the financial transaction itself. After receiving a user ID from the application running on the mobile phone, the customer identification module of the payment terminal sends it further, online, to a remote server in a data network to check, on the basis of that user ID, whether that user is already enrolled with electronic contact details in the server database for receiving electronic receipts; in case the user had already been registered with the server, the server finds an e-mail address related to the account of the respective user and sends this information in its reply message to the customer identification module of the payment terminal; if the server responds that there is no enrollment data found related to the respective user ID, so that there is no e-mail address known of that user, the client identification module at the payment terminal arbitrarily creates a unique temporary enrollment code for the customer in respect with said server and afterwards a local clerk mandatorily informs the customer about the respective unique temporary identification code either by reading it from a screen, or by printing it on a slip, so that the client will be able to access the receipt server and create a definitive account, based on the temporary code. The method presented in document US2016/0350739 Al has the following disadvantages:

- it is not applicable to all types of payment instruments in the category of bank cards or functionally equivalent substitutes thereof, but only in the particular case of payment applications running on mobile smart devices, such as a mobile smartphone, where a client application is configured to receive a query from the customer identification module launched by the payment terminal and to respond back to that query with a customer ID, as essential steps to be performed according to that respective method;

- it requires a second tapping of the smart mobile device onto the contactless reader of the payment terminal, which complicates the operation at the payment terminal and increases the total time that the customer must spend at that payment terminal;

- it cannot be applied in cases where the payment terminal is offline from the respective server that needs to be queried about the clients’ enrollment status and electronic addresses. Therefore, the payment terminal could not determine in offline mode whether there is an account of that client on the server or not, so it could not immediately decide on the destination of the electronic receipt, and later on, when the payment terminal would be online again with the receipt server but the client is no longer present at the terminal, if a query to the server reveals there is no existing enrollment of the respective customer, then it is no longer possible to communicate the customer an eventual temporary code chosen arbitrarily by the identification module for later use.

Another known method is that described in the patent application filed by MasterCard Asia / Pacific PTE LTD and published with the number US20180096314 Al . The respective method illustrates a system of sending an electronic receipt to a cardholder’s e-mail address, which e-mail address expression must be queried online, by the application of the payment terminal from a server located at the issuing bank of the card, together with the information about desired means of receiving transaction receipts as previously chosen by the cardholder through an enrollment process. Thus, the querying of the expression of the electronic destination address that is needed to send the electronic receipt to must be performed online, at the time of the payment transaction, the query message passing through the data circuit from the merchant’s payment terminal to the merchant’s acquiring bank for card payments, then to the international card organization network, then to an intermediary terminal of that card organization and finally to the card issuing bank, and afterwards the answer of the query travels back the same data circuit, in the opposite direction, also online and in real time in respect to the payment transaction. An essential role in the method described in that patent application is played by an intermediary terminal installed at the international card organization, which centralizes the data related to the commercial and payment transactions issued from the cash register systems and card payments terminals installed in merchants’ locations and which, based on the cardholder's bank account identification data that includes an Issuer Identifier Number / Bank Identifier Number, sends a real-time online query to the card issuing bank to obtain an electronic address of the respective cardholder, which address is to be further used by the payment terminal in the step of transmitting the electronic receipt for the performed transaction. The disadvantages of that method are the following:

- the dependence on an online inquiry of the cardholder’s electronic address from a remote server as a prerequisite for transmitting the electronic receipts, respectively the impossibility of such a solution to work offline in regards to the server on which the information about the cardholders’ contact addresses is stored, for instance in cases where the payment terminals would be temporarily disconnected from the data network;

- even when used online, the respective method requires performing some steps of exchanging of electronic messages among the payment terminal, the intermediary terminal and a server at the issuing bank, which increases the total duration of the client’s transaction at the payment terminal and also introduces the risk of a communication failure during the exchange of data, which would delay even more or would completely interrupt the operation of retrieving a cardholder's e-mail address where to send his / her electronic receipt;

- the solution is only applicable cardholders who had previously opted for receiving receipts in electronic format, reason for which they had provided an e-mail or SMS or other type of an electronic address;

- the impossibility of determining the contact address of a cardholder in the case of prepaid cards, which are not correlated at the time of issuance with any customer identity, so neither with any personal contact details.

Another known method is that described in the patent application filed by MasterCard International Incorporated and published with the number US20180101832 Al , by which an e- mail address or an SMS number to which the electronic receipts must be sent had been necessarily recorded in a memory of the card at the time of the card issuing, being encoded either on one of the card's magnetic stripes or in an electronic memory within the integrated circuit of the card. Thus, at each payment transaction, the electronic address of destination of the electronic receipt is read at the payment terminal directly from a card memory, with no need for an online remote query. Even in the case of this method, some of the disadvantages presented above in connection with the method described in the patent application US20180096314 Al are also encountered, namely:

- the solution is applicable only to card holders who had previously opted, at the time of requesting a new card account, to receive receipts in electronic form and who had provided for this purpose an e-mail or an SMS number or other type of an electronic address that was stored in the profile of the card personalization data during the issuing of the card;

- the impossibility of determining a contact address of a cardholder in the case of prepaid cards, which are not correlated at the time of issuance with any customer identity, so no contact details thereof.

The technical problem solved by the present invention consists of extending the applicability and functionality of systems aimed at retrieving electronic addresses of destination for the transmission of electronic receipts pertaining to electronic financial transactions performed with payment instruments at payment terminals regardless whether the payment terminals are in online state or temporarily in offline state with respect to an electronic receipt application server, and of extending the applicability and functionality of said systems to all types of payment instruments that are technically equivalent to a financial card, including the large mass of bank cards already issued in the market, which do not have any contact address stored in their memory aimed at being used for the transmission of electronic receipts. The solution proposed by the present invention also ensures a reduction of the duration and of the complexity of a transaction performed at a payment terminal and complete avoidance of risks associated with eventual data communication failure that may occur in terminal-to-server online queries that would in other known solutions be necessary to check on the existence of pre- enrolled contact details within user accounts in an electronic receipt server’s database in order to retrieve electronic addresses that need to be used for the transmission of the electronic receipts.

The present invention solves this problem by computing locally, at the payment terminal, at each transaction, an electronic address of destination for the transmission of an electronic receipt, thus making it possible to be applicable: regardless of any prior cardholder enrollment in a receipt server system; and independently of any type of pre-existing information about customer’s contact details stored in a memory of the payment instrument; and independently of a merchant’s clerk inquiring the cardholder about any contact detail at the time of the transaction or at any other moment before or after the transaction; and independently of the existence of an active data connection at the time of the transaction between the payment terminal and any type of server. The present invention comprises:

- A method for computing the electronic addresses of destination for the transmission of electronic receipts for financial and / or commercial transactions for which payment is made by payment instruments such as bank cards or similar substitutes, comprising: providing a local application for electronic receipts with at least one identification data of the payment instrument; locally computing a server address of an electronic receipt server, independently of the online or offline status of the payment terminal with respect to an electronic receipt server; locally computing an identifier of an electronic receipt deposit account corresponding to the respective payment instrument, independently of the online or offline status of the payment terminal with respect to an electronic receipt server, wherein the server address and the identifier of the electronic receipt deposit account are determined based on processing only data that is contained in a memory of the payment instrument and / or data that is read from a memory accessible to the local application for electronic receipts that runs on the payment terminal or on another device coupled with the payment terminal. In some embodiments, the method according to the invention also includes transmitting an electronic receipt to the electronic address thus determined and corresponding to the holder of the payment instrument. The method herein disclosed may be applied in applications for the transmission of electronic receipts related to financial transactions made with a payment instrument or for the transmission of electronic copies of fiscal or non-fiscal receipts related to commercial operations for which payments are made by means of bank cards or similar payment instruments or for the transmission of both types of electronic documents. The method further provides, in preferred embodiments, receiving an electronic message comprising an electronic receipt at an electronic receipt server application; identifying an electronic receipt deposit account associated with the payment instrument with which the transaction referred by the received electronic receipt was performed and, if that account does not exist already, creating it on the spot by the electronic receipt server application; depositing the electronic receipt in the respective electronic receipt deposit account.

- A client-side computer program and a server-side computer program for applying the method according to the present invention.

Due to the possibility of being applicable in online mode but also in offline mode when the payment terminals are temporarily disconnected from a connection with the authorization server and / or with a server for managing the cardholders’ electronic addresses, the present invention has a first advantage that it can be used in applications such as airways or maritime transportation in which there could be time intervals with no connection to any remote data network, or in courier applications in areas with poor or no GSM/GPRS signal, or in commercial transactions performed in stores or other spaces that are prone to temporary data connection perturbations or breakdowns. This advantage enriches the benefits introduced by the rules of card organizations and of EMV in respect to modem financial smart card technologies, which, in order to increase the mobility and agility of card payment transactions, allow the authorization of such transactions offline, directly by the payment terminals at which are presented such smart payment instruments, subject to automatic checks of some risk factors.

Another advantage of the present invention is that the proposed solution is applicable to all payment instruments such as bank cards or substitutes thereof, whether they are newly issued or are already in circulation, thus eliminating the condition of a previous cardholders’ enrollment in respect to declaring a contact detail in the form of an electronic address of destination for the transmission of electronic receipts and for eventual prior storing of such contact details in a server or in the payment instrument memory.

Yet another advantage of the present invention is that the destination addresses of the electronic receipts do not expose sensitive information about the financial account of the cardholder nor personal information such as first or last name, which represents a better data security compared to other known solutions and which complies with PCI DSS security standard requirements and also with the GDPR provisions for personal data protection.

On the other hand, by eliminating the need for an online query to a remote server to retrieve electronic address data for sending the electronic receipts, the proposed solution ensures a reduction of the total transaction time and of the customer’s wait time at the payment terminal end also ensures eliminating the risks associated with an eventual data communication interruption before completing the query operation from the respective electronic receipt server about the cardholder’s electronic address.

Yet another advantage of the current invention lies in its applicability even in the case of prepaid cards, which are not correlated with any identity or contact information of a cardholder, but for which the proposed solution is able to dynamically generate electronic receipt accounts to handle electronic receipts starting with the first transaction so to make it possible for the prepaid card’s holder to subsequently retrieve his electronic receipts.

Figures 1 ... 5 accompanying the present description of the invention represent:

- Fig. 1 illustrates a high-level data network scheme that can be used to transmit electronic receipts to an electronic receipt server;

- Fig. 2 illustrates the main elements of a payment instrument in respect to the method according to the invention;

- Fig. 3 illustrates a block diagram of the steps of the method according to the invention for the local computing of the electronic address of destination for the electronic receipts and of the steps of receiving and storing of the electronic receipts at a server;

- Fig. 4 represents the operational steps that are included in the functional block responsible for the local computing of the electronic address of destination of the electronic receipts, which was introduced in Fig. 3;

- Fig. 5 is a logical flow diagram of the functional steps provided for activating the access of a holder of a payment instrument to retrieve his electronic receipts.

Throughout the current description, the phrase "commercial transactions" refer to transactions related to the act of selling products or services, and "financial transactions" refers to the act of fulfilling the payment obligations arising from commercial transactions.

"Payment terminal" means a device that is provided with a secure data exchange interface in respect to a payment instrument such as a financial card, wherein the respective interface is provided with either a magnetic stripe reader or with an integrated circuit card reader with electronic contacts or without electronic contacts such as a contactless reader or Near Field Communication or NFC enabled devices. Payment terminals could be, for instance, in the form of "Electronic Funds Transfer Point of Sale" terminals (shortened "EFTPOS") or "Automatic Teller Machine" (shortened "ATM") or of the type of automatic dispensers of products or services which equipped with card payment modules.

"Card-type payment instrument" means a portable device such as a financial card or other types of objects with functions equivalent to those of a financial card, such as, but not limited to: contactless stickers, bracelet or fobs, NFC enabled smartphone or tablet or smart watch etc., these payment instruments comprising an identification data set that includes at least one identification code of the respective payment instrument that is uniquely linked to a holder’s financial account in the system of an issuing organization. The terms "card-type payment instrument", "payment instrument" and "card" are used throughout the current specification with the same meaning, as defined herein.

The terms "cash register", "electronic cash register" and the acronym "ECR" refer equivalently to equipment for marking commercial transactions for the sale of goods or services, such as fiscal or non-fiscal cash registers or personal computers equipped with fiscal modules and with specialized applications for selling of products and services, or portable smart devices like tablets or mobile phones that are optionally provided with fiscal modules or are optionally connected with other devices that are equipped with fiscal modules, or fiscal or non- fiscal self-service devices such as automated dispensers (vending machines). In respect to the scope and to the terminology used in this description, the cash registers and the automated dispensers are responsible for carrying out commercial transactions, including the optional creation and issuance of a commercial receipt that can be fiscal or non-fiscal, depending on concrete implementations. The term "application" is used within this document with the meaning of computer program.

By "determining by computational operations" or by "computing" or "deducing" a component of an electronic address, it shall be understood the execution by a computer program or by a programmable device of at least one processing operation on at least one data, for example, but without being limited to that, reading a parameter and creating a character string based on that parameter; creating a character string by concatenating or otherwise compounding two or more data strings; adding or subtracting special characters to a string; mapping some type of data with some other type of data or with values of data strings or parameters; encrypting or otherwise encoding a data etc.

The method according to the present invention provides, at each transaction made with a payment instrument, the local execution, that is at the place where the transaction is originated, of certain operations for computing an electronic address of destination for the transmission of the electronic receipt for the respective transaction. The results so obtained must always be the same for transactions made with the same payment instrument on any of a certain group of payment terminals as long as all the payment terminals in the respective group run the same or functionally equivalent electronic receipt applications that comply with the same variant of the presented method, which applications are configured with the same parameter values in respect to electronic receipts and with the same criteria for computing the expressions of the electronic addresses for the transmission of the electronic receipts.

In presenting the syntax of the electronic addresses of the servers and of the electronic deposit accounts to which the electronic receipts will be transmitted, the following symbols are conventionally used in this document: round brackets ( ) are used to indicate the execution of the function to the left of the open bracket which takes as input data the argument from within the round brackets; straight brackets [ ] are used for symbolizing optional data fields in the syntax described; the three-point sequence ... is used to symbolize the continuation of a series of elements according to the logic or the format presented immediately before the three-point sign. The partial or complete syntax of the electronic addresses computed in the examples presented in this description are written in bold text.

Fig. 1 illustrates a scheme that is commonly encountered in practice, in which a merchant has got an EFTPOS payment terminal 1, which can perform an electronic payment transaction by means of a payment instrument 2 that was issued by an issuing financial company 3 and has got a cash register device 4 as well. Further on in the current description, the method according to the present invention shall be presented in conjunction with the use of a payment terminal 1 of the type EFTPOS, although the exact same method can be implemented and used in case of any other types of payment terminals that can accept financial transactions by means of a payment instrument 2, such as ATMs or automated dispensers of products, or personal computers or portable smart devices that can be used to make online payments via the Internet.

The cash register 4 can be connected to the payment terminal 1 through an ECR-POS data interface 5 through which the cash register 4 can send payment authorization commands to a financial application 6 that is run by the terminal payment 1 and which, after authorizing the financial transaction either offline directly by the payment terminal 1 or online with an acquiring server 7 of an acquiring bank 8 to which the merchant is affiliated, returns an information message corresponding to the performed transaction back to the cash register 4. Upon receiving an online authorization request for a financial transaction originated from a payment terminal 1, the acquiring server 7 checks the I IN (Issuer Identification Number) code that is included in the PAN (Primary Account Number) of the payment instrument 2 from the transaction data to retrieve a matching card organization 9 that governed the issuing of the payment instrument 2 and the specific issuing bank 3 of the payment instrument 2. If the issuing bank 3 is different from the acquiring bank 8, the acquiring server 7 forwards the authorization request message further to an inter-switching server 10 at a card organization 9 that is determined based on the IIN code read from the PAN of the payment instrument 2. For simplicity, in Fig. 1 is represented the connection of the acquiring server 7 to a single card organization 9; the acquiring server 7 may be connected to one or more card organizations 9, each having at least one inter-switching server 10 of its own and one or more affiliated issuing banks 3. The inter-switching server 10 determines which is the issuing bank 3 of the payment instrument 2 and then reroutes the transaction authorization request to an authorization server 11 installed at the respective issuing company 3. The authorization server 11 identifies in the system of the issuing bank 3 the financial account matched with the payment instrument 2 through the PAN number, checks the cardholder's PIN code in case the transaction is made with online PIN verification and then checks the cardholder’s financial account data to determine if the financial transaction can be authorized, and if positive sends an authorization confirmation back on the same circuit, in the opposite direction up to the payment terminal 1 that originated the financial transaction authorization request. If the payment cannot be authorized, the authorization server 11 sends an error code to the payment terminal 1. After receiving an authorization confirmation either online from an authorization server 11 or offline from an EMV library integrated with the financial application 6 running on the payment terminal 1 or after the expiration of a timeout interval, the financial application 6 provides a set of data characteristic to a financial receipt content, data which can be taken in the form of an electronic receipt 12 by an electronic receipt client-application 13 according to the present invention which is run by the payment terminal 1 or by the cash register 4 or by other device that is coupled with the payment terminal 1, for transmission to an electronic address 14.

In a basic embodiment, the method according to the present invention comprises:

- Computing, locally and regardless of any online or offline status of the payment terminal 1 in respect to any type of a server, the expression of a server address 15 where a server-application 17 is listening for the receiving and storing of the electronic receipts 12;

- Computing, locally and regardless of any online or offline status of the payment terminal 1 in respect to any type of a server, the expression of an identifier 16 of an electronic receipts deposit account where the electronic receipts 12 issued for a payment instrument 2 must be deposited.

In some embodiments, the method may also comprise at least one of the following steps: optionally encrypting and or transposing in a shorter form of the expression of the electronic receipt account identifier 16; optionally transmitting an electronic message comprising the electronic receipt 12 to an electronic receipt server application 17; receiving the electronic message comprising the electronic receipt 12 at the server application 17; storing at least a part of the content of the electronic message in an electronic receipt deposit account that is uniquely bound to the payment instrument 2. The client-application for electronic receipts 3 can optionally create the electronic receipt 12 based on data taken from the financial application 6 or/and from an application running on the cash register 4 or can retrieve from a memory or from a data interface an electronic receipt 12 already created by the financial application 6 or by another application.

The server address 15 and the electronic receipt account identifier 16 can compound a fully determined electronic address 14 that designates a server and a user’s deposit account for electronic receipts corresponding to the payment instrument 2 used in the respective transaction. The users’ deposit accounts for electronic receipts 12 are managed by the electronic receipt server-application 17 running on a server 18.

The method of automatic transmitting of electronic receipts 12 according to the present invention can be applied in a similar manner also in a variant of this method in which the client electronic receipt client-application 13 is run on an external equipment connected by a data interface with the payment terminal 1, for example on the cash register 4 which is coupled with the payment terminal 1 through a ECR-POS data interface 5, in such a case the data necessary for generating the electronic receipt 12 for the financial transaction being transmitted by the financial application 6 to the electronic receipts client-receipt 13 through the data interface ECR-POS 5. Also, the method according to the invention is equally applicable for the transmission of the electronic receipt of the financial transaction made with the payment instrument 2 or for the transmission of an electronic receipt issued for the commercial transaction for which a financial transaction was performed with the payment instrument 2 or for the transmission of both types of said electronic documents. Throughout this document, the electronic receipt 12 means any of these variants.

Fig. 2 illustrates some key elements of a card-type payment instrument 2: a data memory 19, a first identifier ID1 that uniquely identifies the payment instrument 2 in the system of the issuing financial company 3; optionally, a second identifier ID2 and a third identifier ID3 that carry some attributes of the payment instrument 2 and / or of its holder. If the issuing financial company 3 is of the type of a commercial bank and if the card 2 is issued under the logo of a card organization 9, the first identifier ID1 is the PAN number of the card 2, the second identifier ID2 is the name of the cardholder of the card 2 and the third identifier ID3 is the expiry date of the card 2 (month/year), these latter two being also visually printed on the bank card in general. It is known that the PAN numbers of the payment instruments 2 of the type of bank cards are created at the time of their issuance according to the ISO / IEC 7812-1 standard. The PAN number can have a total length between 8 and 19 digits and is made up of the following three subsets of digits: the first 6 digits represent the Issuer ldentifier Number code, abbreviated IIN, of the issuing financial company 3 of the respective payment instrument; the following digits up to the penultimate digit of the PAN inclusively represent an identifier CID of the cardholder’s financial account in the accounting system of the issuing financial company 3; the last digit in the PAN is a check digit of the integrity of the previous digits in the PAN number, according to the Luhn algorithm. According to ISO / IEC 7812-1 :2017, the I1N code will consist of the first 8 digits of the PAN as of 2022. The method according to the invention is applicable in the same way regard less of the length of the IIN code.

The block diagram depicted in Fig. 3 illustrates the steps of the method according to the present invention. At the functional block 100, the electronic receipt client application 13 receives from the financial application 6 or from a memory that can be locally accessed by the electronic receipt client application 13 at least the first identifier ID1 of the payment instrument 2 which, in preferred embodiments of the method according to the invention, consists of the PAN number of the payment instrument 2. In some embodiments, the method also provides for reading at least one from the second identifier ID2 and the third identifier ID3 of the payment instrument 2, preferably one piece of data that is requested, besides the PAN number, in online payment transactions for purchases over the internet, such as the cardholder’s name and / or the expiry date of the payment instrument 2.

At the functional block 200, detailed in Fig. 4, the electronic receipt client application 13 computes, locally and independently of the electronic receipt server application 17, the server address 15 of the electronic receipt server application 17. The server address 15 is fully determined at step 220 by processing at least one determinant in the form of a character string which results after performing either only the step 210a, or only the step 210b, or both steps, 210a and 210b, depending on different embodiments of the method according to the invention. In step 210a, a determinant of the server address 15 is computed as the output of a function that takes as input data the identification code of the card issuing organization 9 or of the issuing financial company 3. In preferred embodiments of the method, in which ID1 is the PAN number of the payment instrument 2, the respective server address determinant found in step 210a is the IGN code included in the PAN number. In step 210b, one or more determinants of the server address 15 result as output of a function that takes as input data only parameters that are read from a local memory, for example a memory of the payment terminal 1, to which the electronic receipt client application 13 has access. In the method embodiments where only the step 210a is executed from the group of the steps 210a and 201b, different server addresses 15 can be obtained at different payment transactions that are performed with different payment instruments 2, depending on the card organizations 9 and on the issuing banks 3 of those payment instruments 2, that is, the implemented solution can transmit electronic receipts to one or more receipt servers that are controlled by one or more issuing banks 3 or by one or more card organizations 9 or by one or more third party service providers. In the embodiments where only the step 210b is used from the group of the steps 210a and 201b, the server addresses 15 can be computed based on parameters that do not depend on the card issuing bank 3 nor on the card organization 9, but they may be just static parameters or they may be variable data that depend only on criteria implemented in the electronic receipt client application 13 and which can be independent of the identification data of the payment instrument 2. In the method embodiments in which both steps 210a and 210b are executed to compound the server addresses 15, different server addresses 15 (pointing at different receipt servers 18) may be computed at different payment transactions, depending to the card organizations 9 and on the issuing banks 3 of the respective payment instruments 2 used in those transactions, and, optionally, depending on other computing criteria implemented in the logic of the electronic receipts client application 13.

The server address 15 includes at least the network address of the electronic receipt server application 17 which, depending on the implementation technology, can be called through one of several forms of addressing through a data network, for example in the form of a URL address that can include the name of a type of schema, such as http or https or email, or a Fully Qualified Domain Name (FQDN), or an IP address and a TCP or UDP port. The server address 15 may further comprise a directory path from the file structure of the electronic receipt server 18. In some embodiments of the method according to the invention, the FQDN within the server address 15 is compound of a series of determinants separated by a character as follows:

[subdomain2. [subdomainl.] ...].SLD_name.TLD_name

in which the hierarchical peak of the domain, TLD_name, is constituted by the Top Level Domain name, this being either a generic domain such as com, org, info, net, edu, tv or a country specific domain of type ro, fr, bg etc. Also, the expression of the local path within the file structure of the server 18 is compound of another chain of determinants of type character string separated by a

character.

Thus, the values of the determinants that are included in the server address 15 are computed independently of the online or offline status of the payment terminal 1 in respect to the electronic receipt server application 17, by performing either step 210a or step 210b or both, depending on the embodiments of the method according to the invention.

To avoid the need for a real-time remote online query of an IIN code database in order to retrieve relevant matching attributes - such as bank name, country name, TLD name - in respect to the issuing organization 3 and to the card organization 9 corresponding to the payment instrument 2 used for the payment transaction, such IIN mapping data is locally kept in a local memory to which the electronic receipt client application 13 can have access. Moreover, the method according to the invention may provide, in some preferred embodiments of implementation, a periodic update of the files containing IIN mapping data, as set forth within the functional block 300 represented in dotted line in the diagram given in Fig. 3, through a function of the electronic receipt client application 13 that updates these IIN mapping data from an external data source, which can in turn update its information related to domestic or international IIN codes through a global IIN-Lookup service database.

Next are presented three examples of implementation of the method according to the present invention for computing a server address 15 of an electronic receipt server application 17 to which an electronic receipt 12 should be transmitted.

The first example refers to an embodiment of the method that uses both steps 210a and 210b to determine the server address 15. In a transaction performed, for example, with a bank card 2 having a PAN number = 4256031234567897, which includes the code IGN = 425603 (the first 6 digits of the PAN) and the financial account identifier of the card holder CID = 123456789, the electronic receipt client application 13 assigns, at the operational block 100, the value of the PAN number to the first identifier ID1, that is, ID1 = 4256031234567897. In step 210a, the electronic receipt client application 13 retrieves in a local memory that the IIN code 425603 is matched to the card organization 9 named "VISA" and corresponds to the issuing bank 3 named "ING BANK, NV", which operates in the country with the name "Romania". Based on these data, still in step 210a, the electronic receipt client application 13 further looks up in the local memory containing IIN mapping data for the following determinants: the Top Level Domain name is ".ro" corresponding to the country "Romania", the Second Level Domain name is ".ing" corresponding to the name of the issuing bank "ING BANK, NV" and, optionally, a partial subdirectory path where the server application 17 is hosted, which is dependent on the retrieved card organization name would be in this example "/visa". In step 210b, one or more determinants containing a static parameterized sub-domain name, for example "customer_services" and / or at least another partial subdirectory path that points to the server application 17 is accessed from a local memory accessible to the electronic receipt client application 13, for example "/electronic_receipts". In step 220, the electronic receipt client application 13 executes a function that has as input data the determinants found in step 210a and / or in step 210b and assigns the output value to the expression of the server address 15: "customer-services.ing.ro/visa/electronic-receipts/”, at which the server application 17 can be retrieved for calls, wherein the server application 17 can expose for example a web service and can have a call name in the form of a character string parameter that is also retrieved among the determinants of the server address 15 found in step 210b.

The second example provides a simpler scheme for implementing the method according to the invention by executing only step 210a from the group of the steps 210a and 210b, which ensures the local computing of the server address 15 only in respect to the IIN code of the card 2, that is, depending on the card organization 9 and on the card issuing bank 3. In this case, for a transaction performed with the same card 2 from the first example that has PAN = 4256031234567897, the deduced server address 15 is, for example, "receipt-services.ing.ro/", which resulted using only the determinant "receipt-services.ing.ro" that was looked up for in the local memory where was found in the form of this full string as being correlated with the IIN code 425603 of the card 2.

The third example, applicable in simple implementation schemes with a single global electronic receipt server 18 regardless of the card organization 9 and of the issuing bank 3, provides only for using step 210b from the group of the steps 210a and 210b, and then the deduced server address 15 may be, for example, "receipt-services-provider-company.ro", obtained by using a single determinant consisting of a static parameter which encompasses this full string regardless of the I IN code of the payment instrument 2, or it may be for example "receipt-services-provider-company.ro/electronic-receipts/” obtained by compounding two determinants, each consisting of a fixed parameter,“ receipt-services-provider-company.ro” as domain part and “electronic-receipts” as the name of the electronic receipt server application 17 running on the electronic receipt server 18, again regardless of the IIN code.

In step 230 of Fig. 4, the electronic receipt client application 13 computes the electronic receipt account identifier 16 managed by the electronic receipt server application 17 where the electronic receipt 12 of the transaction performed with the payment instrument 2 must be deposited. The electronic receipt account identifier 16 is computed in step 203 as a result of a function taking as input data at least a partial string of at least one of the first identifier ID1, second identifier ID2 and third identifier ID3 that are recorded in the memory 19 of the payment instrument 2, thus not being necessary to query any remote server, nor to request any contact data from the holder of the payment instrument 2 at the time of the transaction, nor to retrieve specific contact details from a memory of the payment instrument 2 where such data would had been eventually written at the phase of the issuance of the payment instrument 2. In an embodiment of the method according to the present invention, the electronic receipts account identifier 16 is constituted by a string of characters contained in the first identifier ID1 of the payment instrument 2, namely in the PAN number. The respective character string can be a string comprising at least a substring of the second part of the PAN number structure, that is, of the CID identifier of the cardholder's financial account, the CID identifier being uniquely bound to the cardholder’s financial account within the system of the issuing financial company 3. In the method embodiments in which only step 210b from the group of the steps 210a and 210b is executed to compute the server address 15, in order to avoid the risk of confusing between two eventually identical identifiers CID.l and CID.2 pertaining to two different financial accounts opened at two different issuing companies 3.1 and 3.2, that is, CID.l and CID.2 being preceded by two different IIN.1 and IIN.2 codes in two different PAN.l and PAN.2 numbers, the method according to the invention provides for the creation of the electronic receipt account identifier 16 as a string comprising both the CID identifier and the UN code, for example it can be the entire character string that makes up the PAN number.

The electronic receipt account identifier 16 can be implemented in the electronic receipt server application 17 in the form of an electronic mailbox within an e-mail service or as a subdirectory name or as a user index in a database or in another form, depending on the technology of the server application 17. Correspondingly, the electronic receipt account identifier 16 will be transmitted by the electronic receipt client application 13 either visible in the full electronic address 14, or inside a header or inside a data field comprised in an electronic message 20 that contains the electronic receipt 12 and which is transmitted to the electronic receipt server application 17 called at the server address 15. ln the latter case, the server application 17 will have to extract from each received electronic message 20 the data field containing the electronic receipt account identifier 16 to identify in which deposit account the respective electronic receipt 12 must be stored.

ln step 240, the complete electronic address 14 of the deposit account of the electronic receipt 12 is established for the transactions made with the payment instrument 2, as being the data pair comprising the server address 15 and the electronic receipts account identifier 16.

Two examples of establishing an electronic receipt account identifier 16 and, subsequently, a complete electronic address 14 are presented next. In the first example, it is considered that the electronic receipt server application 17 exposes an e-mail service and the electronic receipt deposit accounts are of the type of electronic mailboxes. Provided that the bank card 2 having PAN = 4256031234567897 is used to perform a transaction, this whole string shall be directly assigned as the value of the electronic receipt account identifier 16 within the server application 17 in the form of a mailbox name ,,4256031234567897”. Composing this mailbox name, for example, with the second example of determining the server address 15 presented above in this document, the complete electronic address 14 will have the expression: "4256031234567897@receipt-services.ing.ro"; or, by composing this user mailbox expression with the third example of determining the server address 15 above, the complete email address 14 will have the expression "4256031234567897@receipt-services-provider- company.ro".

In the second example of establishing an electronic receipt account identifier 16 and, subsequently, a full electronic address 14, it is considered that the electronic receipt server application 17 exposes a web service launched through an application file that is located in a directory path on the server 18 and the individual deposit accounts of the electronic receipts 12 of the holders of the payment instruments 2 are represented in the form of subdirectories or files or other types of data containers. Assuming that the bank card 2 having PAN = 4256031234567897 is used, the financial account identifier CID = 123456789 thus found can be assigned in this example as the value of the electronic receipt account identifier 16 without the risk of being confused with a CID of another issuer (preceded by another IIN code value within the PAN), since the server address 15 in the case of this example is already set based on the specific IIN code read from the payment instrument 2; the electronic receipt account identifier 16 will be used as a subdirectory name that will be indicated by the electronic receipt client application 13 in a field within an XML file that also contains the electronic receipt 12 and which will be transmitted to the server application 17. Applying this result in conjunction with the result of the first example of determining the server address 15 from above, the client application 13 will call the server application 17 at the server address 15 "customer- services.ing.ro/visa/electronic-receipts/" and will deposit the electronic receipt 12 in a user’s deposit account identified by a string containing the identifier "123456789"; or, applying the resulted electronic receipt account identifier 16 having the value "123456789" in conjunction with the result of the third example of determining the server address 15 from above, the client application 13 will call the server application at the server address 15 "receipt-services- provider-company.ro/electronic-receipts/" where it will send an XML file that contains a data field comprising the electronic receipt account identifier 16 having the value "123456789" which identifies the deposit account where the electronic receipt 12 must be deposited, the electronic receipt 12 also being comprised within the respective XML file.

In the preferred embodiments of the method according to the invention, the method also comprises encrypting of the expression of the electronic receipt account identifier 16, in accordance with the PCI-DSS requirements as follows: in an optional step 231, the electronic receipt client application 13 assigns the electronic receipt account identifier 16 the output of a secure hash function that takes as input data at least a subset of the financial account identifier CID or the entire PAN number. In addition, to avoid the possibility of retrieving PAN numbers departing from the values of final hashes through a cyberattack that would compare tapped hash values of electronic receipt account identifier 16 with results of the hash function on PAN numbers generated by an attacker from real IIN codes concatenated with random CID financial account identifiers and with a matching Luhn check number, the method optionally comprises a step for first computing the electronic receipt account identifier 16 as the output value of a function which compounds two input data, preferably the first identifier ID1 and one of the second identifier ID2 and third identifier ID3 of the payment instrument 2. For example, the compound function can be a concatenation of two strings of characters. In the preferred variants of the method, the first identifier ID1 comprising a string from the PAN shall be compound with the second identifier ID2 of the payment instrument 2, consisting of the cardholder name after the latter has been adjusted by eliminating the spaces and other punctuation marks from the composition of the first and last name and by replacing eventual special characters with other characters that are allowed by the electronic address syntax according to the technology of the server application 17, so that after the execution of the compounding function, the new expression of the electronic receipt account identifier 16 shall contain exclusively alphanumeric characters and shall be in the form "PAN"|"adjusted(Cardholder_Name)", and then this new string is passed as input data to a secure hash function whose output will be assigned to the electronic receipt account identifier 16. This new value of the electronic receipt account identifier 16 is an abstracted expression from which the initial value of the PAN number can no longer be deduced or matched with randomly generated PAN values. An example of a secure hash algorithm is SHA-1 , which, regardless of the input text length, produces a fixed-length hash value of 160 bits. For greater security, other secure hash algorithms can be used, for example SHA-2, which has several sub-variants: SHA-224, SHA-256, SHA-384 or SHA-512, which produce fixed lengths hash values of 224, 256, 384 and 512 bits, respectively. If SHA-1 is used, the 160-bit result is represented as a string of 40 hexadecimal characters; if SHA-256 is used, the result is represented as a string of 64 hexadecimal characters and so on.

In order to provide a shorter length of the resulted hash value of the electronic receipt account identifier 16 to comply with an URL or e-mail address syntax, the method according to the invention includes in step 232 a computing operation that transposes the initial hash value of the electronic receipt account identifier 16 from the hexadecimal format based on 4-bit symbols in another symbol representation which is based on a higher number of bits per symbol, for example 5-bit symbols, such as the Base32 system, which is a 32-character subset of the ASC1I character set, consisting of all capital letters of the English alphabet, A-Z, and the digits 2-7. The length of a string represented by 5-bit symbols has a length equal to four-fifths of the length of the same string represented by 4-bit symbols. Thus, the Base32 coding of a SHA-l’s 160-bit hash value shall have a length of 32 characters, the Base32 coding of a SHA-224 hash value shall have a length of 45 characters, the Base32 coding of a SHA-256 hash value shall have a length of 52 characters, the Base32 coding of a SHA-384 hash value shall have a length of 77 characters, and the Base32 coding of a SHA-512 hash value shall have a length of 103 characters.

For method embodiments that implement high security secure hash functions, which produce very long outputs, there could be combined two secure hash functions, for example: SHA-1 (SHA-512(“PAN”|adjusted(“Cardholder_Name”))), so that the final value of the electronic receipt account identifier 16 complies to the syntax of the data container names used according to the technology of the server application 17.

The electronic address 14 determined at the functional block 200 of Fig. 3 and 4 will be subsequently used for the transmission of the complete electronic message 20 comprising the electronic receipt 12. The operation of creating and effectively transmitting the message 20 to the electronic receipt server application 17 can be performed as an optional step of the method according to the present invention, either by the electronic receipt client application 13 or by another application that receives the local ly computed components of the electronic address 14 from the electronic receipt client application 13. Depending on the online or offline state of connectivity between the payment terminal 1, or the cash register 4, and the server 18 running the electronic receipt server application 17, the functional block 400 of Fig. 3 provides either for storing the electronic message 20 in a local memory for transmission at a later time, or for transmiting the electronic message 20 to the electronic receipt server application 17 at the end of the financial transaction for which the respective electronic receipt 12 is created.

The electronic receipt server application 17 has access to a database 21 in which it stores the electronic receipts 12 in electronic deposit accounts associated with the payment instruments 2 and identified through corresponding electronic receipt account identifiers 16. The electronic deposit accounts are created on the spot by the server application 17 upon receipt of each first electronic message 20 that contains an electronic receipt account identifier 16 that does not exist yet in the database 21 or are created by an explicit previous enrollment of the holder of the payment instrument 2 within the server application 17. After the automatic or manual creation of an electronic receipt deposit account, the holder of the corresponding payment instrument 2 can have access to his account for retrieving his electronic receipts 12 through a remote connection, from a computer 23 or from a smart phone or tablet or other portable smart device 24 over a data network 22. The user’s access to the server application 17 is ensured through a secure authentication interface 25.

The function block 500 of Fig. 3 refers to operational steps performed in respect to the method according to the present invention at the electronic receipt server application 17. Upon receiving of each electronic message 20, the server application 17 searches the database 21 for an electronic receipt deposit account corresponding to the electronic receipt account identifier 16 contained in the electronic message 20, and if that deposit account does not exist, the server application 17 creates it on the spot. Then, the server application 17 stores at least part of the content of the electronic message 20 in the respective deposit account within the database 21.

In order to avoid the server application 17 creating electronic deposit accounts as a result of some electronic messages transmitted by non-legitimate applications or systems instead of authentic and legitimate electronic receipts client applications 13, the electronic messages 20 can be optionally encrypted or digitally signed before transmission and the server application 17 shall accept only those electronic messages 20 that can be verified according to the respective encryption or digital signature.

In order to allow the users who are also holders of the payment instruments 2 to retrieve their electronic receipts 12 deposited in their corresponding electronic deposit accounts in the electronic receipt server application 17, the proposed method further comprises authenticating of each user in the server application 17 through a secure authentication interface 25. The electronic receipts 12 of a user are stored in his deposit account as of the first financial transaction made with the respective user’s payment instrument 2, for which an electronic receipt 12 was issued, even if the respective holder of the payment instrument 2 did not yet have an access account in the electronic receipt server application 17 to retrieve his electronic receipts 12. The holder of the payment instrument 2 will be able to gain remote access to his electronic receipts 12 at any time after he activates a login account at the first access of the server application 17. Afterwards, the user’s access will be granted only after going through an authenticating step through the secure authentication interface 25. The creation and activation of a user’s login account at the first accessing of the electronic receipt server application 17 is made, according to the method of the present invention, by requesting the user to perform an online operation with his payment instrument 2 directly from a user‘s device, be it a personal computer or a smart device or the like, through which the user can access the secure authentication interface 25. Such an authentication step is necessary in order to identify the payment instrument 2 associated with the electronic deposit account of the user’s electronic receipts 12 for which the access account is requested and to verify the user’s quality of authentic holder of the payment instrument 2. This online authentication step can consist of a pre- authorization of an online payment or of a definitive online payment of a certain amount, similarly to regular online purchases by card over the internet. By successfully completing such an online payment transaction with the payment instrument 2 directly from the user’s device, the user is deemed to genuinely own the respective payment instrument 2 after proving he knows or has visual access to the first identifier ID1, the second identifier ID2 and the identifier third ID3 and to a card verification value that are printed on the payment instrument 2, or after enabling the use of a tokenized data of a payment instrument 2 through a payment application running on a personal smart device, therefore the electronic receipt server application 17 decides that the respective user is the authentic holder of the payment instrument 2 and allows finalizing the enrollment of his login account. The enrollment step also requests the user to choose a username and a password and optionally fill in some personal data, such as an alternate e-mail address, telephone number, etc. which can be used for various notifications. Afterwards, the server application 17 allows the respective user to log in and get access to his electronic receipt deposit account that is bound to the electronic receipts account identifier 16 correlated with the user’s payment instrument 2. Once logged in his account, the user can retrieve all his electronic receipts 12 already accumulated from the first transaction with the payment instrument 2 for which a receipt was issued in electronic form.

In one embodiment of the method, the electronic receipt server application 17 also includes a function of automatic identification of certain electronic receipts 12 through a search in the database 21 based on certain search criteria and parameters which are read by the server application 17 from an internal or external data source or which are manually entered by an operator, for instance certain transaction amount and calendar dates. In correlation with the results of the automatic search of electronic receipts 12 that correspond to the respective criteria and parametric values, the server application 17 also includes a function of transmitting an electronic notification to the holders of the so retrieved electronic receipts 12. Notifications can be sent either in the holders' electronic receipt accounts within the database 21 or at an optional contact data found in the holders' profiles, or both. The optional functions of automatic search of electronic receipts 12 according to search criteria and parameters that can be updated periodically, automatically or manually, represent a technical solution to notify the owners of the electronic receipts 12 automatically retrieved according to search criteria and parameters much faster (even instantaneously) and more efficiently than by letting the respective users search by themselves for such matching results through other known technical means, for example by looking up in newspapers or other type of mass-media. Therefore, such a solution ensures two aspects: by the one hand, all users that own electronic receipts 12 matching the respective automatic search criteria receive automatic notifications; by the other hand, the notifications are received very early after the search criteria are announced by the respective games or events organizers, so that the respective receipt owners have enough time to take necessary further actions pertaining to the respective retrieved electronic receipts 12 and not miss certain deadlines or even the opportunity to be made aware of their matching with the respective search criteria. Such a solution can be proposed for instance to be implemented for identifying and notifying immediately the holders of the electronic documents that are declared winners at games such as fiscal receipt lotteries or other organized events, for which certain electronic receipts 12 can be selected.

Claims

1. Method of determining an electronic address for the transmission of an electronic receipt (12) containing data that is correlated to a financial transaction performed at a payment terminal (1) by means of a payment instrument (2) which is identified by a first identifier (ID1), characterized in that it comprises:

- locally computing a server address (15) for calling an electronic receipt server application (17), wherein the server address (15) comprises a string of characters, which results as output of a function that takes as input data a raw form or a processed form of at least one data from the group made of: an identification code of a card organization (9) and /or of a issuing financial company (3) of the respective payment instrument (2) and at least one determinant which is stored as a parameter in a local memory;

- locally computing an electronic receipt account identifier (16) corresponding to the holder of the payment instrument (2), wherein the electronic receipt account identifier (16) comprises a string of characters which results as output of a function that takes as input data a raw form or a processed form of at least one data from the group made of: a string of characters that is contained in a financial account identifier (CID) of the holder of the payment instrument (2) as set in the system of the issuing financial company (3) and a string of characters that is comprised in a second identifier (ID2) of the payment instrument (2) and a string of characters that is comprised in a third identifier (ID3) of the payment instrument (2);

- optionally, storing in a data memory or transmitting to at least one data interface a data set comprising at least one data from the group made of the server address (15) and the electronic receipt account identifier (16);

- optionally, creating an electronic message (20) that comprises the electronic receipt (12) and, optionally, comprises the electronic receipt account identifier (16);

- optionally, sending the electronic message (20) to the server address (15).

2. Method according to claim 1, characterized in that the first identifier (ID1) of the payment instrument (2) comprises at least part of the Primary Account Number of the payment instrument (2) and the identification code of the card payment organization (9) or of the issuing financial company (3) of the payment instrument (2) contains at least part of the Issuer Identification Number included in the Primary Account Number.

3. The method of claim 1, characterized in that it further comprises: - applying a hash function to the value of the electronic receipt account identifier (16) and assigning the output value of the hash function as the new value of the electronic receipt account identifier (16), so that it is not computationally feasible to deduce any part of any of the first identifier (ID1) and the second identifier (ID2) and the third identifier (ID3) of the payment instrument (2) departing from the new value of the electronic receipt account identifier (16).

4. Method according to claim 1, characterized in that it further comprises:

- transposing the initial character string that represents the expression of the electronic receipt account identifier (16) into a subsequent string of characters that are encoded through a greater number of bits than the number of bits by which were encoded the characters from the initial character string, so that the subsequent character string comprises less characters than the initial character string, in order to adapt the length of the string of the electronic receipt account identifier (16) to a length that is compatible with the technology of the electronic receipt server application (17).

5. Method according to claim 1, characterized in that it further comprises:

- receiving, by an electronic receipt server application (17), the electronic message (20) which contains the electronic receipt (12);

- reading the value of the electronic receipt account identifier (16) from the electronic message (20);

- verifying the existence of an electronic receipt deposit account that is uniquely correlated with the electronic receipt account identifier (16) and, if such a deposit account does not exist, creating a deposit account that is uniquely bound to the electronic receipt account identifier (16);

- depositing at least part of the electronic message (20) in the electronic receipt deposit account.

6. The method of claim 5, characterized in that it further comprises:

- creating a login account of the holder of the payment instrument (2) for retrieving his electronic receipts (12) within the electronic receipt deposit account, through an enrollment operation that comprises authenticating the user by performing an online authorization operation of a transaction performed with the payment instrument (2).

7. Method according to claim 5, characterized in that it further comprises:

- providing the electronic receipt server application (17) with a set of parameters as input data for setting at least one search criterion for an automatic search in a database (21) for certain electronic receipts (12) that comprise either electronic financial receipts or electronic copies of commercial receipts or both types of said electronic receipts;

- retrieving the electronic receipts (12) that meet the at least one search criterion;

- sending a notification to the electronic receipt deposit accounts of the holders of the electronic receipts (12) thus retrieved, and / or sending an electronic notification to an optional contact address of the respective holders.

8. A computer program (13), characterized in that it includes instructions which, when executed by a processor, determines performing the steps of the method of claim 1.

9. A system for the implementation of the method of claim 1 , characterized in that it comprises:

a computing device (1, 4) which comprises a processor and which is coupled with a data interface that is configured to read data from a memory (19) of the payment instrument (2); and

a computer program (13) which includes instructions which, when executed by said computing device (1, 4), determines performing the steps of the method of claim 1.

10. A computer program for the implementation of the electronic receipt server application (17) according to claim 5, characterized in that it includes instructions which, when executed by a processor, determines performing the following steps:

- receiving the electronic message (20) which contains the electronic receipt (12);