Simply put, Splunk is a data crunching engine for IT data. It is a remarkable piece of software, extremely easy to install, configure and use. And it even comes free if you don't want to use its enterprise features and your data isn't too large.
The Postilion payment system comes with an embedded monitoring facility that is based on event generation. Postilion monitoring is nicely layered across the entire payments engine and the Postilion SDK has a namespace dedicated to it, so Postilion developers can also benefit from this infrastructure.
But the monitoring facility, as nice as it is, leaves a lot to be desired in terms of searching. Any person that has operated the Postilion payment system can testify to that effect. Although there are consoles to query events using some criteria, the needs of the operational staff are always impossible to predict.
Using Splunk to index Postilion events opens a whole range of new possibilities as far as monitoring the payment system goes. There are two main ways to send your events to a Splunk instance:
- Write a custom program or data export that takes the latest events and dump them to a directory indexed by Splunk.
- Use the SDK to create a custom scribe that will feed SPlunk either indirectly (through files) or directly (through a UDP socket).
Once the events start flowing into Splunk, you can use all of Splunk facilities to search your data. Some of the cool things you can do:
- Convert any piece of disparate data in fields. Splunk does a great job at extracting fields out of raw data, allowing for better querying.
- Generate reports and charts based on fields.
- Create all sorts of monitors and alerts. Sure, Postilion has alerts as well but Splunk really excels in this area. For example, you can create an alert that will notify staff is a cutover event isn't indexed at a specific time.
After a few hectic weeks, the completion of the Dynamic Currency Conversion (DCC) project we've undertaken is now visible. The purpose was to configure a payments system in such a way to allow the user (a bank) to perform DCC on their ATM terminals.
For a bank, this is the simplest scenario for DCC. Until now, the bank dispensed Euros to their acquiring customers and sent transactions to the schemes in Euro. With DCC, the bank will now present the DCC offer to their acquiring card holders and, if they accept it, sent the transaction to the schemes in the billing currency of the cardholder and dispense Euros.
So, what have we learned during the implementation? Quite a few things.
- It might go without saying but it's very important for the acquirer to go to the schemes and find out about the hidden costs of a DCC implementation. Barring certification costs, an acquirer that wishes to implement DCC may find out that the schemes are not very forthcoming regarding their charge policies. Acquirers need to find out about yearly costs, and hidden costs that may appear in the guise of funds requested as collateral by the schemes.
- If possible, try to avoid updating the ATM application in order to avoid the relevant certification cycles. Depending on the scheme requirements for DCC, this may not always be possible.
- Pay particular attention to the settlement and chargeback processes and find out how the introduction of multiple currencies change these.
- Allow your operational staff to have their say before the project nears its completion. Introducing multiple currencies on the acquiring side, even if the introduction is restricted to settlement, will affect the way your operations do your balancing.
And the most important thing: devote serious time to investigate the roll out of your new service from a marketing perspective. An ATM network may have thousands of ATMs but some terminals are worth way more than others. It has been observed from past data that a handful of terminals that are located to key locations (main tourist attractions, major convenience spots and so on) may account for a vast volume of acquiring transactions (20% of your terminals may bring in 80% of the volume, depending on deployment). Some locations are also favored by specific demographic groups (Rhodes is famous for attracting a disproportionately large number of UK visitors).
Your marketeers need to make the extra effort to advertise the DCC service
- Ensure that your terminals are neat and stand-out.
- Make deals with travel agents, local hotels and retailers to drive more traffic to your terminals.
- Introduce granular fees to encourage card holders to make larger withdrawals.
- Advertise your charge rates and make damn sure that the customers understand why they are beneficial to them (DCC is a service that made a bad name for itself; more correctly, greedy acquirers and ill-behaved merchants have given DCC a bad name).
- Target specific demographics with special deals on some locations.
It's finally over. ACI has acquired S1 and has entered into what ACI calls the S1 integration phase. What this means is that S1 is a big mouthful even for the payments software giant, so they have to see how best to integrate the various pieces of S1 into their existing offerings.
By reading the ACI announcement, it appears that all S1 divisions except the payments division will have a future with ACI, as they have product offerings complementary to the pre-acquisition ACI product suite. The future of the payments division and the S1 Payments Platform is not as certain and the ACI announcement is somewhat vague about it. There's talk about "functionality overlap", and of creating "a best-in-class product". These phrases can be interpreted in very different ways.
From the management's point of view, it doesn't make sense to retain two different product lines that overlap significantly. It consumes resources to maintain and upgrade two different products. It might also be confusing to prospect and existing customers.
On the other hand, the S1 Payments Platform has a very strong presence in the Retail market so it's not a trivial decision for ACI to summarily EOL this platform. But retaining it in order to get a piece of this market leads again to having two different product offerings...
I believe that the big unknown here is how will Postilion customers react to the ACI-S1 merger and, if Postilion is to be scrapped, how well prepared is ACI to migrate those customers to Base-24 eps (well, the big ones at any rate). For the time being, I'd expect that ACI will keep rolling Postilion bug and mandate updates but the future of Postilion is at the moment unclear, to say the least.
And what of the state of the market? ACI was the biggest kid on the block before the S1 acquisition. With the customer base of S1, the runner up is now a distant second to ACI and the market for switches is starting to look like the market for search engines.
This can be both a blessing and a curse for ACI competitors. On the one hand, integrating S1 into ACI is going to be a difficult exercise regardless of how it's done. This will surely create opportunities for smaller switch vendors with differentiated offerings. On the other hand, ACI as the unquestionable market leader carries a lot of weight and can use their dominating position in various ways in order to make it difficult for other vendors to get customers to sign with them and not ACI.
During the last few months, I repeatedly found myself trying to determine how to better demonstrate the capabilities of my company's new products. Working with payment systems, this always creates the same problem: almost all functionality of our products resides on the server side. There's nothing visually appealing to show, unless someone considers ISO 8583 traces and transaction records appealing (which is not likely).
So I started working on demo applications. And a demo application these days translates to either a web-based or a mobile-based application. Since some of our products offer capabilities for the end-users of our prospect customers, which are mostly banks and processors, and given the current trend of our time, it's becoming clearer that mobile-based demos are the way to go.
Here's the problem: how do you turn developers who are experts in creating server-based payment applications that most often than not completely lack a user interface, to developers that can create good-looking mobile demos? The answer so far turns out to be: slowly.
Mobile development is a totally different beast than the payment system in almost every imaginable way.
- The mobile user interface is of prime importance, whereas core payment system components may lack a user interface altogether.
- While more powerful than ever before, mobile devices still impose severe limitations in terms of processing power and memory capacity when you're used to working in a server-based environment.
- Regardless of your choice (Android or iPhone) the development workflow is radically different, hence you get an additional barrier that needs to be negotiated.
A different mindset is required. My experience so far is painful but slowly improving with time. The most important personal asset that is being heavily taxed is my patience. I find that even the simplest things can take a significant amount of time to accomplish. It's not only the fact that one is not familiar with the mobile development mode and need to constantly look up some piece of reference; the edit-deploy-debug cycle is frustratingly slow.
Consequently, the sole piece of advice I can offer is: be patient. Take your time. Go through the process of working out samples even if they appear to be brain-dead easy. Write a few applications on your own even if they are equally worthless to the easy samples. Slowly try new things, a few at a time. Whatever you do, make sure that you don't start on a schedule before acquiring enough experience to make informed decisions about development effort required to accomplish something, regardless of how trivial it may seem.
We've recently set out at my workplace to perform a daring undertaking: implement authorization scripting for a payment system that does not have a scripting facility. The idea initially surfaced some time ago as a half-joke. "Wouldn't it be something if the switch supported scripting"? It seemed a bit crazy at first.
We debated amongst ourselves for a while about the merits of such a capability. During our time working with the payment system, it became apparent that we could do anything we wanted by using the software development kits. It was also obvious that some solutions we provided were bloated-by-design by static code and would be better implemented by authoring a quick script. Validating the input of a cardholder performing a custom payment at the ATM is a very good example of such a situation. Validations typically examine few transactions and verify the cardholder input by using a custom verification algorithm, such as a variation of a check digit verification algorithm. The typical solution would be to author a custom plug-in and attach it to the payment system; easy and can be delivered in a few days. The scripting solution would require creating a few lines of scripting code; easier and can be delivered in a couple of hours.
There was value in the idea, no matter how preposterous it might seem. It's not, after all, every day that you set out to plug-in something as significant as a scripting facility to a payment system. However, the flexible nature of the system allowed us to be optimistic.
So we rigged a proof-of-concept implementation and tried it out. The results were surprisingly pleasant and everyone started thinking of scripts for everything after working with our pilot. Stress-testing the solution to more than one thousand scripts per second was the final action before we started using the ideas from the pilot to create a full-blown system.
Some time passed and we're now there, with a scripting product finalized. It's surprising how your perspective changes from the time when you're building proof-of-concept, throw-away code to the moment you set out to create a polished product. A gazillion things that we didn't expect needed to be handled in a manner that makes sense to an end-user. Create a new scripting language or use an existing one lots of people are familiar with? Which one? How would the user write and debug scripts? How would the scripting service be notified of configuration changes? What facilities should the scripting service offer to the end-user, on top of those provided by the scripting language itself? What level of control should we allow to scripts? How could scripts be extended to communicate with external data? And external systems?
Once again, the graphical user interface
took a disproportionate amount of time when seen through the eyes of a
developer/integrator who would be quite happy with configuring
everything through a raw XML interface. But the real lesson here was understanding the need for a roadmap in order to reduce the scope to something manageable and release version 1.0 in a reasonable amount of time.
If we took the time to implement everyone's idea, and lots of people had great ideas, we would be lucky to have released 1.0 sometime at the end of the next year. One developer had a great visualization about how the graphical interface could be made to be much more intuitive. Another proposed a radical implementation that would allow anything in the payment system to be scripted. Yet another one indicated that a workflow should be used to push scripts through an author, then through an approving member, then to testing, to QA and then to production. Very often I was finding myself in the awkward position of having to shoot down good ideas that I liked just to keep the scope manageable for an initial implementation. "That's for version 2.0" became a phrase spoken quite a few times.
Having a developer's background, I can understand what a kill joy I turned out to be. Still, I had to be firm about the release date otherwise there wouldn't be a specific release date. And I do like releasing software!
One recurring theme that keeps coming back over the last few years is how to best integrate payment systems in a SOA environment. The SOA acronym may mean different things to different people but I've found that, more often than not, when developers think of SOA, web services and related technologies are involved.
Web services offer the advantage of providing a common framework of communication between different systems. The concept is powerful enough to bridge the gap between different programs, different development languages and different operating systems.
It should, therefore, not come as a surprise to know that payment systems users increasingly require their payment systems to connect to web services. Some payment systems are better at this than others. But I've found that the majority of payment systems have ISO 8583 so close to their heart that it's not as easy as it should be to use an external web service.
During the last few months, I've decided to tackle this in a generic way to allow payment systems to connect to web services at the backend. The approach is simple: create a SOA adapter that translates ISO 8583 to web service calls in a configurable way. The SOA adapter would connect to the payment system, receive an incoming ISO 8583 message, understand what is being said, call the appropriate web service and return the results to the payment system using an ISO 8583 response message.
This seems easy enough at first glance and it's a task that, in some form of another, most developers have encountered at some point of their career. Communicate with one system using its own language/API and translate what is being said to another system's language/API.
In the context of the SOA adapter, there is a complication. On the one hand you have web services that, more or less, use the same language. But on the other hand you have payment systems that use ISO 8583 in completely different ways that are often incompatible between each other.
One approach to tackle this is to create different flavors of the SOA adapter. This way you could end up with SOA.BaseI, SOA.Biciso, SOA.PostBridge and several other combinations that cater for specific needs. While this could solve the problem, it quickly adds up maintenance costs as it's necessary to keep track of different versions of the software.
The approach I've used is to code an ISO 8583 implementation generic enough to be able to read the application-level protocol from an XML configuration file. In this way, you have a single version of the software which comes with several configuration files so you just pick one that works for you. Plus, you get the benefit that you can implement an ISO 8583 customization by changing an existing XML file or by creating a new one; no code changes.
After completing this development exercise, the result is a clever piece of middleware that can be used to quickly connect payment systems to external web services using configuration only. The notion appears to be good enough to market. An end-user could connect the SOA adapter to their system, edit a few configuration files to describe their web services, their methods and parameters and SOA adapter just picks this info up and does the rest.
It may come as a surprise to some but the most difficult task which I'm still battling with is the creation of a user interface to drive the configuration. Strictly speaking, a config GUI is not required to use SOA adapter, especially when the technical background of potential end-users is considered. But, like my boss says, a GUI is more than just a necessary evil; it's the front end of the system and plays a major role in forming the perception users can have of the whole system.
After a short struggle, ACI has managed to acquire S1.
In a big turn of events, starting from the S1-Fundtech merger proposal to today's (3/10) press release, ACI has finally achieved their objective.
This acquisition creates a true payments software giant. Not that ACI wasn't the market leader before; but with this acquisition the new ACI will have the vast majority of the market with all other competitors coming a very distant second.
How does this translate for ACI and S1 customers, both existing and prospect ones? No way to tell at this point. It all depends upon the strategy that ACI will follow in the next few months. Will Base24.EPS be favored instead of S1's Postilion? Or will ACI keep both offerings...for now? Despite the original ACI position, Base24.EPS and Postilion have much more in common than not and it might not make sense to keep both products alive.
This situation certainly is familiar to people that remember what happened to Open/2. Postilion, though, had more traction than S2's Open/2 and ON/2 combination and there are a lot more customers that have chosen Postilion during the last two or three years. I would expect that there are a lot of nervous customers around, wondering how this situation will play out.
