Method and system for matching electronic sales receipts to users of customer purchase transactions

Abstract

A method and system for matching of electronic sales receipts that identify a user by using payment account reference (PAR) instead of payment instrument information to protect personal information of the user. The use of the PAR provides a number of advantages. The PAR is considered to be non-sensitive data and cannot be abused outside the card network-the PAR cannot be used for payment, entirely different from the PAN (primary account, also known as a card number). Using PAR is a safer and faster way to identify transactions and users to issue digital receipts. The PAR remains unchanged regardless of card expiration, re-issuing, and the like.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to co-pending U.S. Provisional Application No. 63 / 322,029, filed on March 21, 2022, and relates to all subject matter common to both applications. The disclosure of the provisional application is incorporated herein by reference in its entirety. Technical Field

[0003] The present invention relates to a method and system for matching an electronic sales receipt resulting from a purchase transaction to a user. Background Art

[0004] Currently, users (e.g., private consumers, business users, companies, or others) can purchase and / or pay for items (physical or non-physical products or services) from a point-of-sale (POS), such as a brick-and-mortar store or online store or account. The point-of-sale prints a physical receipt, and / or transmits an electronic sales receipt via email, text, or other transmission technology. Alternatively, the receipt must be downloaded from a website.

[0005] Currently, there are very few ways to issue digital receipts that are full of friction, costly, extremely inconvenient, and rely on very sensitive cardholder data. Some of the best-known methods for obtaining digital receipts are nothing but friction, as they require customers to scan a QR code, and / or provide an email or phone number for each receipt to be issued digitally. These are truly outdated things in the digital receipt space.

[0006] Since the beginning of QR, email and SMS based receipts, new and smarter processes have emerged, namely technology that allows for automatic receipt issuance based on the customer’s payment card. This technology is specifically called “card linking” technology, which was developed for loyalty and has been inappropriately adapted and patched to meet the needs of issuing digital-only receipts.

[0007] Using "card linking", as part of this purchase transaction, the user typically provides a payment instrument, such as a PAN card, digital wallet, or payment device to initiate payment. Here, a PAN card refers to a payment instrument, such as a credit or debit card, which uses a Primary Account Number (PAN) to identify account information. This PAN is part of the information collected and used to process transactions, and in many cases it is part of the information used to identify and track transactions (along with the name on the card).

[0008] Card linking technology may be smart in a loyalty context as it allows a payment card to be linked to a customer, therefore allowing the customer's qualifying transactions to be identified. However, the technology was built for loyalty, which makes it very expensive in a digital receipt-only context. The current card linking process relies on multi-step and very expensive middleware - which is rife with loyalty technology for issuing digital receipts - which has many inherent disadvantages. Card linking technology that relies solely on the PAN as the primary identifier has significant risks and issues.

[0009] However, there is an increasing need in the industry to protect users' data. Likewise, consumers are increasingly concerned about privacy regarding the sharing of personal and / or sensitive information. For example, in many instances, merchants may not identify or only partially identify the PAN used in a transaction in the generated receipt data.

[0010] The PAN number is a highly sensitive payment initiator, meaning it first needs to be securely encrypted to PCI DSS standards, and it is only transmitted, processed, and stored in and between PCI DSS certified environments. This is a big problem because the closer the system / method is to the merchant, the further away the system / method is from a PCI DSS certified environment (since there is rarely PCI DSS certification at the merchant level). As a result, this results in unnecessary additions of steps and costs to the process of issuing a digital receipt, which overcomplicates the process. The closer the method / process is to the merchant level, the simpler and closer to real-time the steps for issuing a digital receipt, i.e. the added steps from the card linking method (which involves PAN) and other similar current methods, which equates to longer processing times, more computing power required, increased risk, and significantly higher costs for all parties involved.

[0011] The high sensitivity of the PAN also means that the PAN may or may not be renewed when the card is automatically renewed on a periodic basis. However, the PAN will always be renewed when the card is replaced. This poses a challenge to the card linking infrastructure because they need to capture new PAN input from the customer in order to be able to continuously identify and send receipts to the customer.

[0012] Digital payment wallets (such as Apple Pay TM and Google Pay TM) have also been hailed as a favourable payment option due to ease of use and reduced friction. However, this shift in the means of payment poses a major challenge to the current card-linked receipt infrastructure, which finds it difficult to adapt to fully cater to this shift. The reason is that these digital payment wallets mask the PAN with the device account number – the combination of a given payment card and a given device (smart watches, smartphones, tablets, computers and other smart devices that support payments) is given a unique device account number. The use of this number instead of the PAN forms part of the in-built security measures of the digital payment wallets, helping to protect the cardholder data during the payment transaction. As a result, the card-linking infrastructure finds it difficult to cope with it as the PAN is a unique identifier and when it is no longer easily available, it becomes increasingly difficult to identify and issue receipts to the customer. The card-linking infrastructure has not been successful in overcoming this challenge.

[0013] Another mechanism for protecting user data is the Payment Account Reference (PAR) number. PAR was introduced by EMVCo to address challenges faced by merchants and acquirers due to the reduction in the use of PAN, such as through tokenization (including PAN shielding in digital wallets). PAR enables merchants and acquirers to monitor and maintain fraud, loyalty, and reporting programs that currently depend on PAN. Payment Account Reference (PAR) is a value associated with a primary account number (PAN). PAR can link tokenized and PAN-based transactions without requiring PAN as a linking mechanism (PAR to PAN, 1:1). Although PAN is a sensitive transaction parameter, PAR is not sensitive data, nor is it Payment Card Industry (PCI) account data. Therefore, PAR can be used to identify users in place of PAN, and thereby enable merchants, payment processors, acquirers, BIN controller issuers, card schemes, POS systems, payment gateways, and service providers to uniquely identify cardholder accounts without continuing to expose and store PAN. Similarly, PAR can be used in place of PAN for inquiries to card schemes and issuers. It should be understood that PAR is only used to uniquely reference PAN and cannot be used to replace PAN in payment transaction processing. Thus, if cardholder data stored at a payment processor, acquirer, merchant, and / or service provider is compromised and / or stolen, the stored PAR number cannot be used to commit fraud.

[0014] Every time a PAN number is transmitted, processed or stored, it carries a significant amount of risk, and the risk is even greater when PAN data moves from one system / stakeholder to another. The more steps and system integrations there are, the greater the risk of PAN data being leaked / exposed. Another issue with the current card linking infrastructure for issuing digital receipts is that the customer's PAN number and the associated qualifying transaction are identified after payment authorization (the clearing phase of the transaction), depending on when the payment processor / acquirer allows the card scheme to identify the qualifying transaction, and therefore the customer. This process may occur instantly, and in some instances, may take longer (up to 1-3 days), depending on the country of purchase, the payment processor / acquirer, and whether it is a cross-border transaction. Summary of the invention

[0015] The present invention is directed to a further solution to address the aforementioned needs, in addition to having other desirable features. The present invention extends the personal identification protection functionality of PAR by enabling it to be used to identify users, to identify transactions and to issue electronic sales receipts in an unconventional manner. Specifically, the system and method for issuing electronic sales receipts of the present invention uses PAR instead of PAN (or any other potentially sensitive information) or other types of card linking technology to identify users and the transactions performed that result in the issuance of electronic sales invoices to users. The use of PAR provides several advantages. PAR numbers are considered non-sensitive data and are not subject to PCI requirements for protecting account data and cannot be abused outside of the card network - PAR numbers cannot be used for payments, which is completely different from PAN (primary account number, aka card number). Using PAR is a safer and faster way to identify transactions and users to issue digital receipts. PAR numbers can remain unchanged despite card expiration, reissue, etc. PAR does not have any other functions other than being able to identify customers and / or link the payment account represented by the PAN to an affiliated payment token. Therefore, in an ideal case, PAR can be stored in a non-PCI certified environment, such as a merchant's local POS system. Therefore, using PAR to issue digital receipts will allow several steps in the card linking infrastructure to be eliminated, thereby speeding up the process of issuing digital receipts closer to real time. However, the PAR lifecycle is determined by the Bank Identifier Number (BIN) controller.

[0016] At a very high level, issuing a receipt requires two things: 1) being able to identify the customer from the transaction, and 2) being able to take the SKU line item data based on the transaction information and match it to the customer's account. This is very problematic for the card linking infrastructure because the POS system has the data at the SKU line item level, but not the PAN (since the POS system cannot store the PAN because it requires the POS system to be PCI DSS authenticated), and the card linking infrastructure has the PAN but not the SKU line item level data. Therefore, when the card linking infrastructure issues a receipt to a customer, the process utilizes a large degree of guesswork based estimation, i.e., pairing the SKU line item data with the PAN data - they match the data from both systems based on parameters such as merchant ID, date and time stamp, transaction amount, merchant code, authorization code, last 4 PAN digits, terminal ID, currency code, etc. Therefore, the transaction and SKU line item data are not uniquely matched, but rather matched based on a method of elimination because all the necessary systems are unable to store or process the PAN. Ultimately, this exposes the card linking infrastructure to a large number of process failures; matches may not be unique, or time may not be properly synchronized between different infrastructure components. Matching with PAR, on the other hand, is unique in that the PAR data from the transaction can be matched 1-to-1 with the PAR data from the merchant’s POS system, as the storage and processing of the PAR data does not require PCI DSS compliance.

[0017] In summary, from a security / risk and processing perspective, the PAR infrastructure is far superior to the current card linking infrastructure because there are fewer steps overall, fewer sensitive PAN processing steps (if any), and fewer parameters that need to be analyzed, which means less computational processing power required and, therefore, faster receipt response delivery times (closer to real-time), more accurate and more secure / reliable identification, fewer errors, and less risk (leakage and exposure of sensitive PAN data). The traditional card linking infrastructure cannot compete with the equivalent PAR infrastructure at any level.

[0018] In order to be able to issue a digital sales receipt with line items based on PAR, there are three main data flows required: 1) obtaining the PAR (facilitating identification of the user), 2) payment or transaction data (notifying the system that one of the users has used their card), and 3) line item sales receipt data (allowing the receipt data to be extracted and issued to the user in a digital format). Each of these data flows can operate in a variety of ways and involve one or more actors.

[0019] 1) Obtaining PAR:

[0020] a) PAR can be obtained directly through the card schemes (Visa, MasterCard, Amex, etc.) via an API call which can mine and request a PAN to PAR exchange for any given card in any given card scheme.

[0021] b) PAR is available directly through the issuer (Citigroup, Bank of America, JPMorgan Chase, Amazon, Apple, etc.) via an API call which can mine and request a PAN to PAR exchange for any given card of any given customer of the issuer (and only the issuer's customers here).

[0022] c) PAR can be obtained directly from the user's payment device (smart watch, smartphone, tablet, computer and other payment-enabled smart devices) because the payment device can contain a PAR readable with a payment device reader (such as a payment terminal / payment device reader).

[0023] d) PAR may be obtained through a BIN controller which may issue a PAR, for example via an API call which may mine and request a PAN to PAR exchange.

[0024] e) PAR can be obtained through the merchant through a combination of the above, the merchant can provide registered users to receive a digital receipt when the user completes the purchase. PAR can be obtained directly from the completed purchase, or the PAN / token from the purchase can be used to obtain PAR and register the user through the merchant.

[0025] f) A combination of the above.

[0026] 2) Payment or transaction data:

[0027] a) The Sales Receipt System can obtain transaction data directly from the Issuer or BIN Controller; therefore, the Issuer or BIN Controller will provide notification when a transaction has been authorized / confirmed / cleared / settled for a user of the System.

[0028] b) The sales receipt system can obtain transaction data directly from the card scheme; thus, the card scheme is notified when a transaction has been authorized / confirmed / cleared / settled for a user of the system.

[0029] c) The sales receipt system can obtain transaction data directly from the acquirer or payment processor; therefore, the acquirer or payment processor will be notified when a transaction has been authorized / confirmed / cleared / settled for a user of the system.

[0030] d) The Sales Receipt System can obtain transaction data directly from the merchant (including POS system, payment terminal / payment device reader or payment gateway); therefore, the merchant will be notified when a transaction has been authorized / confirmed / cleared / settled for a user of the system.

[0031] e) A combination of the above.

[0032] 3) Sales receipt data:

[0033] a) The Sales Receipt System can obtain the receipt data from the Issuer (BIN Controller) - Here the Issuer is directly / indirectly integrated with the POS and / or merchant systems, where it is the Issuer that extracts or receives the data and pulls it into its system. The Sales Receipt System can leverage this integration between the POS (and / or merchant) and the Issuer, resulting in the Sales Receipt System being able to obtain the receipt data directly from the Issuer.

[0034] b) The sales receipt system can obtain receipt data from the card scheme - Here the card scheme is directly / indirectly integrated with the POS and / or merchant system, where it is the card scheme that extracts or receives the data and pulls it into its system. The sales receipt system can take advantage of this integration between the POS (and / or merchant) and the card scheme, resulting in the sales receipt system being able to obtain receipt data directly from the card scheme.

[0035] c) The sales receipt system can obtain receipt data from the acquirer and / or payment processor - Here the acquirer and / or payment processor is directly / indirectly integrated with the POS and / or merchant system, where it is the acquirer and / or payment processor that extracts or receives the data and pulls it into its system. The sales receipt system can just take advantage of this integration between the POS (and / or merchant) and the acquirer and / or payment processor, resulting in the sales receipt system being able to obtain receipt data directly from the acquirer and / or payment processor.

[0036] d) The sales receipt system can obtain the receipt data from the merchant (or POS system or payment gateway) - Here the sales receipt system can integrate itself directly with the merchant system, thus allowing the sales receipt system to extract or receive the receipt data directly from the merchant system.

[0037] e) A combination of the above.

[0038] This is the matching of transaction or payment data (point 2) with receipt data (point 3), which is a challenge as few merchant systems cater to the use of PAR. Therefore, for this linkage of data, the sales receipt system should not rely solely on PAR, but expand the scope to not only PAR, but also other payment / transaction parameters that can be used to identify the transaction, such as transaction ID, amount, date, time, etc. In an ideal situation, PAR would be a unique identifier that is unique in both systems (point 2 and point 3), but given the way the world actually operates, other payment / transaction parameters need to be considered.

[0039] Furthermore, in an ideal scenario, where PAR becomes more widespread and accepted, and PAR is non-PCI account data and cannot be misused to authorize or initiate financial transactions, PAR could be stored locally on all POS devices in the future, which would further reduce processing time and costs.

[0040] According to an embodiment of the present invention, a method for matching an electronic sales receipt to a user of a purchase transaction of a customer of a user is provided. The method includes: a merchant computing system receives payment data via a payment instrument, the payment instrument having payment instrument information provided to complete payment of a purchase transaction of a customer; the merchant computing system communicates the payment instrument information to a payment processor computing system; the payment processor computing system processes the payment, stores payment data of the purchase transaction including a reference to a customer payment account reference (PAR) number in a data repository, and confirms the processing of the payment by the merchant computing system; the merchant computing system completes the purchase transaction and stores the sales receipt data in the merchant data repository; a sales receipt computing system having a customer PAR associated with a user stored thereon receives the payment data, wherein the customer is identified by the customer PAR; the sales receipt computing system receives the sales receipt data generated by the merchant computing system; and the sales receipt computing system matches the payment data and the sales receipt data to the user using the customer PAR, and does not require a payment instrument or payment instrument information. The matching enables an electronic sales receipt to be issued to the user.

[0041] According to an aspect of the invention, the payment instrument comprises one of: a primary account number (PAN) and a token corresponding to the PAN or a PAN derivative.

[0042] According to aspects of the invention, a customer PAR is provided with a payment instrument. In other aspects, the customer PAR is provided to a payment processor computing system as part of payment processing. In some such aspects, the customer PAR is provided to a payment processor computer system by an acquirer, card scheme, or issuer computing system.

[0043] According to aspects of the invention, the method further includes the sales receipt computing system receiving a primary account number (PAN), sending the PAN to an issuer or card scheme to request a PAR corresponding to the PAN, receiving a customer PAR in response to the request, and storing the customer PAR.

[0044] According to aspects of the invention, processing a payment includes providing payment instrument information to one or more of an acquirer, a card scheme, and an issuer and in response receiving payment data for a purchase transaction from one or more of the acquirer, the card scheme, and the issuer.

[0045] According to aspects of the invention, the payment processing confirmation includes a payment authorization message sent to the sales receipt computing system.

[0046] According to aspects of the invention, the payment data received by the sales receipt computing system is provided by the payment processing computing system. In some such aspects, the payment processing computing system provides the payment data to the sales receipt computing system when the payment processing is confirmed. In some such aspects, receiving the payment data includes the sales receipt computing system requesting the payment data from the payment processing computing system using the customer PAR, and receiving the payment data stored in the payment processor data repository including a reference to the customer PAR in response to the request. In further aspects, receiving the payment data from the payment processor computing system also includes the payment processing computing system receiving a request for payment data from the sales receipt computing system, identifying the payment data stored in the payment processor data repository including a reference to the customer PAR, and providing the sales receipt computing system with the identified payment data stored in the payment processor data repository including a reference to the customer PAR.

[0047] According to aspects of the invention, payment data received by a sales receipt computing system is provided by an acquirer computing system involved in a payment process. In some such aspects, the acquirer computing system provides the payment data to the sales receipt computing system when the payment process is confirmed. In other aspects, receiving the payment data includes the sales receipt computing system requesting the payment data from the acquirer computing system using the customer PAR and receiving the payment data stored in the acquirer data repository including a reference to the customer PAR in response to the request. In some such aspects, receiving the payment data from the acquirer computing system also includes the acquirer computing system receiving a request for payment data from the sales receipt computing system, identifying the payment data stored in the acquirer data repository including a reference to the customer PAR, and providing the sales receipt computing system with the identified payment data stored in the acquirer data repository including a reference to the customer PAR.

[0048] According to aspects of the invention, the payment data received by the sales receipt computing system is provided by a card scheme computing system involved in the processing of the payment. In some such aspects, the card scheme computing system provides the payment data to the sales receipt computing system when the payment processing is confirmed. In other aspects, receiving the payment data includes the sales receipt computing system requesting the payment data from the card scheme computing system using the customer PAR, and receiving the payment data stored in the card scheme data repository including a reference to the customer PAR in response to the request. In some such aspects, receiving the payment data from the card scheme computing system also includes the card scheme computing system receiving a request for the payment data from the sales receipt computing system, identifying the payment data stored in the card scheme data repository including a reference to the customer PAR, and providing the sales receipt computing system with the identified payment data stored in the card scheme data repository including a reference to the customer PAR.

[0049] According to aspects of the invention, the payment data received by the sales receipt computing system is provided by an issuer computing system involved in a payment process. In some such aspects, the issuer computing system provides the payment data to the sales receipt computing system when the payment process is confirmed. In other aspects, receiving the payment data includes the sales receipt computing system requesting the payment data from the issuer computing system using the customer PAR and receiving the payment data stored in the issuer data repository including a reference to the customer PAR in response to the request. In some such aspects, receiving the payment data from the issuer computing system also includes the issuer computing system receiving a request for the payment data from the sales receipt computing system, identifying the payment data stored in the issuer data repository including a reference to the customer PAR, and providing the sales receipt computing system with the identified payment data stored in the issuer data repository including a reference to the customer PAR.

[0050] According to aspects of the invention, the payment data received by the sales receipt computing system is provided by a merchant computing system. In some such aspects, the merchant computing system provides the payment data to the sales receipt computing system upon completion of the purchase transaction. In other aspects, receiving the payment data includes the sales receipt computing system requesting the payment data from the merchant computing system using the customer PAR and receiving, and in response to the request, the payment data stored in a merchant data repository including a reference to the customer PAR. In some such aspects, receiving the payment data from the merchant computing system also includes the merchant computing system receiving a request for the payment data from the sales receipt computing system, identifying the payment data stored in the merchant data repository including a reference to the customer PAR, and providing the sales receipt computing system with the identified payment data stored in the POS and / or merchant data repository including a reference to the customer PAR.

[0051] According to aspects of the invention, the sales receipt data received by the sales receipt computing system is provided by a merchant computing system. In some such aspects, the merchant computing system provides the sales receipt data to the sales receipt computing system when the purchase transaction is completed. In other aspects, receiving the sales receipt data from the merchant computing system includes the sales receipt computing system extracting transaction parameters from the received payment data; requesting the sales receipt data from the merchant computing system using the extracted transaction parameters; and receiving the sales receipt data stored in the merchant data repository in response to the request. In some such aspects, the transaction parameters include one or more of the following: merchant / POS of the transaction, transaction ID, merchant / POS ID, merchant code, authorization code, last 4 PAN digits, first 6 PAN digits, PAR, PAN token / derivative, terminal ID, currency code, amount of the transaction, date of the transaction, and time of the transaction. In further aspects, receiving the sales receipt data from the merchant computing system also includes the merchant computing system receiving a request for sales receipt data from the sales receipt computing system; identifying the sales receipt data stored in the merchant data repository including the transaction data; and providing the sales receipt computing system with the identified sales receipt data stored in the merchant data repository. In still further aspects, the sales receipt data stored in the data repository includes a customer PAR. In some such aspects, receiving the sales receipt data from the merchant computing system includes the sales receipt computing system requesting the sales receipt data from the merchant computing system using the customer PAR and, in response to the request, receiving the sales receipt data stored in the merchant data repository including a reference to the customer PAR. In some such further aspects, receiving the sales receipt data from the merchant computing system also includes the merchant computing system receiving a request for sales receipt data from the sales receipt computing system; identifying sales receipt data stored in the merchant data repository including a reference to the customer PAR; and providing the identified sales receipt data stored in the POS data repository including a reference to the customer PAR to the sales receipt computing system.

[0052] According to aspects of the invention, the sales receipt data received by the sales receipt computing system is provided by the payment processing computing system. In some such aspects, the payment processing computing system provides the sales receipt data to the sales receipt computing system when the purchase transaction is completed. In other aspects, receiving the sales receipt data from the payment processing computing system includes the sales receipt computing system extracting transaction parameters from the received payment data; requesting the sales receipt data from the payment processing computing system using the extracted transaction parameters; and receiving the sales receipt data stored in the payment processor data repository in response to the request. In some such aspects, the transaction parameters include one or more of the following: merchant / POS of the transaction, transaction ID, merchant / POS ID, merchant code, authorization code, last 4 PAN digits, first 6 PAN digits, PAR, PAN token / derivative, terminal ID, currency code, amount of the transaction, date of the transaction, and time of the transaction. In further aspects, receiving sales receipt data from a payment processing computing system further comprises the payment processing computing system receiving a request for sales receipt data from the sales receipt computing system; identifying sales receipt data stored in a payment processing data repository including transaction data; and providing the sales receipt computing system with the identified sales receipt data stored in the payment processing data repository. In still further aspects, the sales receipt data stored in the data repository includes a customer PAR. In some such aspects, receiving sales receipt data from a payment processing computing system comprises the sales receipt computing system requesting sales receipt data from the payment processing computing system using the customer PAR; and, in response to the request, receiving sales receipt data stored in the payment processing data repository including a reference to the customer PAR. In some such further aspects, receiving sales receipt data from a payment processing computing system further comprises the payment processing computing system receiving a request for sales receipt data from the sales receipt computing system; identifying sales receipt data stored in the payment processing data repository including a reference to the customer PAR; and providing the sales receipt computing system with the identified sales receipt data stored in the payment processing data repository including a reference to the customer PAR.

[0053] According to aspects of the invention, sales receipt data received by a sales receipt computing system is provided by an acquirer computing system involved in processing a payment. In some such aspects, the acquirer computing system provides the sales receipt computing system with the sales receipt data upon completion of a purchase transaction. In other aspects, receiving the sales receipt data from the acquirer computing system includes the sales receipt computing system extracting transaction parameters from the received payment data; requesting the sales receipt data from the acquirer computing system using the extracted transaction parameters; and, in response to the request, receiving the sales receipt data stored in an acquirer data repository. In some such aspects, the transaction parameters include one or more of: merchant / POS of the transaction, transaction ID, merchant / POS ID, merchant code, authorization code, last 4 PAN digits, first 6 PAN digits, PAR, PAN token / derivative, terminal ID, currency code, amount of the transaction, date of the transaction, and time of the transaction. In other aspects, receiving sales receipt data from an acquirer computing system further comprises the acquirer computing system receiving a request for sales receipt data from the sales receipt computing system; identifying sales receipt data stored in an acquirer data repository including transaction data; and providing the identified sales receipt data stored in the acquirer data repository to the sales receipt computing system. In still other aspects, the sales receipt data stored at the acquirer includes a customer PAR. In some such aspects, receiving sales receipt data from the acquirer computing system comprises the sales receipt computing system requesting the sales receipt data from the acquirer computing system using the customer PAR; and, in response to the request, receiving the sales receipt data stored in the acquirer data repository including a reference to the customer. Further in some such aspects, receiving sales receipt data from the acquirer computing system also includes the acquirer computing system receiving a request for sales receipt data from the sales receipt computing system; identifying sales receipt data stored in the acquirer data repository that includes a reference to the customer PAR; and providing the identified sales receipt data stored in the acquirer data repository that includes a reference to the customer PAR to the sales receipt computing system.

[0054] According to aspects of the invention, sales receipt data received by a sales receipt computing system is provided by a card scheme computing system involved in processing a payment. In some such aspects, the card scheme computing system provides the sales receipt computing system with the sales receipt data upon completion of a purchase transaction. In other aspects, receiving the sales receipt data from the card scheme computing system includes the sales receipt computing system extracting transaction parameters from the received payment data; requesting the sales receipt data from the card scheme computing system using the extracted transaction parameters; and, in response to the request, receiving the sales receipt data stored in a card scheme data repository. In further aspects, the transaction parameters include one or more of: merchant / POS of the transaction, transaction ID, merchant / POS ID, merchant code, authorization code, last 4 PAN digits, first 6 PAN digits, PAR, PAN token / derivative, terminal ID, currency code, amount of the transaction, date of the transaction, and time of the transaction. In some further aspects, receiving sales receipt data from a card scheme computing system further comprises the card scheme computing system receiving a request for sales receipt data from the sales receipt computing system; identifying sales receipt data stored in a card scheme data repository including transaction data; and providing the identified sales receipt data stored in the card scheme data repository to the sales receipt computing system. In some such further aspects, the sales receipt data stored in the card scheme includes a customer PAR. Still further in some such aspects, receiving sales receipt data from a card scheme computing system comprises the sales receipt computing system requesting sales receipt data from the card scheme computing system using the customer PAR, and receiving sales receipt data stored in the card scheme data repository including a reference to the customer in response to the request. In some such aspects, receiving sales receipt data from a card scheme computing system further comprises the card scheme computing system receiving a request for sales receipt data from the sales receipt computing system, identifying sales receipt data stored in the card scheme data repository including a reference to the customer PAR, and providing the identified sales receipt data stored in the card scheme data repository including a reference to the customer PAR to the sales receipt computing system.

[0055] According to aspects of the invention, sales receipt data received by a sales receipt computing system is provided by an issuer computing system involved in processing a payment. In some such aspects, the issuer computing system provides the sales receipt data to the sales receipt computing system upon completion of a purchase transaction. In other aspects, receiving the sales receipt data from the issuer computing system includes the sales receipt computing system extracting transaction parameters from the received payment data; requesting the sales receipt data from the issuer computing system using the extracted transaction parameters; and receiving the sales receipt data stored in the issuer data repository in response to the request. In some such aspects, the transaction parameters include one or more of: merchant / POS of the transaction, transaction ID, merchant / POS ID, merchant code, authorization code, last 4 PAN digits, first 6 PAN digits, PAR, PAN token / derivative, terminal ID, currency code, amount of the transaction, date of the transaction, and time of the transaction. In other such aspects, receiving sales receipt data from an issuer computing system further comprises the issuer computing system receiving a request for sales receipt data from the sales receipt computing system; identifying the sales receipt data stored in an issuer data repository including transaction data; and providing the identified sales receipt data stored in the issuer data repository to the sales receipt computing system. In still other aspects, the sales receipt data stored at the issuer includes a customer PAR. In some such other aspects, receiving sales receipt data from an issuer computing system comprises the sales receipt computing system requesting sales receipt data from the issuer computing system using the customer PAR and, in response to the request, receiving sales receipt data stored in the issuer data repository including a reference to the customer. Still further in some such aspects, receiving sales receipt data from an issuer computing system further comprises the issuer computing system receiving a request for sales receipt data from the sales receipt computing system; identifying the sales receipt data stored in the issuer data repository including a reference to the customer PAR; and providing the identified sales receipt data stored in the issuer data repository including a reference to the customer PAR to the sales receipt computing system.

[0056] According to aspects of the invention, further comprising storing one or more of the payment data, the receipt data, and the electronic sales receipt in which the user is identified by the PAR in a data repository of the sales receipt computing system.

[0057] According to aspects of the invention, a merchant computing system comprises a point of sale (POS) system. In other aspects, a merchant computing system comprises a payment gateway. In still other aspects, a merchant computing system comprises a payment terminal or a payment device reader.

[0058] According to aspects of the invention, the method includes the sales receipt calculation system issuing an electronic sales receipt to a user. In other aspects, the method further includes providing payment data and sales receipt data matched / linked with the user to one or more of: a merchant, a payment processor, an acquirer, a card scheme, and an issuer so that an electronic sales receipt can be issued to the user.

[0059] According to aspects of the invention, a sales receipt computing system receives PARs from one or more of: a user, a merchant, a payment processor, an acquirer, a card scheme, and an issuer.

[0060] According to an embodiment of the present invention, a system for matching an electronic sales receipt to a user of a customer purchase transaction is provided, the system comprising a merchant computing system, a payment processor, and a sales receipt computing system. The merchant computing system comprises a processor and a data store, and is configured to: receive payment data via a payment instrument having payment instrument information provided to complete payment for a customer purchase transaction; communicate the payment instrument information to the payment processor computing system; receive confirmation of payment processing; complete the purchase transaction; and store the sales receipt data in a data repository. The payment processor computing system comprises a processor and a data store, and is configured to: receive payment instrument information from the merchant computing system; process payment; store payment data for the purchase transaction including a reference to the customer in the data repository; and confirm processing of the payment by the merchant computing system. The sales receipt computing system includes a processor and a data store, and is configured to: store a customer payment account reference (PAR) associated with a user in a data repository; receive payment data; store the received payment data in the data repository; receive sales receipt data generated by a merchant computing system; store the received sales receipt data in the data repository; and match the payment data and the sales receipt data to the user using the PAR, wherein the matching enables an electronic sales receipt to be issued to the user and stored in the data repository.

[0061] According to an embodiment of the present invention, a method for issuing an electronic sales receipt to a user of a customer purchase transaction is provided. The method involves: a merchant computing system receiving payment data via a payment instrument having payment instrument information provided for completing payment for a customer purchase transaction; the merchant computing system communicating the payment instrument information to a payment processor computing system; the payment processor computing system processing the payment, storing the payment data for the purchase transaction in a payment processor data repository, and confirming the processing of the payment with the merchant computing system; the merchant computing system completing the purchase transaction and storing the sales receipt data in the merchant data repository, receiving the payment data, matching the payment data and the sales receipt data to the user using a payment account reference (PAR), and issuing an electronic sales receipt to the sales receipt computing system, the sales receipt computing system storing the electronic sales receipt in the data store; and the sales receipt computing system providing access to the electronic sales receipt to the user.

[0062] According to an embodiment of the present invention, a system for issuing an electronic sales receipt for a customer purchase transaction to a user is provided, the system comprising a merchant computing system, a payment processing system, and a sales receipt computing system. The merchant computing system comprises a processor and a data store, and is configured to: receive payment data via a payment instrument having payment instrument information provided for completing payment for a customer purchase transaction; communicate the payment instrument information to the payment processor computing system; receive confirmation of payment processing; complete the purchase transaction; store the sales receipt data in a data repository; receive payment data; store the payment data in the data repository; match the payment data with the sales receipt data; and issue an electronic sales receipt to the user using a customer payment account reference (PAR) instead of a payment instrument or payment instrument information. The payment processor computing system comprises a processor and a data store and is configured to: receive payment instrument information from the merchant computing system; process payment; store the payment data for the purchase transaction in the data repository; and confirm the processing of the payment with the merchant computing system. The sales receipt computing system includes a processor and data storage and is configured to: receive an electronic sales receipt issued from a merchant; store the electronic sales receipt in a data repository; and provide access to the electronic sales receipt to a user using a customer PAR. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] These and other features of the present invention will be more fully understood by reference to the following detailed description taken in conjunction with the accompanying drawings, in which:

[0064] Figure 1 is an example system for monitoring purchase transactions at a point of sale and issuing an electronic sales receipt to a user based on the transactions according to an embodiment of the present invention;

[0065] Figure 2is a flow chart depicting an example method for issuing an electronic sales receipt to a user for a customer purchase transaction;

[0066] Figure 3 is a flow chart depicting an example method of performing a PAN to PAR exchange;

[0067] Figure 4 is a flow chart depicting an example method of requesting payment data;

[0068] Figure 5 is a flow chart depicting an example method of receiving a request for payment data;

[0069] Figure 6 is a flow chart depicting an example method for requesting receipt data;

[0070] Figure 7 is a flow chart depicting an example method of receiving a request for receipt data; and

[0071] Figure 8 is a block diagram of an example computing device for implementing an electronic sales receipt system. DETAILED DESCRIPTION

[0072] Illustrative embodiments of the present invention relate to a method and system for issuing electronic sales receipts that identify users by using a Payment Account Reference (PAR) number instead of payment instrument information to protect the user's personal information. The use of PAR provides several advantages. PAR numbers are considered non-sensitive data and non-PCIDSS account data and cannot be abused outside of the card network - PAR numbers cannot be used for payments, which is completely different from PAN (primary account number, aka card number). Using PAR is a safer, faster and frictionless way to identify transactions and users to issue digital sales receipts. PAR numbers will remain unchanged in most cases despite card expiration, reissue, etc.

[0073] Figures 1 to 8 One or more exemplary embodiments of the method and system for issuing electronic sales receipts according to the present invention are shown, wherein like parts are designated by like reference numerals throughout. Although the present invention will be described with reference to one or more exemplary embodiments shown in the accompanying drawings, it should be understood that many alternative forms can embody the present invention. Those skilled in the art will additionally understand different ways to change parameters of the disclosed embodiments, such as size, shape or type of components or materials, in a manner that still complies with the spirit and scope of the present invention.

[0074] Figure 1 A system 100 for processing and tracking customer purchase transactions and issuing electronic sales receipts is depicted in FIG.

[0075] The system 100 includes a merchant 102, a user 104, a payment processor 106, and a sales receipt system 108. In some embodiments, the system 100 may also include one or more of an acquirer 110, a card scheme 112, and a card issuer (or BIN controller) 114. Each of these components communicates with other components of the system 100. For example, the components 102, 104, 106, 108, 110, 112, and 114 may communicate electronically, such as through a network. It should also be understood that one or more of the components 102, 104, 106, 108, 110, 112, and 114 (or some or all of the functionality provided by them) may be combined with or otherwise found in other components 102, 104, 106, 108, 110, 112, and 114.

[0076] Merchant 102 is a place where customers pay for goods or services (such as merchants or suppliers). It may include a point of sale (POS) system 115, a payment terminal / payment device reader 116, and / or a payment gateway 117 including software, hardware, or a combination of both.

[0077] POS system 115 is software and / or hardware typically used to receive, process and store information about payment of goods or services when conducting transactions at merchants. Payment terminal or payment device reader 116 is hardware for reading and accepting payment instruments of PAN card (credit card or debit card) type. Payment gateway 117 is software and / or hardware typically used to receive, process and store information about payment of goods or services when conducting transactions online. Payment terminal or payment device reader 116 and / or payment gateway 117 can be part of POS system 115 or separate. In some instances, POS system 115, payment terminal or payment device reader 116, or payment gateway 117 including necessary software and hardware are provided by separate or third parties contracted by merchants 102. Regardless of the implementation method, POS system 115, payment terminal or payment device reader 116 and / or payment gateway 117 provide necessary functions for merchants to conduct transactions using credit cards, debit cards, digital wallets or PAN cards, and will be considered as part of the functions provided by merchants 102 for the purpose of this disclosure.

[0078] Merchant 102 receives the payment information and records the details of the transaction as sales receipt data. It can be at a physical store or a virtual point of sale, such as an online store, an online store, a computer or mobile electronic device, or any combination thereof. In this example, merchant 102 also includes a data repository 118 for storing sales receipt data for purchase transactions and, in some instances, payment or transaction data.

[0079] Sales receipt data may include detailed and relevant information such as merchant data (name, address, ID number), receipt / order ID, date and time, barcode, cash register, return policy, loyalty, rewards, employee details, notes, references, a description or list of each item purchased and the cost of each item, the category of items purchased, the total cost of all items, plus a description or list of any taxes or fees paid or discounts applied. In contrast, payment or transaction data, such as provided in a PAN card (e.g., credit or debit card) receipt, only specifies the total amount to be charged, without providing a detailed breakdown and description of each individual line item, discount, tax or fee that makes up the total amount to be charged. Furthermore, by law, PAN card (credit / debit card) receipts cannot be used for financial accounting, tax deductions, VAT, etc., while sales receipts can be used for financial accounting, tax deductions, VAT, etc.

[0080] The user 104 is the owner or individual associated with a payment instrument 119 being used to transact with the merchant 102. In some instances, the user 104 may be a customer transacting with the merchant 102. In other instances, the customer conducting the transaction may be an agent of the user 104 with whom the payment instrument 118 is associated. The payment instrument 119 used to conduct the transaction is a primary account number (PAN) of a PAN card (such as a credit or debit card) or a token corresponding to the PAN.

[0081] The payment processor 106 is the entity designated by the merchant 102 to process payment instrument 119 (credit card, debit card, etc.) transactions. The payment processor 106 has the infrastructure and technical connections necessary to authorize transactions and move them through the entities involved in the processing of payments. It also manages the process of settling funds - moving funds from the issuer 114 to the acquirer 110. In this example, the payment processor 106 also includes a data repository 120 for storing payment or transaction data for purchase transactions.

[0082] The sales receipt system 108 maintains an account for the user 104 and receives and / or collects payment or transaction data and receipt data associated with purchase transactions conducted using a payment instrument 119 associated with the user 104, and matches the payment data and receipt data to the user 104 using the PAR to issue an electronic sales receipt to the user 104. The sales receipt system 108 need not store sensitive payment instrument information for the user 104 but instead can use the PAR to track transactions conducted by the user 104 using the payment instrument 119. The sales receipt system 108 may further include a data repository 122 for storing data such as: account data including the PAR for the user 104, payment data for the purchase transactions, and sales receipt data for the purchase transactions.

[0083] Acquirer 110 is a financial institution that handles funds for merchant 102. Sometimes acquirer 110 is the same entity as payment processor 106. In some embodiments, acquirer 110 may further include a data repository 124 for storing payment data for purchase transactions and, in some instances, sales receipt data for purchase transactions.

[0084] Card schemes 112 are payment networks that are linked to payment cards, such as debit cards, credit cards, or other PAN cards, of which banks or any other eligible financial institutions can become members. Examples of such card schemes include Visa TM 、Mastercard TM 、American Express TM , Dankort TM 、UnionPay TM and Discover TM In some embodiments, the card scheme 112 may further include a data repository 126 for storing payment data for purchase transactions and, in some instances, sales receipt data for purchase transactions.

[0085] Issuer 114 is a financial institution that represents user 104 in a financial transaction and issues payment instruments 119 to user 104 for use in the transaction. In some instances, issuer 114 may also include a BIN controller. In certain embodiments, issuer 114 may further include a data repository 128 for storing payment data for purchase transactions and, in some instances, sales receipt data for purchase transactions.

[0086] The operation of the system 100 is Figure 2 Before any electronic sales receipts can be issued, the user 104 needs to register with the sales receipt system 108 (step 202). This involves interaction between the user 104 and the sales receipt system 108, in this case electronic communication, such as Figure 1146 and arrow 148. Such registration 202 includes providing information about the user 104 that is typically required for setting up an account, including name, contact information PAN number or PAN token / equivalent (to be used for the PAN to PAR exchange described herein), etc. In some embodiments, this is performed via the sales receipt system's own web interface or the sales receipt system's own application on the user's 104 computing device, or directly via the merchant's own system, via a service provider / partner / customer of the sales receipt system (such as a bank, issuer, expense management system or other receipt provider), or a combination thereof. As part of the process, the PAR for the user 104 is stored on the sales receipt system 108 as part of the user's account. The PAR may be provided by the user 104, the payment instrument 119, or the merchant 102, or obtained by performing a PAN to PAR exchange. Figure 3 Further discussion of obtaining PAR is provided.

[0087] Figure 3 An example method 300 for performing a PAN to PAR exchange is depicted. A PAN or PAN token or PAN equivalent or PAN derivative of a credit card, debit card, or PAN card is sent to a card scheme 112 or issuer (or BIN controller 114) to request a PAR corresponding to the PAN or PAN token or PAN equivalent or PAN derivative (step 302). The corresponding PAR is then received in response to the request (step 304). The PAR may then be stored (step 306). This type of PAN to PAR exchange may be performed by any entity (merchant 102, user 104, etc.). In an example where the exchange is performed by the sales receipt system 108, for example, the communication between the sales receipt system 108 and the card scheme is performed by Figure 1 The communication with the issuer 114 is indicated by arrows 166 and 168. Figure 1 Indicated by arrows 170 and 172 in FIG.

[0088] Figure 2 The registration of a registered user as described in (step 202) need only occur once, and each of a user's PAN or PAN token or PAN equivalent or PAN derivative may only be registered once, after which any number of transactions may be processed by the system, and electronic sales receipts may be issued by the system using the user account data as described in the remainder of method 200 beginning with step 204. However, a user account may be updated in a similar manner to include changes to the user data.

[0089] Any given customer purchase transaction begins with the merchant 102 accessing the POS system (such as Figure 1The terminal / payment device reader (or payment gateway) indicated by arrow 130 in FIG. 1 receives payment data from a payment instrument 119 having payment instrument information for a customer purchase transaction (step 204). Information for the payment instrument 119 may be provided electronically or physically, such as by providing a PAN card such as a credit or debit card for reading by a device at device 1102.

[0090] The merchant 102 then communicates the payment instrument information to the payment processor 106 computing system, such as Figure 1 134 in (step 206). Payment processor 106 then processes the payment (step 208). In some embodiments, processing the payment involves providing payment instrument information to the purchase transaction and in response receiving payment data for the purchase transaction from one or more of the acquirer, card scheme, and issuer. The transmission of such data may occur through direct or indirect communication. For example, in Figure 1 , the payment processor 106 may provide payment instrument information to the acquirer 110 as indicated by arrow 150. In response, the acquirer 110 provides payment data as indicated by arrow 152. The acquirer 110 may, in turn, obtain payment information from the card scheme 112 by providing payment instrument information to the card scheme 112 (as indicated by arrow 154) and receiving payment data in response (as indicated by arrow 156). Similarly, the card scheme 112 may obtain payment data from the card issuer (or BIN controller) 114 by providing payment instrument information to the card issuer 112 (as indicated by arrow 158) and receiving payment data in response (as indicated by arrow 160). It should be understood that such interactions to obtain payment data may occur between any of the entities 102, 106, 110, 112, 114. For example, where the payment processor 106 and the acquirer 110 are the same entity, the payment processor 106 may communicate with the card scheme 112 and / or the issuer 114 to obtain payment data.

[0091] The payment data is stored in the payment processor data repository 120 (step 210). In some embodiments, the payment data includes a customer PAR. In some such embodiments, the customer PAR is provided to the payment processor 106 along with the payment instrument 119. In other embodiments, the customer PAR is obtained by the payment processor computing system as part of the payment processing. For example, the customer PAR may be provided to the payment processor 106 by the acquirer 110, the card scheme 112, or the issuer (or BIN controller) 114.

[0092] The payment processor 106 then confirms the processing of the payment with the merchant 102 (step 212). In some embodiments, the processing of confirming the payment may also include providing a payment authorization message that is sent to the sales receipt system 108. In some embodiments, payment data may also be provided to the merchant 102 as part of the payment confirmation. In some instances, this data includes a PAR. The payment data may be stored in the merchant's 102 data repository 117.

[0093] The merchant 102 then completes the purchase transaction (step 214). In some embodiments, this includes printing a physical sales receipt for the user 104, such as Figure 1 The sales receipt data is then stored in the merchant data repository 118 (step 216). In some embodiments, the data may also include PAR.

[0094] The sales receipt system 108 then receives the payment data, or a portion of the payment data, (step 218). As previously indicated, the user is identified by a customer PAR stored in the data repository 122 of the sales receipt system 108. Using the PAR, the sales receipt system 108 can identify which payment data is associated with the user. The payment data can be received from the payment processor 106, the acquirer 110, the card scheme 112, the issuer (or BIN controller) 114, or even the merchant 102. As previously discussed with respect to payment processing (step 208), any one or more of these entities can provide the payment data. The payment data can be provided with or without being requested. For example, in some embodiments, the payment data is provided to the sales receipt system 108 by the merchant 102, the payment processor 106, the acquirer 110, the card scheme 112, or the issuer (or BIN controller) 114 when the payment is confirmed. In other embodiments, the payment data is provided in response to a request from the sales receipt system 108. In some embodiments, the request is made using the customer PAR. Figure 4 An example method 400 is provided for executing by the sales receipt system 108 to request payment data from the payment processor 106, the acquirer 110, the card scheme 112, the issuer (or BIN controller) 114, or the merchant 102, while Figure 5 An example method 500 is provided that is performed by a payment processor 106 , an acquirer 110 , a card scheme 112 , an issuer (or BIN controller) 114 , or a merchant 102 in response to a request from a sales receipt system 108 .

[0095] In some such embodiments, Figure 4As described, the sales receipt system 108 may make a request for payment data to one or more of the merchant 102, payment processor 106, acquirer 110, card scheme 112, or issuer (or BIN controller) 114 using the customer PAR stored in the data repository 122 (step 402), and in response receive the payment data including the customer PAR provided by the customer, which is stored in the response data repository 116, 120, 124, 126, 128 of the merchant 102, payment processor 106, acquirer 110, card scheme 112, or issuer 114 to which the request was made.

[0096] (Step 404).

[0097] exist Figure 5 In the embodiment described in , the merchant 102, payment processor 106, acquirer 110, card scheme 112, or issuer (or BIN controller) 114 to which the request for payment data is directed receives a request for payment data including a provided customer PAR. The payment data including the provided customer PAR is identified in the corresponding data stores 117, 120, 124, 126, and 128 (step 504). The identified payment data including the customer PAR is provided to the requestor, in this case the sales receipt system 108 (step 506).

[0098] However, it should be noted that payment data may also be provided without being requested. In some embodiments, the corresponding data repositories 117, 120, 124, 126, and 128 may be configured to automatically provide payment data to the sales receipt system 108. It should also be understood that a request may be made without using PAR. In such embodiments, the request and response are similar to those described below with reference to Figure 6 and Figure 7 The process for requesting and receiving sales receipt data is described, under which other transaction parameters may be used to identify the transaction, including but not limited to merchant / POS, transaction ID, merchant / POS ID, merchant code, authorization code, last 4 PAN digits, first 6 PAN digits, PAN token / derivative, terminal ID, currency code, transaction amount, transaction date, and transaction time.

[0099] Communications with merchant 102 are performed by Figure 1 The communication with the payment processor 106 is indicated by arrows 138 and 140. Figure 1 The communication with the acquirer 110 is indicated by arrows 142 and 144. Figure 1 The communication with the card scheme 112 is indicated by arrows 162 and 164. Figure 1The communication with the issuer (or BIN controller) 114 is indicated by arrows 166 and 168 in FIG. Figure 1 Indicated by arrows 170 and 172 in FIG. In some embodiments, such communication is performed via an API call, webhook, or similar means of communication between systems / computer devices / databases. It should also be understood that Figure 4 and Figure 5 The method may also be used to request payment data between any of the payment processor 106, acquirer 110, card scheme 112, or issuer (or BIN controller) 114.

[0100] Reference Figure 2 In addition to receiving the payment data (step 218), the sales receipt system 108 receives sales receipt data (step 220). Although the sales receipt data is typically generated and stored at the merchant 102 (step 216), the sales receipt data may also be received from the payment processor 106, the acquirer 110, the card scheme 112, or the issuer (or BIN controller) 114. In certain embodiments, the payment processor 106, the acquirer 110, the card scheme 112, or the issuer (or BIN controller) 114 may have access to the sales receipt data through direct or indirect communication with the merchant 102. Such communications are indicated by arrows 134, 136, 150, 152, 154, 156, 158, 160, 172, 174, 176, 178, 180, and 182.

[0101] The sales receipt data may be provided with or without being requested. For example, in some embodiments, the sales receipt data is provided to the sales receipt system 108 by the merchant 102, payment processor 106, acquirer 110, card scheme 112, or issuer (or BIN controller) 114 when a payment transaction is completed. In other embodiments, the sales receipt data is provided in response to a request from the sales receipt system 108. Figure 6 An example method 600 is provided for execution by the sales receipt system 108 to request sales receipt data from a merchant 102, a payment processor 106, an acquirer 110, a card scheme 112, or an issuer 114 (or a BIN controller) while Figure 7 An example method 700 is provided that is performed by a merchant 102 , a payment processor 106 , an acquirer 110 , a card scheme 112 , or an issuer 114 (or a BIN controller) in response to a request from a sales receipt system 108 .

[0102] like Figure 6As illustrated, the sales receipt system 108 makes a request for sales receipt data to one or more of the merchant 102, payment processor 106, acquirer 110, card scheme 112, or issuer (or BIN controller) 114 (step 602), and in response, receives sales receipt data matching the request, which is stored in the corresponding data repository 118, 120, 124, 126, 128 of the merchant 102, payment processor 106, acquirer 110, card scheme 112, or issuer (or BIN controller) 114 to which the request was made (step 604). However, unlike the payment data, the sales receipt data stored in the corresponding data repository 118, 120, 124, 126, 128 may not include the customer PAR. In the event that the customer PAR is not included in the sales receipt data, the sales receipt system extracts the transaction parameters from the received payment data and includes those transaction parameters in the request. The transaction parameters may include, but are not limited to, one or more of the following: merchant / POS of the transaction, transaction ID, merchant / POS ID, merchant code, authorization code, last 4 PAN digits, first 6 PAN digits, PAN token / derivative, terminal ID, currency code, transaction amount, transaction date, and transaction time. Where the sales receipt data includes a customer PAR, the customer PAR may be included in the request.

[0103] like Figure 7 As shown, the merchant 102, payment processor 106, acquirer 110, card scheme 112, or issuer (or BIN controller) 114 to which the request for sales receipt data is directed receives a request for sales receipt data including identification information, such as transaction parameters extracted from payment data or customer PAR (step 702). The sales receipt data including the provided transaction parameters or customer PAR is identified in the corresponding data repository 118, 120, 124, 126, and 128 (step 704). The identified sales receipt data including the provided transaction parameters or customer PAR is provided to the requester, in this case, the sales receipt system 108 (step 706).

[0104] Communications with merchant 102 are performed by Figure 1 The communication with the payment processor 106 is indicated by arrows 138 and 140. Figure 1 The communication with the acquirer 110 is indicated by arrows 142 and 144. Figure 1 The communication with the card scheme 112 is indicated by arrows 162 and 164. Figure 1 The communication with the issuer (or BIN controller) 114 is indicated by arrows 166 and 168 in FIG. Figure 1170 and 172. Communication between the payment processor 106 and the merchant 102 is indicated by arrows 134 and 136. Communication between the acquirer 110 and the merchant 102 is indicated by arrows 172 and 174. Communication between the card scheme 112 and the merchant 102 is indicated by arrows 176 and 178. Communication between the issuer (or BIN controller) 114 and the merchant 102 is indicated by arrows 180 and 182. In some embodiments, such communication is performed via API calls, webhooks, or similar means of communication between systems, computer devices, or databases.

[0105] It should also be understood that Figure 6 and Figure 7 The method of can also be used to request sales receipt data between any of the payment processor 106, the acquirer 110, the card scheme 112, or the issuer (or BIN controller) 114. Similarly, Figure 6 and Figure 7 The method may be used to request payment data between any of the payment processor 106 , acquirer 110 , card scheme 112 , or issuer (or BIN controller) 114 .

[0106] Reference Figure 2After receiving the payment data (step 218) and the sales receipt data (step 220), the sales receipt system 108 then matches the payment data and the sales receipt data to the user identified by the customer PAR stored in the data repository 122 (step 222). In some embodiments, where the sales receipt system 108 receives the sales receipt data and the payment data from different entities, the sales receipt system 108 may need to match or otherwise link the separately received sales receipt data and payment data to the user using the PAR. In one embodiment, where the sales receipt system 108 receives the sales receipt data and the payment data from the same entity, the sales receipt data and the payment data may already be matched or otherwise linked and only need to be matched or linked to the customer using the PAR. An electronic sales receipt may then be issued to the identified user by the sales receipt system 108 or another entity (such as the merchant 102, the payment processor 106, the acquirer 110, the card scheme 112, or the card issuer (or BIN controller) 114) (step 224). Issuance of an electronic sales receipt is facilitated by providing matching or otherwise linked payment data, sales receipt data, and user data identified by the customer to the entity issuing the electronic sales receipt via the sales receipt system 108. In some embodiments, issuing the electronic receipt involves providing an electronic communication to a computing device of the user 104. In other embodiments, the electronic sales receipt is provided using a web interface or application that the user 104 uses to register an account on the sales receipt system 108, or to register an account in the merchant 102's own system, or to register an account with a service provider / partner / customer of the sales receipt system 108 (such as a bank, issuer, expense management system, or other receipt provider), or a combination thereof (step 202). In some such embodiments, the electronic sales receipt (or any other stored data) may be used as part of an archiving, billing, or accounting system and may be accessed or otherwise provided using a customer PAR associated with the user 104.

[0107] Any suitably and specially configured electronic or computing device may be used to implement the functionality described herein for a merchant 102 (including a POS system 115, a payment terminal / payment device reader 116, and / or a payment gateway 117), a user 104, a payment processor 106, a sales receipt system 108, an acquirer 110, a card scheme 112, or a card issuer (or BIN controller) 114. Figure 8 An illustrative example of such an electronic or computing device 800 is depicted in FIG. Computing device 800 is merely an illustrative example of a suitable computing environment and in no way limits the scope of the present invention. Figure 8The "computing device" shown may include a "workstation," "server," "laptop," "desktop," "device," "smart device," "tablet," "smartphone," "ECR," or other specially configured computing devices, as will be understood by those skilled in the art. While computing device 800 is depicted for illustrative purposes, embodiments of the present invention may utilize any number of computing devices 800 to implement a single embodiment of the present invention in any number of different ways. Thus, embodiments of the present invention are not limited to a single computing device 800, as will be understood by those skilled in the art, nor are they limited to a single type of implementation or configuration of the example computing device 800.

[0108] Computing device 800 may include a bus or network 810 that may be coupled directly or indirectly to one or more of the following illustrative components: memory 812 , one or more processors 814 , one or more presentation components 816 , input / output ports 820 , and a power source 824 .

[0109] Those skilled in the art will appreciate that bus 810 may include one or more buses, such as an address bus, a data bus, a network, or any combination thereof. Those skilled in the art will also appreciate that, depending on the intended application and use of a particular embodiment, multiple of these components may be implemented by a single device. Similarly, in some instances, a single component may be implemented by multiple devices. Thus, Figure 8 It is merely an illustration of an exemplary computing device that may be used to implement one or more embodiments of the invention and is in no way limiting of the invention.

[0110] The computing device 800 may include or interact with various computer-readable media. For example, the computer-readable media may include random access memory (RAM); read only memory (ROM); electronically erasable programmable read only memory (EEPROM); flash memory or other memory technology; CDROM, digital versatile disk (DVD), solid state drive (SSD), cloud, or other optical or holographic media; magnetic cassettes, magnetic tapes, disk storage, or other magnetic storage devices that can be used to encode information and can be accessed by the computing device 800.

[0111] The memory 812 may include computer storage media in the form of volatile and / or non-volatile memory. The memory 812 may be removable, non-removable, or any combination thereof. Exemplary hardware devices are devices such as hard disk drives, solid-state memory, optical disk drives, and the like. The computing device 800 may include one or more processors that read data from components such as the memory 812, various I / O components 820, and the like. A presentation component 816 presents data indications to a user or other device. Exemplary presentation components include display devices, speakers, printing components, vibration components, and the like.

[0112] I / O ports 818 may enable computing device 800 to be logically coupled to other devices, such as I / O components 820, using serial, parallel, or network and / or wireless communication protocols. Some I / O components 820 may be built into computing device 800. Examples of such I / O components 820 include microphones, joysticks, recording devices, game controllers, satellite dishes, scanners, printers, wireless devices, networking devices, and the like.

[0113] Figures 2 to 7 The functionality of the present invention as described in Figure 1 and Figure 8 The system and hardware are provided by the execution of software, which transforms the hardware into specially configured hardware suitable for implementing the technological advancement of the present invention. It should be understood that the functionality of any component can be combined with any other component of the system or provided by any other component of the system in other ways, as long as the desired operability and performance are maintained. For example, in some embodiments, the merchant 102 (or, in some cases, the POS system 115 and / or payment gateway 116 of the merchant 102) can perform the matching of payment data to receipt data and generate an electronic receipt or otherwise issue an electronic receipt. Such an electronic receipt will only identify the user 104 by the customer PAR. In some versions of this embodiment, the receipt system 108 will receive and store the electronic receipt for archiving, accounting and distribution to the user 104, or access by the user 104 in the future. It should also be noted that the system and method of the present invention do not exclude the operation of using other third-party systems, any of which can also perform matching, or any other functions described herein. Some such integrations with other third-party systems may or may not include all inventive aspects of the present invention, but this does not necessarily exclude such integrations.

[0114] As used herein, the terms "include" and "comprising" are intended to be interpreted as inclusive, rather than exclusive. As used herein, the terms "exemplary", "example" and "illustrative" are intended to mean "serving as an example, instance or description", and should not be interpreted as indicating or not indicating a preferred or advantageous configuration relative to other configurations. As used herein, the terms "about", "roughly" and "approximately" are intended to cover changes that may exist in the upper and lower limits of the range of subjective or objective values, such as changes in attributes, parameters, sizes and dimensions. In a non-limiting example, the terms "about", "roughly" and "approximately" mean at 10%, or add 10% or less, or minus 10% or less. In a non-limiting example, the terms "about", "roughly" and "approximately" mean close enough to be considered to be included by those skilled in the art of the relevant field. As used herein, the term "substantially" refers to a complete or nearly complete extension or degree of an action, feature, attribute, state, structure, project or result, as understood by those skilled in the art. For example, a "substantially" circular object would mean that the object is either completely a circle to a mathematically determinable limit, or as close to a circle as will be recognized or understood by those skilled in the art. The exact degree of deviation allowed from absolute completeness may depend in some instances on the particular context. However, in general, the degree of near-completeness will have the same overall result as achieving or obtaining absolute and complete completion. As will be understood by those skilled in the art, the use of "substantially" when used in a negative sense is equally applicable to referring to the complete or near-complete lack of an action, characteristic, attribute, state, structure, item, or result.

[0115] As used herein, an "electronic sales receipt" is a non-physical sales receipt, whether it is referred to as a "computerized," "electronic," "digital," "paperless," or "programmed" sales receipt. Additionally, it should be noted that there is a significant difference between a "sales receipt" and a "card receipt," as a sales receipt is the most detailed form of receipt one can obtain (including, but not limited to, line items), and therefore has a variety of uses, whereas a simple "card receipt" does not have the same users.

[0116] In view of the foregoing description, numerous modifications and alternative embodiments of the present invention will be apparent to those skilled in the art. Therefore, this description is to be construed as illustrative only, and is for the purpose of teaching those skilled in the art the best mode for implementing the present invention. The details of the structure may be substantially changed without departing from the spirit of the present invention, and the exclusive use of all modifications falling within the scope of the appended claims is reserved. The embodiments have been described in this specification in a manner that enables a clear and concise description to be written, but it is intended and will be understood that the embodiments may be combined or separated differently without departing from the present invention. It is intended to limit the present invention only to the extent required by the appended claims and applicable legal rules.

[0117] It should also be understood that the following claims are intended to cover all generic and specific features of the invention described herein, together with all statements of the scope of the invention which as a matter of language could be said to fall therein. It should also be understood that the following claims are intended to cover all generic and specific features of the invention described herein, together with all statements of the scope of the invention which as a matter of language could be said to fall therein.

Claims

1. A method for matching an electronic sales receipt to a user of a customer purchase transaction, the method comprising: The merchant computing system receives payment data via a payment instrument having payment instrument information provided to complete payment for the customer purchase transaction; The merchant computing system communicates the payment instrument information to the payment processor computing system; The payment processor computing system: Process payments; storing payment data for the purchase transaction including a reference to a customer payment account reference (PAR) in a data repository; and confirming processing of the payment via the merchant computing system; The merchant computing system: Complete said purchase transaction; and storing sales receipt data in a merchant data repository; a sales receipt computing system having stored thereon a customer PAR associated with the user, receiving the payment data, wherein the customer is identified by the customer PAR; The sales receipt computing system receives sales receipt data generated by the merchant computing system; and The sales receipt calculation system matches the payment data and the sales receipt data to a user using the customer PAR and without requiring the payment instrument or payment instrument information, wherein the matching enables issuance of an electronic sales receipt to the user.

2. The method according to claim 1, wherein: The payment instrument comprises one of: a primary account number (PAN) and a token corresponding to the PAN or a PAN derivative.

3. The method according to claim 1, wherein: The customer PAR is provided with the payment instrument.

4. The method according to claim 1, wherein: The customer PAR is provided to the payment processor computing system as part of the payment processing.

5. The method according to claim 4, wherein: The customer PAR is provided to the payment processor computer system by an acquirer, card scheme, or issuer computing system.

6. The method according to claim 1, further comprising: The sales receipt calculation system: Receive a Primary Account Number (PAN) or PAN token or PAN equivalent; sending the PAN or PAN token or PAN equivalent to an issuer or card scheme to request a PAR corresponding to the PAN or PAN token or PAN equivalent; receiving the customer PAR in response to the request; and The customer PAR is stored.

7. The method according to claim 1, wherein: Processing the payment includes providing payment instrument information to one or more of an acquirer, a card scheme, and an issuer and in response receiving payment data for the purchase transaction from one or more of the acquirer, the card scheme, and the issuer.

8. The method according to claim 1, wherein: The payment processing confirmation includes a payment authorization message that is sent to one or more of: the merchant computing system, the acquirer computing system, the card scheme computing system, the issuing computing system, and the sales receipt computing system.

9. The method according to claim 1, wherein: The payment data received by the sales receipt computing system is provided by the payment processing computing system.

10. The method according to claim 9, wherein: The payment processing computing system provides the payment data to the sales receipt computing system when payment processing is confirmed.

11. The method according to claim 9, wherein: Receiving the payment data comprises the sales receipt computing system: requesting payment data from the payment processing computing system using the customer PAR; and In response to the request, payment data stored in the payment processor data repository including a reference to the customer PAR is received.

12. The method according to claim 11, wherein: Receiving the payment data from the payment processor computing system further comprises the payment processing computing system: receiving a request for payment data from the sales receipt computing system; identifying the payment data stored in the payment processor data repository including a reference to the customer PAR; and The identified payment data stored in the payment processor data repository including a reference to the customer PAR is provided to the sales receipt computing system.

13. The method according to claim 1, wherein: The payment data received by the sales receipt computing system is provided by an acquirer computing system involved in the processing of the payment.

14. The method according to claim 13, wherein: The acquirer computing system provides the payment data to the sales receipt computing system when payment processing is confirmed.

15. The method according to claim 13, wherein: Receiving payment data includes the sales receipt computing system: requesting payment data from the acquirer computing system using the customer PAR; and In response to the request, payment data stored in an acquirer data repository including a reference to the customer PAR is received.

16. The method according to claim 15, wherein: Receiving the payment data from the acquirer computing system further comprises the acquirer computing system: receiving a request for payment data from the sales receipt computing system; identifying the payment data stored in the acquirer data repository including a reference to the customer PAR; and The identified payment data stored in the acquirer data repository including a reference to the customer PAR is provided to the sales receipt computing system.

17. The method according to claim 1, wherein: The payment data received by the sales receipt computing system is provided by a card scheme computing system involved in the processing of the payment.

18. The method according to claim 17, wherein: The card scheme computing system provides the payment data to the sales receipt computing system when payment processing is confirmed.

19. The method according to claim 17, wherein: Receiving the payment data comprises the sales receipt computing system: requesting payment data from the card scheme computing system using the customer PAR; and In response to the request, the payment data stored in a card scheme data repository including a reference to the customer PAR is received.

20. The method according to claim 19, wherein: Receiving the payment data from the card scheme computing system further comprises the card scheme computing system: receiving a request for payment data from the sales receipt computing system; identifying the payment data stored in the card scheme data repository including a reference to the customer PAR; and The sales receipt computing system is provided with the identified payment data stored in the card scheme data repository including a reference to the customer PAR.

21. The method according to claim 1, wherein: The payment data received by the sales receipt computing system is provided by an issuer computing system involved in the processing of the payment.

22. The method according to claim 21, wherein: The issuer computing system provides the payment data to the sales receipt computing system when payment processing is confirmed.

23. The method according to claim 21, wherein: Receiving the payment data comprises the sales receipt computing system: requesting payment data from the issuer computing system using the customer PAR; and In response to the request, the payment data stored in an issuer data repository including a reference to the customer PAR is received.

24. The method according to claim 23, wherein: Receiving the payment data from the issuer computing system further comprises, by the issuer computing system: receiving a request for the payment data from the sales receipt computing system; identifying payment data stored in the issuer data repository including a reference to the customer PAR; and The identified payment data stored in the issuer data repository including a reference to the customer PAR is provided to the sales receipt computing system.

25. The method of claim 1, wherein: The payment data received by the sales receipt computing system is provided by the merchant computing system.

26. The method according to claim 25, wherein: The merchant computing system provides the payment data to the sales receipt computing system upon completion of the purchase transaction.

27. The method according to claim 25, wherein: Receiving the payment data comprises the sales receipt computing system: requesting payment data from the merchant computing system using the customer PAR; and In response to the request, the payment data stored in the merchant data repository including a reference to the customer PAR is received.

28. The method according to claim 27, wherein: Receiving the payment data from the merchant computing system further comprises the merchant computing system: receiving a request for payment data from the sales receipt computing system; identifying payment data stored in the merchant data repository including a reference to the customer PAR; and Payment data stored in a merchant data repository including a reference to the customer PAR is provided to the sales receipt computing system.

29. The method of claim 1, wherein: The sales receipt data received by the sales receipt computing system is provided by the merchant computing system.

30. The method of claim 29, wherein: The merchant computing system provides the sales receipt data to the sales receipt computing system upon completion of the purchase transaction.

31. The method of claim 29, wherein: Receiving the sales receipt data from the merchant computing system comprises the sales receipt computing system: extracting transaction parameters from the received payment data; requesting the sales receipt data from the merchant computing system using the extracted transaction parameters; as well as In response to the request, the sales receipt data stored in the merchant data repository is received.

32. The method according to claim 31, wherein: The transaction parameters include one or more of: merchant / POS of the transaction, transaction ID, merchant / POS ID, merchant code, authorization code, last 4 PAN digits, first 6 PAN digits, PAR, PAN token / derivative, terminal ID, currency code, amount of the transaction, date of the transaction, and time of the transaction.

33. The method according to claim 31, wherein: Receiving the sales receipt data from the merchant computing system further comprises the merchant computing system: receiving a request for the sales receipt data from the sales receipt computing system; identifying sales receipt data stored in the merchant data repository including the transaction data; as well as The identified sales receipt data stored in the merchant data repository is provided to the sales receipt computing system.

34. The method of claim 29, wherein: The sales receipt data stored in the data repository includes the customer PAR.

35. The method of claim 34, wherein: Receiving the sales receipt data from the merchant computing system comprises the sales receipt computing system: requesting the sales receipt data from the merchant computing system using the customer PAR; and In response to the request, sales receipt data stored in the merchant data repository including a reference to the customer PAR is received.

36. The method of claim 35, wherein: Receiving the sales receipt data from the merchant computing system further comprises the merchant computing system: receiving a request for the sales receipt data from the sales receipt computing system; identifying sales receipt data stored in the merchant data repository that includes a reference to the customer PAR; as well as The identified sales receipt data stored in the merchant data repository including a reference to the customer PAR is provided to the sales receipt computing system.

37. The method of claim 1, wherein: The sales receipt data received by the sales receipt computing system is provided by the payment processing computing system.

38. The method of claim 37, wherein: The payment processing computing system provides the sales receipt data to the sales receipt computing system upon completion of the purchase transaction.

39. The method of claim 37, wherein: Receiving the sales receipt data from the payment processing computing system comprises the sales receipt computing system: extracting transaction parameters from the received payment data; requesting the sales receipt data from the payment processing computing system using the extracted transaction parameters; and In response to the request, sales receipt data stored in the payment processor data repository is received.

40. The method of claim 39, wherein: The transaction parameters include one or more of: merchant / POS of the transaction, transaction ID, merchant / POS ID, merchant code, authorization code, last 4 PAN digits, first 6 PAN digits, PAR, PAN token / derivative, terminal ID, currency code, amount of the transaction, date of the transaction, and time of the transaction.

41. The method of claim 39, wherein: Receiving the sales receipt data from the payment processing computing system further comprises the payment processing computing system: receiving a request for the sales receipt data from the sales receipt computing system; identifying sales receipt data stored in the payment processing data repository including the transaction data; and The identified sales receipt data stored in the payment processing data repository is provided to the sales receipt computing system.

42. The method of claim 37, wherein: The sales receipt data stored in the data repository includes the customer PAR.

43. The method of claim 42, wherein: Receiving the sales receipt data from the payment processing computing system comprises the sales receipt computing system: requesting the sales receipt data from the payment processing computing system using the customer PAR; and In response to the request, sales receipt data stored in the payment processing data repository including a reference to the customer PAR is received.

44. The method of claim 43, wherein: Receiving the sales receipt data from the payment processing computing system further comprises the payment processing computing system: receiving a request for the sales receipt data from the sales receipt computing system; identifying sales receipt data stored in the payment processing data repository including a reference to the customer PAR; and The identified sales receipt data stored in the payment processing data repository including a reference to the customer PAR is provided to the sales receipt calculation system.

45. The method of claim 1, wherein: The sales receipt data received by the sales receipt computing system is provided by an acquirer computing system involved in processing the payment.

46. ​​The method of claim 45, wherein: The acquirer computing system provides the sales receipt data to the sales receipt computing system upon completion of the purchase transaction.

47. The method of claim 45, wherein: Receiving the sales receipt data from the acquirer computing system comprises the sales receipt computing system: Extracting transaction parameters from received payment data; requesting the sales receipt data from the acquirer computing system using the extracted transaction parameters; and In response to the request, sales receipt data stored in the acquirer data repository is received.

48. The method of claim 47, wherein: The transaction parameters include one or more of: merchant of the transaction, transaction ID, merchant ID, merchant code, authorization code, last 4 PAN digits, first 6 PAN digits, PAR, PAN token / derivative, terminal ID, currency code, amount of the transaction, date of the transaction, and time of the transaction.

49. The method of claim 47, wherein: Receiving the sales receipt data from the acquirer computing system further comprises the acquirer computing system: receiving a request for the sales receipt data from the sales receipt computing system; identifying sales receipt data stored in an acquirer data repository including the transaction data; as well as The identified sales receipt data stored in the acquirer data repository is provided to the sales receipt computing system.

50. The method of claim 45, wherein: The sales receipt data stored at the acquirer includes the customer PAR.

51. The method of claim 50, wherein: Receiving the sales receipt data from the acquirer computing system comprises the sales receipt computing system: requesting the sales receipt data from the acquirer computing system using the customer PAR; and In response to the request, sales receipt data stored in the acquirer data repository including a reference to the customer is received.

52. The method of claim 51, wherein: Receiving the sales receipt data from the acquirer computing system further comprises the acquirer computing system: receiving a request for the sales receipt data from the sales receipt computing system; identifying sales receipt data stored in an acquirer data repository that includes a reference to the customer's PAR; and The identified sales receipt data stored in the acquirer data repository including a reference to the customer PAR is provided to the sales receipt computing system.

53. The method of claim 1, wherein: The sales receipt data received by the sales receipt computing system is provided by a card scheme computing system involved in the processing of the payment.

54. The method of claim 53, wherein: The card scheme computing system provides the sales receipt data to the sales receipt computing system upon completion of the purchase transaction.

55. The method of claim 53, wherein: Receiving the sales receipt data from the card scheme computing system comprises the sales receipt computing system: Extracting transaction parameters from received payment data; requesting the sales receipt data from the card scheme computing system using the extracted transaction parameters; and In response to the request, sales receipt data stored in the card scheme data repository is received.

56. The method of claim 55, wherein: The transaction parameters include one or more of: merchant / POS of the transaction, transaction ID, merchant / POS ID, merchant code, authorization code, last 4 PAN digits, first 6 PAN digits, PAR, PAN token / derivative, terminal ID, currency code, amount of the transaction, date of the transaction, and time of the transaction.

57. The method of claim 55, wherein: Receiving the sales receipt data from the card scheme computing system further comprises the card scheme computing system: receiving a request for the sales receipt data from the sales receipt computing system; identifying sales receipt data stored in a card scheme data repository including said transaction data; and The identified sales receipt data stored in the card scheme data repository is provided to the sales receipt computing system.

58. The method of claim 53, wherein: The sales receipt data stored at the card scheme includes the customer PAR.

59. The method of claim 58, wherein: Receiving the sales receipt data from the card scheme computing system comprises the sales receipt computing system: requesting the sales receipt data from the card scheme computing system using the customer PAR; and In response to the request, sales receipt data stored in the card scheme data repository including a reference to the customer is received.

60. The method of claim 59, wherein: Receiving the sales receipt data from the card scheme computing system further comprises the card scheme computing system: receiving a request for the sales receipt data from the sales receipt computing system; identifying sales receipt data stored in a card scheme data repository that includes a reference to the customer's PAR; and The identified sales receipt data stored in the card scheme data repository including a reference to the customer PAR is provided to the sales receipt calculation system.

61. The method of claim 1, wherein: The sales receipt data received by the sales receipt computing system is provided by an issuer computing system involved in processing the payment.

62. The method of claim 61, wherein: The issuer computing system provides the sales receipt data to the sales receipt computing system upon completion of the purchase transaction.

63. The method of claim 61, wherein: Receiving the sales receipt data from the issuer computing system comprises the sales receipt computing system: Extracting transaction parameters from received payment data; requesting the sales receipt data from the issuer computing system using the extracted transaction parameters; and In response to the request, sales receipt data stored in the issuer data repository is received.

64. The method of claim 63, wherein: The transaction parameters include one or more of: merchant / POS of the transaction, transaction ID, merchant / POS ID, merchant code, authorization code, last 4 PAN digits, first 6 PAN digits, PAR, PAN token / derivative, terminal ID, currency code, amount of the transaction, date of the transaction, and time of the transaction.

65. The method of claim 63, wherein: Receiving the sales receipt data from the issuer computing system further comprises the issuer computing system: receiving a request for the sales receipt data from the sales receipt computing system; identifying sales receipt data stored in an issuer data repository including the transaction data; and The identified sales receipt data stored in the issuer data repository is provided to the sales receipt computing system.

66. The method of claim 61, wherein: The sales receipt data stored at the issuer includes the customer PAR.

67. The method of claim 66, wherein: Receiving the sales receipt data from the issuer computing system comprises the sales receipt computing system: requesting the sales receipt data from the issuer computing system using the customer PAR; and In response to the request, sales receipt data stored in the issuer data repository including a reference to the customer is received.

68. The method of claim 67, wherein: Receiving the sales receipt data from the issuer computing system further comprises the issuer computing system: receiving a request for the sales receipt data from the sales receipt computing system; identifying sales receipt data stored in an issuer data repository that includes a reference to the customer's PAR; and The identified sales receipt data stored in the issuer data repository including a reference to the customer PAR is provided to the sales receipt computing system.

69. The method of claim 1 further comprising storing one or more of the payment data, receipt data, and the electronic sales receipt wherein the user is identified by the PAR in a data repository of the sales receipt computing system.

70. The method of claim 1, wherein: The merchant computing system includes a point of sale (POS) system.

71. The method of claim 1, wherein: The merchant computing system includes a payment gateway.

72. The method of claim 1, wherein: The merchant computing system includes a payment terminal or payment device reader.

73. The method of claim 1, further comprising: The sales receipt calculation system issues an electronic sales receipt to the user.

74. The method of claim 1, further comprising: The payment data and sales receipt data matched to the user are provided to one or more of: a merchant, a payment processor, an acquirer, a card scheme, and an issuer so that an electronic sales receipt can be issued to the user.

75. The method of claim 1, wherein: The sales receipt computing system receives PAR from one or more of: a user, a merchant, a payment processor, an acquirer, a card scheme, and an issuer.

76. A system for matching an electronic sales receipt to a user of a customer purchase transaction, the system comprising: A merchant computing system comprising a processor and data storage, the merchant computing system being configured to: receiving payment data via a payment instrument having payment instrument information provided to complete payment for the customer's purchase transaction; communicating payment instrument information to a payment processor computing system; Receive confirmation of payment processing; completing said purchase transaction; and storing sales receipt data in the data repository; A payment processor computing system comprising a processor and a data store, the payment processor computing system being configured to: receiving payment instrument information from the merchant computing system; Process payments; storing payment data for the purchase transaction including a reference to a customer payment account reference (PAR) in the data repository; and confirming processing of the payment via the merchant computing system; A sales receipt computing system comprising a processor and a data storage, the sales receipt computing system being configured to: storing a customer PAR associated with the user in the data repository; receiving the payment data, wherein the customer is identified by the customer PAR; storing the received payment data in the data repository; receiving the sales receipt data generated by the merchant computing system; storing the received sales receipt data in the data repository; as well as The payment data and the sales receipt data are matched to the user using the PAR, wherein the matching enables an electronic sales receipt to be issued to the user.

77. A method for issuing an electronic sales receipt to a user for a customer purchase transaction, the method comprising: The merchant computing system receives payment data via a payment instrument having payment instrument information provided to complete payment for the customer purchase transaction; The merchant computing system communicates the payment instrument information to the payment processor computing system; The payment processor computing system: Process payments; storing the payment data including a reference to a customer payment account reference (PAR) for the purchase transaction in a data repository; and confirming processing of the payment with the merchant computing system; The merchant computing system: completing said purchase transaction; storing sales receipt data in a merchant data repository; receiving payment data wherein the customer is identified by the customer PAR; matching the payment data and the sales receipt data to the user using PAR; issuing an electronic sales receipt to a sales receipt computing system, the sales receipt computing system storing the electronic sales receipt in a data store; as well as The sales receipt computing system provides a user with access to the electronic sales receipt.

78. A system for issuing an electronic sales receipt to a user for a customer purchase transaction, the system comprising: A merchant computing system comprising a processor and data storage, the merchant computing system being configured to: receiving payment data via a payment instrument having payment instrument information provided to complete payment for the customer's purchase transaction; communicating payment instrument information to a payment processor computing system; Receive confirmation of payment processing; completing said purchase transaction; storing sales receipt data in the data repository; Receive payment data; storing the payment data in the data repository; Matching payment data with sales receipt data; as well as issuing an electronic sales receipt to the user using a customer payment account reference (PAR) instead of the payment instrument or payment instrument information; A payment processor computing system comprising a processor and a data store, the payment processor computing system being configured to: receiving payment instrument information from the merchant computing system; Process payments; storing payment data for the purchase transaction including a reference to the customer PAR in the data repository; and confirming processing of the payment with the merchant computing system; A sales receipt computing system comprising a processor and a data storage, the sales receipt computing system being configured to: receiving the electronic sales receipt issued from the merchant; storing the electronic sales receipt in the data repository; as well as The customer PAR is used to provide the user with access to the electronic sales receipt.

Images