RECURRING PAYMENTS

TECHNICAL FIELD

[0001] The present invention relates to a system and method for generating a payment schedule for direct, recurring, repeated or pre-scheduled payments. In particular, the present invention relates to a system and method that allows customers to create or amend a direct debit or recurring payment schedule without the direct involvement of a merchant.

BACKGROUND ART

[0002] Direct, recurring, repeated or pre-scheduled payments (referred to hereafter as 'direct debits' or 'recurring payments') are generally based on an agreement with a financial institution under which a third party - usually a merchant or supplier of direct debit services (hereinafter referred to collectively as a "merchant" for convenience) - withdraws funds from the account or account associated with a credit or debit card (hereafter referred to as 'account') of a customer. Often, direct debit payments are at scheduled intervals of time, for instance for the payment of regular bills or invoices.

[0003] Before direct debit or recurring payments can be made, the customer must authorise the withdrawal of funds from their account by the merchant. Typically, a payment request file (including the monetary value of the withdrawals and the dates on which the withdrawals will occur) is created by the merchant and sent to the financial institution for processing. This payment request file may hold multiple or singular payment instructions.

[0004] If a variation to the payment schedule in the payment request file is required (for instance, to increase or decrease the monetary value of the payments, or change the dates or time intervals of the payments), the customer must contact the merchant to have the payment schedule changed, and the merchant must then enter these changes into its system. In addition, if the customer misses a payment (for instance, due to insufficient funds in its account) this must be dealt with as an extra payment that falls outside the original payment schedule.

[0005] For merchants, making variations to payment schedules for their customers is time- consuming and incurs costs which cannot be recovered from the customer. Similarly, such variations are generally undesirable for customers who are relying on the merchant to take prompt action to process the variation to the payment schedule before the next scheduled payment occurs.

[0006] There is therefore a need for an improved system and method for generating a payment schedule for direct or recurring payments.

[0007] It will be clearly understood that, if a prior art publication is referred to herein, this reference does not constitute an admission that the publication forms part of the common general knowledge in the art in Australia or in any other country.

SUMMARY OF INVENTION

[0008] The present invention is directed to a method and system for direct payments which may at least partially overcome at least one of the abovementioned disadvantages or provide the consumer with a useful or commercial choice.

[0009] With the foregoing in view, the present invention in one form, resides broadly in a method for creating a payment schedule, the method comprising the steps of: sending, from a first electronic device associated with a customer, a debit request including one or more payment parameters; receiving, with a second electronic device associated with an intermediary, the debit request, wherein the second electronic device is associated with an authorisation server, the authorisation server adapted to compare the one or more payment parameters against a predetermined acceptable value range for at least one of the one or more payment parameters such that, upon determining that the one or more payment parameters fall within the acceptable value range for the or each respective payment parameter, the authorisation server is adapted to generate a payment schedule request, and wherein the second electronic device is adapted to send the payment schedule request to a third electronic device associated with a financial institution to create a payment schedule.

[0010] The first electronic device may be of any suitable form. For instance, the first electronic device may be a computer, mobile telephone, tablet or the like. As previously stated, the first electronic device is associated with a customer.

[001 1] The customer may be any suitable entity. For instance, the customer may be an individual, a group of two or more individuals, a corporate entity, a group of two or more corporate entities, a trust, a partnership or the like. It is envisaged, however, that the customer may be an entity that wishes, or intends, to purchase goods and/or services from a merchant. In some embodiments of the invention, the customer may already be purchasing goods and/or services from a merchant, but may wish to vary an existing payment schedule for the goods and/or services.

[0012] It is envisaged that the customer may be purchasing goods and/or services from the merchant on an ongoing basis. For instance, the customer may be purchasing goods and/or services on a subscription basis, or may be purchasing the goods and/or services in

instalments. Such goods and services may include gym memberships, club or group memberships, subscriptions (for instance to a website, newspaper or magazine), internet services, telecommunications services, insurance policies, educational services (such as to childcare centres and schools), loan repayments (including car loans, personal loans, store loans, credit cards, mortgages etc.) or goods and services from any other suitable provider. Thus, it is envisaged that the customer may be making a plurality of payments (either regular or irregular) to the merchant for the goods and/or services over a period of time.

[0013] The debit or recurring payment request and payment schedule presentation (hereby referred to as debit request) may include any suitable information. For instance, the debit request may be in the form of a message that allows for the creation of a payment schedule, and may include, for instance, a data package including one or more of a payment method, formatting indicating how the system processes the payment method, as well as additional information such as one or more pieces of information relating to the customer (such as, but not limited to, name, address, date of birth, telephone number, email address, financial institution account details, credit or debit card details, employer details, salary or income information, tax file number, next of kin or the like, or any suitable combination thereof), one or more pieces of information relating to the merchant (such as, but not limited to, name, address, date of birth, telephone number, email address, financial institution account details, credit card details or the like, or any suitable combination thereof) and the like. In a preferred embodiment of the invention, the debit request may include one or more pieces of information relating to the customer and one or more pieces of information relating to the merchant.

[0014] The one or more payment parameters may be of any suitable form. It is envisaged, however, that the one or more payment parameters may relate to a payment or payments that the customer intends to make to the merchant. In particular, it is envisaged that the one or more payment parameters may relate to a plurality of payments (and, in particular, scheduled payments) that the customer intends to make to the merchant. The one or more payment parameters may include a payment amount, a payment date, a payment frequency, a payment term, an interest rate, a payment history or the like, or any suitable combination thereof. In some embodiments of the invention, the one or more payment parameters may be used to establish a new payment schedule between a customer and a merchant. Alternatively, the one or more payment parameters may be used to create a new payment schedule that is a variation on an existing payment schedule that already exists between a customer and a merchant.

[0015] The debit request may also be provided in any suitable form. For instance, the debit request may be in the form of an email, SMS message, MMS message, voice recording, video, voice mail, direct message into the customer ^' s bank account, or the like, or any combination thereof.

[0016] In another embodiment of the invention, the creation of a debit request may be conducted using one or more electronic interfaces displayed on the first electronic device. Preferably, the one or more electronic interfaces may be associated with the intermediary. In this embodiment, the one or more electronic interfaces may be associated with the second electronic device and/or the authorisation server. In some embodiments of the invention, the one or more electronic interfaces may be accessed online, for instance through a website or an application, such as an application downloaded to a mobile telephone, computing tablet or the like. The application may include one or more application programming interfaces (APIs) that a customer may access through graphical user interfaces (GUIs) using the electronic device. It is envisaged that the application may (via the one or more APIs) send notifications or messages to the customer. In this way, the authorisation server may effectively communicate with the customer through the one or more APIs. Thus, it is envisaged that the debit request may be sent from the first electronic device to the second electronic device via an Internet connection whereby the customer remotely accesses the one or more electronic interfaces. This electronic interface may be delivered as part of another electronic system or application, for example, the electronic interface may be delivered as part of or via a customer's electronic banking application or other such electronic applications via webhook, API, iFrame or other such methodology.

[0017] In this embodiment of the invention, it is envisaged that information (including the one or more payment parameters) may be entered into the one or more electronic interfaces by a customer in any suitable format. However, it is envisaged that the information may be entered into the one or more electronic interfaces in human readable format, such as using a keyboard or keypad associated with the first electronic device.

[0018] The debit request may be sent in any suitable format. For instance, the information (including the one or more payment parameters) contained in the debit request may be received by the second electronic device in human readable format. More preferably, however, the information (including the one or more payment parameters) contained in the debit request may be received by the second electronic device in machine readable format. Thus, it is envisaged that the website or application may (via the one or more APIs) convert information entered by the customer into machine readable form.

[0019] It is envisaged that changes to the interface produced and displayed on the first electronic device are preferably made and/or a new interface is displayed and produced depending upon the instructions and/or interaction that a customer has with the interface, and thereby with the second electronic device and/or the authorisation server.

[0020] The second electronic device may be of any suitable form. For instance, the second electronic device may be a computer, mobile telephone, tablet or the like. As previously stated, the second electronic device is associated with an intermediary.

[0021] The intermediary may be any suitable entity. For instance, the intermediary may be an individual, a group of two or more individuals, a corporate entity, a group of two or more corporate entities, a trust, a partnership or the like. It is envisaged, however, that the intermediary may be an entity that acts as an intermediary between the customer and the financial institution. Thus, it is envisaged that the intermediary may require authorisation from the financial institution in order to be able to generate and send a payment schedule request to the financial institution (via the third electronic device associated with the financial institution). In addition, it is envisaged that the intermediary may be authorised by the merchant to generate the payment schedule request should the one or more payment parameters all fall within the acceptable value range for the respective payment parameter.

[0022] In a preferred embodiment of the invention, the acceptable value ranges for at least one of the one or more payment parameters may be provided to the intermediary by the merchant. The acceptable value ranges may be provided to the intermediary in a form for entry by the intermediary. More preferably, however, the merchant may enter the acceptable value ranges for the payment parameters into one or more electronic interfaces displayed on an electronic device associated with the merchant. Preferably, the one or more electronic interfaces may be associated with the intermediary. In this embodiment, the one or more electronic interfaces may be associated with the second electronic device and/or the authorisation server. In some embodiments of the invention, the one or more electronic interfaces may be accessed online, for instance through a website or an application, such as an application downloaded to a mobile telephone, computing tablet or the like. The application may include one or more application programming interfaces (APIs) that the merchant may access using the electronic device. It is envisaged that the application may (via the one or more APIs) send notifications or messages to the merchant. In this way, the authorisation server may effectively communicate with the merchant through the one or more APIs. Preferably, the merchant may access the one or more electronic interfaces remotely via an Internet connection. In a preferred embodiment of the invention, at least one of the one or more electronic interfaces accessed by the merchant may be different to the one or more electronic interfaces accessed by the customer. Thus, users of the website or application may be provided with different levels or forms of access depending on the nature of the user (i.e. whether the user is a customer, merchant or financial institution).

[0023] A merchant may provide any suitable number of acceptable value ranges. For instance, the merchant may provide acceptable value ranges for one or more payment parameters such as a payment amount, a payment date, a payment frequency, a payment term, an interest rate, a payment history or the like, or any suitable combination thereof. In some embodiments of the invention, a merchant may enter an acceptable value range for each applicable payment parameter. Alternatively, a merchant may elect not to enter an acceptable value range for one or more payment parameters. For example, a merchant may elect not to enter an acceptable value range for payment frequency. In this embodiment of the invention, the merchant may not be concerned with the frequency of payments received from the customer, provided that any monies owing are paid in full within a particular payment term.

[0024] In some embodiments of the invention, the merchant may provide the same acceptable value ranges for all customers. Alternatively, the merchant may provide different acceptable value ranges based on the status of the customer. In this embodiment, it is envisaged that the merchant may provide more flexible acceptable value ranges for longstanding customers, customers with good payment histories, customers owing only relatively small amounts of money or the like. On the other hand, less flexible acceptable value ranges may be provided for new customers, customers with poor payment histories, customers owing relatively large amounts of money or the like. The merchant may provide this information to the intermediary (in which case the information may be held on the authorisation server), or, in a preferred embodiment, the authorisation server may access one or more external servers or databases to determine whether the customer's debit request should be compared against more flexible acceptable value ranges or less flexible acceptable value ranges. The one or more external servers or databases may be of any suitable form, and may be associated with, for instance, the merchant, the financial institution or another entity (such as a credit rating agency or the like).

[0025] It is envisaged that, upon receipt of the debit request, the authorisation server will compare the one or more payment parameters in the debit request against corresponding acceptable value ranges for each of the one or more payment parameters. In some embodiments of the invention, the debit request may be refused or rejected by the authorisation server if the customer's payment parameters fall outside the acceptable value range for one or more of the payment parameters. For instance, if the customer's chosen payment amount falls below the acceptable value range, or if the customer's chosen payment term is greater than the acceptable value range, the authorisation server may refuse or reject the debit request. In this situation, it is envisaged that a message confirming the rejection or refusal of the debit request may be sent from the second electronic device to the first electronic device and/or the third electronic device and/or the electronic device associated with the merchant. In some

embodiments of the invention, the message confirming the rejection or refusal of the debit request may include the reasons for the rejection or refusal of the debit request such that, upon receipt of the message, the customer may send a further debit request wherein the one or more payment parameters may be adjusted to lie within the respective acceptable value ranges.

[0026] Alternatively, if the one or more payment parameters in the debit request fall within the acceptable value ranges for each of the relevant one or more payment parameters, the authorisation server may authorise the debit request. By authorising the debit request, the authorisation server confirms that the one or more payment parameters chosen by the customer and contained in the debit request are acceptable to the merchant, and that the merchant would be willing to either establish a new payment schedule (or vary an existing payment schedule) based on the customer's selected one or more payment parameters.

[0027] Once the debit request is authorised by the authorisation server, the authorisation server may generate a payment schedule request based on the one or more payment parameters. The payment schedule request may be of any suitable form, although it is envisaged that the payment schedule request may be generated in machine readable format. The payment schedule request, once generated by the authorisation server, may be sent by the second electronic device to the third electronic device associated with the financial institution.

[0028] The payment schedule request may include any suitable information. Preferably, however, the payment schedule request includes the customer's payment parameters as authorised by the authorisation server. Thus, the payment schedule request may include one or more of a payment amount, a payment date, a payment frequency, a payment term, an interest rate, a payment history or the like, or any suitable combination thereof.

[0029] The third electronic device may be of any suitable form. For instance, the third electronic device may be a computer, mobile telephone, tablet or the like. [0030] The financial institution may be of any suitable form, and may be a bank, credit union, credit card company, online payment system or the like, or any suitable combination thereof. In a preferred embodiment of the invention, the financial institution is a financial institution at which the merchant holds an account, and preferably an account into which the customer's payments are to be received.

[0031] Preferably, the third electronic device may be associated with a financial institution server. In this embodiment of the invention, it is envisaged that the financial institution server may, upon receipt of the payment schedule request, create the payment schedule. Preferably, as the one or more payment parameters contained in the payment schedule request have been authorised by the authorisation server, the financial institution server may not be required to perform any additional authorisation of the one or more payment parameters. Instead, the financial institution server may simply create a payment schedule based on the authorised payment parameters contained in the payment schedule request.

[0032] Of course, the financial institution server may conduct an audit or review of the payment schedule request. Such a review or audit may be, for instance, to ensure that the payment schedule request is genuine (i.e. has been issued by the second electronic device associated with the intermediary) and has not been issued fraudulently.

[0033] It is envisaged that the payment schedule may be retained in the financial institution server. The payment schedule may include information such as payment date, payment amount, payment frequency and so on, such that, when a payment date contained in the payment schedule is reached, the financial institution server may generate a payment request for the payment of the payment amount. The payment request may be transmitted electronically from the third electronic device to a fourth electronic device associated with a customer's financial institution. It will be understood that the term "customer's financial institution" is intended to refer to a financial institution (a bank, credit union, credit card company, online payment system or the like) at which the customer holds an account from which the payment amount is to be deducted.

[0034] Upon receipt of the payment request, the customer's financial institution may authorise the transfer of the payment amount from a payment credential (financial institution account, credit card, online payment system account or the like) of the customer to a payment credential (financial institution account, credit card, online payment system account or the like) of the merchant or the receiving entity such as a third party payment facilitator or intermediary. [0035] Upon receipt of the payment amount to the payment credential of the merchant (or other party as previously referred to), it is envisaged that the financial institution server may update the payment schedule and monitor for the next payment date at which a further payment amount is to be transferred.

[0036] A system for generating a payment schedule, the system comprising: a processor; at least one non-transitory computer readable storage medium storing instructions on the processor, wherein when the instructions are executed by the processor it causes the system to: authorise a debit request including one or more payment parameters sent from a first electronic device associated with a customer and received by a second electronic device associated with an intermediary, wherein authorising the debit request comprises: comparing the one or more payment parameters to a predetermined acceptable value range for each of the one or more payment parameters; determining whether the one or more payment parameters fall within the predetermined acceptable value range for each respective payment parameter; and where it is determined that the one or more payment parameters fall within the

predetermined acceptable value range for each respective payment parameter, authorising the generation and sending of a payment schedule request authorisation to a third electronic device associated with a financial institution in order to generate the payment schedule.

[0037] Embodiments of the present invention concern the support tools surrounding scheduled direct debit or recurring payments. Some embodiments can be implemented as an overlay service to existing direct debit payment arrangements.

[0038] Some embodiments look to create an additional service layer within the regular, repeated direct debit or direct entry payments that are performed by business via their merchant facility at a bank or via a third party 'direct debit service provider. Embodiments will do this by allowing customers to self-manage certain aspects their direct debit arrangements with the business through an internet based service delivered on mobile phones or computers. Embodiments of the present invention are referred to below as the direct or recurring payment application or as the direct or recurring payment application system.

[0039] Through integrations such as APIs (REST, SOAP), webhooks, HTTPS or other such message/response sequences, the direct or recurring payment application of the present invention sits between the merchant's bank batch processing file and the customer's direct or recurring payment application portal and account allowing customers to instigate changes to their direct debit or recurring payment arrangements with the merchant without the need for the merchant to manually update their bank batch processing files (all files that are relevant to order direct debit payments via bank or third party will hence forth be referred to a batch processing files), single payment instructions or third party payment service files/accounts.

[0040] The customer's direct or recurring payment application account/portal is created during the 'merchant set up phase' as a result of HTTPS messaging GET referrals and responses/API integrations (including but not limited to Java, Microsoft Competent Object Modelling (COM) Microsoft.net, PHP, SOAP or REST, webhook or other such methodologies) with the merchant's CMS, third party payment provider, customer payment records or other customer record and electronic payment filling systems such as bank interfaces. The merchant will complete authorisations where required to allow the direct or recurring payment application access to the required information. The authorisations may be produced by the merchant's bank or software provider. If the merchant is using xml, txt, or csv based documents as their batch processing file to send to their bank or payment provider for scheduled payment processing, the direct or recurring payment application will allow the merchant to upload this to the direct or recurring payment application system in order to create payment arrangement data and records for the merchant's customers. A combination of all of these methods may be used by the merchant in order to upload and fulfil all data requirements of the direct or recurring payment application system. The customer details retrieved are (including but not limited to) name, contact details such as email, address and phone number, bank account details - BSB, Account name and number - of the account from which the merchant receives direct debit payment and payment arrangements (including but not limited to) payment amounts, schedule, start date, end date and payment history. Information will be parsed and displayed as per the Ul of the direct or recurring payment application customer account/portal. Security and storage of this information will follow known security protocols such as encryption and, where required, tokenisation. The direct or recurring payment application will not alter the original state of the storage of the information on the 'merchant side'. The direct or recurring payment application, where required for timely information recall, will store information by known secure practices in known cloud server environments such as Amazon Web Servers, where it will assign internal system account references to the information so that it is display as correct will recalled by the customer. The information retrieval and display will be continually repeated and ongoing in a scheduled (based on but not limited to scheduled payment dates and events) or ad-hoc manner to reflect all changes and updates received from the bank or payment processor who performs the payments on -behalf of the merchant - such as debit payments successfully or unsuccessfully processed- as per standard REST/SOAP practices. In this way the customer can accurately and on demand view their payment arrangements, contact details, payment history and future scheduled payments through their customer portal. [0041] At the completion of the successful 'merchant set up phase' all existing and active customers in the system will receive messages instigated through the direct or recurring payment application system using -known methods such as email server or 'Messagebird' or similar SMS providers- to their mobile phone or email, a unique url link and code identifier. This unique link when followed will take the customer to the access portal for their specific direct or recurring payment application customer account.

[0042] Utilising known and existing oauth, device ID, 4 digit passcode and any other known security measures, the customer can verify and access their account. This account is then deemed 'active' in the direct or recurring payment application system and a successful 'link' is established between the direct or recurring payment application's customer account and the merchant's bank batch process file (either in a staging environment in the case of authorisation for changes required form the merchant for merging or active instant change merging)

[0043] In order for a new (new meaning an additional customer account established or created outside of the initial direct or recurring payment application set up phase) customer

account/portal to be created, the merchant must first create a new customer account and payment arrangement information (including but not limited to payment amount, payment schedule, starting date, ending date) in their existing system that has been previously integrated with their direct or recurring payment application merchant account. This account information will be parsed via at the merchant's instigation. The merchant will instruct the direct or recurring payment application system to 'retrieve new account' (or similar) by clicking the 'Find New Account' command/button (or similar).

[0044] This is will instruct the direct or recurring payment application system to perform a GET retrieval, display new account information found to the merchant for confirmation. The merchant will 'confirm' and the account creation for the customer will commence as described above 'customers in the system will receive messages instigated through the direct or recurring payment application system using -known methods such as email server or 'Messagebird' or similar SMS providers- to their mobile phone or email, a unique url link and code identifier. This unique link when followed will take the customer to the access portal for their specific direct or recurring payment application customer account utilising known and existing oauth, device ID, 4 digit passcode and any other known security measures, the customer can verify and access their account. This account is then deemed 'active' in the direct or recurring payment application system and a successful 'link' is established between the direct or recurring payment application's customer account and the merchant's bank batch process file (either in a staging environment in the case of authorisation for changes required form the merchant for merging or active instant change merging)'. The merchant is notified of all active direct or recurring payment application accounts via their merchant dashboard.

[0045] Customers with active direct or recurring payment application account/portals may complete the legal and required DDR forms (Direct Debit Request) forms or other such authorisations within the direct or recurring payment application system. Customers imported into the system during the 'merchant set up phase' will be assumed to have completed a DDR at the beginning of their direct debit arrangements with the merchant and will not be required to complete additional DDRs unless they opt to make changes affecting the original agreement from within the direct or recurring payment application system. Changes that affect the original DDR include but are not limited to - change of bank account from which the payment originates, permanent changes to their payment arrangements such as increased amount or frequency change. In these cases, existing customers will complete the following process that will also apply to new customers (new as defined above 'additional customer account established or created outside of the initial 'direct or recurring payment application set up phase').

[0046] Customers will access and verify account as described above. For new customers and changes affecting the current DDR arrangements, customers will first be asked to completely read and agree to the conditions of the DDR which will be displayed and signed according to known legal electronic document agreements.

[0047] The DDR's legal content will be generated as per known standard document

requirements and the areas the required customised information for the individual agreement (including but not limited to customer details, payment arrangements, merchant details and bank account details) will be populated according to the corresponding information drawn from the system during the customer creation account/GET information stage.

[0048] The customer will agree to the DDR or other such authorisations and sign as per known legal electronic signature methodologies or other verification methods such as unique code confirmation or check-box acceptance acknowledgement. The completed form will be sent to the merchant via email and via the direct or recurring payment application merchant

account/dashboard or stored in a database. A copy will also be sent to the customer via email and be available to retrieval/view via the customer portal or stored in a database. The form will therefore be stored according to known security protocols in the direct or recurring payment application servers for customer and merchant recall. The merchant will forward a copy via email or other to their payment provider or bank according to their own individual arrangements. The stored 'form' may take the form of human-readable long-form electronic agreements or take the form of machine-readable time-stamped event logs to record customer acceptance and interactions as the current compliance and security standards may require.

[0049] Customers may instigate changes to their direct debit or recurring payment

arrangements with merchant once their direct or recurring payment application account/portal is 'active'. These changes can be made using the direct or recurring payment application interface on an internet connected device such as a mobile phone or computer or other. The direct or recurring payment application interface will allow the customer to order changes (these changes are described in detail later in this document) including but not limited to temporary payment date changes for one or more payments, changes to the bank account from which the payment originates, one-off payments (which may occur in circumstances such as making up for a previously missed or late payment), contact detail changes, splitting the payment between two accounts and other changes.

[0050] Through the direct or recurring payment application merchant dashboard, merchants can set parameter rules for allowed changes that can be made by the customer without individual change approvals. These rules may apply to (but are not limited to) situations such as allowable days for the customer to defer a payment (meaning the merchant may allow a customer to defer their scheduled payment by 1 -7 days without direct approval for this change), allowances for rules regarding outstanding payments such as days the direct or recurring payment application system will display outstanding amounts for payment before the merchant manually pursues payment for the outstanding amount or number of payment deferrals per month or other time period. The rules the merchant sets through the merchant Ul which will display rule options to the merchant will then form the permitted parameters for change in the customer portals with payment agreements associated to that merchant. Customer change options displayed will confirm to the rules set by the merchant associated to that payment agreement.

[0051] When the customer orders a 'temporary' change to be made to their account or payment arrangements with the merchant, the direct or recurring payment application will create instigate a push API request (or similar communication) to communicate this change with the merchant's or payment facilitator's batch or single instruction processing file. The format of this request will either be a merge change request whereby the direct or recurring payment application will complete the change, check and remove redundant/duplicate/changed or expired information as a result of that change from the file and notify the merchant and the customer of the

updated/changed information via email and their respective portal/dashboards. The batch or single instruction payment processing file will then be sent without need for further alteration as per the standard arrangement for the merchant and their bank/payment provider. In some cases, the merchant may need to manually merge the changes to their batch

document/payment system. In this case a daily change request summary may be sent to the merchant via email and their direct or recurring payment application account describing the change request, action required, customer details and other relevant information. The merchant may manually update the changes in their file/payment provider system and acknowledge the change requests as 'actioned' in the direct or recurring payment application system whereby the customer will be notified via their direct or recurring payment application account that the change request has been completed.

[0052] When the customer makes a change to the date of a payment, the future payment schedule is not altered - for example if a customer is scheduled to make a payment every second Tuesday and orders a change to the next scheduled payment so that it is instigated on the Friday (3 days later than originally scheduled), the next payment after the changed date and all those after will continue as originally scheduled for every second Tuesday. The direct or recurring payment application will impart this logic via the push API links to ensure that the change is accurately reflected and only action upon the immediately affect payment date.

[0053] In the case of a customer either temporarily or permanently ordering a change of bank account from which their payment originates, unless the account is preloaded into the system with a completed DDR (or similar authorisation), the customer must complete a new DDR (or similar authorisation) to authorise the debit from the new account.

[0054] A customer may load multiple accounts into their direct or recurring payment application portal and each will be authorised by separate DDRs (or similar authorisations) which will be stored and communicated as above. Once this is completed, the customer may switch between their 'loaded' accounts without the need for further DDRs (or similar authorisations).

[0055] If the customer wishes to make a change to their contact details, these changes are may be parsed via push API to the merchant's CRM or other system that the merchant has integrated with the direct or recurring payment application system or communicated via daily change summary to the merchant's direct or recurring payment application account or email.

[0056] If the customer wishes to make a one-off payment which means a payment outside of the regular schedule payment agreement in place with the merchant, they may do so by selecting One off payment' (or similar Ul) button in their direct debit portal where the function is enabled. The direct debit system may display amounts that remain outstanding in the customer account outside of the regular payment arrangement. These amounts can be drawn from the payment responses returned from the merchant's bank or via the third party payment portal or other system. Responses that are marked with codes indicating unsuccessful payments will be shown in the merchant's direct or recurring payment application system where they can be pushed to the customer system as an outstanding amount. The customer can the elect to pay this preloaded outstanding amount. The direct or recurring payment application system will parse the customer reference specific to the merchant system, the payment details specific to the merchants system and other relevant details into the merchant's existing payment system - either bank or other provider. The customer may then make the payment in this environment that has been prepopulated with details via the direct or recurring payment application. The customer may make payments as per the merchant's existing payment system allows. The payment may take place as a hosted environment in the direct or recurring payment application system or in the merchant or payment environment - both of these payment methodologies are known processes. Once the customer has successfully completed payment via the existing merchant payment system, the direct or recurring payment application will display a record of this payment in the customer's direct or recurring payment application account and will notify the merchant of the payment via email and direct or recurring payment application account. The direct or recurring payment application will also remove 'outstanding amount' from the customer display portal.

[0057] Should the customer open a new payment agreement with a new merchant, or have existing payment agreements with multiple merchants, (see payment 6), a new authorisation and account will be created for initial account verification, following this initial verification, the customer will be able to access all existing payment arrangements from all merchants via the same customer account/portal. All payment arrangements will be managed separately by the customer and the direct or recurring payment application system. The direct or recurring payment application system will store data in such a way that merchants only have access to the customer and payment arrangement data that is 'owned' by them as per known

authorisation and data storage practices.

[0058] The direct or recurring payment application system will display the customer's payment history in the customer portal/account. This information will be retrieved via get /pull request through the API (or other method of communication) established with the merchant's existing payment system, bank, third party provider or other. The direct or recurring payment application will translate codes that indicate successful and unsuccessful (and possible reasons for unsuccessful payments) and display the date and outcome of this event in the customers portal/account.

[0059] The direct or recurring payment application may be used as part of a payment processor and gateway in its own right. In which case, all APIs and integrations referred to with third party payment service providers will become in-system communication that occurs within the direct or recurring payment application system. The focus of this patent therefore is on the ability for the customer to instigate changes to their direct debit arrangements with merchants and the merchant payment provider or bank, and the way in which the direct or recurring payment application then actions, reports, communicates and manages these changes, in either the existing merchant systems or in their own operating payment systems. In some cases this will be achieved through external system integrations and in some cases, the direct or recurring payment application will be the processor and gateway services providers as well as customer portal providers as detailed in this patent description document.

[0060] Embodiments of the present invention can have immediate impact upon businesses that rely upon direct debit repeated payments - either through a merchant bank facility or a third party processor. These businesses will all have a high 'touch point' and administrative cost around managing customer change requests, missed payments and account management such as:

- Loan providers

- Gyms

- Clubs and groups

- Subscription services

- Childcare centres

- Banks wishing to provide better service tools to merchants

- Third party payment providers wishing to offer additional services to their customers

[0061] The direct or recurring payment application does not disturb the existing payment provider in these business - rather the direct or recurring payment application acts as an overlay service to the payment system, streamlines customer management and reduces missed payments, reduces merchant's commitment to the administration and human capital required currently to manage customer change requests to existing payments and provides a customer service tool.

[0062] Embodiments of the present invention provide numerous advantages over the prior art. For instance, the present invention allows customers to self-manage their direct debit arrangements with merchants (within rules set by the merchant). Further, embodiments of the present invention will typically provide the customer with a much faster approval of, and change to, their existing payment schedule than the prior art due to the use of the authorisation server.

[0063] In addition, embodiments of the present invention can be advantageous for merchants who, in the past, have been required to spend time and incur costs in order to vary a customer's payment schedule. Instead, with the present invention, other than setting the accepted value ranges for the payment parameters, the merchant is not required to undertake any action in order to set up a variation to a payment schedule.

[0064] Any of the features described herein can be combined in any combination with any one or more of the other features described herein within the scope of the invention. Those skilled in the art will appreciate that not all of the above advantages will necessarily be achieved by all embodiments of the present invention.

[0065] The reference to any prior art in this specification is not, and should not be taken as an acknowledgement or any form of suggestion that the prior art forms part of the common general knowledge.

BRIEF DESCRIPTION OF DRAWINGS

[0066] Preferred features, embodiments and variations of the invention may be discerned from the following Detailed Description which provides sufficient information for those skilled in the art to perform the invention.

[0067] The Detailed Description is not to be regarded as limiting the scope of the preceding Summary of the Invention in any way.

[0068] The Detailed Description will make reference to a number of drawings as follows: FIG. 1 illustrates a prior art method for creating a payment schedule. FIG. 2 illustrates a method for creating a payment schedule according to an embodiment of the present invention.

FIGs. 3, 4, 5, 6, 7 and 8 illustrate examples of various graphical user interfaces (GUIs) that are used by a customer to access an application programming interface (API) and alter various payment parameters, such as payment dates and payment amounts, according to an embodiment of the present invention.

DESCRI PTION OF EMBODIMENTS

[0069] In FIG. 1 there is illustrated a method for creating a payment schedule according to the prior art. In this Figure, a customer 10 sends a direct debit request 12 to a merchant 13. The direct debit request 12 is typically created because the customer 10 wishes to purchase goods or services from the merchant 13 on an ongoing basis, or in instalments. Typically, the direct debit request 12 will include information such as identification information of the customer 10 (such as name, date of birth, address, telephone number, a payment credential such as the details financial institution account, debit or credit card or the like). In addition, the direct debit request 12 will typically include information such as the frequency of payments that the customer 10 will make to the merchant 13, the monetary amount of each payment and so on.

[0070] If the merchant 3 is prepared to provide goods and services to the customer 10 on the terms contained in the direct debit request 12, the merchant 13 accepts the direct debit request 12. The merchant 13 then creates a payment schedule 1 1 and sends the payment schedule 1 1 to its financial institution 14.

[0071] When the payment schedule 1 1 indicates that a payment from the customer 10 to the merchant 13 is due, the merchant's financial institution 14 sends a message 15 to the customer's financial institution 16. The message 15 includes both an indication of when a payment 17 must be made, and the monetary value of the payment 17. In response to the message 15, the customer's financial institution 16 then sends the payment 17 to the merchant's financial institution 14.

[0072] Upon receipt of the payment 17, the merchant's financial institution 14 then monitors the payment schedule 1 1 for the next payment, at which time a further message 15 will be sent to the customer's financial institution 16 seeking a further payment 17.

[0073] If the customer 10 wishes to make changes to the payment schedule 1 1 (for instance to increase or decrease the monetary value of the payment, or to increase or decrease the frequency of payments), the customer 10 must send a change request 18 to the merchant 13. The merchant 13 is then required to generate a new payment schedule 1 1 and send it to the merchant's financial institution 14. For the merchant, the creation of a new payment schedule 1 1 involves lost time, as well as incurring costs that cannot be recouped from the customer 10. Similarly, the customer 10 is reliant on the merchant 13 generating a new payment schedule 1 1 in a timely manner. If, for instance, the merchant 13 fails to generate a new payment schedule 1 1 before the next payment is due, the customer 10 will end up making one or more payments according to the old payment schedule. This could result in, at best, inconvenience or, at worst, financial hardship for the customer 10.

[0074] In FIG. 2 there is illustrated a method for creating a payment schedule according to an embodiment of the present invention. In this Figure, a customer 10 creates a debit request 12. The debit request 12 is created using one or more electronic interfaces (not shown) associated with an electronic application downloaded to an electronic device 19 in the form of a mobile telephone associated with the customer 10. The debit request 12 includes one or more payment parameters, such as a payment frequency, a monetary value of each payment, a term over which payments are made, and/or identification information of the customer 10 (such as name, date of birth, address, telephone number, a payment credential such as the details financial institution account, debit or credit card or the like).

[0075] Once created, the debit request 12 is sent via the Internet using the electronic device 19 to an electronic device 20 in the form of a computer associated with an intermediary 21. The electronic device 20 is associated with an authorisation server 22 that, upon receipt of the debit request 12, compares the one or more payment parameters in the debit request 12 against one or more predetermined acceptable value ranges related to at least one of the one or more payment parameters.

[0076] The one or more acceptable value ranges are determined by the merchant 13. The one or more acceptable value ranges are the payment terms (payment parameters such as payment frequency, payment term, the monetary value of a payment etc.) that the merchant 13 would be prepared to accept from the customer 10. The merchant 13 provides the intermediary 21 with the acceptable value ranges for at least one of the one or more payment parameters by entering the acceptable value ranges into one or more electronic interfaces (not shown) associated with an electronic application downloaded to an electronic device 23 in the form of a computer associated with the merchant 13. In this embodiment of the invention, the acceptable value ranges are sent to the electronic device 20 from electronic device 23 via the Internet and are stored in the memory of the authorisation server 22. The acceptable value ranges are accessed by the authorisation server 22 in response to the receipt of a debit request 12 from a customer

10.

[0077] In another embodiment of the invention, the one or more acceptable value ranges may be stored in the memory of a server 24 associated with the merchant 13. Upon receipt of a debit request 12 from a customer 10 of the merchant 13, the authorisation server 22 may

communicate electronically with server 24 to access the one or more acceptable value ranges.

[0078] In either case, once the merchant 13 has provided the acceptable value ranges to the intermediary 21 , and no direct input is required from the merchant 13 when creating a payment schedule 11. Even when a customer 10 sends a change request 18 to the intermediary 21 to make a change to an existing payment schedule 1 1 (and, therefore, to create a new payment schedule 11 ), the merchant 13 is not required to provide any direct input. Instead, the intermediary 21 creates the payment schedule 11 on behalf of the merchant 13 based on whether the payment parameters contained in the change request 18 fall within the acceptable value ranges.

[0079] If the payment parameters contained in the debit request 12 or the change request 18 fall outside the acceptable value ranges, the authorisation server 22 may send a message via the Internet from the electronic device 20 to the electronic device 19 associated with the customer 10. The customer 10 may then, if desired, generate and send a new debit request 12 or change request 18 with different payment parameters. The authorisation server 22 will then compare the payment parameters in the new debit request 12 or change request 18 against the acceptable value ranges.

[0080] If the authorisation server 22 determines, upon comparing the payment parameters in the debit request 12 or the change request 18 that the payment parameters fall within the applicable acceptable value ranges provided by the merchant 13, the authorisation server 22 authorises the creation of a payment schedule 1 1 including information such as, but not limited to, the term and/or frequency of the payments to be made to the merchant 13 by the customer 10, the monetary value of the payments and so on.

[0081] In some embodiments, it may be necessary for all of the payment parameters to fall within the acceptable value ranges before the debit request 12 can be authorised by the authorisation server 22. Alternatively, it may be necessary for only some of the payment parameters to fall within acceptable value ranges before the debit request 12 can be authorised by the authorisation server. For instance, if the monetary value of the payment and the payment term fall within the acceptable value ranges, a merchant 13 may not be concerned as to whether the payment frequency falls within the acceptable value range for that payment parameter.

[0082] In other embodiments of the invention, a merchant 13 may not provide an acceptable value range for all payment parameters. Thus, in this embodiment, any value of a particular payment parameter selected by a customer 10 for which an acceptable value range is not provided by the merchant 13 may be authorised by the authorisation server 22.

[0083] A merchant 13 may provide the same acceptable value ranges to each of its customers 10. Alternatively, different acceptable value ranges may be associated with different customers 10, or different groups of customers 10. For instance, if a customer 10 is a long-term customer 10 of a merchant 13 and/or has a good credit history, the merchant 13 may be prepared to offer more flexible acceptable value ranges than to a new customer or an existing customer with a poor credit history.

[0084] The payment schedule 1 1 is sent by the electronic device 20 associated with the intermediary 21 to an electronic device 25 associated with the merchant's financial institution 14 via the Internet. When the payment schedule 11 indicates that a payment from the customer 10 to the merchant 13 is due, the merchant's financial institution 14 sends an electronic message 15 using electronic device 25 to an electronic device 26 associated with the customer's financial institution 16. The electronic message 15 includes both an indication of when a payment 17 must be made, and the monetary value of the payment 17. The electronic message 15 may also include information such as the identification details of the customer 10 and/or the merchant 13 as well as the details of the accounts the customer 10 and/or the merchant 13 holds with their respective financial institutions. In response to the electronic message 15, the customer's financial institution 16 then electronically sends the payment 17 to the merchant's financial institution 14. More specifically, the payment is debited from the customer's account with the customer's financial institution 16 and is credited to the merchant's account with the merchant's financial institution 14.

[0085] Upon receipt of the payment 17, the merchant's financial institution 14 then monitors the payment schedule 1 1 for the next payment, at which time a further message 15 will be sent to the customer's financial institution 16 seeking a further payment 17. [0086] Further embodiments of the present invention allow the customer to have amendment and management capabilities described, which effects other types of payment, settlement or clearing systems and networks associated with banking systems and networks. For example, that may include but is not limited to payments that are intended to take place on BECS, SWIFT, NPPA or other fast payment systems, RTGS and credit card scheme payment systems or any other payment system that may perform recurring, repeated or pre-scheduled payments.

[0087] FIGs. 3, 4, 5, 6, 7 and 8 illustrate examples of various graphical user interfaces (GUIs) that are used by a customer to access an application programming interface (API) and alter various payment parameters, such as payment dates and payment amounts, according to an embodiment of the present invention.

[0088] FIG. 3 illustrates an example of a GUI showing a customer's debit schedule presentation on an electronic device of the customer. Details 300 of the debtor are shown as well as details 310 about the amount of the debt and terms of payment. Details 320 of the payment account used for the payments is also shown.

[0089] FIG. 4 illustrates an example of a GUI showing specific payment parameters 400 that are currently scheduled, including dates and payment amounts, in a format that the customer can manage or edit.

[0090] FIG. 5 illustrates an example of a GUI showing specific dates 500 that are available for making a specific payment. For example, if the customer selected the date "29 Oct 2018" from the dates 400 shown in FIG. 4, the dates 500 shown in FIG. 5 reflect that the particular merchant scheduled to receive a payment has authorised the customer to change that payment date to any of "29 September, 30 September, 1 October, 2 October or 3 October". Such an authorisation is implemented by the merchant designating the dates 500 as within a

predetermined acceptable value range.

[0091] FIG. 6 illustrates an example of a GUI that is displayed to the customer following the customer's selection of the date 500 of "29 SEP" on the GUI of FIG. 5. Accordingly, the customer has chosen to move the payment of $5.02 originally scheduled for 29 Oct 2018, as reflected in the payment parameters 400 shown in FIG. 4, to 29 September 2018. Thus new payment parameters 600, including the changed payment date and an associated

administrative fee of $1.10 are shown to the customer.

[0092] FIG. 7 illustrates an example of a GUI that is displayed to the customer after the customer selects the SAVE button 610 on the GUI of FIG. 6. A notice 700 is displayed that indicates that the administrative fee of $1.10 will be incurred as a result of making the payment schedule change. The customer then has the option to either cancel the payment parameter change or to proceed with the change and thus alter the scheduled payment date.

[0093] FIG. 8 illustrates an example of a GUI that is displayed to the customer after the customer selects the CHANGE DATE option from the notice 700 on the GUI of FIG. 7. A notice 800 is thus displayed to the customer and indicates that the payment parameters have been successfully updated. The updated payment parameters 810 that are now scheduled, including the changed payment date and the changed payment amount that adds the $1.10

administrative fee, are also shown.

[0094] In the present specification, the word 'comprising' and its derivatives including

'comprises' and 'comprise' include each of the stated integers but does not exclude the inclusion of one or more further integers.

[0095] Reference throughout this specification to 'one embodiment' or 'an embodiment' means that a particular feature, structure, or characteristic described in connection with the

embodiment is included in at least one embodiment of the present invention. Thus, the appearance of the phrases 'in one embodiment' or 'in an embodiment' in various places throughout this specification are not necessarily all referring to the same embodiment.

Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more combinations.

[0096] In compliance with the statute, the invention has been described in language more or less specific to structural or methodical features. It is to be understood that the invention is not limited to specific features shown or described since the means herein described comprises preferred forms of putting the invention into effect. The invention is, therefore, claimed in any of its forms or modifications within the proper scope of the appended claims (if any) appropriately interpreted by those skilled in the art.