WO2016189311A1 - Système informatique permettant de mettre en oeuvre un paiement de transaction - Google Patents

Système informatique permettant de mettre en oeuvre un paiement de transaction Download PDF

Info

Publication number
WO2016189311A1
WO2016189311A1 PCT/GB2016/051522 GB2016051522W WO2016189311A1 WO 2016189311 A1 WO2016189311 A1 WO 2016189311A1 GB 2016051522 W GB2016051522 W GB 2016051522W WO 2016189311 A1 WO2016189311 A1 WO 2016189311A1
Authority
WO
WIPO (PCT)
Prior art keywords
receipt
transaction
customer
payment
identifier code
Prior art date
Application number
PCT/GB2016/051522
Other languages
English (en)
Inventor
David Michael
Original Assignee
Zeet Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Zeet Ltd filed Critical Zeet Ltd
Priority to EP16726386.2A priority Critical patent/EP3304458A1/fr
Publication of WO2016189311A1 publication Critical patent/WO2016189311A1/fr

Links

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.

Abstract

L'invention concerne un procédé de mise en oeuvre d'un paiement de transaction au moyen d'un système informatique, ledit procédé comprenant les étapes suivantes : un point de vente (POS) (100) génère une demande de paiement électronique (400), génère un reçu de transaction (200) et attribue à la transaction un code d'identification (300) de transaction ; le POS (100) transmet le reçu de transaction conjointement avec le code d'identification à un serveur de reçus (110) à des fins de stockage, transmet la demande de paiement et ledit code d'identification à un système de paiement d'une banque du client (120, 140), les détails de la transaction ainsi que ledit code d'identification apparaissant ultérieurement sur un relevé bancaire (150) du client et sur des moyens de consultation (130) de reçus, séparés du système de paiement, et communique avec le serveur de reçus ; lorsque le client fait en sorte que le code d'identification soit transféré, du relevé bancaire vers les moyens de consultation de reçus, le serveur de reçus localise le reçu de transaction et le transmet aux moyens de consultation de reçus afin d'afficher le reçu à l'intention du client.
PCT/GB2016/051522 2015-05-26 2016-05-26 Système informatique permettant de mettre en oeuvre un paiement de transaction WO2016189311A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP16726386.2A EP3304458A1 (fr) 2015-05-26 2016-05-26 Système informatique permettant de mettre en oeuvre un paiement de transaction

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
GB1508922.0 2015-05-26

Publications (1)

Publication Number Publication Date
WO2016189311A1 true WO2016189311A1 (fr) 2016-12-01

Family

ID=53506285

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2016/051522 WO2016189311A1 (fr) 2015-05-26 2016-05-26 Système informatique permettant de mettre en oeuvre un paiement de transaction

Country Status (3)

Country Link
EP (1) EP3304458A1 (fr)
GB (1) GB201508922D0 (fr)
WO (1) WO2016189311A1 (fr)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109544170A (zh) * 2018-11-26 2019-03-29 努比亚技术有限公司 一种交易快照验证方法、设备及计算机可读存储介质
CN109976969A (zh) * 2017-12-27 2019-07-05 航天信息股份有限公司 一种电子发票信息的监控方法、装置、设备及介质
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
US11270017B2 (en) * 2018-10-16 2022-03-08 International Business Machines Corporation Selective exchange of transaction data
US11303642B2 (en) 2019-06-03 2022-04-12 The Toronto-Dominion Bank Dynamic management of consent and permissioning between executed applications and programmatic interfaces
EP4220516A4 (fr) * 2020-09-28 2024-01-31 Toshiba Tec Kk Serveur de reçus, procédé de traitement d'informations, support d'enregistrement de programme et système serveur

Citations (3)

* Cited by examiner, † Cited by third party
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
US20050114215A1 (en) * 2003-11-20 2005-05-26 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

Patent Citations (3)

* Cited by examiner, † Cited by third party
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
US20050114215A1 (en) * 2003-11-20 2005-05-26 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

Cited By (11)

* Cited by examiner, † Cited by third party
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
US11023604B1 (en) 2015-11-23 2021-06-01 United Services Automobile Association (Usaa) Systems and methods to track, store, and manage events, rights and liabilities
US11790097B1 (en) 2015-11-23 2023-10-17 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
US11816984B1 (en) 2016-01-20 2023-11-14 United Services Automobile Association (Usaa) Systems and methods for traffic management via inter-party resource allocation
CN109976969A (zh) * 2017-12-27 2019-07-05 航天信息股份有限公司 一种电子发票信息的监控方法、装置、设备及介质
US11270017B2 (en) * 2018-10-16 2022-03-08 International Business Machines Corporation Selective exchange of transaction data
CN109544170A (zh) * 2018-11-26 2019-03-29 努比亚技术有限公司 一种交易快照验证方法、设备及计算机可读存储介质
CN109544170B (zh) * 2018-11-26 2023-08-11 努比亚技术有限公司 一种交易快照验证方法、设备及计算机可读存储介质
US11303642B2 (en) 2019-06-03 2022-04-12 The Toronto-Dominion Bank Dynamic management of consent and permissioning between executed applications and programmatic interfaces
EP4220516A4 (fr) * 2020-09-28 2024-01-31 Toshiba Tec Kk Serveur de reçus, procédé de traitement d'informations, support d'enregistrement de programme et système serveur

Also Published As

Publication number Publication date
GB201508922D0 (en) 2015-07-01
EP3304458A1 (fr) 2018-04-11

Similar Documents

Publication Publication Date Title
US11107061B2 (en) System and method for implementing payment via quick response (QR) code
CN111066044B (zh) 用于商家qr码的数字支持服务
CA2896755C (fr) Systemes et methodes de production de transmission de donnees securisee entre systemes informatiques en reseau
CN105359452B (zh) 用于将加密安全性作为服务的系统和方法
WO2016189311A1 (fr) Système informatique permettant de mettre en oeuvre un paiement de transaction
US7433845B1 (en) Data structure, method and system for generating person-to-person, person-to-business, business-to-person, and business-to-business financial transactions
US20170372417A1 (en) Digital asset account management
US20120116933A1 (en) System and method for automatic reconciliation of transaction account spend
EA035549B1 (ru) Система электронных платежей и способ их совершения
US20140229305A1 (en) Real time paperless payment control
MX2008012200A (es) Sistema y metodo de administrcion de informacion.
CA2414038A1 (fr) Procede et systeme pour le traitement de paiements par internet
AU2001268692A1 (en) Method and system for processing internet payments
US20160260097A1 (en) Assignment of transactions to sub-accounts in payment account system
CN110612701A (zh) 使用移动装置的安全远程交易系统
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 (ko) 휴대단말기를 이용한 금융거래 중개 시스템
US11935023B2 (en) Extended-length payment account issuer identification numbers
WO2012143547A1 (fr) Contrôle de paiement sans papier en temps réel
KR100958839B1 (ko) 게시판 댓글을 활용한 자금첨부 시스템 및 그 방법
AU2021104965A4 (en) Methods, Systems and Software Platform for facilitating charitable donation payments within one or more digital donation devices
TW201346808A (zh) 電子兌換券與自動化處理電子兌換券的方法
US20210142317A1 (en) Systems and methods for global financial transaction routing
JP2020170462A (ja) 決済処理システム、決済処理方法、サーバ、およびプログラム
WO2017006194A1 (fr) Système de paiement effectué en temps réel

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16726386

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2016726386

Country of ref document: EP