Method and system for matching electronic sales slips with users for customer purchase transactions - Patents.com

Abstract

A method and system for electronic sales slip reconciliation that protects user identity by using a Payment Account Reference (PAR) instead of payment instrument information to identify the user. The use of a PAR provides several advantages: PAR is considered non-sensitive data and cannot be misused outside the card network, i.e., PAR cannot be used for payments unlike PAN (Primary Account Number, aka card number). The use of a PAR is a more secure and faster way of identifying transactions and users for issuing digital receipts. The PAR remains the same even when cards expire, are reissued, etc.

Description

[Technical field]

[0001] [CROSS REFERENCE TO RELATED APPLICATIONS] This application claims priority to and the benefit of co-pending U.S. Provisional Patent Application No. 63 / 322,029, filed March 21, 2022, and all subject matter is common to both applications, the disclosure of which is incorporated herein by reference in its entirety.

[0002] The present invention relates to a method and system for reconciliation of electronic sales slips resulting from user purchase transactions. [Background technology]

[0003] Currently, a user, e.g., an individual consumer, corporate user, business, or other, may purchase and / or pay for an item (physical or non-physical good or service) from a point-of-sale (POS), e.g., a physical store or an online shop or account, where a physical receipt is printed and / or an electronic receipt is transmitted via email, text, or other transmission technology. Alternatively, the receipt must be downloaded from a website.

[0004] Currently there are very few ways to issue digital receipts and they are filled with friction, costly, very inconvenient and rely on very sensitive cardholder data. Some of the most well known ways to obtain digital receipts are frictionless because they require the customer to scan a QR code and / or provide an email or phone number for every digitally issued receipt. These are the dinosaurs in the digital receipt space.

[0005] Starting with QR, email and SMS-based receipts, a new and smarter process is emerging that allows receipts to be automatically issued based on the customer's payment card. This technology is specifically called "card-linking" technology, which is technology developed for loyalty and then ineptly tweaked and pieced together to serve the need to issue digital receipts.

[0006] In "card linking," as part of the purchase transaction, the user typically provides a payment instrument such as a PAN card, digital wallet, or payment device to activate the payment. Here, a PAN card refers to a payment instrument such as a credit or debit card that utilizes a Primary Account Number (PAN) to identify the account information. This PAN is part of the information collected and used to process the transaction, and in many instances is part of the information (along with the name on the card) used to identify and track the transaction.

[0007] Card linking technology can be smart in the loyalty context because it allows for linking a payment card with a customer, thereby identifying the customer's conditional transactions. However, this technology was built for loyalty and is very costly in the context of digital receipts only. The current card linking process relies on multi-stage and very expensive middleware full of loyalty technologies to issue digital receipts and has many inherent shortcomings. Card linking technology that relies only on PAN as the primary identifier comes with significant risks and problems.

[0008] However, there is a growing demand in the industry to protect user data, as well as growing privacy concerns from consumers regarding sharing personal and / or sensitive information. For example, in many instances, merchants may not identify, or may only partially identify, the PAN used in a transaction in the generated receipt data.

[0009] PAN number is a very sensitive payment initiator, which means it must first be securely encrypted to PCI DSS standards and should only be transmitted, processed, and stored in or between PCI DSS compliant environments. This is a big problem because as the system / method gets closer to the merchant, the system / method gets further away from the PCI DSS compliant environment (since there is very little PCI DSS compliance at the merchant level). Consequently, this results in unnecessary added steps and costs in the process of issuing digital receipts, which overcomplicates the process. Moving the method / process closer to the merchant level, issuing digital receipts, i.e. additional steps from card linking methods (with PAN) and other similar current methods that are simpler and closer to real-time, equates to longer processing times, more computing power required, increased risk, and a significant increase in costs for all parties involved.

[0010] The high confidentiality of the PAN also means that the PAN may or may not be updated when the card is automatically renewed. However, the PAN will always be updated when a card is replaced. This poses a challenge for the card-linking infrastructure, as it needs to capture new PAN input from the customer in order to be able to continually identify the customer and send receipts.

[0011] Digital payment wallets (e.g., Apple Pay™ and Google Pay™) are also being received as a favorable payment option due to their ease of use and reduced friction. However, this change in payment instruments poses a major challenge to the current card-linking receipt infrastructure, which is having difficulty adapting to fully accommodate this change. The reason is that these digital payment wallets mask the PAN with a device account number, i.e., a given combination of payment card and a given device (smartwatch, smartphone, tablet, computer, and other payment-enabled smart device) is given a unique device account number. The use of this number instead of the PAN forms part of the built-in security measures of the digital payment wallets that help protect cardholder data during payment transactions. Thus, the card-linking infrastructure is struggling to cope, as the PAN is a unique identifier, and if it is no longer readily available, it becomes increasingly difficult to identify the customer and issue receipts to them. The card-linking infrastructure has not been able to successfully overcome this challenge.

[0012] Another mechanism for protecting user data is the Payment Account Reference (PAR) number. PAR was introduced by EMVCo to address challenges for merchants and acquirers resulting from the decline in the use of PAN, such as through tokenization (including PAN masking in digital wallets). PAR enables merchants and acquirers to monitor and maintain fraud, loyalty, and reporting programs that rely on PAN today. A Payment Account Reference (PAR) is a value linked to a Primary Account Number (PAN). PAR allows tokenized PAN-based transactions to be linked (1:1 PAR to PAN) without requiring PAN as the linking mechanism. While 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 in place of PAN to identify the user and thereby enable merchants, payment processors, acquirers, BIN controllers, issuers, card schemes, POS systems, payment gateways, and service providers to uniquely identify a cardholder's account without continually exposing and storing the PAN. Similarly, the PAR can be used in place of the PAN for inquiries to card schemes and issuers. It should be understood that the PAR is only a unique reference to the PAN and cannot be used to replace the PAN in processing payment transactions. Therefore, if stored cardholder data at a payment processor, acquirer, merchant, and / or service provider is compromised and / or stolen, the stored PAR number cannot be used fraudulently.

[0013] Every time a PAN number is transmitted, processed or stored, there is a significant risk involved, and the risk is even greater when PAN data is moved from one system / stakeholder to another. The more steps and system integrations there are, the greater the exposure to PAN data compromise / exposure. A further problem with the current card-linking infrastructure for issuing digital receipts is that the customer's PAN number and associated conditional transaction are identified after payment authorization (clearance phase of the transaction), which depends on when the payment processor / acquirer enables the card scheme to identify the conditional transaction and the customer. This process can be instantaneous, but in some cases it may take longer (up to 1-3 days) depending on the country of purchase, the payment processor / acquirer, and whether it is an international transaction. Summary of the Invention

[0014] The present invention is directed to a further solution to address the aforementioned needs, in addition to other desirable features. The present invention extends the personal identity protection capabilities of PARs by allowing a non-traditional way to identify transactions and use them to identify users for purposes of issuing electronic sales slips. Specifically, the system and method for issuing electronic sales slips of the present invention uses PARs instead of PANs (or any other potentially sensitive information) or other types of card linking techniques for identification of users and transactions performed, which result in the issuance of electronic sales slips to users. The use of PARs provides several advantages: PAR numbers are considered non-sensitive data, are not subject to PCI requirements for protecting account data, and cannot be misused outside of the card network, i.e., PAR numbers are not usable for payments, unlike PANs (primary account numbers, i.e., card numbers). The use of PARs is a more secure and faster way of identifying transactions and users for issuing digital receipts. PAR numbers can remain the same despite cards expiring, being reissued, etc. PARs do not have any other functionality other than identifying a customer and / or being able to link a payment account represented by a PAN with an affiliated payment token. Therefore, in an ideal world, PARs can be stored in a non-PCI compliant environment such as a merchant's local POS system. Therefore, using PARs to issue digital receipts can eliminate several steps in the card linking infrastructure and therefore accelerate the process of issuing digital receipts closer to real-time. However, the lifecycle of a PAR is determined by the Bank Identifier Number (BIN) controller.

[0015] 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 capture SKU line item data and pair it with the customer's account based on the transaction information. This is very problematic for the card linking infrastructure because the POS system has the SKU line item level data but not the PAN (because the POS system cannot store the PAN since it is required to be PCI DSS compliant), and the card linking infrastructure has the PAN but not the SKU line item level data. So when the card linking infrastructure issues a receipt to the customer, the process relies heavily on guesswork - pairing the SKU line item data with the PAN data and matching the data provided by both systems based on parameters such as merchant ID, date and time stamp, transaction amount, merchant code, authorization code, last four digits of PAN, terminal ID, currency code, etc. Thus, the transaction and SKU line item data are not uniquely matched because none of the systems required can store or process the PAN, but rather are matched based on an exclusionary methodology. Ultimately, this exposes the card-linking infrastructure to a myriad of process failures; the match may not be unique, or time may not be properly synchronized between different infrastructure components. On the other hand, since storage and processing of PAR data does not require PCI DSS compliance, with PAR, the match is unique because that PAR data from a transaction can be matched one-to-one with PAR data from the merchant's POS system.

[0016] In summary, from a security / risk and processing perspective, the PAR infrastructure is far superior to current card-linking infrastructures because fewer steps overall, fewer (if any) sensitive PAN processing steps, and fewer parameters that need to be analyzed means much less computing processing power is required, resulting in faster receipt response delivery times (closer to real-time), more accurate and safer / secure identification, fewer errors, and reduced risks (default and sensitive PAN data exposure). Traditional card-linking infrastructures simply cannot compete with comparable PAR infrastructures.

[0017] To be able to issue a digital sales slip with line items based on a PAR, three main data streams are required: 1) acquisition of the PAR (facilitates identification of the user), 2) payment or transaction data (notifies the system that one of the users has used their card), and 3) line item sales slip data (allows extraction and issuance of receipt data in a digital format to the user). Each of these data streams can operate in different ways and may involve one or multiple actors. 1) Obtaining PAR: a) PAR can be obtained directly through the card scheme (Visa, MasterCard, Amex, etc.) via an API call that can tap into the PAN and request a PAR swap for any given card within any given card scheme. b) PAR can be obtained directly through the issuer (Citigroup, US Bank, JPMorgan, Amazon®, Apple®, etc.) via an API call that can tap into the PAN and request a PAR swap for any given card for any given customer of the issuer (here limited to only the issuer's customers). c) The payment device may contain a PAR that is readable by a payment device reader (e.g., payment terminal / payment device reader), so that the PAR can be obtained directly from the user's payment device (smartwatch, smartphone, tablet, computer, and other payment-enabled smart devices). d) PARs can be obtained through a BIN controller, which can issue PARs via an API call that can, for example, tap into a PAN and request a PAR swap. e) PAR can be obtained through a combination of the above via a merchant and once the user completes a purchase, the merchant can offer the user to sign up to receive a digital receipt. PAR can be obtained directly from the completed purchase or the PAN / token from the purchase can be used to capture the PAR and register the user via the merchant. f) A combination of the above. 2) Payment or Transaction Data a) The sales slip system can obtain transaction data directly from the issuer or BIN controller; so that the issuer or BIN controller can provide notifications to users of the system when a transaction has been authorized / confirmed / approved / confirmed. b) The sales voucher system can get transaction data directly from the card scheme; so that the card scheme can provide notifications to users of the system when a transaction has been authorized / confirmed / approved / confirmed. c) The sales slip system may obtain transaction data directly from the acquirer or payment processor; so that the acquirer or payment processor provides notification to users of the system when a transaction has been authorized / confirmed / approved / confirmed. d) The sales ticket system can obtain transaction data directly from merchants (including POS systems, payment terminals / payment device readers, or payment gateways); so that merchants can provide notifications to users of the system when transactions have been authorized / confirmed / approved / confirmed. e) A combination of the above. 3) Sales slip data a) The Receipt System can get receipt data from the Issuer (BIN Controller), where the Issuer has direct / indirect integration with the POS and / or Merchant systems and it is the Issuer that extracts or receives the data into those systems. The Receipt System can leverage this integration between the POS (and / or Merchant) and the Issuer, which allows the Receipt System to get receipt data directly from the Issuer. b) The voucher system can obtain receipt data from the card scheme, where the card scheme has direct / indirect integration with the POS and / or merchant systems and it is the card scheme that extracts or receives the data into those systems. The voucher system can exploit this integration between the POS (and / or merchant) and the card scheme, thereby enabling the voucher system to obtain receipt data directly from the card scheme. c) The sales invoice system can obtain receipt data from the acquirer and / or payment processor, where the acquirer and / or payment processor have direct / indirect integration with the POS and / or merchant systems and it is the acquirer and / or payment processor that extracts or receives the data into those systems. The sales invoice system only needs to leverage this integration between the POS (and / or merchant) and the acquirer and / or payment processor, thereby enabling the sales invoice system to obtain receipt data directly from the acquirer and / or payment processor. d) The sales voucher system can obtain receipt data from the merchant (or POS system or payment gateway), where the sales voucher system may have its own direct integration with the merchant system, allowing the sales voucher system to extract or receive receipt data directly from the merchant system. e) A combination of the above. With so few merchant systems accepting the use of PAR, matching the transaction or payment data (point 2) with the receipt data (point 3) becomes a challenge. Therefore, for this linking of data, sales slip systems should not rely only on PAR but should extend beyond PAR to other payment / transaction parameters that can be used to identify the transaction, e.g. transaction ID, amount, date, time, etc. In an ideal world, the PAR would be the only unique identifier in both systems (points 2 and 3), but considering how the world actually works, other payment / transaction parameters need to be factored in.

[0018] Furthermore, in an ideal world, as PARs become more widespread and accepted, and because PARs are non-PCI account data and cannot be misused to authorize or initiate financial transactions, PARs could in the future be stored locally on all POS devices, which could further reduce processing times and costs.

[0019] According to an embodiment of the present invention, a method for matching an electronic sales slip with a user for a customer purchase transaction is provided, the method includes: a merchant computing system receiving payment data via a payment instrument having payment instrument information provided to complete payment for the 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 and storing the payment data for the purchase transaction in a data store including a reference to a customer payment account reference (PAR) number, and confirming processing of the payment with the merchant computing system; the merchant computing system completing the purchase transaction and storing sales slip data in a merchant data store; receiving the payment data at a sales slip computing system where the customer PAR associated with the user is stored, the customer being identified by the customer PAR; the sales slip computing system receiving the sales slip data generated by the merchant computing system; and the sales slip computing system matching the payment data and the sales slip data with the user using the customer PAR and without the need for the payment instrument or payment instrument information. The matching enables issuance of an electronic sales slip to the user.

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

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

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

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

[0024] According to an aspect of the invention, the payment processing confirmation comprises a payment authorization message sent to the sales voucher computing system.

[0025] According to aspects of the invention, the payment data received by the sales slip 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 slip computing system when a payment transaction is confirmed. In some such aspects, receiving the payment data comprises the sales slip computing system requesting payment data from the payment processing computing system using the customer PAR, and receiving, in response to the request, the payment data stored in the payment processor data store that includes a reference to the customer PAR. In still further aspects, receiving the payment data from the payment processor computing system further comprises the payment processing computing system receiving the request for payment data from the sales slip computing system, identifying the payment data stored in the payment processor data store that includes a reference to the customer PAR, and providing the identified payment data stored in the payment processor data store that includes a reference to the customer PAR to the sales slip computing system.

[0026] According to aspects of the invention, the payment data received by the Sales Note Computing System is provided by an Acquirer Computing System involved in the processing of the payment. In some such aspects, the Acquirer Computing System provides the payment data to the Sales Note Computing System when payment processing is confirmed. In other aspects, receiving the payment data comprises the Sales Note Computing System requesting payment data from the Acquirer Computing System using the customer PAR, and receiving, in response to the request, the payment data stored in an Acquirer Data Store that includes a reference to the customer PAR. In some such aspects, receiving the payment data from the Acquirer Computing System further comprises the Acquirer Computing System receiving the request for payment data from the Sales Note Computing System, identifying the payment data stored in the Acquirer Data Store that includes a reference to the customer PAR, and providing the identified payment data stored in the Acquirer Data Store that includes a reference to the customer PAR to the Sales Note Computing System.

[0027] According to aspects of the invention, the payment data received by the sales slip 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 slip computing system when payment processing is confirmed. In other aspects, receiving the payment data comprises the sales slip computing system requesting payment data from the card scheme computing system using the customer PAR, and receiving in response to the request the payment data stored in a card scheme data store that includes a reference to the customer PAR. In some such aspects, receiving the payment data from the card scheme computing system further comprises the card scheme computing system receiving the request for payment data from the sales slip computing system, identifying the payment data stored in the card scheme data store that includes a reference to the customer PAR, and providing the identified payment data stored in the card scheme data store that includes a reference to the customer PAR to the sales slip computing system.

[0028] According to aspects of the invention, the payment data received by the sales slip computing system is provided by an issuer computing system involved in the processing of the payment. In some such aspects, the issuer computing system provides the payment data to the sales slip computing system when payment processing is confirmed. In other aspects, receiving the payment data comprises the sales slip computing system requesting payment data from the issuer computing system using the customer PAR, and receiving, in response to the request, the payment data stored in an issuer data store that includes a reference to the customer PAR. In some such aspects, receiving the payment data from the issuer computing system further comprises the issuer computing system receiving the request for payment data from the sales slip computing system, identifying the payment data stored in the issuer data store that includes a reference to the customer PAR, and providing the identified payment data stored in the issuer data store that includes a reference to the customer PAR to the sales slip computing system.

[0029] According to aspects of the invention, the payment data received by the sales slip computing system is provided by the merchant computing system. In some such aspects, the merchant computing system provides the payment data to the sales slip computing system when the purchase transaction is completed. In other aspects, receiving the payment data includes the sales slip computing system requesting payment data from the merchant computing system using the customer PAR, and receiving, in response to the request, the payment data stored in a merchant data store that includes a reference to the customer PAR. In some such aspects, receiving the payment data from the merchant computing system further includes the merchant computing system receiving the request for payment data from the sales slip computing system, identifying the payment data stored in the merchant data store that includes a reference to the customer PAR, and providing the identified payment data stored in the POS and / or merchant data store that includes a reference to the customer PAR to the sales slip computing system.

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

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

[0032] According to aspects of the invention, the sales slip data received by the Sales Slip Computing System is provided by an Acquirer Computing System involved in processing the payment. In some such aspects, the Acquirer Computing System provides the sales slip data to the Sales Slip Computing System when the purchase transaction is completed. In other aspects, receiving the sales slip data from the Acquirer Computing System includes the Sales Slip Computing System extracting transaction parameters from the received payment data, requesting the sales slip data from the Acquirer Computing System using the extracted transaction parameters, and receiving the sales slip data stored in an Acquirer Data Store 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 digits of PAN, first 6 digits of PAN, PAR, PAN token / derivative, terminal ID, currency code, transaction amount, transaction date, and transaction time. In other aspects, receiving the sales slip data from the acquirer computing system further comprises the acquirer computing system receiving a request for the sales slip data from the sales slip computing system, identifying the sales slip data stored in an acquirer data store that includes the transaction data, and providing the identified sales slip data stored in the acquirer data store to the sales slip computing system. In yet other aspects, the sales slip data stored at the acquirer includes the customer PAR. In some such aspects, receiving the sales slip data from the acquirer computing system comprises the sales slip computing system requesting the sales slip data from the acquirer computing system using the customer PAR, and receiving, in response to the request, the sales slip data stored in an acquirer data store that includes a reference to the customer PAR.Further, in some such aspects, receiving the sales slip data from the acquirer computing system further includes the acquirer computing system receiving a request for the sales slip data from the sales slip computing system, identifying the sales slip data stored in an acquirer data store that includes a reference to the customer PAR, and providing the identified sales slip data stored in an acquirer data store that includes a reference to the customer PAR to the sales slip computing system.

[0033] According to aspects of the invention, the sales slip data received by the sales slip computing system is provided by a card scheme computing system involved in processing the payment. In some such aspects, the card scheme computing system provides the sales slip data to the sales slip computing system when the purchase transaction is completed. In other aspects, receiving the sales slip data from the card scheme computing system includes the sales slip computing system extracting transaction parameters from the received payment data, requesting the sales slip data from the card scheme computing system using the extracted transaction parameters, and receiving the sales slip data stored in a card scheme data store in response to the request. In still further aspects, the transaction parameters include one or more of the merchant / POS of the transaction, transaction ID, merchant / POS ID, merchant code, authorization code, last 4 digits of PAN, first 6 digits of PAN, PAR, PAN token / derivative, terminal ID, currency code, transaction amount, transaction date, and transaction time. In some further aspects, receiving the sales slip data from the card scheme computing system further comprises the card scheme computing system receiving a request for the sales slip data from the sales slip computing system, identifying the sales slip data stored in a card scheme data store that includes the transaction data, and providing the identified sales slip data stored in the card scheme data store to the sales slip computing system. In some such further aspects, the sales slip data stored at the card scheme includes the customer PAR. In still further such aspects, receiving the sales slip data from the card scheme computing system comprises the sales slip computing system requesting the sales slip data from the card scheme computing system using the customer PAR, and receiving, in response to the request, the sales slip data stored in a card scheme data store that includes a reference to the customer PAR.In some such aspects, receiving the sales slip data from the Card Scheme Computing System further includes the Card Scheme Computing System receiving a request for the sales slip data from the Sales Scheme Computing System, identifying the sales slip data stored in a Card Scheme Data Store that includes a reference to the customer PAR, and providing the identified sales slip data stored in a Card Scheme Data Store that includes a reference to the customer PAR to the Sales Scheme Computing System.

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

[0035] According to an aspect of the invention, the method further comprises storing one or more of the payment data, receipt data, and the electronic sales slip, the user being identified by the PAR in a data store of the sales slip computing system.

[0036] According to an aspect of the invention, the merchant computing system comprises a Point of Sale (POS) system. In another aspect, the merchant computing system comprises a payment gateway. In yet another aspect, the merchant computing system comprises a payment terminal or a payment device reader.

[0037] According to an aspect of the invention, the method includes the sales ticket computing system issuing an electronic sales ticket to the user. In another aspect, the method further includes providing the matched / linked payment data and sales ticket data to one or more of a merchant, a payment processor, an acquirer, a card scheme, and an issuer so that an electronic sales ticket can be issued to the user.

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

[0039] According to an embodiment of the present invention, there is provided a system for matching an electronic sales slip with a user for a customer purchase transaction, the system including a merchant computing system, a payment processor, and a sales slip computing system. The merchant computing system has a processor and a data store and is configured to receive payment data via a payment instrument with payment instrument information provided to complete payment for the customer purchase transaction; communicate the payment instrument information to a payment processor computing system; receive confirmation of payment processing; complete the purchase transaction; and store sales slip data in the data store. The payment processor computing system has a processor and a data store and is configured to receive payment instrument information from the merchant computing system; process the payment; store payment data for the purchase transaction in the data store including a reference to a customer; and confirm processing of the payment with the merchant computing system. The sales slip computing system has a processor and a data store and is configured to: store the customer PAR associated with the user in the data store; receive the payment data, where the customer is identified by the customer payment account reference (PAR); store the received payment data in the data store; receive the sales slip data generated by the merchant computing system; store the received sales slip data in the data store; and match the payment data and the sales slip data to the user using the PAR, where the match enables issuance of an electronic sales slip to the user.

[0040] According to an embodiment of the present invention, there is provided a method of issuing an electronic sales ticket to a user for a customer purchase transaction, the method including the steps of: a merchant computing system receiving payment data via a payment instrument having payment instrument information provided to complete payment for the 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 and storing the payment data for the purchase transaction in a payment processor data store and confirming processing of the payment with the merchant computing system; the merchant computing system completing the purchase transaction and storing the sales ticket data in a merchant data store; receiving the payment data; matching the payment data and the sales ticket data to the user using the payment account reference (PAR); issuing an electronic sales ticket to a sales ticket computing system storing the electronic sales ticket in a data store; and the sales ticket computing system providing user access to the electronic sales ticket.

[0041] According to an embodiment of the present invention, there is provided a system for issuing an electronic sales slip to a user for a customer purchase transaction, the system including a merchant computing system, a payment processing system, and a sales slip computing system, the merchant computing system having the processor and a data store, and configured to receive payment data via a payment instrument having payment instrument information provided to complete a payment for the customer purchase transaction, communicate the payment instrument information to a payment processor computing system, receive confirmation of payment processing, complete the purchase transaction, store sales slip data in the data store, receive payment data, store payment data in the data store, match the payment data with sales slip data, and issue an electronic sales slip to the user using a customer payment account reference (PAR) in place of the payment instrument or payment instrument information, the payment processor computing system having a processor and a data store, and configured to receive payment instrument information from the merchant computing system, process the payment, store payment data for the purchase transaction in the data store including a reference to the customer PAR, and confirm processing of the payment with the merchant computing system. A sales ticket computing system has a processor and a data store and is configured to receive the electronic sales ticket issued by the merchant, store the electronic sales ticket in a data store, and provide user access to the electronic sales ticket using the customer PAR. [Brief description of the drawings]

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

[0043] [Figure 1] 1 is an example of an illustrative system for monitoring purchase transactions at a storefront and issuing electronic sales tickets to users based on the transactions, according to an embodiment of the present invention.

[0044] [Diagram 2] FIG. 2 is a flow diagram illustrating an example methodology for issuing an electronic sales ticket to a user for a customer purchase transaction.

[0045] [Diagram 3] FIG. 1 is a flow diagram illustrating an exemplary methodology for executing a PAN / PAR swap.

[0046] [Figure 4] FIG. 1 is a flow diagram illustrating an example methodology for requesting payment data.

[0047] [Diagram 5] FIG. 1 is a flow diagram illustrating an example methodology for receiving a request for payment data.

[0048] [Figure 6] FIG. 1 is a flow diagram illustrating an example methodology for requesting receipt data.

[0049] [Figure 7] FIG. 11 is a flow diagram illustrating an example methodology for receiving a request for receipt data.

[0050] [Figure 8] FIG. 1 is a block diagram of an example computing device that may be used to implement an electronic sales ticket system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0051] An exemplary embodiment of the present invention relates to a method and system for issuing electronic sales slips that protects user identity by using a payment account reference (PAR) number instead of payment instrument information to identify the user. The use of PARs offers several advantages: PAR numbers are considered non-sensitive data and non-PCI DSS account data and cannot be misused outside the card network, i.e., PAR numbers cannot be used for payments, unlike PANs (Primary Account Numbers, aka card numbers). The use of PARs is a more secure, faster, and frictionless means of identifying transactions and users for issuing digital sales slips. PAR numbers remain the same in most cases, even though cards expire, are reissued, etc.

[0052] 1 through 8, in which like parts are designated with like reference numerals throughout, illustrate an exemplary embodiment or embodiments of a method and system for issuing an electronic sales ticket, in accordance with the present invention. Although the present invention will be described with reference to the example embodiment or embodiments illustrated in the drawings, it should be understood that many alternative forms can embody the invention. Those skilled in the art will further recognize various ways to change the parameters of the disclosed embodiments, such as the size, shape, or type of elements or materials, while remaining consistent with the spirit and scope of the present invention.

[0053] A system 100 for processing and tracking customer purchase transactions and generating electronic sales tickets is depicted in FIG.

[0054] The system 100 includes a merchant 102, a user 104, a payment processor 106, and a sales slip system 108. In certain 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 is in communication with the other components of the system 100. For example, the components 102, 104, 106, 108, 110, 112, and 114 may be in electronic communication, such as via 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 the other components 102, 104, 106, 108, 110, 112, and 114.

[0055] A merchant 102 is a location, such as a merchant or vendor, where a customer makes a payment for goods or services. The merchant 102 may include a point of sale (POS) system 115, a payment terminal / payment device reader 116, and / or a payment gateway 117 having software, hardware, or a combination of both.

[0056] The POS system 115 is software and / or hardware typically used to receive, process, and store information regarding payments for goods or services when transactions are performed at a merchant. The payment terminal or payment device reader 116 is hardware used to read and accept PAN card (credit or debit) type payment instruments. The payment gateway 117 is software and / or hardware typically used to receive, process, and store information regarding payments for goods or services when transactions are performed online. The payment terminal or payment device reader 116 and / or the payment gateway 117 may be part of the POS system 115 or may be separate. In some cases, the POS system 115, the payment terminal or payment device reader 116, or the payment gateway 117, including the necessary software and hardware, are provided by a separate or third party contracted by the merchant 102. Regardless of the implementation, the POS system 115, payment terminal or payment device reader 116, and / or payment gateway 117 provide the functionality necessary for a merchant to conduct transactions using credit cards, debit cards, digital wallets, or PAN cards, and are considered, for purposes of this disclosure, part of the functionality provided by the merchant 102.

[0057] The merchant 102 receives the payment information and records the transaction details as sales slip data, which may be a physical storefront or a virtual storefront such as a web shop, online store, computer, or mobile electronic device, or any combination thereof. In this example, the merchant 102 further includes a data store 118 for storing the sales slip data of the purchase transaction, and in some cases, payment or transaction data.

[0058] Sales slip data may include merchant data (name, address, ID number), receipt / order ID, date and time, barcode, cash drawer, return policy, royalties, rebates, employee details, notes, references, a description or list of each item purchased along with detailed associated information such as the cost of each item, the category of items purchased, the total price of all items plus a description or list of any taxes or fees charged and discounts applied. In contrast, payment or transaction data such as that provided in a PAN card (e.g., credit or debit card) receipt reveals only the total amount charged without providing a detailed breakdown of the items that make up the total amount charged and an explanation of each individual line item, discount, tax, or fee. Furthermore, a PAN card (credit / debit) receipt cannot legally be used for things like financial bookkeeping, tax credits, VAT, etc., whereas a sales slip can be used for financial bookkeeping, tax credits, VAT, etc.

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

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

[0061] The sales receipt system 108 maintains accounts for users 104, receives and / or collects payment or transaction data and receipt data associated with purchase transactions made using a payment instrument 119 associated with the user 104, and matches the payment and receipt data to the user 104 using the PARs for issuing electronic sales receipts to the user 104. The sales receipt system 108 need not store sensitive payment instrument information for the user 104, but instead may use the PARs to track transactions made using the payment instrument 119 for the user 104. The sales receipt system 108 may further include a data store 122 for storing data: account data for the user 104 including the PARs, payment data for purchase transactions, and sales receipt data for purchase transactions.

[0062] The acquirer 110 is a financial institution that handles funds for the merchant 102. The acquirer 110 may be the same entity as the payment processor 106. In certain embodiments, the acquirer 110 may further include a data store 124 for storing payment data for purchase transactions, and in some cases sales slip data for purchase transactions.

[0063] The card scheme 112 is a payment network linked to payment cards, such as debit, credit, or other PAN cards, of which a bank or any other eligible financial institution may be a member. Examples of such card schemes include Visa™, Mastercard™, American Express™, Dankort™, UnionPay™, and Discover™. In certain embodiments, the card scheme 112 may further include a data store 126 for storing payment data for purchase transactions, and in some cases sales slip data for purchase transactions.

[0064] The issuer 114 is a financial institution that acts on behalf of the user 104 in a financial transaction and issues the user 104 a payment instrument 119 for use in the transaction. In some cases, the issuer 114 may also include a BIN controller. In certain embodiments, the issuer 114 may further include a data store 128 for storing payment data for purchase transactions, and in some cases sales slip data for purchase transactions.

[0065] The operation of the system 100 is described in the method 200 of the flow chart of FIG. 2. Before any electronic sales tickets can be issued, the user 104 needs to be registered with the sales ticket system 108 (step 202). This involves an interaction, in this case electronic communication, between the user 104 and the sales ticket system 108 as indicated by arrows 146 and 148 in FIG. 1. This registration 202 involves providing information about the user 104 that is typically required to set up an account, including name, contact information, PAN number, or PAN token / equivalent (used for the PAN / PAR swap described herein), etc. In certain embodiments, this is performed via a web interface or application of the sales ticket system itself on the user's 104 computing device, or directly via the merchant's own system, through the sales ticket system's service provider / partner / customer (e.g., a bank, issuer, expense management system, or other receipt provider), or a combination thereof. As part of this process, the PAR of the user 104 is stored on the sales ticket system 108 as part of the user's account. PAR may be provided by a user 104, a payment instrument 119, or a merchant 102, or may be obtained by executing a PAN / PAR swap. Further discussion of obtaining PAR is provided herein in connection with FIG.

[0066] FIG. 3 illustrates an exemplary methodology 300 for performing a PAN / PAR swap. 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 upon request (step 304). The PAR may then be stored (step 306). This type of PAN / PAR swap may be performed by any entity (merchant 102, user 104, etc.). For example, in the example of a sales slip system 108 performing a swap, communication between the sales slip system 108 and the card scheme is shown by arrows 166 and 168 in FIG. 1. Communication with the issuer 114 is shown by arrows 170 and 172 in FIG. 1.

[0067] 2 (step 202) to register a user need only be done once, while each of a user's PAN or PAN token or PAN equivalent or PAN derivative may only need to be registered once, after which any number of transactions can be processed and electronic sales slips can be issued by the system using the user account data described in the remainder of method 200 beginning at step 204. However, user accounts can be updated in a similar manner to include changes to the user data.

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

[0069] The merchant 102 then communicates the payment instrument information to the payment processor 106 computing system (step 206), indicated in FIG. 1 by arrow 134. The payment processor 106 then processes the payment (step 208). In certain embodiments, processing the payment includes providing the 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 therefrom. This transfer of data may occur through direct or indirect communication. For example, in FIG. 1, the payment processor 106 may provide the payment instrument information to the acquirer 110, indicated by arrow 150. In response, the acquirer 110 provides the payment data, indicated by arrow 152. The acquirer 110 can in turn obtain payment information from the card scheme 112 by providing the payment instrument information to the card scheme 112, indicated by arrow 154, and in response receiving the payment data, 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 scheme 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, if 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 the payment data.

[0070] The payment data is stored 210 in a payment processor data store 120. In some embodiments, the payment data includes the 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.

[0071] The payment processor 106 then confirms the transaction of the payment with the merchant 102 (step 212). In certain embodiments, the confirmation of the transaction of the payment may also include providing a payment authorization message sent to the sales slip system 108. In some embodiments, payment data may also be provided to the merchant 102 as part of the payment confirmation. In some cases, this data includes the PAR. The payment data may be stored in the data store 117 of the merchant 102.

[0072] The merchant 102 then completes the purchase transaction (step 214). In certain embodiments, this includes printing a physical sales ticket for the user 104, as indicated by arrow 132 in FIG. 1. The sales ticket data is then stored in the merchant data store 118 (step 216). In certain embodiments, this data may also include the PAR.

[0073] The sales invoice 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 store 122 of the sales invoice system 108. Using this PAR, the sales invoice 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 on request or unsolicited. For example, in some embodiments, the payment data is provided to the sales invoice 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 upon request from the sales invoice system 108. In some embodiments, the request is made using the customer PAR. Figure 4 provides an example method 400 performed by the sales slip system 108 to request payment data from a payment processor 106, an acquirer 110, a card scheme 112, an issuer (or BIN controller) 114, or a merchant 102, while Figure 5 provides an example method 500 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 the sales slip system 108.

[0074] 4, the sales receipt system 108 can use the customer PAR stored in data store 122 (step 402) to 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, and in response receive payment data including the customer PAR provided by the customer that is stored in the respective data store 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 (step 404).

[0075] 5, the merchant 102, payment processor 106, acquirer 110, card scheme 112, or issuer (or BIN controller) 114 for which the request for payment data was intended receives the request for payment data including the provided customer PAR (step 502). The payment data including the provided customer PAR is identified in the respective data stores 117, 120, 124, 126, and 128 (step 504). The identified payment data including the customer PAR is provided to the requester, in this case sales slip system 108 (step 506).

[0076] It should be noted, however, that payment data may also be provided without a request being made. In certain embodiments, each of data stores 117, 120, 124, 126, and 128 may be configured to automatically provide payment data to sales slip system 108. It should also be understood that a request may be made without the use of a PAR. In such embodiments, the request and response would be similar to the process for requesting and receiving sales slip data, as described below with reference to Figures 6 and 7, where other transaction parameters may be used to identify the transaction, including, but not limited to, the merchant / POS of the transaction, transaction ID, merchant / POS ID, merchant code, authorization code, last 4 digits of PAN, first 6 digits of PAN, PAN token / derivative, terminal ID, currency code, transaction amount, transaction date, and time of the transaction.

[0077] Communication with the merchant 102 is shown in FIG. 1 by arrows 138 and 140. Communication with the payment processor 106 is shown in FIG. 1 by arrows 142 and 144. Communication with the acquirer 110 is shown in FIG. 1 by arrows 162 and 164. Communication with the card scheme 112 is shown in FIG. 1 by arrows 166 and 168. Communication with the issuer (or BIN controller) 114 is shown in FIG. 1 by arrows 170 and 172. In certain embodiments, this communication is performed by API calls, web hooks, or similar means of communication between systems / computing devices / databases. It should also be understood that the methodology of FIG. 4 and FIG. 5 can be used for requests for payment data between any of the payment processor 106, acquirer 110, card scheme 112, or issuer (or BIN controller) 114.

[0078] Referring again to FIG. 2, in addition to receiving payment data (step 218), the sales slip system 108 receives sales slip data (step 220). While the sales slip data is typically generated and stored at the merchant 102 (step 216), the sales slip data can 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 slip data through direct or indirect communication with the merchant 102. Such communication is indicated by arrows 134, 136, 150, 152, 154, 156, 158, 160, 172, 174, 176, 178, 180, and 182.

[0079] The sales slip data may be provided upon request or unsolicited. For example, in some embodiments, the sales slip data is provided to the sales slip 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 slip data is provided in response to a request from the sales slip system 108. Figure 6 provides an example method 600 performed by the sales slip system 108 to request sales slip data from the merchant 102, payment processor 106, acquirer 110, card scheme 112, or issuer 114 (or BIN controller), while Figure 7 provides an example method 700 performed by the merchant 102, payment processor 106, acquirer 110, card scheme 112, or issuer 114 (or BIN controller) in response to a request from the sales slip system 108.

[0080] 6, the sales slip system 108 makes a request for sales slip data from 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 slip data matching the request stored in the respective data stores 118, 120, 124, 126, 128 of the merchant 102, payment processor 106, acquirer 110, card scheme 112, or issuer 114 (or BIN controller) for which the request was made (step 604). However, unlike the payment data, the sales slip data stored in the respective data stores 118, 120, 124, 126, 128 may not include customer PAR. If customer PAR is not included in the sales slip data, the sales slip system extracts 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 digits of PAN, first 6 digits of PAN, PAN token / derivative, terminal ID, currency code, transaction amount, transaction date, and time of the transaction. If the sales slip data includes a customer PAR, the customer PAR may be included in the request. As illustrated in FIG. 7, the merchant 102, payment processor 106, acquirer 110, card scheme 112, or issuer (or BIN controller) 114 for which the request for sales slip data is intended receives a request for sales slip data including identifying information such as transaction parameters or customer PAR extracted from the payment data (step 702). The sales slip data including the provided transaction parameters or customer PAR is identified in the respective data stores 118, 120, 124, 126, and 128 (step 704). The identified sales slip data, including the provided transaction parameters or customer PAR, is provided to the requester, in this case sales slip system 108 (step 706).

[0081] Communications with the merchant 102 are shown in Figure 1 by arrows 138 and 140. Communications with the payment processor 106 are shown in Figure 1 by arrows 142 and 144. Communications with the acquirer 110 are shown in Figure 1 by arrows 162 and 164. Communications with the card scheme 112 are shown in Figure 1 by arrows 166 and 168. Communications with the issuer (or BIN controller) 114 are shown in Figure 1 by arrows 170 and 172. Communications between the payment processor 106 and the merchant 102 are shown in Figure 1 by arrows 134 and 136. Communications between the acquirer 110 and the merchant 102 are shown in Figure 1 by arrows 172 and 174. Communications between the card scheme 112 and the merchant 102 are shown in Figure 1 by arrows 176 and 178. Communications between the issuer (or BIN controller) 114 and the merchant 102 are shown in Figure 1 by arrows 180 and 182. In certain embodiments, this communication is performed by API calls, web hooks, or similar means of communication between systems, computing devices, or databases.

[0082] It should also be appreciated that the methodologies of Figures 6 and 7 can be used for requests for sales slip data between any of the payment processors 106, acquirers 110, card schemes 112, or issuers (or BIN controllers) 114. Similarly, the methodologies of Figures 6 and 7 can be used to request payment data from any of the merchants 102, payment processors 106, acquirers 110, card schemes 112, or issuers (or BIN controllers) 114 when a PAR is not available to make the request.

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

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

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

[0086] 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 further appreciate that multiple such components may be implemented by a single device, depending on the intended application and use of a particular embodiment. Similarly, in some cases, a single component may be implemented by multiple devices. As such, FIG. 8 is merely illustrative of an example computing device that may be used to implement one or more embodiments of the present invention, and is not intended to limit the invention in any way.

[0087] Computing device 800 can include or interact with a variety of computer readable media. For example, computer readable media can include Random Access Memory (RAM); Read Only Memory (ROM); Electronically Erasable Programmable Read Only Memory (EEPROM); Flash memory or other memory technologies; CD-ROM, digital versatile disk (DVD); Solid State Drive (SSD), cloud, or other optical or holographic media; magnetic cassettes, magnetic tape, magnetic disk storage, or other magnetic storage devices that can be used to encode information and that can be accessed by computing device 800.

[0088] The memory 812 may include computer storage media in the form of volatile and / or non-volatile memory. The memory 812 may be removable or non-removable, or any combination thereof. Exemplary hardware devices are devices such as hard drives, solid state memories, and optical disk drives. 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, etc. The presentation components 816 present data indications to a user or other devices. Exemplary presentation components include display devices, speakers, printing components, vibrating components, etc.

[0089] The I / O ports 818 may allow the 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 of which may be built into the computing device 800. Examples of such I / O components 820 include microphones, joysticks, recording devices, game pads, satellite dishes, scanners, printers, wireless devices, and network devices.

[0090] The functionality of the present invention depicted in FIGS. 2-7 is provided by the systems and hardware of FIGS. 1 and 8 through the execution of software that transforms the hardware into specifically configured hardware suitable for implementing the technical advances of the present invention. It should be understood that the functionality of any component may be combined with or otherwise provided by any other component of the system so long as the desired operability and performance is maintained. For example, in some embodiments, the merchant 102 (or, in some cases, the POS system 115 and / or the payment gateway 116 of the merchant 102) may perform a match of payment data against receipt data and generate or otherwise issue an electronic receipt. This electronic receipt will identify the user 104 only by the customer PAR. In some versions of this embodiment, the receipt system 108 will receive the electronic receipt and store it for archival, bookkeeping, and distribution to or future access by the user 104. It should further be noted that the systems and methods of the present invention do not preclude operation with other third party systems, any of which may also perform the match or any other functionality described herein. Any such integration with other third party systems may or may not include all of the inventive aspects of the present invention, but does not necessarily preclude such integration.

[0091] As used herein, the terms "comprise" 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, illustration, or illustration" and should not be interpreted as indicating or not indicating a preferred or advantageous configuration over other configurations. As used herein, the terms "about," "generally," and "approximately" are intended to cover variations that may exist at the upper and lower limits of a range of subjective or objective values, such as variations in properties, parameters, sizes, and dimensions. In one non-limiting example, the terms "about," "generally," and "approximately" mean exactly, or up to plus or minus 10 percent. In one non-limiting example, the terms "about," "generally," and "approximately" mean close enough to be considered included by one of ordinary skill in the relevant art. As used herein, the term "substantially" refers to a perfect or nearly perfect degree or extent of an action, feature, property, state, structure, item, or result, as would be understood by one of ordinary skill in the art. For example, an object that is "substantially" circular would mean that the object is perfectly circular to the limits that can be mathematically determined, or is close to a circle as would be recognized or understood by a person of ordinary skill in the art. The exact tolerance for deviation from absolute perfection may depend in some instances on the particular context. In general, however, the closeness to perfection will be such that absolute total perfection would have the same overall result as achieved or obtained. The use of "substantially" is equally applicable when used in a negative sense, referring to a complete or nearly complete lack of an action, feature, property, state, structure, item, or result, as would be recognized by a person of ordinary skill in the art.

[0092] As used herein, an "electronic sales slip" is a non-physical sales slip, whether it is referred to as a "computerized," "electronic," "digital," "non-paper," or "programmed" sales slip. It should also be noted that there is a notable difference between a "sales slip" and a "card receipt," since a sales slip is the most detailed form of receipt available (including but not limited to line items) and therefore has multiple purposes, whereas a simple "card receipt" does not have the same purpose.

[0093] Numerous modifications and alternative embodiments of the present invention will be apparent to those skilled in the art in light of the foregoing description. This specification is therefore to be construed as merely illustrative, and is intended to teach those skilled in the art the best mode for carrying out the invention. Details of construction may be substantially changed without departing from the spirit of the invention, and the exclusive use of all modifications that come within the scope of the appended claims is reserved. Although embodiments have been described herein in a manner that allows a clear and concise specification to be written, it will be understood and recognized that the embodiments may be variously combined or separated without departing from the invention. The present invention shall be limited only as required by the appended claims and applicable law.

[0094] It should also be understood that the following claims encompass all the generic and specific features of the invention described herein, and all descriptions of the scope of the invention that may be said to fall within their scope as a matter of language.It should also be understood that the following claims encompass all the generic and specific features of the invention described herein, and all descriptions of the scope of the invention that may be said to fall within their scope as a matter of language.

Claims

1. 1. A method for matching an electronic sales ticket with a user for a customer purchase transaction, comprising: receiving, by a merchant computing system, payment data via a payment instrument having payment instrument information provided to complete payment for said customer purchase transaction; said merchant computing system communicating payment instrument information to a payment processor computing system; The payment processor computing system includes: Process payments; storing the payment data for the purchase transaction in a data store that includes a reference to a customer payment account reference (PAR); and verifying transaction of said payment using said merchant computing system; The merchant computing system: Completing the purchase transaction; and storing the sales slip data in a merchant data store; receiving said payment data at a sales voucher computing system in which said customer PAR associated with said user is stored, said customer being identified by said customer PAR; receiving, by the sales ticket computing system, the sales ticket data generated by the merchant computing system; and said sales slip computing system matching said payment data and said sales slip data with said user using said customer PAR and without needing said payment instrument or payment instrument information, said matching enabling issuance of an electronic sales slip to said user. method.

2. 2. The method of 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 of claim 1 , wherein the customer PAR is provided using the payment instrument.

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

5. The method of 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 sales slip computing system: Receive a Primary Account Number (PAN) or a PAN token or a PAN equivalent; submitting the PAN or PAN token or PAN equivalent to an issuer or card scheme to request the PAR corresponding to the PAN or PAN token or PAN equivalent; receiving the customer PAR in response to the request; and storing said customer PAR; The method of claim 1 further comprising:

7. 2. The method of claim 1, wherein processing the payment comprises providing payment instrument information to one or more of an acquirer, a card scheme, and an issuer, and receiving payment data for the purchase transaction therefrom in response.

8. 2. The method of claim 1, wherein the payment processing confirmation comprises a payment authorization message sent to one or more of the merchant computing system, the acquiring computing system, the card scheme computing system, the card issuing computing system, and the sales voucher computing system.

9. The method of claim 1 , wherein the payment data received by the sales slip computing system is provided by the payment processing computing system.

10. 10. The method of claim 9, wherein the payment processing computing system provides the payment data to the sales slip computing system when a payment transaction is confirmed.

11. The step of receiving the payment data includes the step of: requesting payment data from the payment processing computing system using the customer PAR; and In response to the request, receiving the payment data stored in the payment processor data store, the payment data including a reference to the customer PAR. The method of claim 9 having the steps:

12. The step of receiving the payment data from the payment processor computing system comprises the step of: receiving the request for payment data from the sales slip computing system; Identifying the payment data stored in the payment processor data store that includes a reference to the customer PAR; and providing the identified payment data stored in the payment processor data store that includes a reference to the customer PAR to the sales slip computing system; The method of claim 11 further comprising the steps of:

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

14. 14. The method of claim 13, wherein the acquirer computing system provides the payment data to the sales slip computing system when a payment transaction is confirmed.

15. The step of receiving the payment data includes the step of: Requesting payment data from the acquirer computing system using the customer PAR; and In response to the request, receiving the payment data stored in an acquirer data store that includes a reference to the customer PAR. The method of claim 13 having the steps:

16. The step of receiving the payment data from the acquirer computing system includes the step of: receiving the request for payment data from the sales slip computing system; Identifying the payment data stored in the acquirer data store that includes a reference to the customer PAR; and providing the identified payment data stored in the acquirer data store that includes a reference to the customer PAR to the sales slip computing system; The method of claim 15 further comprising the steps of:

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

18. 20. The method of claim 17, wherein the card scheme computing system provides the payment data to the sales slip computing system when a payment transaction is confirmed.

19. The step of receiving the payment data includes the step of: requesting payment data from said card scheme computing system using said customer PAR; and In response to the request, receiving the payment data stored in a card scheme data store that includes a reference to the customer PAR.

20. The method of claim 17, comprising the steps of:

20. The step of receiving the payment data from the card scheme computing system comprises the step of: receiving the request for payment data from the sales slip computing system; Identifying the payment data stored in the card scheme data store that includes a reference to the customer PAR; and providing the identified payment data stored in the card scheme data store that includes a reference to the customer PAR to the sales voucher computing system; 20. The method of claim 19 further comprising the steps of:

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

22. 22. The method of claim 21, wherein the issuer computing system provides the payment data to the sales slip computing system when a payment transaction is confirmed.

23. The step of receiving the payment data includes the step of: Requesting payment data from the issuer computing system using the customer PAR; and In response to the request, receiving the payment data stored in an issuer data store that includes a reference to the customer PAR.

22. The method of claim 21 having the steps:

24. The step of receiving the payment data from the Issuer Computing System includes the step of the Issuer Computing System: receiving the request for payment data from the sales slip computing system; Identifying the payment data stored in the issuer data store that includes a reference to the customer PAR; and providing the identified payment data stored in the issuer data store that includes a reference to the customer PAR to the sales slip computing system; 24. The method of claim 23 further comprising the steps of:

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

26. 26. The method of claim 25, wherein the merchant computing system provides the payment data to the sales ticket computing system when the purchase transaction is completed.

27. The step of receiving the payment data includes the step of: requesting payment data from the merchant computing system using the customer PAR; and In response to the request, receiving the payment data stored in the merchant data store that includes a reference to the customer PAR.

26. The method of claim 25, comprising the steps:

28. The step of receiving the payment data from the merchant computing system includes the merchant computing system: receiving the request for payment data from the sales slip computing system; Identifying the payment data stored in the merchant data store that includes a reference to the customer PAR; and providing the identified payment data stored in a merchant data store that includes a reference to the customer's payment receipt to the sales slip computing system; 30. The method of claim 27 further comprising the steps of:

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

30. 30. The method of claim 29, wherein the merchant computing system provides the sales slip data to the sales slip computing system when the purchase transaction is completed.

31. The step of receiving the sales slip data from the merchant computing system includes the step of: Extracting transaction parameters from the received payment data; requesting the sales slip data from the merchant computing system using the extracted transaction parameters; and In response to the request, receiving the sales slip data stored in the merchant data store.

30. The method of claim 29, comprising the steps:

32. 32. The method of 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 digits of PAN, first 6 digits of PAN, PAR, PAN token / derivative, terminal ID, currency code, transaction amount, transaction date, and transaction time.

33. The step of receiving the sales slip data from the merchant computing system includes the merchant computing system: receiving the request for the sales ticket data from the sales ticket computing system; Identifying the sales slip data stored in the merchant data store that includes the transaction data; and providing the identified sales slip data stored in the merchant data store to the sales slip computing system.

32. The method of claim 31 further comprising the steps of:

34. 30. The method of claim 29, wherein the sales slip data stored in the data store includes the customer PAR.

35. The step of receiving the sales slip data from the merchant computing system includes the step of: requesting the sales slip data from the merchant computing system using the customer PAR; and In response to the request, receiving the sales slip data stored in the merchant data store that includes a reference to the customer PAR.

35. The method of claim 34, comprising the steps:

36. The step of receiving the sales slip data from the merchant computing system includes the merchant computing system: receiving the request for the sales ticket data from the sales ticket computing system; Identifying the sales slip data stored in the merchant data store that includes a reference to the customer PAR; and providing the identified sales slip data stored in the merchant data store that includes a reference to the customer PAR to the sales slip computing system; 36. The method of claim 35 further comprising the steps of:

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

38. 40. The method of claim 37, wherein the payment processing computing system provides the sales slip data to the sales slip computing system when the purchase transaction is completed.

39. The step of receiving the sales slip data from the payment processing computing system comprises the step of: Extracting transaction parameters from the received payment data; requesting the sales slip data from the payment processing computing system using the extracted transaction parameters; and In response to the request, receiving the sales slip data stored in the payment processor data store.

38. The method of claim 37, comprising the steps of:

40. 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 digits of PAN, first 6 digits of PAN, PAR, PAN token / derivative, terminal ID, currency code, transaction amount, transaction date, and transaction time.

41. The step of receiving the sales slip data from the payment processing computing system includes the step of: receiving the request for the sales ticket data from the sales ticket computing system; Identifying the sales slip data stored in the payment processing data store that includes the transaction data; and providing the identified sales slip data stored in the payment processing data store to the sales slip computing system.

40. The method of claim 39 further comprising the steps of:

42. 38. The method of claim 37, wherein the sales slip data stored in the data store includes the customer PAR.

43. The step of receiving the sales slip data from the payment processing computing system comprises the step of: requesting said sales slip data from said payment processing computing system using said customer PAR; and In response to the request, receiving the sales slip data stored in the payment processing data store that includes a reference to the customer PAR.

43. The method of claim 42, comprising the steps:

44. The step of receiving the sales slip data from the payment processing computing system includes the step of: receiving a request for the sales ticket data from the sales ticket computing system; Identifying the sales slip data stored in the payment processing data store that includes a reference to the customer PAR; and providing identified sales slip data stored in the payment processing data store that includes a reference to the customer PAR to the sales slip computing system; 44. The method of claim 43 further comprising the steps of:

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

46. 46. ​​The method of claim 45, wherein the acquirer computing system provides the sales slip data to the sales slip computing system when the purchase transaction is completed.

47. The step of receiving the sales slip data from the acquirer computing system includes the step of the sales slip computing system: Extracting transaction parameters from the received payment data; requesting the sales slip data from the acquirer computing system using the extracted transaction parameters; and In response to the request, the sales slip data stored in an acquirer data store is received.

46. ​​The method of claim 45, comprising the steps:

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

49. The step of receiving the sales slip data from the acquirer computing system includes the step of: receiving a request for the sales ticket data from the sales ticket computing system; Identifying the sales slip data stored in an acquirer data store that includes the transaction data; and providing the identified sales voucher data stored in an acquirer data store to the sales voucher computing system; 48. The method of claim 47 further comprising the steps of:

50. 46. ​​The method of claim 45, wherein the sales slip data stored at the acquirer includes the customer PAR.

51. The step of receiving the sales slip data from the acquirer computing system includes the step of the sales slip computing system: Requesting the sales slip data from the acquirer computing system using the customer PAR; and In response to the request, receiving the sales slip data stored in an acquirer data store that includes a reference to the customer PAR.

51. The method of claim 50, comprising the steps:

52. The step of receiving the sales slip data from the acquirer computing system includes the step of: receiving a request for the sales ticket data from the sales ticket computing system; Identifying the sales slip data stored in an acquirer data store that includes a reference to the customer PAR; and providing the identified sales slip data stored in an acquirer data store that includes a reference to the customer PAR to the sales slip computing system; 52. The method of claim 51 further comprising the steps:

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

54. 54. The method of claim 53, wherein the card scheme computing system provides the sales slip data to the sales slip computing system when the purchase transaction is completed.

55. The step of receiving the sales slip data from the card scheme computing system comprises the steps of: Extracting transaction parameters from the received payment data; requesting the sales slip data from the card scheme computing system using the extracted transaction parameters; and In response to the request, receiving the sales slip data stored in a card scheme data store.

54. The method of claim 53, comprising the steps:

56. 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 digits of PAN, first 6 digits of PAN, PAR, PAN token / derivative, terminal ID, currency code, transaction amount, transaction date, and transaction time.

57. The step of receiving the sales slip data from the Card Scheme Computing System comprises the steps of: receiving a request for the sales ticket data from the sales ticket computing system; Identifying the sales slip data stored in a card scheme data store that includes the transaction data; and providing the identified sales voucher data stored in the card scheme data store to the sales voucher computing system.

56. The method of claim 55 further comprising the steps of:

58. 54. The method of claim 53, wherein the sales slip data stored in the card scheme includes the customer PAR.

59. The step of receiving the sales slip data from the card scheme computing system comprises the steps of: requesting said sales slip data from said card scheme computing system using said customer PAR; and In response to the request, receiving the sales slip data stored in a card scheme data store that includes a reference to the customer PAR.

59. The method of claim 58, having the following structure:

60. The step of receiving the sales slip data from the Card Scheme Computing System comprises the steps of: receiving a request for the sales ticket data from the sales ticket computing system; Identifying the sales slip data stored in a card scheme data store that includes a reference to the customer PAR; and providing the identified sales voucher data stored in a card scheme data store that includes a reference to the customer PAR to the sales voucher computing system; 60. The method of claim 59 further comprising the steps of:

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

62. 62. The method of claim 61, wherein the issuer computing system provides the sales slip data to the sales slip computing system when the purchase transaction is completed.

63. The step of receiving the sales slip data from the issuer computing system comprises the steps of: Extracting transaction parameters from the received payment data; requesting the sales slip data from the issuer computing system using the extracted transaction parameters; and In response to the request, receiving the sales slip data stored in an issuer data store.

62. The method of claim 61 having the steps:

64. 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 digits of PAN, first 6 digits of PAN, PAR, PAN token / derivative, terminal ID, currency code, transaction amount, transaction date, and transaction time.

65. The step of receiving the sales slip data from the issuer computing system includes the step of: receiving a request for the sales ticket data from the sales ticket computing system; Identifying the sales slip data stored in an issuer data store that includes the transaction data; and providing the identified sales slip data stored in an issuer data store to the sales slip computing system.

64. The method of claim 63 further comprising the steps of:

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

67. The step of receiving the sales slip data from the issuer computing system comprises the steps of: requesting the sales slip data from the issuer computing system using the customer PAR; and In response to the request, receiving the sales slip data stored in an issuer data store that includes a reference to the customer PAR.

67. The method of claim 66, comprising the steps of:

68. The step of receiving the sales slip data from the issuer computing system includes the step of: receiving a request for the sales ticket data from the sales ticket computing system; Identifying the sales slip data stored in an issuer data store that includes a reference to the customer PAR; and providing the identified sales slip data stored in the issuer data store that includes a reference to the customer PAR to the sales slip computing system; 68. The method of claim 67, further comprising the steps:

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

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

71. The method of claim 1 , wherein the merchant computing system comprises a payment gateway.

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

73. The method of claim 1 , further comprising the step of said sales ticket computing system issuing an electronic sales ticket to said user.

74. providing the payment data and sales receipt data matched to 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. The method of claim 1 further comprising:

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

76. 1. A system for matching electronic sales slips with users for customer purchase transactions, the system comprising: A merchant computing system having a processor and a data store, the merchant computing system comprising: receiving payment data via a payment instrument having the provided payment instrument information to complete payment for the customer purchase transaction; communicating the payment instrument information to a payment processor computing system; Receive confirmation of payment processing; Completing the purchase transaction; and Store the sales slip data in the data store. It is structured as follows: The payment processor computing system having a processor and a data store, the payment processor computing system comprising: receiving payment instrument information from said merchant computing system; Process payments; storing payment data for the purchase transaction in the data store including a reference to a customer payment account reference (PAR); and Verify the transaction of the payment using the merchant computing system It is structured as follows: A sales slip computing system having a processor and a data store, the sales slip computing system comprising: storing the customer PAR associated with the user in the data store; receiving said payment data, wherein said customer is identified by said customer PAR; storing the received payment data in the data store; receiving the sales ticket data generated by the merchant computing system; storing the received sales slip data in the data store; and The PAR is used to match the payment data and the sales ticket data to the user, where the match enables issuance of an electronic sales ticket to the user. It is configured as follows: A system comprising:

77. 1. A method for issuing an electronic sales ticket to a user for a customer purchase transaction, comprising: receiving, by a merchant computing system, payment data via a payment instrument having payment instrument information provided to complete payment for said customer purchase transaction; said merchant computing system communicating payment instrument information to a payment processor computing system; The payment processor computing system includes: Process payments; storing the payment data for the purchase transaction in a data store that includes a reference to a customer payment account reference (PAR); and verifying transaction of said payment using said merchant computing system; The merchant computing system: Completing said purchase transaction; storing the sales slip data in a merchant data store; receiving said payment data, wherein said customer is identified by said customer PAR; Matching said payment data and said sales slip data to said user using said PAR; issuing an electronic sales ticket to a sales ticket computing system that stores the electronic sales ticket in a data store; and said sales ticket computing system providing user access to said electronic sales ticket; A method comprising:

78. 1. A system for issuing electronic sales tickets to users for customer purchase transactions, the system comprising: A merchant computing system having a processor and a data store, the merchant computing system comprising: receiving payment data via a payment instrument having the provided payment instrument information to complete payment for the customer purchase transaction; communicating the payment instrument information to a payment processor computing system; Receive confirmation of payment processing; Completing said purchase transaction; storing sales slip data in said data store; Receive payment data; storing payment data in said data store; Matching payment data with sales slip data; and issuing an electronic receipt to said user using a customer payment account reference (PAR) in place of said payment instrument or payment instrument information; It is structured as follows: The payment processor computing system having a processor and a data store, the payment processor computing system comprising: receiving payment instrument information from said merchant computing system; Process payments; storing payment data for the purchase transaction in the data store that includes a reference to the customer PAR; and Verify the transaction of the payment using the merchant computing system It is structured as follows: A sales slip computing system having a processor and a data store, the sales slip computing system comprising: receiving said electronic sales slip issued by said merchant; storing said electronic sales ticket in a data store; and Providing user access to the electronic sales slip using the customer PAR It is configured as follows: system.

Images