Our Blog

Defining new payment interfaces the easy way with Aviso Novate

The payments business is bedeviled by diversity. Messaging standards for international card schemes like Visa and Mastercard can vary from country to country, country specific card standards abound (for example GICC in Germany) while certain industries have payment specifications all of their own – just ask any petrol payment operator. While ISO8583 style messages are prevalent, they aren’t alone – APACS is arguably the most important payment in the UK and Ireland for example.

That’s not even mentioning the necessity to support non-card based payment types in certain countries, for example iDEAL in the Netherlands or Sofort in Germany.  If this wasn’t enough, merchants are becoming more demanding of their acquiring partners when it comes to payment types support. There is a large (and largely unserviced) market of international bricks and mortar merchants who would like to have an acquiring partner who can service all the payment types that are relevant in the markets that they operate in. The onward march of online retailers is an even more striking example of a market that needs a straightforward and  comprehensive solution to allow their customers to use the payment types that they typically wish to utilise.

Because of these pressures, it is important that payments processors run a switching platform that makes standing up a new payments interface as simple and straightforward as possible. At Aviso, much of our development effort on Novate has gone into solving precisely this problem. As a result of this effort, we have what we think is an elegant solution for payments processors who wish to support large numbers of payments interfaces.

To support this, we have created a powerful domain specific language (DSL) to give user the power to define both message definitions and message transformations. This DSL allow switching administrators to make use of numerous powerful abstractions to quickly and easily define messages (down to the field or subfield level, including both data encodings and numeric encodings), and to then define transformations between these messages and some other message (for example you may wish to define a transformation between an APACS 70 incoming auth and a JCB 200 message). Of course these transformations also allow the participation of a source of state (i.e. a database) so that if you need to run particular queries to populate fields of a message as part of a transformation then that is perfectly possible. As Novate is built using Clojure, edn was the obvious choice when it came to deciding how to represent our message and transformation configurations.

The right way to define new payments interfaces

While some players in the payments space have decided to implement message transformation using GUI tools, our experience ‘on the other side of the fence’ in terms of running production systems is that you simply can’t beat text-based configuration. When systems present configuration options in plain text, it’s possible to use whatever text editing tool you want to edit configuration, message formats can be printed out if users so wish, and users can use version control to keep track of who made what changes when, and what versions go into production.

The approach we’ve taken has allowed us to define message formats at an exceptionally detailed (and powerful) level. If you’d like to learn more, why not drop us a line.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*