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.
