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.
It looks like ACI has been at least partly successful with their offer to acquire S1. Partly because the proposed merger between S1 and Fundtech is now history and ACI has averted the rise of an S1-Fundtech combination which would be an even bigger competitor than S1 is on their own right.
So what happens now? By the turn of events it appears that after the ACI offer turned hostile, both ACI and S1 are building up their S1 stock to get control of the company. The S1 board is fiercely fighting against this but, despite initial impressions, it's not going to be easy for S1 to maintain autonomy.
When the S1 stock jumped up a few notches, some sold and some bought. At the end, it appeared that it's not entirely clear if the S1 CEO can rally the shareholders to fight off the attempted ACI takeover. And with the shareholder meeting for the Fundtech merger cancelled, it remains to be seen who has the most votes.
The current situation is not exactly the best S1 hoped for. There is uncertainty amongst both existing and prospect customers, as well as resellers of S1 products. Will the S1 payments platform still be around a year from today? That is the important question here. Although not a betting man, I would be willing to bet that the current situation is hurting S1 financially. Prospect customers, especially those affected by the ACI sunset, would not feel comfortable by selecting S1 now and then find out that they'll be dealing with ACI again after a few months.
With things being what they are, a shadow of doubt is cast upon the S1 future. Even if ACI does nothing at the moment, no one can be sure that they're not just accumulating S1 stock and trying to convince the shareholders to back them up so they can force a change of the board members or reach an agreement with the board behind the scenes.
In that sense ACI has gained an advantage over S1, at least for now. S1 has to clear this mess as quickly as they can, especially during the year of the setting sun. Unless of course, the game ends with ACI managing to acquire their most serious competitor.
