Patrick Clarke, CTO of Omnipay
Omnipay’s CTO talks to Siliconrepublic.com about building a platform to disrupt the e-commerce payments sector, the importance of security and why it’s not always good to be on the bleeding edge.
What does your role involve?
My primary responsibility is to ensure our platform is available 24 x 7 because we offer real-time processing services to about 32 companies, right across the world. In a way, the platform never sleeps so that’s my fundamental role.
At a more granular level, I’m responsible for the technology operations group which is responsible for the platform and its infrastructure and I’m also responsible for the software development team, the compliance team and security team.
Our group is responsible for both internal and customer-facing systems. Our internal IT systems use the same technology as our platform uses. That’s useful because from a support perspective, our customers are looking at the same interface that we are. It also means we can beta test and when a new feature is proven, release it to customers.
Do you see yourself as a pure technologist, or a business person, or a mix of both?
At this point I’d say I’ve really a foot in both camps – I’m the bridge between our business and the underlying technology. While I’m the technology custodian of the platform, that only exists to serve what the customer wants.
How much of a challenge was it to build the original technology infrastructure behind Omnipay, and to do it in a way that would disrupt the market?
At the time, when we set out, what we realised was we needed to build a platform that offered a better integrated experience than banks. The solutions available at the time were legacy systems.
For us, the challenge was to come together and build – with no legacy – a new platform that better served customers. In doing that, the challenge was, do we build everything ourselves, or do we buy/build? We settled on a buy/build mix and that has served us well.
How do you decide what gets bought and what gets built?
You want some aspects of your service to be delivered by someone who’s already done it but for the unique features, you want a hand in those. It’s a question of deciding how to build around established applications and make them unique.
You almost build a wrapper around bought-in applications and expose the wrapper to your clients so you can build new features in that wrapper that may or may not interact with the underlying systems.
You develop and host all of your systems from Dublin – what were the reasons behind that decision and how are you set up?
In early days you tend to want to go to the data centre to do bits and pieces and you want to do that in person. These days it’s relatively rare.
The big challenge in Dublin is cost. While the data centre provisioning is not so bad, the challenge is around the electricity prices – particularly now that data centres are starting to split out the cost between electricity and maintaining the infrastructure … more and more contracts are based on the principle of ‘consumer pays’.
Our DR [disaster recovery] facility is housed on-site in our own building and we use IBM Managed Services for our data centre.
What technology decisions did you take in the early days that set the course for the company now?
We probably took two key decisions from the beginning: one was that we would use the Java programming language for all in-house development, and the other was to use IBM P Series Unix servers. They’ve always had a good name for reliability and certainly our experience over the 13 years has been very positive with them.
Did you ever have to rewrite your technology strategy at any stage or have you just needed to build on what was originally put in place?
Largely we built on what we originally put in place. We did replace a bought-in solution with an in-house solution because we wanted to provide it to our customers and give them access to that aspect of the system and that wasn’t easily achieved with the purchased application.
What are the considerations when you’re thinking about a change like that?
Clearly there’s a cost in walking away from a solution you’ve purchased and there’s a cost in building your own, but when you weigh it out, you feel that this is the right thing to do.
What are the big emerging market trends you’re going to need to take account of – either for your own systems or in new online payment instruments that consumers will be using?
It really is the great thing about the payments industry – there is always change in it and probably the biggest area of change is the adoption of mobile payments, where transactions will occur either on mobile phones or with the help of mobile phones – like the Hailo app and other applications, like where tradespeople come to your house and instead of taking case, they take credit card details just by using phone technology and add-ons.
How big a part does security play in your systems development?
Security is absolutely critical in the payments processing industry, so much so that we are audited independently by another company for the Payment Card Industry Data Security Standard [PCI DSS]. We’re considered a level one service provider, so we’re under the maximum scrutiny.
Can you say what percentage of your budget you allocate to it?
In terms of data, we tend not to separate out security because in everything we do, there’s a security aspect but it probably isn’t itemised.
If we look at this year’s capital budget, we’re probably spending 10pc directly on attributable security changes but then you’ll find in other things we’re doing, security is still a very important aspect.
How would you describe your security posture overall?
Security is an on-going process. You can’t be guaranteed that you’ve always got it right but if you’ve got the right control environment, you should be able to contain anything that happens.
It would be a brave person that would say ‘we’re 100pc secure’ but you do have to work with as much knowledge as you can possibly gather because the threats are evolving and there’s something new every month to be aware of.
How rapid are the changes in the payments sector, and what effect does this have in your technology spending to keep ahead of those changes?
That’s an interesting question because probably the most rapid change in this sector is actually growth. Year on year, particularly in the e-commerce world, the growth rate is between 25 and 35pc. That’s a massive scaling and it’s an area we’ve done a lot of work in.
What’s your main project for this year?
Probably our most important projects are new customers coming on board. We will take on five new customers this year, and our most important product initiative is probably our transaction stopwatch which is an additional fraud control – so transactions can be ‘paused’ for analysis.
Our customers are the ones taking the risk on the transaction but what we have to do is provide systems and processes that allow detection and that can be smart about transactions that should be held.
Given the amount of information that’s passing through your systems, is big data a trend you’re watching?
We work very much on the basis of a single data store: big data turns that on its head and it stores pieces of data spread across systems. It is of interest to us. We’ll follow the trend and keep an eye on it.
We’re in a very traditional industry so the adoption of some of these features has to be slower. There are a lot of data privacy issues that would have to be dealt with, particularly when you look at big data in the cloud. It’s relatively early days in it as a technology. We tend not to work on the bleeding edge.
Given that Omnipay is now part of a larger organisation at First Data, how much autonomy do you have in terms of choosing technology or providers?
First Data has some very established technology providers and wherever possible, I tend to try and leverage these relationships for any new requirements that occur because they give us a proven track record of delivery and usually establishes volume discounts as well!
But occasionally a need arises that a First Data provider doesn’t have a solution for, and there are lots of local arrangements for that. Some of those solutions find their way from Omnipay back into the wider First Data organisation.
For example, we started using Acquirer Systems – an Irish company on Pearse Street – that provides test software for the payment industry and we used it for a number of years. First Data picked up on it and are now using it in the US.
