Authorization scripting

Modern payment systems usually offer a multitude of configuration options that cater for a large variety of situations. The thing, though, with such configuration parameters is that they are meant to cover the different situations that are thought up by the system designers. The extent of configuration parameters is limited by the architectural fantasies of the system designers. When users of payment systems delve outside these limits (something that tends to happen quite often) there comes a moment when configuration just doesn't cut it.

When configuration can't do the job, the traditional way of implementing changes in a payment system is through adding code. This could manifest in many forms depending on the system architecture. An external message protocol may be coded as a plug-in. A component may allow user exits to be written. If code for core components is available, end users may hack away at it and change the system behavior to implement their requirements (a practice that they universally regret in the years to come).

At the business spectrum, end users don't like code changes for several reasons.

• They usually take a disproportionate amount of time to implement and thoroughly test.
• They carry a financial cost.
• Custom code tends to cater for uncommon situations and is generally not well covered by patches and upgrades.
• When piled up, custom code may erode the system in a kind of spaghetti state.

A not-so-new development that claims to minimize the need for custom code is scripting. What a scripting facility in a payment system offers is an abstraction of a lot of the intricacies of application languages, making it possible for non-programmers to quickly implement a script. In addition, scripts are generally interpreted in nature and thus more dynamic.

To the user, scripting seems like a panacea but is it? It's true that a scripting facility offers some advantages.

• The interpreted nature of scripts makes it easy to dynamically inject them in the authorization process without downtime.
• Some customizations are very easy to implement with a script.
• Implementation of a script generally requires less time and resources than a code change.
• Scripts can be much more easily implemented by end users than code changes can.

However, not everything is as it seems.

• By default, execution of scripts is an order of magnitude slower than execution of code.
• Just as with configuration, the scripting model places restrictions to the customizations that are possible with a scripting language.
• Making it easier to implement changes doesn't necessarily translate to a more manageable situation. Instead of code spaghetti you could have a script spaghetti of the same complexity, especially with script-happy users.
• The burden of script maintenance and proper alignment with system patches and upgrades is generally on the end user.

A proper scripting facility is obviously a nice addition to a payment system. It's better to have it that not to have it. But it should also be appropriately rated by end users. No scripting facility, regardless of how useful it may be, can make up for shortcomings of a system in other critical areas. And, regardless of the versatility of the scripting facility, there will always come a time when implementation of custom code will be inevitable. In that respect, a scripting facility is useful but a software development kit is what's really invaluable.