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
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
  • G06Q20/401—Transaction verification
• • 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/22—Payment schemes or models
  • G06Q20/26—Debit schemes, e.g. "pay now"
• • 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
• • 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/20—Point-of-sale [POS] network systems
  • G06Q20/202—Interconnection or interaction of plural electronic cash registers [ECR] or to host computer, e.g. network details, transfer of information from host to ECR or from ECR to ECR
• • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
  • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
  • G06Q20/3223—Realising banking transactions through M-devices
• • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
  • G06Q20/327—Short range or proximity payments by means of M-devices
  • G06Q20/3276—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being read by the M-device
• • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
• • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
  • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
  • G06Q20/3415—Cards acting autonomously as pay-media
• • 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/38—Payment protocols; Details thereof
  • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists

Definitions

• the present invention relates to a method and a device (system) for securely processing a payment, in particular largely using existing infrastructure and with the possibility of simple use.
• a credit balance or a direct connection to a payment institution and assignment to an account is managed on the mobile phone via an app, and the payment is handled via a wireless interface at the payment station.
• WLAN or Bluetooth can be used as interface, the payment is so easy and if appropriate algorithms are used also safe, and the user does not have to carry a purse anymore when he goes shopping, the mobile phone is with it anyway.
• the present invention accordingly provides a method according to claim 1, a system according to claim 12 and a debit card according to claims 13 or 14.
• the present invention relates to a method of payment processing at a pay station of a seller using a mobile device of a buyer, wherein the payment station has a terminal equipped for debit cards, and the terminal is usually provided with card port (insertion slot, proximity area), display, input device (numerical Keyboard, touch-sensitive display) and interface to a payment institution.
• a debit card and / or the terminal or other location associated with the terminal is provided with an element for wirelessly transmitting debit card-specific identification information to the mobile device.
• the corresponding identification in and can also be made available on the display of the terminal or another display in the premises of the terminal, also it is possible to transmit the identification information wirelessly, for example via a low-energy Bluetooth connection.
• the proposed payment transaction has at least the following steps, wherein the order of the first 4 steps (ID transmission, entry of purchase sum, triggering of mobile payment with debit card or input at the terminal, transfer and KI)) may be as indicated, the first step (ID transfer) but also after or during step 2 and / or step 3 and / or step 4):
• this step may be active or passive by the provider of the identification information, for example also by reading a QR code, barcode, scannable identification code or the like with the mobile device (MG));
• T Terminal
• ZI payment institution
• the step mentioned above can either be triggered via the connection of the debit card, but it is also possible to trigger this step, for example, by means of a key input.
• the actual debit card is not absolutely necessary if there is an identifier stored in the terminal which, for example, contains the identifier of the debit card for identification at the control entity and / or at the payment institution or allows correlation with the identifier of the debit card at the corresponding locations. The terminal does not even need to use a debit card during the payment process.
• a debit card it is possible to present a debit card to the terminal one time after switching on or only at the beginning of a work shift and to deposit the corresponding information in the terminal, so that the person responsible for the terminal then activates the corresponding process via an input on the screen or on the keyboard to trigger the mobile payment.
• a pincode or something similar can be provided for triggering.
• mobile payment can also be implemented using existing hardware designed for the usual debit card-based purchasing processes, the only additional hardware that has to be made available is the actually unusual seller-specific debit card that is used in the terminal is introduced, and there must be correspondingly modified processes at the payment institution and at the coordination instance, or, if the card is a specially recognizable card by the terminal and the terminal on that basis the data itself directly to the coordination instance (KI) Routes can be implemented at the coordination instance to handle a transaction.
• the actually unusual seller-specific debit card that is used in the terminal is introduced, and there must be correspondingly modified processes at the payment institution and at the coordination instance, or, if the card is a specially recognizable card by the terminal and the terminal on that basis the data itself directly to the coordination instance (KI) Routes can be implemented at the coordination instance to handle a transaction.
• KI coordination instance
• the method is characterized in that the identification information is a code which can be read out via a camera of the mobile device, preferably a QR code, and / or one via a wireless interface, preferably via a Bluetooth interface, in particular preferably via a low-energy Bluetooth interface of the mobile device (MG) readable identification information.
• This information may be provided on the debit card or on the terminal, for example. If the debit card is equipped with a low-energy Bluetooth chip, which is supplied with the debit card in the card port of the terminal (T) and transmits the identification information to the mobile device via a short-range secure data transmission, can be a particularly simple and largely tamper-free for the buyer Information transmission.
• the process has the following steps, unless otherwise specified in the following order:
• steps 1 and 2 may also be performed simultaneously or in the reverse order;
• the card is a card which can be identified as being specially recognizable by the terminal and the terminal is able to route the data itself directly to the coordination instance (KI) on this basis):
• the debiting of the account of the buyer can take place via the coordination instance and / or via the payment institution, wherein preferably the debiting of an account of the buyer at another payment institution takes place via the coordination instance.
• the mobile device can be a tablet or a smartphone.
• the terminal is preferably a conventional terminal for the
• the debit card is preferably a debit card associated with an account of the seller at the payment institution, which additionally carries the identification information, preferably in the form of a mobile-readable QR code or in the form of a Bluetooth low-energy chip.
• beacon Bluetooth low energy device
• the identification information it is also possible to provide the identification information in a secure form.
• the identification information it is then possible for the identification information to be encrypted information is also time dependent, for example, using a standard product as available from RSA Security Inc.
• the identification information can, as stated, be provided via a beacon provided on the debit card, but it is also possible to provide one at the terminal. For example, powered via a USB interface to such a terminal, such a beacon must then not be integrated into the software of the terminal.
• the communication between the terminal and the payment institution and / or the communication between the payment institution and the coordination instance and / or the communication between the coordination instance and the mobile device and / or the communication between the debit card and the terminal, and / or the communication between the payment institution and the terminal are preferably carried out in encrypted form.
• the identification information stored on the debit card and read out either optically or via Bluetooth by the mobile device is preferably different identification information than the identification information exchanged between the debit card and the terminal, and / or between the terminal and the payment institution, and / or between payment institution and coordination instance, and / or between terminal and coordination instance, but the respectively specifically transmitted identification information is correlated or stored in databases that, preferably at any time, a unique association between the specific debit card used, the specific used at that moment Mobile device or its SIM card, and preferably also the current payment is possible.
• the present invention relates to a system preferably for carrying out a method as set forth above, characterized in that it
• a terminal having a card port, a display, an input device and a preferably secure interface to a payment institution and / or a coordination instance
• a debit card having an element for wirelessly transmitting identification information to the mobile device, and a magnetic stripe and / or chip for debit card-specific information transmission to the terminal;
• a payment institution and / or coordinator in communication with the terminal having an account associated with the debit card of the seller;
• a co-ordinating body in communication with the payment institution, insofar as the communication does not take place directly between the co-ordination authority and the terminal; a portable mobile device of the buyer with an interface for receiving or reading the identification information from the debit card and an interface for communication with the coordination instance.
• the present invention relates to a debit card, in particular for use in a method as described above, and in particular preferably in the context of a system, as also described above, with an element in the form of a QR code and / or a Bluetooth low energy component for wireless transmission of identification information to the mobile device, and with a magnetic strip and / or chip for debit card-specific information transmission to the terminal.
• such a debit card can be characterized by the fact that besides a chip for debit card-specific information transfer to the terminal on the debit card a Bluetooth low-energy chip is arranged, which is energized by the terminal in interaction with the terminal and the short-range transmission the identification information is provided to the mobile device.
• Fig. 1 shows the various elements in the proposed payment system
• Fig. 2 is a flowchart of a payment procedure in such
• FIG. 1 A system suitable for carrying out a payment method as described above is shown schematically in FIG. 1
• a mobile device MR of a purchaser typically a smartphone or a tablet, which is uniquely identified and connected, for example, via a SIM card to a telecommunications network and the Internet. It therefore has an interface which is suitable for establishing a secure connection to a coordination instance (see description below). It also has a processor and memory to run appropriate software (App) to control the payment process.
• the mobile device has a reading interface, for example camera or Bluetooth, which makes it possible to obtain information from the paying agent.
• the mobile device has an input option, typically a keyboard or a touch-sensitive display.
• the system includes a debit card D, which leads the seller and which, unlike the usual payment transactions, just not held by the buyer.
• This debit card is in itself a standard debit card, a debit card is understood in the present context generally, ie also in connection with the general description, a card that allows access to an account at a payment institution or through a credit card company the burden respectively Invoicing prompted.
• the debit card is a bank card, a credit card or the like, also possible is a Maestro card or the like.
• the debit card has an information carrier (magnetic stripe and / or chip), which makes it possible, in or by approaching a terminal, to establish an association with an account maintained at a payment institution (or similar to a credit card institute). It is essentially a conventional debit card.
• this debit card has a more specific one Identification information that can be read by the mobile device of the buyer. It is either a barcode, or a QR code, or even a chip that can wirelessly transmit Bluetooth wireless information via the wireless identification information stored on the chip to the mobile device over a short distance. Alternatively, it is possible to provide this identification information, which ultimately allows correlation between the account associated with the debit card at the payment institution and the mobile device, on the terminal (for example, adhesive with QR code on the terminal), so that the card can remain in the slot of the terminal when the information is to be read from the mobile device.
• the system comprises a per se conventional terminal T for the treatment of payment transactions with a debit card.
• a per se conventional terminal T for the treatment of payment transactions with a debit card.
• a conventional terminal can be used to carry out the method and no specific additional hardware has to be provided.
• the system comprises a payment institution ZI which is associated with the debit card and which maintains an account of the seller of this debit card.
• a payment institution ZI which is associated with the debit card and which maintains an account of the seller of this debit card.
• the system comprises a coordination entity KI, which on the one hand ensures secure communication with the mobile device and, on the other hand, secure communication with the payment institution.
• Coordination instance and payment institution can in principle also coincide.
• the Coordinating Instance is ultimately the central processing station in this process because it provides the correlation between the debit card, terminal and payment institution transfers of purchase amount and debit card identification, respectively, and the seller's account (not used for the monetary transaction) and information about the buyer or his mobile device and account of the seller and account of the buyer.
• the Coordinator also initiates the actual monetary transaction, which may consist of either debiting a buyer's account and crediting it to a seller's account, or crediting it to a seller's account and debiting the buyer's credit on the mobile device or at the coordinating instance.
• the card is a card recognizable by the terminal as being specifically recognizable and the terminal is able to route the data itself directly to the coordinating entity on that basis
• the communication it is possible for the communication to be direct as shown by the dashed arrow in FIG , takes place between the terminal and the coordination instance and the coordination instance either holds and manages the accounts of the seller and the buyer or debits or credits accounts with payment institutions.
• steps 3 and 4 are then replaced by a single step of transferring amount and ID from terminal to KI (dashed arrow in Fig. 1). The amount and ID at KL and step 9 is unnecessary since the authorization is direct from the coordination instance to the terminal.
• the mobile device reads identification information from the debit card or possibly also from the terminal. This is achieved either by reading out a QR code via the camera of the mobile device or by establishing a connection between debit card and short-range mobile device via Bluetooth low energy and transmitting the identification information over a short range to the mobile device.
• the purchase amount is entered in the terminal or the purchase amount is transmitted via a terminal connected to the terminal on the terminal.
• the card is inserted into the terminal, if not already done, and the debit card-specific information, which allows an association with an account at a payment institution, is transmitted to the terminal, typically via an encrypted connection.
• step 3 the purchase amount and the identification information associated with the debit card is transmitted via the data line 1 to the payment institution.
• a debit card associated with the buyer's account queried but it is in step 4, a corresponding information is assigned to this debit card at the payment institution, essentially just the purchase amount and an assignment to the seller sent to a coordinator.
• the coordinating instance first looks up which mobile device has recently read out the information of the QR code associated with the debit card, which ideally happens without loss of time such that the app on the mobile device immediately after reading the information from the debit card this assignment is communicated to the coordination instance, and the assignment in a look-up table at the coordination instance at the time when the information comes from the payment institution is already ready.
• the coordinator will now transfer the payment amount to the mobile phone, typically via a secure internet connection.
• step 7 this information received by the app on the mobile phone is processed by displaying the purchase amount on the display and a prompt is issued to authorize this purchase amount. If necessary, the security can also be increased by a pin or something similar is demanded by this app in a first step.
• the authorization of the purchase amount may either result in the debit of the purchase amount on an account of the buyer, or it may simply be a reduction of a credit held on the mobile device and / or at the coordination instance.
• the process is aborted. For example, it can be provided that if no authorization is received by the coordination instance within a certain period of time, the purchase process is automatically terminated.
• this authorization is again transmitted to the coordinating authority.
• the authorization with the identification of the user account (of the seller) is transmitted to the payment institution.
• the authorization with the identification of the debit card (the seller) is transmitted to the terminal.
• a payment confirmation will be shown on the display and / or a receipt printed on the display, if desired.
• step 8 Is in the above step 8 is not directly charged, but should be for safety's sake, until the terminal was actually issued the confirmation, among other things, possibly also on the terminal between the process was canceled, this confirmation can in turn via the communication channels 1 and 2 transmitted to the coordinating authority, and this charged only after this confirmation has been received.
• the restaurateurs practically all have a mobile credit card reader with whom they can go to the table if a customer wants to pay by card.
• Other small dealers may have u.U. a fixed device.
• the waiter does not want to take a second device for mobile payment acceptance with the table, his private cell phone may not be used. How can a customer pay with mobile payment?
• the merchant receives a "merchant chipcard" from the mobile payment provider when signing up, which does not have to be personalized and does not need an inscription.
• the waiter has the customer scan the back of the card (QR Code). Then the waiter enters the amount to be paid in the card terminal, and puts this "Mobile Payment" card in the existing card terminal., He may even enter the PIN if you can not turn off.
• the customer in the mobile payment app (“wait for amount”) receives the Amount and the request to confirm this.
• the waiter removes the card from the terminal.
• the process of payment is thus very simple, for the customer as easy as mobile payment with a merchant app (scan barcode), for the waiter as easy as a debit card transaction, whereby the device does not have to be given to the customer and the customer does not have a PIN must enter.
• the mobile payment provider as the coordinating authority requests a postal account from one payment institution per merchant.
• These "merchant accounts” are virtual accounts that will never have credit or real transactions, and can be generated en bloc “beforehand” as subaccounts by the mobile payment provider (e.g., 1000 accounts on "supply”).
• the payment institution has normal debit cards produced for these accounts with the normal manufacturer, and a random or sequential pairing code (QR) is applied to the cards on the back. This can also happen with an adhesive.
• QR random or sequential pairing code
• the code can also be produced and supplied independently of the card on a simple laminated "dealer card".
• An extension (a single WEB / service call) is installed at the payment institution in the module that checks the account balance of a debit transaction online. There will be a call for an “online fraud check” or “online organ change”, which can be used for this.
• the call returns a "OK” or “not OK” with a return code.
• the "booking” is then completed positively or negatively on the payment institution backend, in a positive case, if possible, the amount should NOT be charged to the account (balance always remains 0) - but if that can not be changed, that is no problem, because you can balance at the end of the day again.
• OPTIONAL the amount will not be booked, also not in the "OK” case, but the booking will end as with "normal” bookings.
• the payment institution Service call calls a backend process. This gets in the service call the amount and the debit card / account number transmitted.
• the account number or debit card number can be uniquely assigned to a merchant / merchant card.
• the associated pairing code can be searched by lookup (in the simplest case the debit card number is pairing code at the same time, but for security reasons it makes more sense to use a "different" code).
• the backend process (as mentioned above, can be outside of the mobile payment provider / backend) makes a "start order" with the pairing code and asks for the amount via the "normal" mobile payment provider merchant interfaces.
• Mobile Payment Provider as the coordinating entity recognizes the associated mobile of the customer via the pairing code, fetches the customer confirmation of the amount and confirms the booking to the web service. This terminates the payment institution service call with the appropriate return code.
• the booking is posted normally to the merchant account.
• the payment institution system has to charge the amount on the merchant / debit card (the booking has to be executed with the amount), then at the end of the day at reconciliation all bookings on the merchant account are added together with the merchant card and a corresponding credit transfer is transferred to the payment institution so that the Account is balanced again.
• the system has no additional risks for the payment institution or the mobile payment provider. It is based on the normal debit / payment card standard, can not be disabled. Terminal devices that accept debit cards from the payment institution or debit cards from another bank can support the system.

Applications Claiming Priority (3)

Publications (1)

Family

ID=57190024

Family Applications (1)

Country Status (4)

Families Citing this family (1)

Family Cites Families (3)

• 2016
  • 2016-10-24 BR BR112018008396A patent/BR112018008396A2/pt not_active Application Discontinuation
  • 2016-10-24 EP EP16785170.8A patent/EP3369060A1/de not_active Withdrawn
  • 2016-10-24 WO PCT/EP2016/075515 patent/WO2017072067A1/de active Application Filing
  • 2016-10-24 US US15/771,512 patent/US20180336545A1/en not_active Abandoned

Also Published As

Similar Documents

Legal Events