WO2007081286A1

WO2007081286A1 - A method for providing secure billing and payment for a merchant

Info

Publication number: WO2007081286A1
Application number: PCT/SG2006/000042
Authority: WO
Inventors: Lee Chor Hwee Kelvin
Original assignee: Lee Chor Hwee Kelvin
Priority date: 2006-01-13
Filing date: 2006-03-01
Publication date: 2007-07-19
Also published as: SG134182A1

Abstract

The invention relates to a method for providing secure billing and payment for a merchant, including the steps of extracting a billing detail of a client from a billing database of the merchant, formatting the billing detail in a pre-determined format, transmitting the formatted billing detail to a database of a financial institution, mapping the formatted detail to a client's payment database account record of the financial institution; and billing the client through the client's payment account by the financial institution.

Description

A METHOD FOR PROVIDING SECURE BILLING AND PAYMENT FOR A MERCHANT

FIELD OF THE INVENTION

The invention relates to a method for providing secure billing and payment, for a merchant.

BACKGROUND OF THE INVENTION

Presently, merchant organizations, for example merchants in the hospitality industry, offer interval billing to their corporate customers. These merchants bill their clients for any goods or services that they consume at the end of a predetermined period, for example, a month. However, when payment of these bills is not made within an allowable time period, bill payment reminders are sent to these errant clients, through the merchant's accounts receivable team. These bill payment reminders are transmitted either via phone calls, or letters, which is time consuming and constitutes manpower and various resource costs to the merchants.

Unfortunately, merchants are unable to charge any accumulative interest fee although they can charge a one-time late payment fee. Therefore, any payment or fees collected late translates to interest fee loss for the merchant.

Disastrously, when these clients do not pay on time, the merchant's cash flow and liquidity is inadvertently affected.

DESCRIPTION OF FIGURES

In order that the invention might be more fully understood, embodiments of the invention will be described by way of example only, with reference to the accompanying drawings, in which: Figure 1 illustrates the prior art billing and payment flow in a merchant organisation; and

Figure 2 illustrates the method of the present invention.

The attached drawings are not necessarily drawn to scale.

SUMMARY OF THE INVENTION

According to the invention, there is provided a method for providing secure billing and payment for a merchant, including the steps of extracting a billing detail of a client from a billing database of the merchant, formatting the billing detail in a pre-determined format, transmitting the formatted billing detail to a database of a financial institution, mapping the formatted detail to a client's payment database account record of the financial institution; and billing the client through the client's payment account by the financial institution.

Preferably, the step of extracting an accounts receivable billing detail further includes uploading the billing detail to an intermediate server.

Still preferably, the step of formatting the accounts receivable detail in a predetermined format is to format the accounts receivable billing detail to an equivalent financial industrial billing and payment format.

In a preferred embodiment, the format is an Excel format.

Preferably, the step of mapping further includes formatting into a billing format to be sent to the financial institution.

In a preferred embodiment, the billing format is a standard of the financial industry. Preferably, the billing format is any one of the following formats being XML, ISO 8583 and MQ-Series.

Still preferably, a client's record of the financial institution on a server of the financial institution is uploaded into an intermediate server.

Preferably, the client's record on the server of the financial institution is tagged with a unique identifier.

Preferably, the uploaded client record on the intermediate server is tagged with a unique identifier.

Preferably, the unique identifier tagged onto the client's record on the server of the financial institution and the intermediate server is the same.

Still preferably, the unique identifier is a company registration number of the client.

Still preferably, the unique identifier allows the client's record to be identified and mapped to the intermediate server.

Preferably, the billing format is an accounts receivable data.

Still preferably, the financial institution sends invoices to clients based on the accounts receivable data.

Preferably, the payment is made from the financial institution to the merchant organization.

Still preferably, the status of payment is updated on the intermediate server.

Preferably, the status of payment is updated from the intermediate server, to the billing database of the merchant. Still preferably, the method further includes the step of security encryption from the merchant's database, to the intermediate server.

Preferably, the method further includes the step of security encryption from the intermediate server to the server of the financial institution.

Still preferably, the method further includes a user authentication.

Still preferably, the data is encrypted.

In a preferred embodiment, the financial institution is a bank.

DETAILED DESCRIPTION OF THE INVENTION

Reference will now be made in detail to the preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings. The preferred embodiments of the invention are not intended to limit the invention in its broadest aspect to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of the embodiments, numerous specific details are set forth in order to provide an understanding of the present embodiments.

Figure 1 shows the prior art system, specifically in the hospitality industry. However, it is to be understood that the method may be applied to all other industries, and references in the following paragraphs are merely for the ease of illustrating of the invention in a particular industry.

In the prior art, there is no electronic integration between the secured billing and payment of a client. In the prior art, billing is generated at the various points of sale, and is collated into the hotel property management server. The billing is then managed through the server, during the monthly consolidation of the accounts. During this time, the personnel of the merchant organisation will generate and print invoices to the clients, and outstanding bill payments are highlighted and dealt with by mailing chasers and phone calls.

Specifically, Figure 2 illustrates a method for providing secure billing and payment for a merchant, according to an embodiment of the present invention, and includes the steps of extracting a billing detail of a client from a billing database of the merchant, formatting the billing detail in a pre-determined format, transmitting the formatted billing detail to a database of a financial institution, mapping the formatted detail to a client's payment database account record of the financial institution; and billing the client through the client's payment account by the financial institution.

Extracting a billing detail

An administrator at the merchant's organization generates a list of accounts receivable records from a pre-existing Hotel Property Management Server to an intermediate server. The generation may be performed by a batch job, done on a daily basis, or at any predetermined interval of time.

The list of accounts receivable is obtained from the billing records captured at the front office cashiers, business centres, club floors as well as point of sales terminals in restaurants or other food and beverage outlets.

The administrator then uploads the accounts receivable records in data form, in an Excel file format or any pre-determined industrial standard format, such as XML (Extended Mark-up Language), for transmission to the intermediate server. In an embodiment, the generation and uploading of the accounts receivable records is automated, where the Excel file is located in a specified network drive, and a pre-programmed scheduled job then retrieves, uploads and stores the accounts receivable data from the file.

At a pre-determined time, the hotel accounts receivable data is synchronized with the intermediate server. Formatting a billing detail in a pre-determined format

Once the intermediate server completes the consolidation process of data records from the merchant organization, it starts processing the data into an accounts receivable data of a financial institution, in this illustration, a bank. These details will be exported as an Excel file (or its equivalent financial industrial billing and payment format), according to the requirements of the financial institution or bank. Once the data is formatted, this data is then sent to the bank.

Mapping the formatted detail to a client's payment database account record of the financial institution

During the processing, each accounts receivable record is matched or mapped with a bank account of the client before formatting into a message to be sent to the bank. This message is a billing format and may be in various financial industry standard formats such as XML, ISO 8583 or MQ-Series, etc. It serves as both security and compliance file transfers which a financial organisation or bank can accept into their system.

The bank accounts' information of the merchant's client is from an acquiring bank and can be in an Excel file format or any country specific financial standards such as XML or ISO 8583. The information is uploaded into the intermediate server. In order to allow the intermediate server to look up the bank account of a particular merchant's client, a common unique identifier is required to match the information given by the merchant, as well as the bank account given by the acquiring bank. A unique identifier may be generated and tagged into each record belonging to a particular client of a merchant. Or, in another embodiment, a company registration number of the client of the merchant is used, as this is a unique number officially generated for each registered company.

Alternatively, if the company registration number cannot be obtained from either the merchant or the acquiring bank, the bank accounts of the client may be maintained manually via an open account owned by the acquiring bank, based on the information provided by the acquiring bank. This may be performed by an administrator of the intermediate server. The administration will also have the option to return a non-existing account to the hotel, or lodge it with the acquiring bank's nostro account (or common account which a bank retrieves and handles information manually). This option is selective and involves manual decisions and requires labour intervention. It is therefore not preferred.

Transmitting the formatted billing detail to a database of a financial institution

Once the accounts receivable data is compiled into a list, this list is sent to the acquiring bank.

Billing client through client's payment account by the financial institution

When the acquiring bank receives the accounts receivable data, it uses this data to print and send invoices to the client. These clients are likely to be the bank's corporate customers which include the merchant hotels, and the bank can then await payment through their network of payment devices, for example, the ATM, Internet banking, mobile banking, through the bank branch, or via cheque.

At the same time, the bank makes payment to the merchant according to their payment rules, for example, within 3 days, and updates the payment status of each accounts receivable data. The bank processes the paid bank accounts receivable data and sends it to the intermediate server.

Once the intermediate server receives the paid accounts receivable data, it updates the status of the accounts receivable data within the server, and synchronizes with the database of each hotel site. The status is updated to the hotel's database in order to ensure proper audit and manage account reconciliation processes. Once the hotel accounts receivable data is updated with the payment status, an administration of the hotel is able to view the report of paid accounts receivable record, and updates the hotel's database.

Security

Due to the sensitive nature of financial transactions, security measures are necessary to ensure data security from the merchant's database, to the intermediate server, and from the intermediate server, to the server of the financial institution. A direct server to server security encryption is employed. Also, within the intermediate server, 2 level components of security exist:

1. Asset securitization client.

This refers to the client component residing in the database of the merchant's organization and performs the following functions, previously described in the method steps of the present invention: a. collecting, validating and storing the hotel accounts receivable data; b. reformatting the files of the merchant into a standard format identifiable by a financial institution; c. allowing access to an administrator of the merchant.

2. Securitization server

This refers to the server component residing in the intermediate server, for performing the following functions, previously described in the method steps of the present invention : a. consolidating and storing accounts receivable records from the merchants, for example, hotels or resorts, golf clubs, hospitals or commercial offices; b. processing the accounts receivable records into XML format, which is the format used by the financial institution; c. applying validation and business rules, segregating fee models and applicable charges for services that have been rendered by the merchant; d. sending formatted accounts receivable data to the bank; e. receiving paid accounts receivable data from the bank and updating the payment status of the data stored in the server; f. synchronizing the payment status between the securitization server and the securitization client.

Security between merchant organization and intermediate server

The accounts receivable data from the merchant's database, via the asset securitization client, and the asset securitization server of the intermediate server is first synchronized via the TCP/IP HTTP or HTTPS communication. HTTPS is preferred as SSL (Secure Socket Layer) is applied to encrypt the data transmitted over the Internet.

Security between intermediate server and financial institution

The accounts receivable data that has been provided in the agreed XML format (or any other agreed format) will be transmitted via a point-to-point JMS queue, connecting on the asset securitization server and the system of the financial institution.

To provide better security to the overall method, further security measures are available in the various points in the whole method.

Within the asset securitization client :

User authentication

A security feature to require an authentication of an administrator via a user identification and or password is required, to login to the asset securitization client database.

Encryption

Accounts receivable data may be encrypted in the database, using any of the following options : The following options may preferably be adopted :

1. AES (Advance Encryption Standard) strong encryption algorithm by the National

Institute of Standards & Technology; 2. MDSR (Multi Dimensional Space Rotation) strong encryption algorithm by Casio;

3. simple encryption, for example, obfuscation equivalence.

Between the asset securitization client, and the asset securitization server of the intermediate server, the following options may preferably be adopted :

Encryption

Transport layer security may be applied for communication between the asset securitization client and the asset securitization server. The server supports 128-bit encryption, and the following encryption technology options are available : a. Certicom encryption b. Elliptical curve encryption (ECC) c. RSA encryption

Authentication

As previously described, communication between the asset securitization client (residing on the merchant's database), and the asset securitization server, (residing on the intermediate server) is across the organization boundary, and therefore exposed to the Internet. It is extremely critical, especially in financial transactions that the client ensures that it is communicating with a valid server, and vice versa.

To prevent accidental sharing of information, with an unauthorized server, the client generates and uses a server-side digital certificate to positively identify the server it is trying to synchronize with. The encryption algorithm used in the digital certificate has to be compatible with the encryption algorithm used for the transport layer security, for example, ECC or RSA. At the same time, the server needs to authenticate the client before data transmission is allowed. Only clients with specified credentials are allowed to synchronize with the server. Once the authentication fails, the synchronization of data is aborted. Each transmitting and receiving server carries a server identity such as a series of server code, property name and serial number. The authentication is recognised through a secure VPN (Virtual Private Network) or broadband line, which is solely established for each server located at a merchant's site.

Asset securitization server

Authentication

An administrator of the intermediate server will have to login using secured identification and password to gain access to the server.

Authorization

Layers of security may be provided, for different levels of administrators. These different layers will then provide different access rights, to perform different cases, which will be described later.

Encryption

The accounts receivable data and the customer's bank accounts can be encrypted in the database using AES strong encryption algorithm. The data can be encrypted based on columns.

Between the asset securitisation server and the financial institution system

It is preferred that the connection between the asset securitisation server of the intermediate server and the bank's system is via a leased line VPN connection.

Authentication & Authorization

With VPN connection, the server authenticates the client trying to reconnect to it for message delivery, depending on the direction of message delivery. The message delivery is a batch file upload delivery and is initiated by the Asset Securitisation Server. The receiving bank server will act as a recipient to accept the billing and payment messages generated

Encryption

VPN automatically encrypts all traffic travelling over the communication channel. Besides that, MAC (Machine Authentication Communication) or digital signature may also be applied to ensure that the messages sent across are not altered.

These security measures may be selectively adopted, or used in totality, in the application of the present invention.

The data required for the present invention are as follows:

1. Corporate customers' bank account details

These details should be provided by the bank to the intermediate server, in the form of an Excel file format, or any other pre-agreed format. This information is then uploaded by the intermediate server, to the asset securitisation server. The data is used during the processing of consolidated accounts receivable data into the format that the bank requires.

During the data transformation, the intermediate server will map the unique identified, for example, the company registration number, in the consolidated accounts receivable data against the company registration number in the bank customer's account, in order to get the bank account details.

The examples of bank account details include corporate customer name, company registration number, corporate bank account number, corporate bank account branch code, corporate bank account bank code, and corporate customer address(es).

2. Accounts receivable data These data are exported from the hotel's server into an excel or pre-agreed format, and uploaded to the database in the asset securitisation client. This data includes transaction date and time, company name, company registration number, guest name, accounts receivable number, folio or invoice number, room number, department, transaction amount, and cash ID.

This data is stored in the asset securitisation client, after the upload of the excel file into the asset securitisation client.

Consolidated accounts receivable data

This data is stored in the asset securitization server, after the accounts receivable data are synchronized from the asset securitization client to the server. This data include merchant ID, transaction date and time, company name and registration number, guest name, accounts receivable number, folio number, room number, department, transaction amount, batch reference number (to identify the batch that this record was sent to the bank), and upload date, which is the date registered when the record was processed and sent to the bank.

Bank accounts receivable data This data is formatted by the asset securitisation server, and is sent to the acquiring bank in an XML format, or any other format according to the requirements of the bank, for example, ISO8583. The header data, identifying the entity, includes part identifier, payment type, debit account number, batch reference number, effective date, customer branch number, total credit items, total debut amount, charges for account of beneficiary.

The child record data, identifying the detailed components within an entity, include part identifier, transaction reference number, which uniquely identifies the accounts receivable data sent to the bank (and may consist of the merchant ID registered in the intermediate server, suffixed by the folio or invoice number in the hotel accounts receivable data), amount, payee and payee address(es), account number, beneficiary reference number, personal ID, branch code, bank number, details (for example, who or for what purpose the invoice is issued to the client), tax ID, attachment sub-file, advice mode, fax number, e-mail ID, total invoice amount before tax, total tax deducted, total invoice amount after tax, and tax information count.

Paid accounts receivable data

This data is formatted by the acquiring bank and is sent to the intermediate server in an XML format, or ISO8583 format, according to what was previously agreed. This data is similar to the accounts receivable data, except that it registers the payment status and payment date to the asset securitisation server.

Examples of the header record include part identifier, bank reference number, batch reference number, debit account number, total debit amount and currency, total credit items, transaction date, effective date, upload date and import file name. Examples of child record data include part identifier, credit detail number, payee name, credit amount and currency, payee bank and branch code, beneficiary reference number, processing status (indicating the processing status of the accounts receivable data), processing status description, output reference number, paid date indicating the payment date of the accounts receivable data, debit date and remarks.

With the method and architecture of the present invention, the following functions may be performed :

Administrator at merchant organization

1. Upload Hotel Accounts Receivable Data

The hotel billings records are captured at the front office cashiers, business centers, club floors as well as the Point of Sales terminals in the restaurants. These hotel accounts receivable records will be consolidated into the Hotel Property Management Server at the end of each day, which will later be exported to asset securitization client where the hotel's account receivables details will be exported as an Excel file (or its equivalent industrial worksheet format). The administrator at the hotel will upload the data from the converted Excel file into the Asset Securitisation Application at the intermediate server. 2. Query & View Reports

The hotel administrator can query and view reports in Asset Securitisation Application based on a specified date range. The reports may be related to the:

• Hotel accounts receivable records uploaded to the system; and

• Hotel accounts receivable records for which the payment has been made to the bank

3. Clear Paid Accounts Receivable Data

The administrator can clear the paid accounts receivable records based on a specified date range, when prompted by the bank.

Administrator at intermediate server

1. Upload Corporate Customers' Bank Accounts

When the hotel accounts receivable data are consolidated from the merchant's organization in the system, the data will be processed, such that the hotel clients' bank accounts, validation rules as well as various fee models in the acquiring bank will be appended to the data, before sending to the bank for payment collection.

The acquiring bank can provide its corporate customers' bank accounts in batches, and the administrator can upload the information into the system for use during the processing of the accounts receivable data.

2. Maintain Corporate Customers' Bank Accounts The system administrator maintains the corporate customers' bank accounts lodged by the bank and hotel with the intermediates server on an ad-hoc basis whenever required.

3. Maintain Merchant's Information

The intermediate server administrator maintains the information about the merchants that uses the service of intermediate server, for example, the name of the hotel, the company registration number of the hotel and the bank account of the hotel in the acquiring bank.

4. Maintain Fee Model

The intermediate server administrator maintains a fee model, agreed between the hotel, the acquiring bank and the PSP, for each merchant or merchant group.

5. Maintain Intermediate Server Company Information

The intermediate server administrator maintains the company information of intermediate server, specifically the intermediate server's bank account number in the acquiring bank. This information is required for crediting the intermediate server's bank account with the fee earned from the transaction processing.

6. Query & View Reports

The hotel and intermediate server administrators can query and view reports in the Asset Securitisation system based on a specified date range. The reports may be related to the:

• Hotel accounts receivable records that are received from the merchant's organization • Hotel accounts receivable records that are processed and sent to the acquiring bank

• Hotel accounts receivable records that fail to be sent to the acquiring bank, due to no matching bank account found in the system • Fee earned by the intermediate server and the bank.

The hotel and bank administrators can query and view reports using a mobile device to monitor the status of the transaction processing, or to check the income status of the intermediate server, anytime and anywhere.

Authentication and authorization methods may be applied if there are different administrator groups that may have different access levels.

The embodiments have been advanced by way of example only, and modifications are possible within the scope of the invention as defined by the appended claims.

Claims

1. A method for providing secure billing and payment for a merchant, including the steps of extracting a billing detail of a client from a billing database of the merchant; formatting the billing detail in a pre-determined format; transmitting the formatted billing detail to a database of a financial institution; mapping the formatted detail to a client's payment database account record of the financial institution; and billing the client through the client's payment account by the financial institution.

2. A method for providing secure billing and payment for a merchant according to claim 1, wherein the step of extracting an accounts receivable billing detail further includes uploading the billing detail to an intermediate server.

3. A method for providing secure billing and payment for a merchant according to claim 1 , wherein the step of formatting the accounts receivable detail in a predetermined format is to format the accounts receivable billing detail to an equivalent financial industrial billing and payment format.

4. A method for providing secure billing and payment for a merchant according to claim 3, wherein the format is an Excel format.

5. A method for providing secure billing and payment for a merchant according to any one of the preceding claims, wherein the step of mapping further includes formatting into a billing format to be sent to the financial institution.

6. A method for providing secure billing and payment for a merchant according to any one of the preceding claims, wherein the billing format is a standard of the financial industry.

7. A method for providing secure billing and payment for a merchant according to claim 6, wherein the billing format is any one of the following formats being XML, ISO 8583 and MQ-Series.

8. A method for providing secure billing and payment for a merchant according to any of the preceding claims, wherein a client's record of the financial institution on a server of the financial institution is uploaded into an intermediate server.

9. A method for providing secure billing and payment for a merchant according to claim 8, wherein the client's record on the server of the financial institution is tagged with a unique identifier.

10. A method for providing secure billing and payment for a merchant according to claim 9, wherein the uploaded client record on the intermediate server is tagged with a unique identifier.

11. A method for providing secure billing and payment for a merchant according to any one of claims 8 or 9, wherein the unique identifier tagged onto the client's record on the server of the financial institution and the intermediate server is the same.

12. A method for providing secure billing and payment for a merchant according to claim 11 , wherein the unique identifier is a company registration number of the client.

13. A method for providing secure billing and payment for a merchant according to any one of the claims 1, 5 to 12, wherein the unique identifier allows the client's record to be identified and mapped to the intermediate server.

14. A method for providing secure billing and payment for a merchant according to claim 5, wherein the billing format is an accounts receivable data.

15. A method for providing secure billing and payment for a merchant according to any one of the preceding claims, wherein the financial institution sends invoices to clients based on the accounts receivable data.

16. A method for providing secure billing and payment for a merchant according to claim 15, wherein the payment is made from the financial institution to the merchant organization.

17. A method for providing secure billing and payment for a merchant according to claim 15 or 16, wherein the status of payment is updated on the intermediate server.

18. A method for providing secure billing and payment for a merchant according to claim 17, wherein the status of payment is updated from the intermediate server, to the billing database of the merchant.

19. A method for providing secure billing and payment for a merchant according to any one of the preceding claims, wherein the method further includes the step of security encryption from the merchant's database, to the intermediate server.

20. A method for providing secure billing and payment for a merchant according to any one of the preceding claims, wherein the method further includes the step of security encryption from the intermediate server to the server of the financial institution.

21. A method for providing secure billing and payment for a merchant according to any one of the preceding claims, wherein the method further includes a user authentication.

22. A method for providing secure billing and payment for a merchant according to any one of the preceding claims wherein the data is encrypted.

23. A method for providing secure billing and payment for a merchant according to any one of the preceding claims wherein the financial institution is a bank.