1. A transaction processing system for processing plurality of distinct transactions and cards on single platform, said system comprising a. plurality of billing and/or payment terminals connected to processing assembly; b. processing module consisting i. terminal driver switch being configured to drive at least one billing and/or payment terminal and to recognize origin of transaction; and ii. interchange switch being adopted for distinguishing between different types of transactions and route them based on predefined attributes of the transaction; c. closed group card server connected to processing module and is being configured to authorize predetermined transactions; and d. card management module and reporting module.

2. The system as claimed in claim 1, wherein the billing and/or payment terminal is selected from group comprising POS terminal, WEB interface, IVR interface mobile interface, EDC machines and combinations thereof.

3. The system as claimed in claim 1, wherein the terminal driver switch recognizes the transactions received for processing from unregistered terminals and/or unauthorized terminals and/or blocked terminals and takes appropriate actions by responding with appropriate response; preferably rejects such transactions.

4. The system as claimed in claim 1, wherein the terminal driver switch interacts with database having terminal related data information and/or front end software knowledge and capable of taking business decisions.

5. The system as claimed in claim 4, wherein user is allowed to change or add terminal data information through web interface and the terminal driver switch is capable to work as per changed and/or added terminal details without stopping the processing system.

6. The system as claimed in claim 1, wherein the interchange switch routes the transactions based on attributes selected from group comprising Bin number, Date Time, Geography, Reliability, customized merchant specific rules and combinations thereof.

7. The system as claimed in claim 1, wherein the interchange switch is tightly coupled with database server that provides subsequent information to whom a given transaction needs to be sent.

8. The system as claimed in clam 1, wherein the system allows the user to access client side log at the centralized location and said system prompts client side interface based on preconfigured rules for sending the logs with subsequent transaction incoming request.

9. The system as claimed in claim 1, wherein the system is capable of remotely monitoring health of the billing and/or payment terminals from a centralized location and suggest preventive actions to rectify problems before failure at billing and/or payment terminals,

10. The system as claimed in claim 1, wherein the system comprises merchant fraud detection module for detecting fraud transaction at merchant end in real time and said enables the merchant to define predefined parameter for fraud detection module through web interface.

11. The system as claimed in claim 1, wherein the system facilitates the merchant to enable and define different discount schemes based plurality of parameters selected from a group comprising merchant business establishment, time date, issuer card identifier, billing amount and payment amount, and combinations thereof.

12. The system as claimed in claim 1, wherein the closed group card server is integrated with mobile network and web interface for sending transaction related details and/or alerts including marketing message to their customers on any kind of actions,

13. The system as claimed in claim 1, wherein the closed group card server is being configured to manage and authorize transactions selected from a group comprising pre paid, gift coupons, coupons and loyalty.

14. The system as claimed in claim 1, where in reporting module provides comprehensive reports based on merchant based establishment and predefined parameters,

15. A method of processing plurality of distinct transactions and cards on single platform, said method comprising steps of; i. initiating request for processing a transaction by at least one billing terminal to processing module; ii. determining origin of the transaction and recognizing the validity of the transaction by terminal driver switch; iii. determining the fraud probability and taking action based on the result; and thereafter determining the discount rules applicable based on the predefined discount parameters and applying them on the transaction; iv. distinguishing between different types of transaction and forwarding the valid transaction based on predefined attributes of the transaction to acquirer for authorization; v. transmitting acknowledgment packet to the billing terminal for determining status of the terminal before sending transaction request approval messages received from the acquirer; and vi. awaits acknowledgment from the billing terminal and as per the status of acknowledgment it proceeds with the transaction in case of success and in case of failure automatic reversal of the transaction; and vii. sending approved transaction response to the terminal after receiving response to the acknowledgment packet for processing plurality of distinct transactions and cards on single platform.

16. The method as claimed in claim 15, wherein the method enables settling of transactions with bank host to conclude the transactions by invoking settlement with the host for all billing and/or payment terminals from a central location, without any intervention of the front-end terminals themselves.

17. The method as claimed in claim 16, wherein report of passed or failed settlement attempt is generated if repeated attempts at settlement of failed terminal settlements exceeds predefined repeat limit.

18. The method as claimed in claim 16, wherein settling of transactions with plurality of acquirer is performed simultaneously.

19. The method as claimed in claim 15, wherein processing of transaction includes detecting potential card holder or merchant fraud being carried out at the terminal to prevent misuse of the card and/or merchant acquiring facility, comprising steps of: a. detecting if the card being swiped has been swiped in a different geography or multiple times in a pre-defined interval; b. detecting if the same card is being used in the same merchant location repeatedly; and c. detecting if the card number printed on the card matches with the card number printed in the magnetic stripe of the card.

20. The method as claimed in claim 15, wherein the processing of transaction comprises transactions of different types selected from a group comprising card based financial transaction, non-card based financial transaction, card based non financial transaction and non-card based non financial transaction.

FIELD OF THE INVENTION

The present invention relates to processing all kinds of card and non-card based financial and non financial transactions through a single platform. In particularly, it is related to unique arrangements of switch, authorisation module, card management module and reporting module which ultimately result in low investment cost in transaction processing infrastructure and hassle free integration with the various types of authorisation entities.

BACKGROUND OF THE INVENTION

In typical scenario, at merchant locations, it is possible to find two or more types of front end interfaces. First, billing interface which is normally used to create/generate item's detail description (a typical item bill). Second a POS (point of Sale) terminal (provided by specific bank) for facilitating financial transaction, Any additional machine/machines for their Loyalty, Prepaid and Gift Coupon transactions.

Imagine a situation where a customer wants to use cash, credit card and loyalty points to accomplish a particular purchase. Merchant location attendant have to interact with three or more types of interfaces to perform such transaction.

Consider one more situation, a merchant has Acquirer EDC terminal at his location and due to some merchant and Acquirer conflict, bank stop accepting transactions from that particular POS terminal temporarily. This results in loss of merchant business for that period of time.

Consider another situation; a merchant wants to save commission value on a financial transaction, so he installs two or more different bank POS terminals. Based on the card type and card issuer, merchant location attendant swaps card accordingly.

At the end of the day, merchant have to do EOD or settlement for each of installed POS terminal. This becomes worse when merchant establishment locations are discrete and of high number,

Also to facilitate non-cash financial transaction at any business establishments, merchants have to make business arrangement with one or more entities which process and authorises non-cash payment tenders. The whole process involve renting/owning a EDC terminal (provided by the transaction authorization entities) and in return merchant pays commission charges per transaction or lump-sum amount and maintenance fees for the EDC terminal. In the current scenario, many third parties or the financial institutions (like banks) are involved in the transaction authorisation. These Transaction Authorisation Entities are also involved in issuing credit/debit cards on their own or in behalf of some financial institutions (like banks). These Transaction Authorisation Entities works on different business models which makes merchant confused because every Financial Transaction Authorisation Entity's business model have some pros and cons in terms of business arrangement. For example if Transaction Authorisation Entity and card issued from a entity is same, then commission charges on the transaction is less than if both entities are different. Above cited example is the common problem for most of merchants. Merchants also find a solution of the above-cited problem in a unique way. Based on their experience, they get somewhat an idea (for small merchants who don't have sophisticated Business Intelligent Tools) or an exact estimate (for merchant who have Business Intelligence Tools) that which cards or type of cards does customer for purchases mostly use. On the basis of above intelligence, merchants make arrangements with more than one Transaction Authorisation Entities.

As we know that customers purchase behavior is not static but dynamic of very high degree, so merchant has to change according to the customer purchase dynamics very frequently. It simply implies that merchant have to either discontinue or make new business arrangements with one or more Transaction Authorisation Entities repeatedly which is practically impossible. This ultimately results in loss of revenue.

More over if merchants also want to accept non-financial tenders then these Financial Transaction Authorisation Entity are not helpful Ultimately the solution left with merchant is either they establish their own IT infrastructure or take readymade solution from third party provider. Most of the merchant don't have sophisticated IT infrastructure, so they go with the third party provider for maintaining and processing non financial payment tenders.

The end result is that merchant ties up with one or more Financial Transaction Authorisation Entities and third party providers for accepting financial and non-financial payment tenders. To maintain the harmony in merchant's account books, merchant needs to couple all kinds of authorisation entities. But to do this manually is neither cost effective nor efficient. More over it is error prone.

The basic problem in this domain is that all kinds of transactions (cash, financial cards, on financial cards transactions) are treated in isolation. Financial Transaction Authorisation Entities don't want to take care of processing non-financial transaction. The reasons may be govt regulations, their mind set towards transaction processing, financial issues etc. Also third party software providers (for authorizing non financial transactions) are unable or not willing to process financial payment tenders. The reasons for this are govt regulations, lack of knowledge of transaction processing domain, technology limitations, liability issues etc.

Ultimately if we boil down all above discussion then at present no one sees financial and non financial transactions in harmony and not ready to provide single platform for processing all kinds of transaction. Currently there is no integrated solutions present in the market that processing all kinds of transactions and provide comprehensive Business Intelligence solutions to the merchant.

Limitations of Current System in a nutshell

1. Customer service time increases if customer mode of payment is more than one.

2. Customer delight factor goes off as service time increases.

3. Dependency on single Financial Transaction Authorisation Entity is itself risk prone.

4. Managing more than one Acquirer EDC terminal is costly.

5. EOD or settlement is time consuming and cumbersome if any discrepancy occurs.

6. Non Centralized Payment system is difficult to manage.

7. Reconciliation is cumbersome, if merchant runs loyalty, prepaid and gift coupon programs.

Existing Payment Architectures are defined herein below along with their advantages and limitations:

• Current Cr/Dr Authorization Mechanism

In current scenario, a merchant has to keep Billing Software for Invoice generation and supply chain management and EDC terminal for financial tender payment authorisation. Every time on customer purchase instance, merchant location attendant has to swap the credit card at billing software and at EDC, both to accomplish a single transaction.

After swiping card on Billing Software, all purchase related details (items details, mode of payment etc) are captured and stored for taking business related decisions. Next if mode of payment is card, then merchant location attendant swipes card one more time on the EDC Terminal for authorisation. As number of types of payment tender increases, proportionally numbers of swipe also get increases. As shown in Figure 1, after swiping on the EDC terminal, financial transaction hits either acquiring bank of the card or the third party processor of the acquiring bank. The financial transaction is then routed to their respective payment scheme host. Payment Scheme Host then route financial transaction to the Card Issuer. Here transaction actually gets authorize and returns back to the EDC terminal following the same incoming route.

At the end of day* there is a notion of settlement process that is actually a reconciliation process between EDC terminal and Acquiring bank or the third party processor of the Acquiring bank. Figure 2 gives arrangement overview of EDC terminal, acquiring bank/third party transaction processor, payment scheme and card issuer entity ,in case of settlement process.

Pros:

1. Architecture is simple, no extra IT cost needed for integration with the current system.
2. As EDC is maintain by the Third Party, no need have expertise is EDC maintenance.

Cons:

1. Time taken to process one complete purchase is more. Generally, number of billing counters is more than the number of EDC then purchase processing time further increases.

2. In case of Dual swap (one for generating item invoice ,second for processing
transaction),

a. Reconciliation is needed for each item invoice and merchant transaction slip.

b. More prone to human error as merchant location has to enter amount
manually at EDC

3. If transaction is OFF -US, then transaction commission fees increases,

4. Payment process is not centralized; hence maintainability is difficult for large retailers.

a. If merchant location attendant forget to do settlement on the same day,
merchant money got struck for more than T+l days.

b. In case of any dispute, resolution of the matter is difficult in fragmented type
of system.

c. Each bank EDC terminal needs a separate communication link with the authorizes For large retailers who acquire multiple EDC terminals of different banks have to incur extra cost for communication.

5. If merchant install more than one bank EDC for saving commission fees, still there is no assurance which terminal is used by the merchant location attendant. The whole purpose of acquiring multiple EDC defeats if attendant is insensitive with the aim of having multiple EDC.

• Existing Loyalty Program

Typically merchants don't have sophisticated IT infrastructure for their Loyalty Program. At the end of the day, information like purchase amount, loyalty card details have been sent to Loyalty Department where points are calculated on the basis of card type and invoice details and updated file details are sent back to store again.

Redemption process is through coupon generation and distribution to customers. Again a whole cycle has to be repeated for coupon management. If redemption process is online then it is through sophisticated customer care dedicated to Loyalty program only.

If somehow merchant built sophisticated IT capability to process loyalty based transactions online but one major problem still exists that Loyalty System is still a standalone system and not integrated with current financial transaction processing platform.

Pros:

1. No or little IT investment and knowledge.

2. Can easily be outsourced, hence management hassles are less.

Cons:

1. Considerable time lag to get the updated information about the current point status of a given customer. This ultimately reduces the impact of points awarded to customer.

2. As redemption is through gift coupon, time taken to redeem points is more results in customer irritation and loss in interest to the loyalty program,

3. Often customer actually has more points then balance shows on the item invoice so customer never able to redeem his/her full points.

4. Investment needed to set up dedicated customer care for Loyalty Management.

5. As this process in separate from actual financial transaction, accountancy is difficult and cumbersome.

6. As merchant don't have updated customer loyalty information access, there by not able to offer on the spot marketing offers.

■ Existing Coupon Program

In the current scenario, coupons are generated and distributed to the customer. When a customer wants to utilize his/her coupon on a particular purchase, merchant location attendant punches /cross the coupon to make it void for reuse. Now it gets adjusted in the customer current purchase.

For reconciliation, store manager collects the entire coupon and send to their accountancy department.

Here manually coupon management has been done.

Pros:

1. No IT investment needed.
2. No IT sophistication has been needed, as it is not integrated with current system,

Cons:

1. More fraud prone as there is no online authorisation of the coupon.
2. Need to manage coupon at sore level also.
3. Transportation cost of coupon to the centralised location (may be accountancy department). This problem further intensifies if store locations are distributed along several locations.
4. Reconciliation effort is more.

• Existing Pre Paid Program

For accepting Pre Paid cards, merchant has to install new machine and has to set up new switch and terminal. When a customer wants to use his/her prepaid cards, merchant location attendant has to swipe pre paid on to a different kind of machine/hardware.

At the EOD, merchant location attendant has to do settlement with authorisation server in a similar fashion as in case of financial transactions

Pros:
1. Improved cash flow, higher stickiness.
2. Higher return on investment.
3. Ability to launch many marketing programs based on the pre paid accumulated rich customer data.

Cons:
1. Such kind of infrastructure needs considerable amount of investment.
2. During settlement same kind of problem occurs as we discuss in section 2.1.
3. To make prepaid program online, they need to replicate almost banking web based application.
4. No card management capability that is the soul of any marketing decision for the customers.

• Existing Merchant Discount System

In the current scenario, the merchant discount systems are either manual or implemented by Card Issuer through cash back. The discount offered on payment is applicable on some selected range of Issuer cards.

In case of manual, at the time of billing the merchant location attendant manually selects customer card type. Based on the merchant location attendant selection, discount is offered to customer on the bill. The merchant location attendant then proceeds with the payment authorization. Manual selection of customer card type opens a window for fraud. At the EOD, the merchant location attendant has to calculate the total discount offered to customer and do a settlement with the respective Issuer bank.

In case of discount implemented by Card Issuer, the customer is billed for the total bill value without any discount during the billing. The customer has to pay the entire amount. Post the EOD process the issuer calculates discount based on the account type and the merchant followed by cash back to the customer. This entire process is manual, time consuming and cumbersome.

Pros:
1. Improved customer experience.
2. Higher usage of Issuer's Card.

Cons:

1. Highly prone to fraud.
2. During settlement, reconciliation issue with the Issuer Bank.
3. Lesser accountability of the campaign hence leading to incorrect data for further analysis.
4. Customer money blocked till the Issuer gives the cash back.

OBJECTS OF THE INVENTION

The primary object of the present invention is to take care of/overcome multiple EDCs problems as discussed above.

Yet another object of the present invention is to get rid of problem of acquiring and maintaining multiple banks EDC terminal.

Still another object of the invention is to make settlement process automatic and centralized to rule out any payment related issues include delays, disputes.

Still another object of the present invention avoids training merchant location attendant when to use which bank POS terminal for processing a purchase,

Still another object of the present invention is to provide all kind of transaction related data at the centralized location which makes accountancy easy.

Still another object of the present invention is to provide a single interface for item invoice generation and transaction processing without changing the existing billing front-end interface.

Still another objective is to integrate all modes of payment (gift coupons, prepaid, loyalty, and credit/debit cards) through a single interface and provide hassle free settlement process and reconciliation for all modes of payment.
Still another objective is to provide a common platform for different customer interfaces for payment, namely, POS Terminal, Web Interface, IVR Interface, Mobile Interface and similar interfaces.

Still another objective is to improve customer experience during a purchase that is the most important key for any successful business set-up.

In current set-up, all these mode of payment, gift coupon, loyalty etc, are fraud prone as they are offline, so by utilizing the existing online capabilities, objective of instant invention is to make all kinds of mode of transaction online and 100% fraud free.

BRIEF DESCRIPTION OF ACCOMPANYING DRAWINGS

Figure 1 shows Current Cr/Dr Authorization Mechanism

Figure 2 shows current Settlement Mechanism

Figure 3 shows Existing Loyalty Program

Figure 4 shows Existing Pre Paid Program

Figure 5 shows possible architecture of the transaction processing system (UniPAY).

Figure 6 shows settlement process architecture with the different Acquiring Banks.

Figure 7 Shows architecture for other mode of transaction other than credit/debit card.

Figure 8 Shows part of overall architecture for non financial transaction process

Figure 9 shows module wise architecture details and their interaction with each other.

Figure 10 shows placement of different modules and interfaces with respect to database layer.

Figure 11 shows encryption technique used widely.

Figure 12 shows work flow of encryption technique used in invention.

Figure 13 shows work flow of another encryption technique used in invention.

Figure 14 shows two conditions when EDC (in existing arrangement) sends reversal to the authorisation server.

Figure 15 shows condition/s when current invention sends reversal to authorisation host.

Figure 16 shows transaction flow in current invention.
Figure 17 shows transaction flow in current invention when front-end application becomes unresponsive.

Figure 18 shows transaction flow in current invention when either authorisation server becomes unresponsive or network connection between authorisation server and Innoviti uniPAY Processing Platform is down.

Figure 19 shows network arrangement between front-end application and Innoviti uniPAY Processing Platform through a router.

Figure 20 shows part of code used for implementing automatic reversal,

Figure 21 shows rule matrix used for routing a transaction.

Figure 22 shows relationship matrix between receipts related parameters and terminal number.

Figure 23 shows workflow of a transaction and sequence of different modules called during process a transaction.

Figure 24 shows workflow for configuration of different modules of Innoviti UniPAY Processing platform

Figure 25 shows workflow of non financial transaction process

Figure 26 shows overview of the settlement process taking Innoviti UniPAY Processing platform as starting point.

Figure 27 shows flow of settlement process and sequence of different modules called.

Figure 28 shows relationship matrix between different transactions related parameters and acquirers.

Figure 29 shows work flow of Merchant Fraud Detection System.

DETAILED DESCRIPTION OF THE INVENTION

The primary and most important feature of the invention is that it completely removes multiple bank EDCs at merchant establishment and provide a single interface for processing all kinds of transactions for different banks.

The present invention relates to process all kinds of card and non-card based financial and non financial transactions through a single platform, This invention includes unique
arrangements of switch, authorisation module, card management module and reporting module which ultimately result in low investment cost in transaction processing infrastructure and hassle free integration with the various types of authorisation entities.
This invention prevents merchant to make investment, for processing different kind of transactions and cards (may be of different types or of different banks) repeatedly. Further it allows merchant to knock off different kinds of front end softwares/hardwares to process their financial and non financial transactions. As this invention can process data initiating from any kind of front end application, so it provides easy and hassle free integration with merchant*s current billing machine* This invention include methods and algorithm for routing financial and non financial transactions based on the nature of the transaction (nature may be decide on the basis of type of transaction or may be on the basis of unique identity related to that transaction),

This invention is also capable of capturing customer related activities and data from the merchant location which provides logical conclusions to improve the returns on their market investments. This invention uses financial transaction data intelligently to launch programs for non financial type of transaction which ultimately results, increase in market share.

Figure 5 shows detailed description of the invention architecture and its different components in detail. Every front end software is provided with a unique number which is the identity of that front end application. Along with the transaction related details, front end software also sends this unique number to the transaction processing system hereinafter referred as Innoviti uniPAY Processing Platform. As per Figure 5, transactions are initiated at the billing terminal or pos terminal and hit Innoviti uniPAY Processing Platform and then it goes to the subsequent authorisation server,

Innoviti uniPAY Processing Platform has the capability to distinguish between different types of transaction and route them accordingly. Figure 5 also shows various user/customer interaction points with the Innoviti uniPAY Processing Platform and UniPAY Closed-group cards Server. These are web interface i.e. internet, mobile network and all types of merchant end billing software.

Various kinds of rules (e.g. routing rules, blocking rules etc) can be configured at Innoviti uniPAY Processing Platform which ultimately helps in perform above action.

Detailed description of each section of the figure 5 is given below. Along with, it also describes various features and methodology of implementation which makes this product unique.

1. Retail Stores: It is assumed that POS Terminal capability is already there with the merchant without EDC features. In addition to this, it is also assumed that WEB, IVR, MOBILE interfaces exits.

2. Innoviti Terminal Driver Switch: This component actually drives the POS terminal .All POS terminal related details are stored here. This component recognizes the origin of the transaction and take appropriate actions which are as follows:
o If unregistered/unauthorized terminal sent a transaction for processing, it rejects it.
o If the terminal is blocked for n kinds or type of transactions, it takes appropriate actions and rejects the transaction.

At the switch level, we have enough flexibility to add a new terminal with in a short span, At present, the switch does not interact with the database. But primary embodiment of the current architecture is shown in figure 9. Terminal switch has interaction with the database, which ultimately means that if database layer have terminal/front end software knowledge then on the basis of the terminal related data, Terminal Switch is able to take business decisions. Figure 11 show that web interface layer has been placed in conjunction with the database layer. If we saw figure 9 and 10 in a holistic manner then we must conclude that Terminal Switch can respond as per changes in the web interface layer i.e. Terminal Switch can use information provided by the web interface for taking business decisions. This above described arrangement among database layer, terminal switch and web interface layer makes possible to add or edit terminal related information
within a short span. Merchant/customer/user can change/add terminal related information through web interface and Terminal Switch can start working as per changed terminal details without stopping the current system. This facilitates easy addition or installation /removal of terminal/billing software with the Innoviti uniPAY Processing Platform,

3. Innoviti Interchange Switch: This component is the heart of the invention. It is place where all business logic resides. This component has a capability to distinguish between the different types of transactions and process accordingly. Some key features of this component are:

Auto Reversal Mechanism:

> Current Situation: In current EDC machine, reversal will be done only on one situation when EDC don't receive any response of the sent transaction. This shown in CASE 1 of figure 14. But the problem is that there is no point in sending reversal when the transaction is not received at the host end but this type of intelligence is not there in the current EDC machines. This is shown in CASE 2 of figure 14. This ultimately results unnecessary load on the network and at the authorisation server end.

> Innoviti Approach: Innoviti first time implement TCP/IP fundamentals in transaction processing domain. At each and every stage while sending transaction packet Innoviti UniPAY Processing Platform knows whether the send is successful or not.
Innoviti also send Acknowledgment packet to the Billing Software /Front End to know whether connection with Front end is still alive or not. The primary embodiment of this feature is illustrated in figure 16.Brief description of the figure is given below:
Step 1: Billing Software/Front End sends request for processing a transaction to the Innoviti UniPAY Processing Platform.

Step 2: Innoviti UniPAY Processing Platform transforms the transaction request on the basis of Business Logics and send to the Acquirer.

Step 3: Acquirer send response of the transaction to the Innoviti UniPAY Processing Platform.

Step 4: Innoviti UniPAY Processing Platform receives from Acquirer and before sending transaction request approval back to the Billing Software/Front End; Innoviti UniPAY
Processing Platform sends an Acknowledgement packet to the Billing Software to know whether Billing Software is ready /connected to receive transaction response,

Step 5: Billing Software/Front End send Acknowledgement packet response to Innoviti UniPAY Processing Platform.

Step 6: After receiving Acknowledgement packet response, Innoviti UniPAY Processing Platform sends back the approved transaction response to the Billing Software/Front End.

o Advantages of above approach

■ If the transactions fail while sending to the Acquirer, Innoviti UniPAY Processing Platform will not send unnecessary reversal packet for a given transaction as we use TCP/IP socket level programming fundamentals for taking business decisions. Programming level details are shown in figure 20.

■ If Billing Software/Front End is connected to the Innoviti UniPAY Processing Platform through router and we remove network cable from the POS terminal then in this case according to TCP/IP, connection is still established. But actually it is not. This is shown in figure 19. So by implementing the approach as shown in figure 16 we can generate Auto Reversal which is shown in figure 17 and figure 18.

o Route Transaction based on the nature of Transaction: Innoviti Interchange Switch can route transactions based on the following attributes of the transaction. We have developed a rule matrix that is used for routing transactions based on their nature. Matrix structure is given in figure 21.This matrix configuration can be changed through web interface in runtime i.e. during live transaction scenario.

■ Bin Number Based: Innoviti Interchange Switch is tightly coupled with the
database server that provides subsequent information to whom we have to send a given transaction. We have design database in such a manner so that we get one to one relationship for bin range and server address. Above arrangement of database also enable us to route transaction not only on the basis of bin range but also on the basis of specific bin range.

■ Date Time Based: As we already mentioned that Innoviti Interchange Switch is tightly coupled with database server so we also have one to one relationship for bin range/bin number and date time. This ultimately means we have relationship among bin range/bin number, server address and date time (bin range and server address relationship is discussed in above point "Bin Number Based"). Every time while routing a transaction we check the configured date time also while sending a transaction. This above arrangement is detailed out with the live scenario example given below.

Example: Suppose a merchant have authorisation arrangement with two acquirers i.e. Acquirer A and Acquirer B. Now merchant wants that for 9:00 am to 2:00 pm all transactions will be authorise by Acquirer A and from 2:00 pm till 10:00 pm, all transactions will be authorise by Acquirer B.

■ Geography Based: This feature provide flexibility to route transaction based on the location of the Billing Software. Innoviti Interchange Switch have knowledge of each billing software location. Each of these are mapped to a merchant defined geographical hierarchy and business establishment hierarchy. Based on the rule matrix as described in figure 21, Innoviti Interchange Switch will route the transaction as per matrix configuration.

■ Reliability Based: This feature provide merchant less response time of a transaction and better success rate of each transaction (if transaction failed because of network congestion or heavy load on Acquiring Host Servers).Innoviti Interchange Switch contains all information about a transaction. Innvoviti Interchange Switch calculate Reliability Scores for each Acquiring Host for each Day of a week and for different time periods. Like Friday Between 6 pm to 9 pm Jnnoviti Interchange Switch calculates scores for each Acuiring Host. Based on the Reliability Scores, merchant have a flexibility to define routing rules based on the Day of the weeks or for a given time period or combination of both.

■ Customized Merchant Specific Rules: Rule Matrix as shown if figure 21, can be superseded if merchant wants to route transactions according to their business arrangement with the Acquirer. One example can be if merchants have long term association with two different acquirers and merchant wants that 80 % of the transaction will authorise by the one acquirer and rest 20 % with another acquirer. As shown in figure 24, Routing Rules Module is coupled with web layer, so merchant can configure his/her rules through web while the transaction is processing. Routing Rules Module is also coupled with the database layer. This arrangement stores customized merchant rules related information into the database layer which will be used later for taking decisions while the transaction is being processed by the Innoviti uniPAY Processing Platform.

■ Customize Terminal and Transaction specific Receipt: In currently used EDC machines, receipt layout information resides inside the EDC itself. This actually makes receipt layout changes difficult and almost impractical during the running time. If anyone wants to change the receipt layout, then it is almost unavoidable to reload the new code inside the EDC, The primary embodiment of this feature resides itself in the invention architecture (as shown in figure 5). Invention architectural design makes possible to customize the receipt layout at any time and for any number of times. As mentioned above, Innoviti Interchange Switch has complete knowledge of the nature of the transaction and the source of origin of transaction as it is tightly coupled with the database, so Innoviti Interchange Switch can send receipt related information to billing software according to the nature and source of transaction and billing software in turn uses this information for receipt printing. Figure 22 shows the matrix arrangement for acquiring receipt related information.

■ Remote Logging of Client Side: In Current EDC based architecture, there is no provision of getting client side logs remotely. In the existing EDC based arrangement, client side logs are only accessible at the client location only. The primary embodiment of this feature resides itself in the invention architecture (as shown in figure 5) which makes it possible to access client side logs at the centralised location i.e. at the Innoviti uniPAY Processing Platform itself. Innoviti uniPAY Processing Platform prompts client side interface based on the preconfigured rules, to send logs with the next incoming transaction request. A web interface layer (that is coupled with database layer as shown in figure 10) is there to see and analyze client side logs.

■ Customize Rules for blocking Transactions: In current ECD machine there is no provision of blocking transaction as per merchant requirements. Decline of any transaction is governed by the Acquirer predefined rules only. The primary embodiment of this feature resides itself in the invention architecture (as shown in figure 5) which enables the merchant to set his/her specific rule for transactions blocking through a web interface. As shown in figure 24, Block transaction module is coupled with web layer, so merchant can configure his/her rules through web interface for taking any action while transaction are processing. Block transaction module is also coupled with the database layer. This arrangement stores customized merchant rules related information into the database layer which will be used later for taking decisions while the transaction is being processed by the Innoviti uniPAY Processing Platform. Innoviti uniPAY Processing Platform uses one or more parameters and its combination for defining any blocking rules. List of parameters are given below:

1. Bin Number Range
2. Specific Bin Number
3. Date and Time or its combination
4. Billing Software Identification Number

■ Heartbeat Mechanism: In current organisation/architecture of billing software and authorisation server, there is no way to know whether an EDC machine is alive or not. In current arrangement between merchant and acquirer, if any problem persists on merchant site, acquirer will send his agent/maintenance personal to look after the problem. But there is a one problem in this arrangement that this is only a failure recovery mechanism i.e. actions are taken after the failure occurs. There is no scope of taking preventive measure to avoid failure, as EDC or billing software health can't be monitored from remote location. But as shown in figure 5, Innoviti uniPAY Processing Platform and billing software/front end have two way communications, so any number of billing software that are connected to the Innoviti uniPAY Processing Platform can be monitor from a centralised location. Innoviti uniPAY Processing Platform send packet or ping to all connected billing software and based on the response type and time from the Billing Software, calculates and records the health of the Billing System ,As discussed in the section 'Remote Logging of Client Side" Innoviti uniPAY Processing Platform is also able to collect all the information resides in the billing software, so the basis of "Remote Logging of Client Side" and "Heartbeat Mechanism" , Innoviti uniPAY Processing Platform is able to identify billing problem precisely and suggest measures/preventive actions to rectify the problem/s before failure at billing software occurs.

■ Centralized Initialization Of Terminal: In current organization/architecture of billing software and authorisation server, there is no way to Initialize Terminal (Terminal Initialization means configuring Acquirer based Transaction related parameters to the POS Terminal) from a remote location. In current scenario, Acquirer terminal maintenance personal has to go to merchant location physically for Terminal Initialization. But as shown in figure 5, Innoviti uniPAY Processing Platform and billing software/front end have two way communications so Terminal Initialization related parameters are configured and stored at Innoviti Interchange Switch. So in this way, each POS Terminal gets initialize/configured as per Acquirer Initialization parameters from a centralized location.

■ Merchant Fraud Detection System: In current organization/architecture of billing software and authorisation server, only Card Issuer has the capability of detecting fraud in real time. But Card Issuer fraud detection capabilities are only limited to the transaction characteristics based parameters (mainly amount, frequency). These fraud detection parameters are not merchant specific. These are based on the business arrangement between Card Issuer and Card Holder, As Acquirer works more closely with the merchants, they calculate risks and generate reports in T+l day (Transaction Date plus one day), which is merchant specific. But this approach is not proactive because transaction was already authorized and now merchant only remains to incur the loss of fraud. Also, merchant plays no or little role while the Acquirer generates risk report. All these factors imply that Fraud Detection System is more useful to reduce Card Issuer and Acquirer liability more than the merchants. The primary embodiment of this feature resides itself in the invention architecture (as shown in figure 5) which facilitates the merchant to enable and define parameters for Fraud Detection Module which is more appropriate and effective as per merchant requirements and business establishment through the Web Interface. As shown in figure 5, all POS Terminal are connected to the Innoviti uniPAY Processing Platform while Transaction Authorization takes place, so each transaction has passed through the Merchant Fraud Detection Module (as shown in fig 23), hence decisions are taken in real time while transaction is actually authorising. Now merchant is in better situation of defining risks associated with each transaction as per his/her business establishment.

■ Merchant Discount system: In the current organization/architecture of billing software and authorisation server, the merchant discount systems are either manual or implemented by Issuer through cash back. The discount offered on payment is applicable on some selected range of Issuer cards, The primary embodiment of this feature resides itself in the invention architecture (as shown in figure 5) which facilitates the merchant to enable and define different discount schemes based on one or more parameters or combination of parameters. Following are the list of possible parameters:

■ Merchant Business Establishments

■ Time in form of date, day, hour, month, year or combination of two or more,

■ Issuer card identifier that includes range of card numbers, issuer identifier, or any information on card that identifies the characteristics of the card or Issuer.

■ Billing amount and payment amount, in any currencies either in discrete values or in ranges.

As all the transactions are routed through the system, the system has knowledge of the all the characteristics of a transaction. Based on the different discount rules set by merchant through the web interface, as shown in figure 24, the discount is applied on the transaction. After the modifying the transaction as per discounts rules, as shown in figure 23, the transaction is sent for authorization as shown in Fig5.

• UniPAY Closed Group Card Server: This component authorise all kinds of transactions except transactions that require bank/acquirer authorisation. This component manage and authorise transactions for pre paid, gift coupons /coupons, loyalty related etc. The key features of this component are:

> Integration with Mobile Network and Web Interface: This component is coupled with mobile interface that allows merchant to send transaction related details/alert to their customers on any kind of action. For example in case of Loyalty Program, during purchase if customer earned points, he/she gets alert on his/her mobile about his activity. This component also coupled simultaneously with web interface which also gets updated on the same event i.e. on points earning as the case in above given example. Figure 25 gives detailed description of the integration of the UniPAY Closed Group Card Server with mobile and web interface.

CENTRALISED SETTLEMENT PROCESS

As described in figure 2, in existing EDC based architecture, settlement process is initiated by EDCs only that simply implies that if merchant/retailer is multi city based then settlement process can only be initiated from discrete locations or in non centralized manner.

As we discussed in above sections with the help of figure 5 that this current invention makes the payment system more centralised and coherent. So this invention also allows to initiated settlement process from a centralised location i.e. from Innoviti uniPAY Processing Platform and process settlement for each transaction with their subsequent servers (in case of non banking transactions, settlement happens with the UniPAY Closed Group Card Server and in case of other transactions with their acquirers).The primary embodiment of this feature has been described in figure 6, The key feature of this type of arrangement is that it can process settlement with one or more than one acquirer simultaneously. Implementation details of these particular features in described in figure 26.

In view of above discussions, it is evident that Innoviti uniPAY Processing Platform have full detailed knowledge about a given transaction and its authorizing acquirer. So as described in figure 27 , through a web interface , user /merchant selects multiple acquirers and send request for settlement to Innoviti uniPAY Processing Platform. Now on the basis of request, settlement module retrieves information about the transactions and its acquirers and as per acquirer settlement specification modify each and every transactions and repack it and send to the their respective acquirer. All transaction and acquirer related data is retrieve from the database layer (shown in figure 27).

Figure 28 shows a matrix, how acquirer related information for settlement has been stored in the database layer.

DATA ENCRYPTION TECHNIQUE

As per guidelines while storing card related data, it should be in encrypted format. Figure 11 shows the existing methodology used for encrypting data in the database. As shown in figure 12 , encrypting key is stored somewhere at the secured location and when needed encryption module takes/access encrypting key and encrypt the given data.

In primary embodiment of the present invention, uses PASSPHRASE for generating encrypting key and use it for encryption. A 3-DES encryption algorithm is used for encrypting card related data. A detailed description is given in the figure 12. As per figure 12,

1. A PASSPHRASE decrypter module is used to decrypt the PASSPHRASE stored in the database.

2. Now on the basis of the PASSPHRASE (retrieve in above step) is combined with 8-bit salt and encrypted key gets generated.

3. Next with the help of the encrypted key (retrieve in above step) and JAVA 3-DES encryption technique, data gets encrypted and stored,

Yet another embodiment of the present invention is represented in Figure 13. The ENCRYPTION KEY for the algorithms is generated using a PASSKEY. The PASSKEY that is used for generating the ENCRYPTION KEY is forward encrypted and stored, The PASSKEY knowledge is split between two administrators who enter into agreements agreeing to protect their portion of the knowledge. The ENCRYPTION KEY is decrypted at server start and then used for encrypting transaction data on the fly. The ENCRYPTION KEY is deleted whenever server halts.

ADVANTAGES

• No need to store Encrypted Key. It is generated on the fly using passphrase.

• Passphrase is also encrypted and stored in the database. It is decrypted on the fly only when DATA Encryption or Decryption needed.

• If encrypted PASSPHARSE get compromised. It is impossible to generate encryption key because Encryption Key is generated by the combination of passkey and 8-bit salt which is only possible to know if some has access to source code.

MERCHANT FRAUD DETECTION SYSTEM

> IDENTITIES
Identities means parameters against which system create FD scores. They are
• Card Number
• Phone Number
• IP Address
• Email Address

If a transaction contains more than one identity, same score has to be calculated and stored against all identities.

> TYPES OF SCORES:

Fraud Detection Module calculates and maintains score of a given parameter on two basis:
1 Permanent Score
2 Cyclic Score

Permanent Score : This score indicates the potential risk involved with the customer while honoring transaction. This score doesn't effect decision regarding approval or disapproval of a transaction.

Cyclic Score : This score gets resets on daily and weekly basis automatically. This is used quick fraud detection.

> PARAMETERS OF FRAUD DETECTION SCORE:

Divided into two categories:

1, Based on Issuer
• Call Issuer
• Decline Pick Up Card
• Approved Verify ID
■ Invalid Transaction
• Decline
• Expired Card
• Restricted Card
• Exceed Limit Amount
• Exceed PIN Retries
• Unsuccessful Transaction

2.Based on Merchant

> Number of Purchases

> Transaction Amount

o Difference between Average Purchase value and current transaction value
of Customer.

o Difference between current transact ion amount and minimum amount set
by merchant

o Difference between current transact ion amount and maximum amount set
by merchant

SCORE CALCULATION MECHANISM:

1. Daily Score Calculation:

Call Issuer Score, A =c*e K *x
c=constant
x=number of attempts in a day
k-weight average, determined by the seriousness of the error.
Decline Pick Up Score, B=c*e x
c=constant
x=number of attempts in a day
k=weight average, determined by the seriousness of the error.

Approved Verify ID Score, C^c*e K*x
c=constant
x=number of attempts in a day
k=weight average, determined by the seriousness of the error.

Decline Transaction Score, D=c*e K *x
c=constant
x=number of attempts in a day
k=weight average, determined by the seriousness of the error.

Expired Card Score, E=c*e K *c=constant
x=number of attempts in a day
k=weight average, determined by the seriousness of the error.
Restricted Card Score, F=c*e K *x c=constant
x=number of attempts in a day
k=weight average, determined by the seriousness of the error,

Exceed Limit Amount Score, G=c*e K *x
C=constant
x=number of attempts in a day
k=weight average, determined by the seriousness of the error.

Exceed PIN Retries Score, H=c*e K *x
c=constant
x=number of attempts in a day
k=weight average, determined by the seriousness of the error.

Unsuccessful Transaction Score, I=c*e K *x
c=constant
x=number of attempts in a day
k=weight average, determined by the seriousness of the error.
Customer Amount Score, J=C*(AQ — A *yo)
c=constant
Ao = amount of current transaction
A^VG = average purchase value of the customer in a day

Min Amount Score, K=c*(Ao - A MIN) c=constant
Ao = amount of current transaction
AMIN = minimum purchase value of the customer

Max Amount Score, L=c*(Ao - A MAX) c^constant
Ao = amount of current transaction
AMAX = maximum purchase value of the customer

Number of Purchase Score, M=c*e X S Y
c =constant x=number of attempts
X=number of distinct stores
y=number of cities

Note; Sum of all k equals 100.

All Scores values from A to M must be positive, else taken as 0.

Total Daily Score - (wl* A )+( w2* B)+(w3 * C)+(w4* D)+(w5* E)+(w6* F)+(w7+ G)+(w8* H)+(w9* I)+(wl0* J)+(wll* K)+(wl2* L)+(wl3* M)

wl ,w2 ... wl 3 are weighted average and

2. Weekly Score Calculation
Same as daily score calculations but number of attempts are calculated on weekly basis.

3. Permanent Score Calculation

same as daily score calculations but number of attempts are always one.

We Claim:
1. A transaction processing system for processing plurality of distinct transactions and cards on single platform, said system comprising

a. plurality of billing and/or payment terminals connected to processing
assembly;

b. processing module consisting

i. terminal driver switch being configured to drive at least one billing and/or payment terminal and to recognize origin of transaction; and

ii. interchange switch being adopted for distinguishing between different types of transactions and route them based on predefined attributes of the transaction;

c. closed group card server connected to processing module and is being configured to authorize predetermined transactions; and

d. card management module and reporting module.

2. The system as claimed in claim 1, wherein the billing and/or payment terminal is selected from group comprising POS terminal, WEB interface, IVR interface mobile interface, EDC machines and combinations thereof.

3. The system as claimed in claim 1, wherein the terminal driver switch recognizes the transactions received for processing from unregistered terminals and/or unauthorized terminals and/or blocked terminals and takes appropriate actions by responding with appropriate response; preferably rejects such transactions.

4. The system as claimed in claim 1, wherein the terminal driver switch interacts with database having terminal related data information and/or front end software knowledge and capable of taking business decisions.

5. The system as claimed in claim 4, wherein user is allowed to change or add terminal data information through web interface and the terminal driver switch is capable to work as per changed and/or added terminal details without stopping the processing system.

6. The system as claimed in claim 1, wherein the interchange switch routes the transactions based on attributes selected from group comprising Bin number, Date Time, Geography, Reliability, customized merchant specific rules and combinations thereof.

7. The system as claimed in claim 1, wherein the interchange switch is tightly coupled with database server that provides subsequent information to whom a given transaction needs to be sent.

8. The system as claimed in clam 1, wherein the system allows the user to access client side log at the centralized location and said system prompts client side interface based on preconfigured rules for sending the logs with subsequent transaction incoming request.

9. The system as claimed in claim 1, wherein the system is capable of remotely monitoring health of the billing and/or payment terminals from a centralized location and suggest preventive actions to rectify problems before failure at billing and/or payment terminals,

10. The system as claimed in claim 1, wherein the system comprises merchant fraud detection module for detecting fraud transaction at merchant end in real time and said enables the merchant to define predefined parameter for fraud detection module through web interface.

11. The system as claimed in claim 1, wherein the system facilitates the merchant to enable and define different discount schemes based plurality of parameters selected from a group comprising merchant business establishment, time date, issuer card identifier, billing amount and payment amount, and combinations thereof.

12. The system as claimed in claim 1, wherein the closed group card server is integrated with mobile network and web interface for sending transaction related details and/or alerts including marketing message to their customers on any kind of actions,

13. The system as claimed in claim 1, wherein the closed group card server is being configured to manage and authorize transactions selected from a group comprising pre paid, gift coupons, coupons and loyalty.

14. The system as claimed in claim 1, where in reporting module provides comprehensive reports based on merchant based establishment and predefined parameters,

15. A method of processing plurality of distinct transactions and cards on single platform, said method comprising steps of;

i. initiating request for processing a transaction by at least one billing terminal to
processing module;

ii. determining origin of the transaction and recognizing the validity of the transaction by terminal driver switch;

iii. determining the fraud probability and taking action based on the result; and
thereafter determining the discount rules applicable based on the predefined
discount parameters and applying them on the transaction;

iv. distinguishing between different types of transaction and forwarding the valid
transaction based on predefined attributes of the transaction to acquirer for
authorization;

v. transmitting acknowledgment packet to the billing terminal for determining status
of the terminal before sending transaction request approval messages received
from the acquirer; and

vi. awaits acknowledgment from the billing terminal and as per the status of
acknowledgment it proceeds with the transaction in case of success and in case of
failure automatic reversal of the transaction; and

vii. sending approved transaction response to the terminal after receiving response to
the acknowledgment packet for processing plurality of distinct transactions and
cards on single platform.

16. The method as claimed in claim 15, wherein the method enables settling of transactions with bank host to conclude the transactions by invoking settlement with the host for all billing and/or payment terminals from a central location, without any intervention of the front-end terminals themselves.

17. The method as claimed in claim 16, wherein report of passed or failed settlement attempt is generated if repeated attempts at settlement of failed terminal settlements exceeds predefined repeat limit.

18. The method as claimed in claim 16, wherein settling of transactions with plurality of acquirer is performed simultaneously.

19. The method as claimed in claim 15, wherein processing of transaction includes detecting potential card holder or merchant fraud being carried out at the terminal to prevent misuse of the card and/or merchant acquiring facility, comprising steps of:

a. detecting if the card being swiped has been swiped in a different geography or multiple times in a pre-defined interval;

b. detecting if the same card is being used in the same merchant location
repeatedly; and

c. detecting if the card number printed on the card matches with the card number
printed in the magnetic stripe of the card.

20. The method as claimed in claim 15, wherein the processing of transaction comprises transactions of different types selected from a group comprising card based financial transaction, non-card based financial transaction, card based non financial transaction and non-card based non financial transaction.