WO2016189311A1

WO2016189311A1 - Computer system for implementing a transaction payment

Info

Publication number: WO2016189311A1
Application number: PCT/GB2016/051522
Authority: WO
Inventors: David Michael
Original assignee: Zeet Ltd
Priority date: 2015-05-26
Filing date: 2016-05-26
Publication date: 2016-12-01
Also published as: GB201508922D0; EP3304458A1

Abstract

A method of implementing a transaction payment by means of a computer system, comprising: a POS (100) generating an electronic payment request (400), generating a transaction receipt (200), and assigning a transaction identifier code (300) to the transaction, the POS (100) transmitting the transaction receipt together with the identifier code to a receipt server (110), for storage, the POS transmitting the payment request and said identifier code to a payment system of a customer's bank (120, 140), whereby details of the transaction together with said identifier code appear subsequently on a customer's bank statement (150), and a receipt look up means (130), separate from the payment system, and communicating with the receipt server, whereby when the customer arranges for the identifier code to be transferred from the bank statement to the receipt look up means, the receipt server locates and communicates the transaction receipt to the receipt look up means, to display the receipt to the customer.

Description

COMPUTER SYSTEM FOR IMPLEMENTING A TRANSACTION

PAYMENT

Field of the Invention

The present invention relates to a computer system for implementing a method of dealing with transaction payments, such as purchases, together with associated receipts.

Background Art

In the usual course of making a purchase for goods or services with a credit card or other form of digital payment, both the transaction payment details, in the form of a digitally transmitted funds transfer request, and transaction receipt, which is handed to the customer in the form of a hard copy receipt, are created at the same time. However, for accounting purposes, as far as the customer is concerned, the payment appears on a bank statement and then the burden is on the customer to carry the hard copy receipt and subsequently match it up with payment.

• This is slow and expensive as it's not automatic and is done in batches, which for business it's not ideal.

• It is inaccurate as human error such as forgetting to ask, losing receipt or making a mistake when entering the receipt into accounts/expense packages for business purposes.

• It makes tax and accounting compliance less accurate and more time consuming.

• Printing receipt is not good for the environment.

• Limits automation and innovations as receipt are processed by hand.

• Everyone in business must be good at numbers to process receipts accurately.

• Many don't like the burden of processing receipts and would enjoy life more without it. Thus the current solution of generating paper receipts creates a universal problem of reconciling payments with purchase/VAT information and required human management of the process.

US Pat. No 8,643,875 describes a system for emailing receipts of a transaction to the customer, including: obtaining image data representing a receipt corresponding to the purchasing transaction of the customer at the store location; obtaining an e-mail address of the customer; providing an option to print the receipt at the store location and an option to e-mail the receipt to the customer. This has the following problems:

Emailed receipts are not attached to the payment and still require reconciling. Emailed receipt does not offer any machine readable aspect and VAT breakdown still needs to be interpreted by a person.

Email address or membership card needs to be presented at checkout, slowing the checkout process.

Receipt Scanning Services are known where typically sending in an envelope or on a phone that allows a picture of a receipt to be taken, which is then processed by machine using OCR along with human intervention where the processes can't interpret the data on the receipt. Errors do occur and requires reconciling with payment.

Australian Patent No. 2012100855 discloses a system and method for providing an electronic funds and receipt transfer system capable of making available to the customer receipt data relating to an EFTPOS transaction in an electronic format. The receipt data generated by the merchant at the time of sale is attached to the EFTPOS transaction data and sent to the customer's financial institution. To access the receipt data the system allows the customer to access their financial institutions internet banking webpage and print, save or email a copy of the receipt as generated by the merchant at the time of sale. Thus the concept is to get the banks to store the receipt themselves. The problem is that it requires the bank's computer systems to be revised and changed. Alternatively the receipt and EFTPOS data may be stored on a remote server, and the receipt is retrieved by the bank's computer system using the EFTPOS transaction data. However, this transaction data is not known by the customer and so is dependent on the bank retrieving the receipt and so is reliant on the banks adopting the technology. It is an object of the present invention to provide a computer system for automatically linking transaction data to electronic payment records held by a customer' s bank, without requiring any modification of existing computer systems of the bank.

Summary of the Invention

In embodiments of the invention, when a transaction occurs, and a transaction payment request and a transaction receipt are generated, the transaction is assigned a transaction identifier code that is transmitted electronically with the payment request details to a customer's bank computer system. The transaction identifier code appears on the customer's bank statement together with other information, usually present on a bank statement. The transaction identifier is an inert code, consisting of a string of characters, preferably alpha numeric. The transaction receipt is stored online in a receipt server means separate from the bank's system, but with the same transaction identifier, so that it can be retrieved later by the customer either by hand or by software such as an accounts package. One such way of retrieval would be where the customer enters the transaction information to a webpage that retrieves the receipt from the receipt computer system.

Therefore the invention is different to AU2012100855, which requires the banking computer system to interact with EFTPOS data in order to retrieve the receipt data, at the request of the customer. The invention requires no change to the existing banking computer system, since it assigns a transaction reference code to the payment which is used to retrieve the receipt. This code is an inert sequence of characters, so far as the bank's system is concerned, and may conveniently occupy a space normally provided for identifying payment for convenience of the customer.

For the purposes of the present specification, the terms "banks" should be understood to include retail banks, building societies, credit card companies, and any financial institution which provides electronic funds transfer facilities.

For the purposes of the present specification, the terms "receipts" should be understood to include sales receipts, invoices, bills, credit notes and any other means to record sales transactions

Embodiments of the invention may be used for all types of electronic payment systems, credit card, smart phone, etc, where a card holder is present (in a shop), or when a card payment is made on-line from a remote location. Embodiments of the invention can be used for other payment methods such as direct debits, where for regular monthly payments, the correct monthly invoice is available for each direct debt payment.

Embodiments of the invention provide a novel solution to the problem outlined above, in contrast to current proposals, where the customer must pass an identifier to the retailers, such as email address so they can send the receipt. Embodiments of the invention provide a unique identifier, preferably alphanumeric code, written to the payment in a form that is compatible with current banking systems, but long enough to identify the receipt unambiguously and prevent guessing, so that we are able transfer the receipt to the account holder electronically and keep it tied to the payment and so remove manual reconciling and manual transport of the receipt back to the payment. To be compatible with banking system, the identifier should be an inert code of text that is accessible to the customer. The identifier should be random, unique and have a large possible variance to prevent guessing. In our preferred implementation we use 9 alphanumeric characters to give 36^A9 combinations which is over 100 trillion combinations. Our preferred method of ensuring randomness and uniqueness, is by creating them at the receipt server and transferring them to the POS ready for use. Other methods can be used such generating the identifier within the POS based on the time, date and till for the purchase, often known as UUID, but this reduces the randomness of the transaction identifier. Another method would be for the till to generate the code and keep track of previous codes by storing them locally and checking new codes against the identifiers stored.

When EFTPOS transaction data is generated by a customer paying electronically, the unique transaction identifier is added so that it will be made available on the bank statement. We have chosen the description field, also known as a DBA, which a 22 character field. By way of background, a descriptor is usually added in the descriptor field, DBA, the descriptor being a piece of identifying information about a merchant, e.g. business name, phone number, city and/or state, which appears on buyers' credit/debit card statements. These descriptors remind cardholders of the details of the purchase and give them a way to contact the merchant. Standard descriptor information that gets passed through to the cardholder' s statement is the store name and customer service phone number. Thus the main identifier on the bank statement normally shows the store name, or name of the seller or person providing goods or services. In our preferred design, the descriptor is modified for each individual transaction, and comprises the seller's name consisting of 14 characters followed by an asterisk, then followed by the 9 character alphanumeric code. This gives over 100 trillion transaction identifiers for each store. We can also combine this identifier with the date on the statement to further increase the combination by limiting it by time frame, such as within the previous thirty days from the date shown on the statement. This will result in over 100 trillion combinations per store per month.

In embodiments, the transaction identifier is passed to the EFTPOS device from the EPOS before payment is taken. The transaction identifier needs to be written to payment description before sent for authentication. On payment authentication being successful the transaction identifier sent with the payment request is assigned to the generated merchant receipt and is uploaded from the EPOS to the receipt server. Another method may be employed where transaction identifier management routines exist within the EFTPOS device, used to provide an unused transaction identifiers. Once the transaction data is generated, the code is combined and sent to the payment gateway for authentication, and once authenticated the transaction identifier is passed to the EPOS so to be added to the receipt before uploading to the receipt server.

The receipt server provides an API (Application programming Interface) to allow receipts to be retrieved. The API could be used by a website to allow retrieval of receipts by pasting the transaction code into a web form which then retrieves the receipt via the API and displays it to the user. Other embodiments may automate the retrieval of the receipt for import directly into accounts software by retrieving the statement through a bank API and downloading the receipts and inserting them directly into the accounts service via the accounts service API. This will fully automate receipt processing when a purchase is made by card and will increase productivity of millions of people and aid compliance with tax authorities.

Embodiments may prevent banks from accessing all receipt data and automating the process through banking APIs. Banks can't just gather all data because we are the gateway to the data and would prevent such mass access to receipts through a captcha system (Completely Automated Public Turing test to tell Computers and Humans Apart) for manual access. Customers will be able to create an authorised user account on the receipt server. When retrieving a receipt while authorised, the receipt is assigned to that user preventing any future unauthorised access to that receipt. When an authorised user links to an API, such as a banking API, that continuously provides the statement information, receipts will be assigned automatically to user accounts when they appear on the statement and so preventing any future unauthorised access from other users or institutions such as banks.

As we are the gateway to the receipts we may monitor traffic and ensure that any anonymous access to receipt will need to prove they are human using a captcha for example, this would stop mass receipt downloads by the banks. We could pass some data to the merchant on creating the receipt so they need to provide secondary information that was passed at the point of sale,

Embodiments of the invention:

• Work with current banking systems.

• Removes the burden on the individual to reconcile receipts with payments

• Environmental benefit reduces the number of receipts printed

• Privacy for customer is protected as they don't need to give their information such as an email to the retailer in order to get an electronic receipt.

• Increases productivity and improves the life of people in business.

• Receipts can be proved to be from a certain retailer and so reduce fraud.

• VAT breakdown in the receipt so to reduce human error in input VAT compliance.

• Reduce auditing costs

• Automated business accounts management and cash-flow information which is always up to date. Allowing business owners to use the information to aid their business decisions.

• No more chasing employees for receipts.

• No lost input VAT due to lost receipts.

• No additional steps during checkout. Retailers will be able to increase their relationship with the customer by providing additional information and services along with receipt. Such as a link to their customer services or links for product manuals for example.

Retailers will gather much more business intelligence, such as their catchment area.

Great retail information can be gleamed through the system.

Provide receipts for contactless payments.

The customer can also provide their own references to be included within the receipt/invoice. Such as a purchased order number, their name and address or any other data.

The customer can provide a public encryption key to the merchant allowing the receipt data to be encrypted so to guarantee no one else can view the receipt without the associated private key to decode the data. A customer can also provide a reference, which will be available unencrypted alongside the encrypted receipt data, to help the customer identify which private key will be required to decode the receipt.

In a first aspect, embodiments provide a method of implementing a transaction payment comprising:

generating a payment request, generating a transaction receipt, and assigning a transaction identifier code to the transaction,

transmitting said transaction receipt together with said identifier code to a receipt server, for storage therein,

transmitting said payment request and said identifier code to a payment system of a customer's bank, whereby details of the transaction together with said identifier code appear subsequently on the customer's bank statement, the customer arranging for said identifier code to be transferred from the bank statement to a receipt look up means, separate from said payment system, and said receipt look up service communicating with said receipt server in order to locate and communicate said transaction receipt to said receipt look up means, for providing the receipt to the customer. In a second aspect, embodiments provide a computer system for implementing the aforesaid method, comprising:

a POS means for generating a payment request, generating a transaction receipt, and assigning a transaction identifier code to the transaction,

said POS means arranged for transmitting said transaction receipt together with said identifier code to a receipt server, for storage therein,

said POS means arranged for transmitting said payment request and said identifier code to a payment system of a customer's bank, whereby details of the transaction together with said identifier code appear subsequently on a customer's bank statement,

and a receipt look up means, separate from said payment system, and said receipt look up means communicating with said receipt server, whereby when the customer arranges for said identifier code to be transferred from the bank statement to said receipt look up means, said receipt server locates and communicates said transaction receipt to said receipt look up means, for providing the receipt to the customer.

A receipt in this context is a collection of transaction data, comprising at least some of the following data: the transaction code, the price, the data, the merchant and the goods.

The receipt server is the computer program or system which provides functionality for the system, in particular, generating the transaction references and storing receipts, and the other functionality provided to the other components and parties to the system. It may of course be distributed over a network, e.g. of several internet servers. In practice, it will generally be run by a service provider company, and the controlling organisation is referred to here as "the receipt service", though of course commercially it may be provided by one of the other commercial services such as a bank or credit card company or an independent body.

Brief Description of the Drawings

Preferred embodiments of the invention will now be described by way of example with reference to the accompanying drawings, wherein:

Figure 1 shows a high level schematic diagram of a receipt's journey, in accordance with the invention; Figure 2 shows a high level diagram of a POS;

Figure 3 shows a high level diagram of the functions of a receipt server, in accordance with the invention;

Figure 4 shows the hardware components of the receipt server

Figure 5 shows components of the system in accordance with the invention, connected via a network.

Figure 6 shows the requesting of batches of unassigned transaction references from the receipt server;

Figure 7 shows an unassigned transaction reference being assigned to a receipt and payment;

Figure 8 shows a high level diagram of the payment journey with the assigned transaction reference;

Figure 9 shows retrieving the receipt using the transaction reference using a web interface, in accordance with the invention;

Figure 10 shows rendered receipts generated from the receipt data structure;

Figure 11 shows an authentication signature within the receipt data;

Figure 12 shows a receipt being assigned to a customer;

Figure 13 shows automated retrieval of receipts;

Figure 14 is an example of a transaction receipt

Figure 15 shows a schematic diagram of the architecture of an alternative embodiment of the invention

Figure 16 shows a schematic diagram of the basic structure of a payment gateway

Figure 17 shows a schematic diagram of the basic structure of an issuing bank Figure 18 shows a schematic diagram of the customer sign up process where a card network provides payments notifications to the receipt server.

Figure 19 shows a schematic diagram of a process for including multiple items within the same transaction reference 300. Figure 20 show a point-to-point encrypted receipt

Figure 21 shows a schematic diagram of the attachment of a proof of authenticity along with proof of existence to a receipt and a payment.

Figure 22 shows a schematic diagram of the hashing of a receipt and proof of authenticity

Figure 23 shows a schematic diagram of an automated charity donation system

Description of Embodiments

Figure 1 shows a high level schematic diagram of the receipt journey, in accordance with an embodiment of the invention. A transaction reference identifier code 300 in this example is a store name followed by a sequence of alphanumeric characters 9JY2N2WAF separated by an asterisk. A POS 100 creates a transaction payment request 400 and is assigned a transaction reference 300 and is transmitted digitally, separately from the receipt 200, via connection 10 to a payment gateway 120. A successful response 11 is returned from the payment gateway 120 to the POS 100. The receipt 200 is assigned the transaction reference code 300 and is sent via connection 12 to a receipt server 110 to be stored in database 111. The transaction reference 300 is passed inertly as at 13 to the bank's payment settlement system 140, and appears on the customer statement 150, tied to the payment 151 once the payment is debited from the account.

The transaction reference 300 is subsequently taken by the customer from the statement and passed, by a means separate from the payment system, and via connection 14 to a receipt lookup interface 130, such as a browser on a customer's computer or a Phone App, which in turn requests the receipt with transaction reference 300 from the receipt server 110 via connection 15. The receipt server 110 then returns the receipt 200 via connection 16 to the receipt lookup service 130. The receipt retrieval means 110 130, 14, 15, 16 is independent of the bank's payment system.

Figure 2 show that the POS 100 contains an electronic EPOS 105 and an electronic funds transfer POS EFTPOS 108. Figure 3 shows the services provided by the receipt server 110, which comprise, among other things, database 111 for storing receipts, customers and other information. Generator 112 generates random and unique unassigned transaction references 300 which are requested by POS 100. HTTP/HTTPS web services 115 host services through API 116 and receipt template files 235. The services provided by API 116 are 1161 which provides unassigned transaction identifiers to the POS 100, 1162 receives the receipts 200 from the POS 100 which are then stored to the database, 1163 retrieves receipts 200 by means of the transaction identifier. 1164 assigns receipt to a customer account so access can be restricted to the authorised customer. 118 is other services. 119 is the operating system.

Services could be spread over a number of servers.

Figure 4 shows an example structure for receipt server 110. 1101 is the communication infrastructure that interconnects the components. 1102 is the processor, 1103 is the volatile main memory. 1104 is persistent storage. 1105 is the network connection that allows the device to connect to the network 199. 1106 are other optional interfaces, such as USB connections to allow interaction with 110. 1107 is the power source for 110.

Figure 5 shows components of the system according to the invention POS 100, receipt server 110, payment gateway 120, receipt look up service 130 and bank's payment system 140 interconnected via a network 199, which could be a public network, private network or over the internet.

Figure 6 shows a POS 100 sending a request 9 for new unassigned transaction identifier codes 300 to be use in future transactions. The receipt server 110 returns an array 311 of unassigned references 300 to POS 100.

Figure 7 shows the assignment of a transaction identifier 300 to both the payment request 400 and receipt 200 within the POS 100, as described in more detail above.

Figure 8 show the electronically transmitted payment request 400 with the transaction reference 300 contained along with payment transaction data 402 generated for the purposes of card payment, i.e. funds transfer. This is sent to the payment gateway 120, and when the transaction is completed, shows up as a payment identifier item 151 on the customer statement 150. Item 151 consists of the transaction reference 300, the date debited from the account 301, and the amount debited 302. The payment gateway can also generate an electronic signature to authenticate that a payment was made. Referring to figure 21, this electronic signature 2062 is set to the receipt server by the card network 210a and could also be set by the issuing bank 141 on behalf of the customer.

Figure 9 shows a high level diagram of the process of retrieving from receipt server 150 a rendered receipt 221. A web form 210 is provided by look up service 130, and the transaction reference 300 is entered by the customer manually into the input 211 on the web form 210and the submit button 213 is activated. This results in a webpage 220 containing a rendered receipt 221.

Figure 10 shows how receipt 221 is generated through a combination of the receipt data 200 and template files 235. The template files could be HTML, CSS and images.

Figure 11 shows an authentication or digital signature 721 within the receipt 200 that is generated within receipt server 110 and can be used to verify the authenticity of the receipt. A digital signature may additionally or alternatively be added by the store at the POS when the receipt is generated, to show that the receipt was indeed generated by the merchant.

Figure 12 shows a receipt 200 being assigned to a customer account 800 becoming an assigned receipt 201. This is done so customers can easily find receipts in the future and prevent unauthorised access. Referring to Figure 13, if an authorised user links their bank account using a bank API, with OAUTH for example, that continuously provides statement updates 308, receipts will be assigned automatically to authorised user account 800 on the receipt server and so preventing any future unauthorised access from other users or institutions such as banks. Figure 13 shows how it is possible to automate gathering receipts and assigning them to a customer's account. A data structure containing one or more transaction references 300 are provided to an authorised user account 800 and are used by the lookup method 1163 and assigned the receipts 201 to the account 800.

The following is a method that prevents access of the receipt when the transaction identifier appears on the statement to anyone other than the authorised user. A customer has authorised account 800 which has a linked bank API that supports signalling when a pre-auth or settlement is made on the card. This will both ensure the transaction identifier and associated receipt is assigned to the customer's account before it appears on the bank statement, and assuming this occurs before the receipt is available on the receipt server, means that the receipt will never be available to anyone other than the authorised user.

Ideally, a distributed ledger may be maintained and updated each time a receipt is issued in a block chain method, where the receipt is cryptographically hashed, this hashing including components of previously hashed receipts. This distributed ledger may then be used to verify that any particular receipt has not had been changed or tampered with.

Figure 14 shows an example paper receipt that shows both the purchased items and the payment method and details.

Referring to figure 15, the principles may be implemented with different architectures and connectivity. For example, after a POS 100 of a merchant 101 has requested or obtained transaction codes from the receipt server 110, and made a payment request to a payment gateway 120 (in which a transaction code is transmitted as previously described), after the payment gateway has authorised the payment, the payment gateway may establish contact with the receipt server 110, and transmit the transaction code 300. Simultaneously, the POS 100 transmits the receipt 200 to the receipt server 110, where the merchant receipts 202 are stored in a merchant receipt database 501.

The complete stock of all receipts 111 held by the receipt server are accessible to a data service module 125. The Payment gateway 120 may verify the receipt using the transaction code, and the transmission of the transaction code 300 also allows the receipt server to populate the customer receipt database 502 with customer receipts 203.

Further transmissions may be made between the different parties, all via the receipt server and authenticated by it. The merchant may for example access the merchant receipts 202 using accounting software such as Xero or Sage (RTMs) 504. An authentication process with the receipt server may be carried out to allow the accounting software and other merchant integration solutions various permissions with respect to the merchant receipt data, for example to post and retrieve receipts, and to make additions. Third parties may be granted permission to access the merchant receipts 202 and act on behalf of the merchant, such as financial insight providers 506, antifraud solution providers 507, and loyalty scheme providers 508.

Similarly, the customer may access the customer receipts 203 using accounting or expense tracking software such as Xero or Concur (RTMs) 504. Again, an authentication process with the receipt server may be carried out to allow the accounting software and other merchant integration solutions various permissions with respect to the merchant receipt data, for example to originate transactions and retrieve receipts, and to make additions.

Third parties may be granted permission to access the customer receipts 203 and act on behalf of the customer, such as the customer's bank 509, personal finance management solution providers 510, and loyalty scheme providers 511.

Referring to figure 16, the payment gateway or payment system 120 may be comprised of an acquiring bank 120a and a card network 120b.

Referring to figure 17, the Issuing bank 141 typically incorporates the payment settlement system 140.

Figure 18 shows how a customer signs up to receive receipts using the card network as the payment notification service.

Receipt server 110 has a prior configuration held by the card network 120b in the form of configurations and authorisations 2001. This includes settings such as API keys, webhook address and public/private keys. The customer uses the mobile app 2000 to sign up to receive receipts by validating their payment card. To do this, the mobile app 2000 receives a customer sign up token 2010 from receipt server 110, and then makes a payment authorisation 10 and so validates the customer which includes token 2010 in the payment authorisation (Data field 43 within IS08583). A signal 11 is transmitted to confirm a successful authorisation. The card network 120b recognises the token 2010 by being of a predefined format contained within the configurations and authorisations 2001 and/or from a predefined merchant id, also in electronic payment request 400. The card network 120b on a recognised payment system 120 then assigns token 2010 to the customer account number 2020 (such as a tokenised PAN) and sends confirmation 2005 to receipt server 110 to confirm customer sign up using token 2010 as reference. When a customer makes a payment in the future which has a valid receipt id 300, the card network 120b will be able to identifier the consumer using the customer account number 2020 and send the transaction reference identifier code 300 with the associated 2010 to receipt server 110.

As already described in relation to figure 13, it is also possible to retrieve the transaction information from the issuing bank 141. One such example would be using a banking API, such as the Open Banking API in the UK. It will allow the customer to allow receipt server 110 to access the transaction information on behalf of the customer from the issuing bank 141 using an OAuth or similar process. This is a known process and won't be expanded on here.

Figure 19 shows how multiple items are included with the same transaction reference 300.

The till 100 send the receipt 200 to receipt server 110. The card network 120a sends the payment notification 2011 which links the transaction reference 300 to the customer. The customer makes an enquiry 2030 via the app 2000 which can be channelled to the merchant with the context of the transaction reference 300. The till 100 notifies receipt server 110 of a product recall 2030 which is passed on to the customer via 2000. This prompts the customer to return the item to the store for an exchange and the receipt for this exchange is passed 2031 to receipt server 110 from till 100 with the original transaction reference 300. There was no card transaction other than the first payment which links all the future transactions together using the same transaction reference 300.

Figure 20 show a point-to-point encrypted receipt. Rather than sending the receipt 200, the till 100 sends a public key request 200d. The card network 120a sends payment notification 2011 which links the transaction reference 300 to the customer, the app 2000 responds to the key request 200d with the consumer's public key 2032 (which could be cached on the receipt server 110).

The till 100 uses this key to encrypt the receipt 200e which is passed via the receipt server 110 to the app 2000, where it's decrypted with customer's private key.

Figure 21 shows how the proof of authenticity 2052 is attached to receipt 200.

It is created using the private key 2050 to electronically sign the receipt 200. Once the signed receipt arrives at receipt server 110 a hash is sent to the ledger service 2070 where a proof of existence 2056 is created and attached to the receipt 200. This same process is used to create proof of payment 2062 and proof of existence of the payment 2066.

Figure 22 shows how a receipt 200 together with its proof of authenticity 2052 is hashed 2071 and included in a ledger page 2075. The ledger page 2075 is finalised by sending 2073 to a publicly accessible web server 2080 with the URL of 2074. The same ledger page 2075 is hashed 2072 and combined with the url 2074. This embedded in a block-chain transaction 2091 on a public block-chain 2090. The block- chain transaction id 2092 acts as proof of existence 2056 for the receipt 200 and the proof of authenticity 2052.

Gift Aid in the UK is where the government refunds the tax on money given to charity. The basic rate (20%) is gifted to the charity and any additional tax for higher rate tax payers is refunded to the giver. Gift Aid isn't compatible with card payments and contactless payments in particular as it required the giver to fill in a form each time they donate and also report to the tax authority to get a refund on donations. Both these steps are skipped often for small donations. Figure 23 shows how Gift Aid system could be automated. A receipt 200 is sent to the receipt server 110, containing items 2120 that are Gift Aid eligible. The customer is signed up with a Gift Aid service 2100 that interfaces to the customer's receipt database 502 much like the third parties 509, 510 and 511 shown in figure 15. The customer has pre-declared that they wish to give Gift Aid and that they are happy to share their details when they donate. So when service 2100 receives the receipt 200 that contains Gift Aid eligible items 2120 it responds back to the Charity 101 with a message 2110 that contains the giver's details to be added to their Customer Relationship Management system 2130 and tag that transaction as having Gift Aid. The Gift Aid service 2100 handles the interaction with the tax authority on behalf of the giver and the charity. It declares the donation so the giver may be refunded tax on the donations and acts as an intermediary to request the funds on behalf of the charity. Such automation of Gift Aid on card payments should increase the money Charities would receive, along with simplifying the tax refunds for givers.

Claims

A method of implementing a transaction payment comprising:

transmitting said transaction receipt together with said identifier code to a receipt server means, for storage therein,

transmitting said payment request and said identifier code to a payment system of a customer's bank, whereby, details of the transaction together with said identifier code appear subsequently on the customer's bank statement, the customer arranging for said identifier code to be transferred from the bank statement to a receipt look up means, separate from said payment system, and said receipt look up means communicating with said receipt server in order to locate and communicate said transaction receipt to said receipt look up means, for providing the receipt to the customer.

A method according to claim 1, wherein said identifier code comprises a string of alphanumeric characters.

A method according to either previous claim, wherein said identifier is generated by said receipt server, and transmitted to a POS system, which carries out said generating and transmitting steps.

A method according to any previous claim, wherein when payment has been authenticated in said payment system, said identifier code is assigned to said receipt and transmitted to said receipt server.

A method according to any previous claim, wherein said receipt server provides an application programming interface, which communicates with a website to constitute said receipt look up means, said website providing a web form in which is entered said identifier code, and displays the retrieved associated receipt.

A method according to any previous claim, wherein customer accounts software is linked to a bank application programming interface in order to automate the retrieval of the receipt for import directly into said accounts software by retrieving the statement through said bank application programming interface, and downloading the receipts and inserting them directly into the accounts software via an accounts service application programming interface.

7. A method according to any previous claim, wherein said receipt server provides authorised customer accounts, and receipts, authorised to that customer, are assigned to a respective account.

8. A method according to claim 7, wherein said authorised account is linked to a bank application programming interface, whereby said identifier code and said receipt are assigned to said authorised account before details of said transaction appear on a bank statement.

9. A computer system for implementing a method of payment for a transaction, comprising:

a POS means for generating a payment request, generating a transaction receipt, and assigning a transaction identifier code to the transaction, said POS means arranged for transmitting said transaction receipt together with said identifier code to a receipt server means, for storage therein, said POS means arranged for transmitting said payment request and said identifier code to a payment system of a customer's bank, whereby details of the transaction together with said identifier code appear subsequently on a customer' s bank statement,

and a receipt look up means, separate from said payment system, and said receipt look up means communicating with said receipt server means, whereby when the customer arranges for said identifier code to be transferred from the bank statement to said receipt look up means, said receipt server locates and communicates said transaction receipt to said receipt look up means, for providing the receipt to the customer.

10. A computer system according to claim 9, wherein said receipt server means includes a database for storing receipts, a code generating means for generating random and unassigned transaction identifier codes, an application programming interface communicating with said POS means, and a web server to host receipt look up services.

11. A computer system according to claim 10, wherein said application programming interface comprises a means for providing unassigned transaction identifiers to said POS means, a means for receiving receipts from said POS means, which are then stored to the database, a means to retrieve receipts by means of said transaction identifier, and a means to assigns receipt to a customer so access can be restricted to the authorised customer.

12. A computer system according to any of claims 9 to 12,wherein said identifier code comprises a string of alphanumeric characters.

13. A computer system according to any of claims 9 to 13, wherein said receipt server means is arranged to generate said transaction identifier code and to transmit to said POS means.

14. A computer system according to any of claims 9 to 13, wherein when payment has been authenticated in said payment system, said POS means is arranged to assign said identifier code to said receipt and transmit to said receipt server.

15. A computer system according to any of claims 9 to 14, wherein said receipt server means provides an application programming interface, which communicates with a website to provide said receipt look up means, said website providing a web form for entering said identifier code, and a means for display of the retrieve associated receipt.

16. A computer system according to any of claims 9 to 15, wherein customer accounts software is linked to a bank application programming interface in order to automate the retrieval of receipts for import directly into said accounts software by retrieving said bank statement through said bank application programming interface and downloading the receipts and inserting them directly into the accounts software via an accounts service application programming interface.

17. A computer system according to any of claims 9 to 16, wherein said receipt server means provides authorised customer accounts, and receipts authorised to that customer are assigned to the respective account.

18. A computer system according to any of claims 9 to 17, wherein said authorised account is linked to a bank application programming interface, whereby said identifier code and said receipt are assigned to said authorised account before details of said transaction appear on a bank statement.