Description

This method differs from the ‘Blind Processing’ method greatly. The nature of this method is to not fire transactions at each gateway entry point in order, but to record the entry point of each successful transaction, which then in turn becomes the first entry point to try in the next transaction.

How It Works

When the merchant’s system is in a new or “reset” mode, the transactions will use the above “Blind Processing” method. Once this transaction is successful (either transaction authorised or rejected response), the transaction result passed back to the merchant’s system contains information as to the gateway entry point which processed the transaction. This entry point should be persistently stored on the merchant’s system, usually in a database table record of some sort. When the next transaction takes place, it looks at that database table and uses the latest successful gateway entry point as it first entry point to attempt. Like the “Blind Processing” method, if this transaction fails, it will then failover to the next entry point. Again, it will do this until all the entry points have been tried and failed, or the transaction is processed successfully and once again, the successful entry point used is persistently stored ready for the next transaction.

Pros

The “Entry Point State Awareness” method is more sophisticated than the “Blind Processing” method due to its awareness as to the entry points state. This allows more efficient transaction processing during times of an entry point outage.

Cons

This can be an intricate piece of work to develop and implement, even in its simplest form described

in the “How It Works” section. The reason we say this is because you can make it even more sophisticated still, as described in the “Additional Ideas” section below.

Additional Ideas

The “Entry Point State Awareness” method is sophisticated in the sense that it isn’t just blindly firing transactions at each entry point in succession. However, the simple version explained in the “How It

Works” section still has its flaws but was deliberately kept minimal to get the idea across in its simplest form.

One weakness of the simple “Entry Point State Awareness” method described above is the potential for “stale data”. What we mean by this is that if a transaction is processed and the successful entry point

stored, but the next transaction isn’t processed for an hour for example, the “state” of the last successful entry point could easily be invalid. In the world of I.T and the internet, the “state” of systems can change very quickly. You may have a perfectly up and running entry point one minute, something could happen and bring it down and it’s then not able to process transactions. Based on this “stale data”, it would be worth implementing a timeout threshold on the merchant’s system so that if a transaction begins to be processed, but the previous transaction time is greater than the threshold allows, the your “Entry Point

State Awareness” is “reset” and you begin the process again using the “Blind Processing” method. This will ensure not only that you’re using the most successful entry point for each new transaction, but if there is a large enough gap between the previous and the next transaction, that you re-test the each entry point

in succession if your “state awareness” becomes stale.

There is one additional piece of development that merchants can implement on their system to add yet another level of sophistication. This utilises the function “GetGatewayEntryPoints” found earlier in this document. What this function does is fire a very basic message at a specified gateway entry point and if the gateway entry point is up, it will return a complete list of all available gateway entry points and a metric value for each which it deems appropriate. This also means that if any of the gateway entry points are down, the entry point metric value of “-1” is returned for that particular entry point and the others have the metric value adjusted accordingly. The intricate part of this is that you will still need to have multiple gateway entry points to fire this basic message at. This is because, if you only have one entry point to fire this message at, and that entry point is down, then you will not yield a response from the gateway. This function will also return any NEW gateway entry points added that the merchants system may not yet be aware of which will prove to be very useful at increasing the merchants system ultra-high availability status. In order to implement this properly, you will need to have all available entry points persistently stored, in a database being the most favourable option. Then periodically (as you see appropriate) as part of a SCHEDULED server maintenance job of some description firing the

“GetGatewayEntryPoints” message to the gateway using the “Gateway Entry Point State Awareness” method mentioned above. When you get a successful response from the gateway, you insert any NEW gateway entry points that aren’t yet in the database table, and updating all of their respective entry point metric values. The reason you never do this as part of an actual transaction is to not add any delay times to transactions whilst waiting for the “GetGatewayEntryPoints” message to yield its response from the gateway.