EP3304458A1 - Computer system for implementing a transaction payment - Google Patents
Computer system for implementing a transaction paymentInfo
- Publication number
- EP3304458A1 EP3304458A1 EP16726386.2A EP16726386A EP3304458A1 EP 3304458 A1 EP3304458 A1 EP 3304458A1 EP 16726386 A EP16726386 A EP 16726386A EP 3304458 A1 EP3304458 A1 EP 3304458A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- receipt
- transaction
- customer
- payment
- identifier code
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Ceased
Links
- 238000000034 method Methods 0.000 claims abstract description 35
- 230000008676 import Effects 0.000 claims description 3
- 238000012011 method of payment Methods 0.000 claims 1
- 238000010586 diagram Methods 0.000 description 14
- 230000008569 process Effects 0.000 description 13
- 238000012546 transfer Methods 0.000 description 6
- 238000013475 authorization Methods 0.000 description 5
- 238000007792 addition Methods 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 230000015556 catabolic process Effects 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 238000009745 resin transfer moulding Methods 0.000 description 2
- 241000282412 Homo Species 0.000 description 1
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 238000007639 printing Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 235000002020 sage Nutrition 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
- G06Q10/103—Workflow collaboration or project management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/045—Payment circuits using payment protocols involving tickets
- G06Q20/0457—Payment circuits using payment protocols involving tickets the tickets being sent electronically
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/047—Payment circuits using payment protocols involving electronic receipts
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/04—Billing or invoicing
Definitions
- the present invention relates to a computer system for implementing a method of dealing with transaction payments, such as purchases, together with associated receipts.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- the transaction 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.
- 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.
- banks should be understood to include retail banks, building societies, credit card companies, and any financial institution which provides electronic funds transfer facilities.
- 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.
- 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.
- DBA descriptor
- 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.
- 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.
- the main identifier on the bank statement normally shows the store name, or name of the seller or person providing goods or services.
- 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.
- 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.
- 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.
- 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.
- 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.
- Receipts can be proved to be from a certain retailer and so reduce fraud.
- 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.
- 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.
- embodiments provide a method of implementing a transaction payment comprising:
- 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,
- 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.
- 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
- FIG. 3 shows a high level diagram of the functions of a receipt server, in accordance with the invention.
- FIG. 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
- FIG. 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.
- 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.
- 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.
- 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.
- the principles may be implemented with different architectures and connectivity.
- 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)
- the payment gateway may establish contact with the receipt server 110, and transmit the transaction code 300.
- 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.
- the customer may access the customer receipts 203 using accounting or expense tracking software such as Xero or Concur (RTMs) 504.
- accounting or expense tracking software such as Xero or Concur (RTMs) 504.
- RTMs Concur
- 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.
- the payment gateway or payment system 120 may be comprised of an acquiring bank 120a and a card network 120b.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Landscapes
- Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Finance (AREA)
- Human Resources & Organizations (AREA)
- Marketing (AREA)
- Entrepreneurship & Innovation (AREA)
- Data Mining & Analysis (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Description
Claims
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GBGB1508922.0A GB201508922D0 (en) | 2015-05-26 | 2015-05-26 | Computer system for implementing a transaction payment |
PCT/GB2016/051522 WO2016189311A1 (en) | 2015-05-26 | 2016-05-26 | Computer system for implementing a transaction payment |
Publications (1)
Publication Number | Publication Date |
---|---|
EP3304458A1 true EP3304458A1 (en) | 2018-04-11 |
Family
ID=53506285
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP16726386.2A Ceased EP3304458A1 (en) | 2015-05-26 | 2016-05-26 | Computer system for implementing a transaction payment |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP3304458A1 (en) |
GB (1) | GB201508922D0 (en) |
WO (1) | WO2016189311A1 (en) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10586062B1 (en) | 2015-11-23 | 2020-03-10 | United Services Automobile Association (Usaa) | Systems and methods to track, store, and manage events, rights and liabilities |
US10818170B1 (en) | 2016-01-20 | 2020-10-27 | United Services Automobile Association | Systems and methods for traffic management via inter-party resource allocation |
CN109976969A (en) * | 2017-12-27 | 2019-07-05 | 航天信息股份有限公司 | A kind of monitoring method, device, equipment and the medium of electronic invoice information |
US11270017B2 (en) * | 2018-10-16 | 2022-03-08 | International Business Machines Corporation | Selective exchange of transaction data |
CN109544170B (en) * | 2018-11-26 | 2023-08-11 | 努比亚技术有限公司 | Transaction snapshot verification method, device and computer readable storage medium |
US11303642B2 (en) | 2019-06-03 | 2022-04-12 | The Toronto-Dominion Bank | Dynamic management of consent and permissioning between executed applications and programmatic interfaces |
JP7535423B2 (en) * | 2020-09-28 | 2024-08-16 | 東芝テック株式会社 | Receipt server, its program, and server system |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040064373A1 (en) * | 2002-09-30 | 2004-04-01 | Shannon Robert W. J. | Point of sale receipt service |
US7577613B2 (en) * | 2003-11-20 | 2009-08-18 | Ncr Corporation | Provision of receipts for self service or point of sale terminals |
US20140229305A1 (en) * | 2011-04-21 | 2014-08-14 | Dilek Ellan | Real time paperless payment control |
-
2015
- 2015-05-26 GB GBGB1508922.0A patent/GB201508922D0/en not_active Ceased
-
2016
- 2016-05-26 EP EP16726386.2A patent/EP3304458A1/en not_active Ceased
- 2016-05-26 WO PCT/GB2016/051522 patent/WO2016189311A1/en active Application Filing
Also Published As
Publication number | Publication date |
---|---|
WO2016189311A1 (en) | 2016-12-01 |
GB201508922D0 (en) | 2015-07-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11107061B2 (en) | System and method for implementing payment via quick response (QR) code | |
CN111066044B (en) | Digital support service for merchant QR codes | |
CA2896755C (en) | Systems and methods for providing secure data transmission between networked computing systems | |
CN105359452B (en) | For using cryptographic security as the system and method for service | |
US7433845B1 (en) | Data structure, method and system for generating person-to-person, person-to-business, business-to-person, and business-to-business financial transactions | |
EP3304458A1 (en) | Computer system for implementing a transaction payment | |
US20180330342A1 (en) | Digital asset account management | |
US20170372417A1 (en) | Digital asset account management | |
US20120116933A1 (en) | System and method for automatic reconciliation of transaction account spend | |
US20140229305A1 (en) | Real time paperless payment control | |
MX2008012200A (en) | Information management system and method. | |
CA2414038A1 (en) | Method and system for processing internet payments | |
AU2001268692A1 (en) | Method and system for processing internet payments | |
CN110612701A (en) | Secure remote transaction system using mobile device | |
US20160260097A1 (en) | Assignment of transactions to sub-accounts in payment account system | |
US20120173436A1 (en) | Method and system for authorizing, authenticating, implementing, brokering data transfers, and collecting fees for data transfers among distributed electronic devices and servers | |
KR101195547B1 (en) | Finance transaction system using mobile device | |
US11935023B2 (en) | Extended-length payment account issuer identification numbers | |
WO2012143547A1 (en) | Real time paperless payment control | |
AU2021104965A4 (en) | Methods, Systems and Software Platform for facilitating charitable donation payments within one or more digital donation devices | |
KR100958839B1 (en) | Method and system for attaching the money using the reply of board | |
JP2020170462A (en) | Settlement processing system, settlement processing method, server and program | |
TW201346808A (en) | Electronic voucher and method for automatic processing the same | |
WO2017006194A1 (en) | System of payment made in real time | |
KR20090085485A (en) | Method of serving e-mail check service and system thereof |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20171220 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
AX | Request for extension of the european patent |
Extension state: BA ME |
|
DAV | Request for validation of the european patent (deleted) | ||
DAX | Request for extension of the european patent (deleted) | ||
17Q | First examination report despatched |
Effective date: 20190301 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: STREEVA LTD |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R003 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED |
|
18R | Application refused |
Effective date: 20200904 |