LU93182B1 - Payment system - Google Patents

Abstract

A system adapted to the payment of an invoice between a supplier and a client via an e- invoicing platform, using SEPA standards. Fig. 1 93182

Description

Payment system [0001] This invention relates to a secured payment system between a supplier and a client, notably in the SEPA (Single Euro Payment Area) zone, and a method of transferring money between a client and a supplier through an e-invoicing platform.

[0002] When receiving an invoice, some clients do not entirely trust their suppliers to charge them the correct amount. For example, a telecom operator might include additional costs linked to high cost phone numbers that were never called. This type of invoice verification requires attention and often leads to the client not allowing direct debit from the supplier. Due to this lack of confidence in the accuracy of the invoice, the client does not automatically proceed with the payment as a complete inspection of the invoice is needed. Reviewing all invoices is fastidious and time consuming. Associated delay sometimes results in late-payments of the invoice which are charged a corresponding fee. Furthermore, the transactions methods used for paying the invoice may also result in supplementary costs.

[0003] This situation may be further exacerbated by the number of invoices sent to the client, each having a different deadline to pay the invoice to the supplier, with each supplier having its own conditions relating to deadlines and late-payment costs.

[0004] In order to gather the invoices, some grouping systems exist, such as Zoomit in Belgium. However, these invoice grouping systems are linked to particular national banks and, in order to proceed to the payment, it is mandatory to use the bank payment system of the respective bank. Zoomit, for example, is thus only a system for collecting invoices from suppliers and presenting them to the client. Furthermore, Zoomit only handles national payments.

[0005] Other systems such as Doccle or POM provide a system for the payment of invoices. Doccle uses a national payment system (Bancontact) and the payment system of a single national bank which may reduce costs compared to using a national money transferring system such as Bancontact in Belgium. POM uses various card based systems or third party payment services. These systems are dependent on the national banks or expensive international card solutions. None of them provide a flexible system for automatically paying invoices by confident agreement.

[0006] SEQR uses QR Code in point-of-sales (POS) for payment purposes but does not provide a solution for invoice presentment and invoice payment.

[0007] The European Union (EU) standardized the banking and payment landscape as part in its SEPA initiative. The SEPA standards and rulebooks have brought standardized SEPA credit transfers (SCT) and SEPA direct debit (SDD). Preferred embodiments of the present invention rely on those standards for its implementation.

[0008] Today, payment institutions operating in Europe offer very few technically simple and inexpensive payment methods even with these EU payment standardizations. For example, for a 50 euros transaction, the transaction costs paid may be: - Free if using SCT or EPC QR code (European Payment Council Quick-Response code); - 3 to 8 cents if using SDD; - 25 cents if using domestic or national payment system (such as Bancontact in Belgium); -137.5 cents if using a credit card (for example Visa or MasterCard); and - 205 cents if using an e-wallet (such as Paypal).

[0009] Each payment method (e.g. SCT, SDD, national payment system, credit card or e-wallet) relies on a series of levels of payment prosecution. The fundamental level comprises SCT, EPC QR and SDD. The fundamental level provides the technically simplest system with the cheapest transactions fees among all payment methods. Other payment methods are higher ranking level payment methods based on this fundamental level, each higher level using the payment methods of the levels beneath. The overall complexity and associated transaction fees for using a high ranking level payment method is greater than the sum of its sub-level transaction fees. For example, Paypal requires the use of a credit card, the credit card being independent from the national bank but using a national payment system. Consequently, the complexity and associated transaction fee for using Paypal is greater than the complexity and transaction fees when only using a credit card.

[0010] The transaction fees may represent a significant amount of fees at the end of a fiscal year and may greatly vary between banks and between countries. Additionally, when using a PSP (Payment Service Provider) or an e-Wallet, the transaction cost may be between 1 % and 3.5% of the total transaction amount, with minimal fees imposed on all payments.

[0011] One aim of the present invention is to provide a secure payment system which is configured to transfer money from the bank account of the client to the bank account of the supplier through an e-invoicing platform in a secured and fast way whilst reducing the complexity of the system, thus permitting a reduction in transaction costs.

[0012] In accordance with one of its aspects, the present invention provides a system for payment of an invoice as defined in claim 1. The dependent claims define preferred and/or alternative embodiments.

[0013] In accordance with another aspect, the invention provides a method for payment of an invoice by a client comprising, notably in the order recited: - provision of an invoice from an approved supplier to an e-invoicing platform; - storage of the invoice by the e-invoicing platform; - provision of information regarding the invoice to a client; - provision of client confirmation to the e-invoicing platform; - transfer of funds to a bank account associated with the e-invoicing platform from a client bank account for payment of the invoice; and -transfer of funds from the bank account associated with the e-invoicing platform to a bank account of the supplier in settlement of the invoice.

[0014] The e-invoicing platform is provided by an e-invoice solution company which is certified as a payment institution by all the central national banks or equivalent regulating authorities of the countries in which it is operating, for example NBB in Belgium. In order to be certified, the security aspects of the payment service, the governance associated with the service and the company will be audited to make sure that the appropriate security measures are in-place. The e-invoice solution company has a bank account which is configured to receive instructions from the e-invoicing platform.

[0015] The payment process comprises for example the following steps: 1. A supplier sends and provides the invoice details to an e-invoicing platform; 2. The e-invoicing platform stores the invoice details confidentially; 3. The invoice is presented to the client by the e-invoicing platform; 4. The client confirms the payment of the invoice to the e-invoicing platform, preferably with an appropriate security check, for example by clicking on a button to confirm payment in the invoice and providing a PIN code ; 5. The payment is performed by using a SEPA mandate from the client to the e-invoicing platform (SDD). The money is withdrawn from the client’s bank account and placed on a transfer account of the e-invoicing platform. Once the money is present on the bank account of the e-invoicing platform, it is then transferred to the bank account of the supplier, notably by using SCT.

[0016] The payment system of the invention may be based on the combined principles of SDD (SEPA Direct Debit) from the client to the e-invoicing platform and another payment system, notably SCT (SEPA Credit Transfer) applied from the e-invoicing platform to the supplier. This results in a flexible yet structurally simple secured payment system . The payment system may thus require the establishment of a SDD mandate between the client’s bank account and a bank account of the e-invoicing platform.

[0017] The SDD (SEPA Direct Debit) from the client to the e-invoicing platform as used in the payment system provides a disruptive payment method in the sense that it is an inexpensive “mandate proxy” over which the client has full control. This gives the client one place to manage all automated payments providing simplification and time efficiency.

[0018] The payment system preferably comprises a risk management system to avoid payment cancellations and the associated bank fees. The risk management system may be based on analyzing a plurality of payments performed by a client, notably a plurality of payments to the same supplier, and the effective cancellations and using the analysis, for example using machine-learning pattern recognition, to reduce the risks of future cancellations.

[0019] Suppliers are preferably validated prior to being accepted for sending invoices to the e-invoicing platform. The validation process may include a manual or partly manual check that the person that performs the supplier registration has signature rights for the supplier. The validation ensures that invoices that will be paid have been provided by validated suppliers or invoice issuers.

[0020] The payment system is preferably secured, for example requiring a security code , for example a personal identity code (pin-code) and/or by a login combined with a password; this security may be in the form of numbers, letters, signs or combination thereof. Such security may be required in order to proceed with a payment, and/or to access the e-invoicing platform and/or to use a one-click payment system and/or to access invoices and/or to validate a payment and/or to modify personal information such as the bank account number. Such security or verification may be requested for one or more payment operation(s). Even if a non-authorised attacker gains access to perform a payment, for example because he has access to the e-invoicing session of a client and he knows his pin-code, he will only be able to pay the invoices that this client received from validated invoice issuers. Preferably, if a client leaves an e-invoicing session unattended, an attacker could not perform a payment without knowing the pin-code.

[0021] The payment system may operate on software on a computer, on a tablet, on a smartphone or other device having access to the payment system, notably via an internet access.. The IT infrastructure, communication channels and/or processes are preferably secured, notably by HTTPS with cryptographic protocols which enable the encryption of communications between all parties notably communications with the supplier sending invoices, the client using the e-invoicing platform and the operator of the payment system.

[0022] The payment system may allow the client to verify an invoice that has been presented prior to approving payment. The client may thus check that the amount invoiced is correct and should be paid and then proceed with the payment.

[0023] The payment system may be configurable by the client to automatically pay some or all invoices, notably using client configurable automatic payments. For example, the client may set a predetermined automatic payment threshold such that invoices for an amount below the threshold are paid automatically. An individual automatic payment threshold may be associated with each supplier. For example, the client may configure the payment system to automatically pay quarterly invoices sent out by his gas and electricity provider as long as these are not above 100.00 €. The automated payment will be performed in due time, for example one week before the invoice payment is due. The next quarterly invoice that this client will receive will then be matched to this rule and if the conditions are met, the payment will be performed automatically. In that case, instead of receiving a notification that he received an invoice that he needs to pay, the client may receive a notification that he received an invoice that will be or which has been paid automatically. An invoice from a supplier for an amount below the automatic payment threshold for that supplier that has been set by the client will then be paid automatically without requiring further intervention from the client. Invoices that are above the automatic payment threshold may be transmitted to the client, notably for verification and payment. This enables the client to only check the invoices that do indeed require his attention while all the others will be paid automatically. This provides simplification, saves time for the client and helps him concentrate on the invoices that matter.

[0024] The client may change the automatic payment rules at any time. This provides flexibility for invoice management. For example, if the client knows that the available funds in his bank account may not be sufficient on the day of the predetermined automatic payment he can arrange payment for an alternative day. The client may also change the automatic payment threshold for example if the amount of the invoice from a supplier changes for one or more months (for example following indexation of a property rental agreement).

[0025] The client may be able to suspend or delay an automatic payment in the payment system. This may be useful if there is a delay in the client receiving his monthly salary and he does not wish his bank account to go in to debit or to be charged interest on his bank account. The effect of suspending or delaying the automatic payment may be instantaneous. The client may be able to use the standard payment to pay an invoice that is or was included in the automatic payment system. The client may resume one or more automatic payments . An automatic payment that was on-hold and that matches the automatic payment rules may be presented to the client for verification. The client may cancel one or more automatic payments. In case of a SDD payment method, SDD rules states that the client can request cancellation of a SDD payment without cost during the first 8 weeks following the withdrawal. The bank must comply immediately with such a request. The company that performed the withdrawal will then be requested to pay back the bank. A bank fee is also associated with such a cancellation. This means that even if an attacker managed to perform a payment, the client will still be able to cancel this payment within 8 weeks at no cost for him.

[0026] The payment system may further comprise a link to other payment methods such as QR code and/or net-banking.

[0027] In a preferred embodiment, the transfer from the bank account of the client to the bank account of the e-invoicing platform uses SDD payment method. In a preferred embodiment, the transfer to the bank account of the supplier from the bank account of the e-invoicing platform uses SCT payment method. This provides a secure, fast and cheap transfer of money, avoiding further costs to the client. The e-invoicing platform may then pay the invoice without requiring a second confirmation from the client. The client may send an authorization to the e-invoicing platform to automatically transfer money. For example, with a SDD mandate, the client can also configure recurring payments based on rules that he will define. The SDD mandate requires the client to perform a payment to validate that he has access to the bank account from which the money will be withdrawn during subsequent payments. The PSP solution that will be used to perform this validation must also be provided by a certified payment institution.

[0028] An embodiment of the invention will now be described, by way of example only, with reference to the accompanying drawing of which:

Fig. 1 is a schematic representation of the invention.

[0029] A first steps to perform an initial payment may require creating a SDD mandate between the client and the e-invoicing platform. This setup may be performed easily and in less than two minutes, without requiring high knowledge. For example, the client in a secure e-invoicing session makes a very small (e.g. 0,01 €) online transfer from a bank account using a PSP integration to have direct feedback on the transfer to validate that the client can indeed perform payments from that account. The client is then requested to confirm that he wishes to allow withdrawals from that account to pay his invoices. This validates the SDD mandate confirmation; a manual signature or electronic signature may be also be required by some authorities. The client is requested to provide a pin-code that he will use to confirm and secure the payments. Once the SDD mandate has been created, the client sees the payment details. In the system the amount of the invoice and other information relating to the invoice are readable by the client. After providing a pin-code, the client can click on the “Confirm” button and the payment will be processed. In subsequent payments, a click on the pay button followed by the pin-code is sufficient. The payment may then be performed, for example in less than 10 seconds in a very client friendly manner.

Claims (8)

1 A payment system for payment of an invoice between a supplier and a client, the payment system comprising an e-invoicing system which is configured to: accept and store an invoice from an approved supplier; provide information regarding the invoice to the client; upon client confirmation i) receive funds in a payment system’s bank account from a client bank account for payment of the invoice and ii) pay the supplier from the payment system’s bank in settlement of the invoice.

2 A payment system in accordance with claim 1, in which the payment system is configured to receive funds in the payment system’s bank account from the client bank account via a SEPA direct debit (SDD).

3 A payment system in accordance with claim 1 or claim 2, in which the payment system is configured to pay the supplier from the payment system’s bank account in settlement of the invoice via a SEPA credit transfer (SCT).

4 A payment system in accordance with any preceding claim, in which client confirmation comprises a payment confirmation provided to the payment system by the client in respect of an individual invoice.

5 A payment system in accordance with any preceding claim, in which the payment system is configured to comprise an automatic payment threshold for the client in respect of a supplier, notably a client configurable automatic payment threshold, and in which the payment system is configured to treat a configured automatic payment threshold as a client confirmation in respect of an invoice for the client from the supplier for an amount up to the configured amount of the automatic payment threshold.

6 A payment system in accordance with claim 5, in which the payment system is configured to provide information to a client including: - information that an invoice has been received falling within an automatic payment threshold that has been configured and that the invoice will be settled in the absence of further interaction by the client; and - information that an invoice has been received in respect of a supplier for whom an automatic payment threshold has be configured but that the invoice does not conform with the configured automatic payment threshold; and - information that an invoice has been received in respect of which client confirmation is required for payment.

7 A payment system in accordance with any preceding claim, in which client confirmation requires provision to the payment system of a pre-configured client approval security code, notably a PIN code.

8 A payment system in accordance with any preceding claim, in which payment system is configured to accept invoices from suppliers in more than one SEPA country, preferably for suppliers in all SEPA countries.