METHOD AND SYSTEM FOR ISSUING ELECTRONIC PAYMENT REQUEST AND PROVIDING PAYMENT CONFIRMATION
The present invention relates to a method and a system for issuing electronic payment requests and providing payment confirmation.
In order to perform an electronic payment transaction between a payor and a payee the payee generally issues a payment request (typically in the form of an invoice or a bill) presents it on an internet site - either on its own or on that of its financial service provider -, requests the payor to input its payment credentials into a form on the website, or allows the payor to invoke his pre- stored payment credentials, after which the payment information is transmitted for authorisation to the acquirer bank's card management system.. Once the requested payment amount is authorized the payee is notified of the accomplished transaction.
The disadvantage of the current practice is that it is a lengthy and bureaucratic procedure to have an agreement for acceptance (without a guarantee of being approved for the service) with a financial service provider - bank - and it is also a technically complex task to establish the necessary integration with the bank's systems. The cost of preparation and maintenance of the relationship is so high that only enterprises with substantial business and turnover can afford the maintenance of such a relationship.
Another disadvantage of these solutions that the payor needs to provide its payment credentials to unknown payees and there is no guarantee that this payment information will not be misused. The threat is even greater, as recent incidents prove, if the payment details of the payors are pre-stored by the payee as such data bases are open invitations for hackers to try to steal the valuable personal information.
Presently there are no systems that would allow ordinary payees to generate and send electronic payment request to any third party designated by
them, without either joining a closed loop service - like Paypal, where accounts of all the participants are managed by the service - or lengthy business and administrative preparations as well as installation of software applications.
It is an object of the present invention to overcome the aforementioned problems associated with the prior art.
The present invention realizes a service, based on a methodology and a system which is:
• open loop,
o accessible for both businesses and individuals,
o neither the payee nor the payor need to maintain an account with the service;
• any payee
o without the need for any technical integration
o with an account managed by any financial service provider, bank can issue and deliver a payment request to, and request electronic payment from,
• any payor,
o having a personal communication device - mobile phone, notebook, etc. - o and a bank card or bank account suitable for electronic transactions, issued by any banks,
• securely without potentially compromising the sensitive payment related and personal information of the payor
• and both payee and payor receive real-time notification of the payment being performed even before the amounts are settled on the account specified by the payee.
Although the method and system is designed and implemented with the objective of establishing an open loop payment service, it is obvious that the same can be applied to any closed loop service where payment is not performed with a bank card but rather with loyalty card and therefore the account of the payor is rather managed by the loyalty program operator.
In a first aspect the invention provides a method for issuing electronic payment request, and providing real-time payment confirmation characterised by
• receiving electronic payment request data from a payee over an electronic communication channel
• generating an electronic payment request based on the received payment data,
• making the electronic payment request accessible to a payor,
• providing real-time payment confirmation.
In a second aspect the invention provides a system for issuing electronic payment requests, and providing real-time payment confirmation characterised by comprising a server configured
• to receive an electronic payment request data from a payee over an electronic communication channel
• to generate an electronic payment request based on the received payment data,
• to make the electronic payment request accessible to a payor,
• to provide real-time payment confirmation.
In a second aspect the invention provides a system for issuing electronic payment requests and providing real-time payment confirmation, wherein the system is configured
• to allow payees to input on-line payee information comprising at least a payee ID and an account of the payee which is kept and managed outside of the system,
• to allow payees to input transaction related information comprising at least a payment amount data and a payor's mobile phone number.
• to generate and issue, based on the payee provided information, electronic payment request to a payor identified by the mobile phone number ,
• to store the electronic payment request in a repository,
• to make the payment request accessible to the payor identified by the mobile phone number using a mobile device having the mobile phone number provided by the payee,
• to let the payment request be retrieved by the designated payor into the communication device identified by the mobile phone number,
• to receive payment initiation request from the payor for at least one transaction included in the payment request,
• to authorise the payment initiation request through a financial institution connected to the system
• to notify the payor about the result of the payment transaction real-time, and
• to settle the payment amount on the payee's account managed outside of the system.
Particularly preferred embodiments of the invention are defined in the attached dependent claims.
Further details of the invention will be apparent from the accompanying figures and exemplary embodiments.
Fig. 1 is a schematic diagram of a preferred embodiment of the system according to the invention.
Figs. 2a - 2d illustrate pages of an exemplary user interface of a system for performing the method according to the invention.
Fig. 3 is a flow diagram of the first part of a preferred embodiment of the method according to the invention.
Fig. 4 is a flow diagram of the second part of a preferred embodiment of the method according to the invention.
Fig. 5 illustrates an exemplary user interface of a software application installed on a telecommunication device of a payor.
The inventive method is preferably performed by an electronic payment request issuing system 10 comprising preferably a server 11 accessible over the Internet by users (payees 12) wishing to issue an electronic payment request 13 to a specific designated party (payor 14).
Preferably the server 11 hosts an electronic payment request issuing portal 16 allowing the payee 12 to access the electronic payment request issuing system 10. In the context of the present invention where a description of the invention refers to an action taken by the payee 12 it is implied that this action may be performed by any entity acting on behalf of the payee as well (e.g. staff, representative, etc.). Furthermore, it is to be noted that actions taken by a payee 12 are performed via a telecommunication device 12a such as a mobile phone, computer, laptop, notebook, etc. which is able to communicate over an electronic communication channel 52 with the system 10 (typically the server 11). The communication channel 52 may be any kind of conventional communication channel, such as cable or wireless telecommunication channel, in particular Internet network, mobile network, Wifi, etc.
Payee 12 may decide to perform a single transaction, or register with the system 10 in which case some user related, non-sensitive information will be stored in the system 10.
The portal 16 preferably provides a tool for creating and submitting electronic payment request data 13a as well as for creating and personalizing payment request templates. Figs 2a to 2c show an exemplary user interface 20 provided on the portal 16 for submitting electronic payment request data 13a. The user interface 20 of the portal 16 may contain textboxes, checkboxes, scroll boxes etc. for entering data or selecting data from given options or it may have buttons or links for navigating to a specific page 21 , 21a, 21b of the website. In the illustrated example the user interface 20 is provided with a payment input box 22 for entering the amount of the requested payment and a comment input box 24 for entering information to be submitted to the payor 14, such as information regarding the basis of the payment request (e.g. order number identifying a product or service ordered by the payor 14 from the payee 12; a time limit for performing the payment; etc.). In the present example payee information and payor information can be provided on two separate pages 21a, 21b of the user interface 20 which can be accessed by pressing buttons 26 and 27 respectively. Optionally files maybe attached to the payment request data 13a via a browser tool 28. This may serve for example to attach a copy of an
invoice relating to the payment request 13, or product information of the ordered product, or advertisement, etc.
The payee information page 21a preferably allows for entering data (e.g. via textboxes 30) relating to the payee.12 Preferably such data includes the bank account number of the payee 12 to which the payment is requested and data identifying the payee 12 such as his name. In the context of the present invention name may include any data identifying the payee 12 to the payor 14, such as a personal name or a company name, or even a nickname. Possibly other optional data maybe entered into further textboxes 30.
If the payee 12 wishes to use the service regularly he may decide to register, in which case he may store payee specific standard data on the server. Registration can take place in any conventional way, e.g. by prompting the payee 12 to define a username and a password. Alternatively various security measures may be applied in the course of registration such as personal identification with staff of the electronic payment request issuing system 10, or requiring a certified electronic signature issued by a specific authority or a trusted third party. Registration of a payee 12 ensures unique access to the information by the payee 12 and the potential to re-use the stored information for future transaction without the need to provide them again.
If the payee12 has already registered before for the service then some or all of the information necessary for generating a payment request is already available in the system 10 and it is not necessary to re-input them, they simply need to be retrieved from the system 10 by the payee 12 using his unique access credentials.
On the payor information page 21b the payee may enter data (e.g. via textboxes 31) relating to the payor 12 which may be limited to a single ID. Such data may take the form of a mobile phone number which can uniquely identify a device and/or its user with whom the payment request is associated. Such address may also be an IP address of a PC. These addresses may be used as destinations of the payment requests 13 or as identification means of devices which may have access to the payment requests 13 waiting for retrieval by the payor 14 in a payment request repository 19, 19'. If the payment request 13 is
to be actively retrieved any type of personal code - shared secret - to be keyed in may be used
In addition there may also be an e-mail address, social network destination, mobile number, etc. listed, where the payor 14 may be notified by the system 10 that a payment request 13 is waiting for retrieval.
On the payor side the system 10 preferably also includes software application 11a downloadable to the payor's 14 telecommunication device 14a,. The software application 11a is capable of retrieving the payment request, designated for the payor 14, from the payment requests repository by identifying itself, or the mobile communication device 14a it is running on, or the payor 14 itself. Alternatively the software application 11a is also capable of receiving the payment request 13 if it is directly addressed to the communication device 14a it is running on. The software application 11a allows for viewing the payment request 13 and preferably allows for communication with the server 11 over a telecommunication channel 54 in order to respond to the payment request 13 as will be explained in more detail later on. The communication channel 54 may be any kind of conventional communication channel, primarily remote channels such as cable or wireless telecommunication channel, in particular Internet network, mobile network, Wifi, etc. but proximity interfaces like IrDA, NFC, RFID may also be used.
Beside sending the payment request 13 to the payment request repository or directly to the designated payor 14 it is also possible to display it in a coded form on a page of the portal 16 where the payment request 13 is compiled by the payee 12 in order to allow the payor 14 to read the payment request 13 e.g. via his own portable communication device 14a. In this case the payment request 13 is preferably represented in a bar code or a 2D code or other optical identifier which is read by an image capturing apparatus comprised in the mobile device 14a of the payor 14. Preferably payor 14 has already installed the software application 11a belonging to the system, which can recognize the optical identifier and perform a given action based thereon resulting in the payor 14 having access to the payment request 13. For example the optical code may contain an ID number for accessing the payment request
13 stored on the server 11 via the mobile device 14a of the payor 14 or may contain the whole payment request itself.
Similar to the 2D representation of the payment request or its ID is the use of an NFC interface for transferring directly the information to the payor's mobile device.
The system preferably includes an internal or external payment request repository module 19, 19' where the payment requests 13 generated by the system 10 based on the payment request data 13a submitted by the payees 12 may be retrieved from by their designated payors 14 over a telecommunication channel 51. The payors 14 are identified either by their payor's ID - which can be a code, name, etc.- or by the mobile phone numbers of their mobile phones 14a, or by the IP address of the PC they use or any other distinctive code being unique and suitable for the purpose. The identification information associated with the payor 14 and requested for a specific payment request 13 may be part of the payor data inputted by the payee 12 when the payment request 13 was prepared. The repository 19 - may be a database or any other suitable structure - is preferably hosted on the same server 11 which provides the user interface 20, however it might be a remote payment request repository 19' stored at a separate location.
In the context of the present invention whenever a description refers to sending the electronic payment request 13 to a telecommunication device 50 this is understood to include the possibility of sending the payment request to a repository 19 accessible to the payors 14 in which case the designated telecommunication device 50 maybe the same server 11 which hosts the portal 16.
Furthermore, in the context of the present invention sending the electronic payment request 13 to the payor 14 is understood to include any kind of data transfer as a result of which the payor 14 has access to the electronic payment request 13, i.e. the payor 14 can read the payment request 13 and preferably respond thereto.
It should be noted that using a repository 19 for the payment request 13 allows unrestricted access to the payment request 13 by any types of personal
telecommunication devices 14a if they use the agreed communication protocol and can provide the necessary identification. In this case the payee 12 does not need to know what type of user device 14a the payor 14 will use. This is very important to achieve general, simple, unrestricted access for any payor 14.
In case when the payment request 13 is to be sent directly to the payor's 14 communication device 14a the payee 12 needs to know in advance what type of device 14a the payor 14 will use. If a payor 14 is using a regular mobile phone it cannot receive the payment request 13 in e-mail and alternately if a payor 14 is using a PC it cannot receive the payment request 13 in SMS. When using SMS the various types of mobile operating systems may cause further difficulties with all managing differently the applet SMSs which could be used for directly sending payment requests 13 to mobile phones.
The use of the repository 19 has the further advantage that payors 14 can be positively identified by their unique codes when they are attempting to retrieve their payment requests 13. Whereas an e-mail sent to a PC does not guarantee the exclusive delivery to the dedicated recipient.
It should be further noted that whenever a description refers to an action taken by the payor 14 it is implied that this action may be performed by any entity acting on behalf of the payor 14 as well (e.g. staff, representative, etc.). Furthermore, actions taken by the payor 14 are performed via a telecommunication device 14a such as a mobile phone, computer, laptop, notebook, etc. which is able to communicate over an electronic communication channel 52 with the system 10 (typically the server 11).
Preferably the portal 16 also includes the possibility of saving the payment request data 13a entered by the payee 12 in the form of templates either by modifying (or personalizing) existing (possibly predefined) templates or by creating new templates. Existing templates may be chosen e.g. from a scroll box 32 while the creation of new templates maybe prompted by clicking on a button 34 which could open a new page 21c for entering a name for the template into a textbox 36 and saving the template to a template file, or database which is stored in the memory of the server 11 , preferably in a storage area dedicated to the payee 12 as user. In a further session the payee 12 can
simply open one of the existing templates via scroll box 40, or from a list of records whereby previously entered data is loaded to the current session which then can be re-used with or without modification, with or without adding additional information to initiate new transactions.
Figs. 3 and 4 illustrate a preferred embodiment of the method according to the invention. In order to start the process of issuing an electronic payment request 13 the payee 12 visits the portal 16 at the server 11 via his telecommunication device 12a and enters the necessary payment data and/or loads the necessary payment data from a template file in Step 100 with the help of the user interface provided on the portal 16. The payment data comprises preferably at least a payee ID (the name or other identifier of the payee 12) an external account information (such as the bank account of the payee 12 where the payment is to be received), the amount to be paid and a payor ID designating the payor 14. The payor ID is preferably the payor's mobile phone number to which the payment request 13 is to be sent, or by which it will be retrieved from the repository 19, 19'. The payee 12 can then submit the electronic payment request data 13a in Step 101.
In case the payee 12 has registered earlier then his credential - name and destination account number - may already be pre-stored in the system and it is not necessary to provide them again. Also in case the payment request 13 is represented by a digital code on the website it does not need to contain any reference to the payor 14 itself.
The submitted payment request data 13a is received by the system 10 (typically the server 11) in Step 102. In the context of the present invention where a description of the invention refers to an action taken by the system 10 it is implied that this action is performed by the server 11 and the specific software application of the system 10 (or server 11) and using any known data processing application, communication application, etc. running on a physical hardware architecture.
The system 10 then processes the received payment request data 13a which preferably includes automatic checking of the payment request data 13a in Step 104 (for content and context) and as the case may be accepting or
rejecting the payment request data 13a and showing an error message for the payee 12 or proceeding with the transaction.
If the payment request data 13a is complete and executable the system 10 compiles a payment request 13 based on the submitted data 13a in Step 108, after which the payment request 13 is made accessible to the payor 14 in Step 110. This may be performed by the system 10 e.g. by transmitting the electronic payment request 13 to a payment system repository 19 or 19'. This repository 19 may be a part (module) of the system 10 or the repository 19' may even be a remote payment request repository 19' operated completely independently. Transmission therefore may happen locally between two modules of the system 10 or over an electronic communication channel 51 established between the system 10 (typically the server 11) and the remote payment request repository 19'.
Alternatively the payment request may also be sent directly to the telecommunication device 14a of the payor 14, in which case the telecommunication channel 51 is a telecommunication channel 54 established between the payor's 14 telecommunication device 14a and the system 10 (typically the server 11).
Optionally instead of sending the payment request 13 to the repository 19, 19' or to the payor's communication device 14a the system 10 may rather just display the content of the payment request 14 on its web portal 16 accessible for the payor 14. This embodiment has for advantage that the payor 14 need not provide the payee 12 with his mobile telephone number. Although the displayed information could take the form of a simple text message or table the preferred embodiment is the presentation of a barcode or 2D barcode (QR code) containing all important information of the payment request 13. To further increase security of the service this visual information may contain encrypted information which can only be interpreted by the payor's 14 payment application running on its mobile communication device 14a or by the server 11 itself.
Optionally the same information that is contained in the 2D barcode can also be transmitted directly to the payor's mobile phone using its NFC interface.
Based on the payment request 13 which is made accessible to the payor 14 in ways such as described above, the payor 14 needs to capture the payment request 13. Depending on the applied option of the payment request delivery the payor 14 may need to retrieve the payment request 13 from the repository 19 or 19' using the mobile communication device 14a, the mobile number of which has been included in the payment request data 13a. Alternatively, the payor 14 may need to receive the payment request 13 on his mobile handset device 14a by receiving and processing an applet SMS. In another embodiment the payor 14 may need to capture the payment request 13 with the camera or NFC chip of his mobile telephone device 14a. In a possible different embodiment not elaborated earlier yet, the payment request 13 may also be retrieved from the repository 19, 19' by identifying the payment request 13 with a unique ID and referring to this ID when the payor 14 attempts to access the record.
In all these embodiments there is a special payment software application 11a installed and operated on the payor's 14 mobile communication device 14a which can perform the necessary communication and message transformation, message processing tasks and display the results of its activities on the screen of the mobile device 14a.
From the above description it is obvious that the payment request 13 and its payor 14 may be identified with other means than a mobile phone number in which case the payor's personal communication device 14a used for the payment may also be a PC, laptop, notebook, etc.
Preferably the details of the payment request 13 can be viewed via the software application 11a installed on the display 60 of the telecommunication device 14a of the payor 14. In a preferred embodiment the payment request 13 compiled by the system in Step 108 includes the name of the payee 61 , the requested amount 62 and the comments of the payee 63 which can be viewed via the software application 11a on the display 60 of the payor's 14 communication device 14a as indicated in Fig. 5: The software application 11a preferably allows to decline or accept the payment request 13 by activating e.g. a corresponding button 64, 65 or to close the payment request 13 by activating
a third button 66 in order to make a payment decision at a later time. The software application 11a preferably also allows to open previously closed payment requests 13 for further action (declination or acceptance of the payment request 13).
In case the payor 14 chooses to decline the payment request 13 in Step
112 (e.g. by activating the "decline" button 64 in the software application 11a installed on the payor's 14 telecommunication device 14a) then a declination message is sent back to the system 10 in Step 114 over a telecommunication channel established between the system 10 (typically the server 11) and the telecommunication device 14a of the payor 14. The system 10 processes the declination message and preferably informs the payee 12 of the declination in Step 116.
For the event that the payor 14 does not respond within a pre-given time limit (e.g. by activating the "close" button 64 in the software application 11a and not opening the payment request 13 again for further action, or not retrieving the payment request at all), the system 10 preferably monitors whether a response is sent back within this time limit and if no response is received by the system 10 within this time limit, the system 10 preferably informs the payee 12 in Step 118 that payment was not initiated. Preferably the payee 12 is allowed to set the time limit of waiting for a response. The time limit can be set preferably when creating and/or loading the payment request data 13a in Step 100 or when submitting the payment request data 13a in Step 101.
After the payment request 13 is made accessible to the payor 14 the payor 14 is preferably allowed to give a payment order 13' in Step 120 (e.g. by activating the "accept" button 64 in the software application 11a). The initiation of the payment order 13' means that the payor's 14 payment application 11a running on its personal communication device 14a compiles a payment order 13' consisting of data received in the payment request 13 and personal information of the payor 14 comprising at least details of its payment credentials (typically: bank card number, expiry date, CVC/CW code, or account details) and potentially related authorisation details. At least part of the personal information can be stored in advance in the payor's 14 communication device
14a or the whole information may be inputted in relation to a specific transaction. Preferably the software application 11a sends back the payment order 13' to the system 10, which upon receipt of the payment order 13' initiates a payment transaction in Step 122 in accordance with the payor's 14 payment order 13' (see Fig. 4).
It is also conceivable that payors 14 wishing to use the payment service of the system 10 need to register with the system in advance in a similar procedure as the payee's 12, if for nothing else just to receive the payment application 11a.
Another important aspect of the invention being different from previously known solutions is the delivery of the payment request 13 to the payor's 14 communication device 14a for processing, compilation of the payment order 13' in the payor's 14 communication device 14a and then transmission of the complete payment order 13' by the payor 14 to the server 11 which will take care of the payment processing. In all previously known electronic payment solutions the payment requests are presented on a website or even if delivered to the payor the payor only needs to provide its payment credentials but the actual payment order is prepared on the server side.
After initiation of the payment transaction by the system 10 the payment transaction is carried out in a conventional way with the participation of various entities in Step 123. Such entities are typically the financial institute 70 of the system 10 (typically the bank of the system 10), or the financial institute 72 of the payee 12 (typically the bank of the payee 12) as recipients and the financial institute 74 of the payor 14 (typically the bank of the payor 14).
Alternatively payments may be performed against some type of pre- stored values, like loyalty points, in which case the operator of the loyalty program is involved in the transaction.
In an exemplary embodiment the payment transaction is initiated by the system 10 with its own financial institute 70 which contacts the financial institute 74 of the payor 14 requesting the payment transaction based on the payment data (typically bank card data) provided by the payor 14 and the amount indicated in the payment order 13'. If the bank card data is correct, sufficient
funds are available and the requested amount is not above any pre-set limit and there is no other obstacle to carrying out the requested payment transaction the financial institute 74 of the payor 14 confirms the payment transaction to the financial institute 70 of the system 10 and typically carries out a balance transformation on the account held by the payor 14 with his financial institute 74. The actual settlement of the payment transaction typically follows at a later time, which process comprises the settlement between payor's 14 financial institute 74 and the system's 10 financial institute 70 and then between the system's 10 financial institute 70 and the payee's 12 financial institute 72, with the payee's 12 account being eventually credited with the payment amount, or with some lesser amount due to the deduction of some service fees. Any of the two or even all three financial institutes 70, 72, 74 may be the same entities.
Due to the specifics of the method described here the payee 12 does not need to maintain an account with the system 10 or establish one for getting access to his funds, because the system 10 will transfer the paid amount due to the payee 12, to its external account managed by another entity, such as financial service provider, typically the financial institute 72, even more typically a bank.
Once the payment transaction is confirmed by the payor's 14 financial institute 74 to the system's 10 financial institute 70, the latter preferably sends back a real-time confirmation (payment authorisation) to the system 10 in Step 124 (see Fig. 4). Based thereon the system 10 generates a real-time confirmation message 13b, and preferably provides the payee 12 with the realtime confirmation message 13b in Step 126 (e.g. by sending the confirmation message 13b to the payee's 12 telecommunication device 50 over the telecommunication channel 52) whereby the payee 12 is informed real-time of the payment order 13' of the payor 14 and of the confirmation of the payment transaction by the payor's 14 financial institute 74. In the context of the present invention real-time actions are understood to include quasi real-time actions as well, hence a response is real-time (or quasi real-time) if the measured response time is in the order of seconds rather than minutes. This real-time payment confirmation has the benefit that the payee 12 can provide any product
or service to the payor 14 immediately upon receipt of the system's 10 confirmation since the payee 12 is now guaranteed that the financial settlement will follow in due course.
Preferably the payor 14 is also notified real-time about the successful completion of the transaction.
The above-described embodiments are intended only as illustrating examples and are not to be considered as limiting the invention. Various modifications will be apparent to a person skilled in the art without departing from the scope of protection determined by the attached claims.