Ideal payment processing system

Our ideal client administration and payment system now looks like the diagram below. The green arrows indicate the sequence and flow of data when processing an order and the red arrows represent the return flow when authorising credit card payments.

Internal system

While we could manage products, clients and orders in external systems, it makes much more sense for us to have direct control over these items in our own system. These core processes are very tightly coupled to our business model and it makes sense for us to directly control the systems which control these processes.

One example of this is our requirement to control the repeat billing of clients who purchase a subscription product from us. Currently, the WorldPay gateway controls this process which means that we are obliged to adapt our own systems to the WorldPay way of doing things.

This inevitably causes us to make compromises in our own systems, simply to get things done. By controlling the repeat billing process using our own systems, we can design the optimal process for our clients and our business while making use of other satellite systems to play their part.

By connecting our internal systems to external systems via their API’s, we keep the control where we need it and offload the design, creation, operation and maintenance of these satellite systems – for a fixed fee of around $75 per month (Highrise and KashFlow fees combined).

Looking at the 5 year cost of using these systems – $4,500, there’s simply no way we could design, programme, operate and maintain these systems ourselves for anywhere near that amount of money. Keeping core functions in-house and API-ing to best-in-class satellite systems is the cheapest and fastest way of delivering an overall solution.

Highrise

Highrise is a great system from 37Signals which we use as our main Customer Relationship Management tool. Highrise gives us a way of managing notes and actions for clients.

Using the Highrise API, changes to client records, their orders and every interaction we have with them is automatically updated from our internal systems to their corresponding records on Highrise.

KashFlow

Even though KashFlow is a full replacement for QuickBooks, there are a couple of weak areas (from the point of view of our specific business requirements) which means that KashFlow cannot be at the heart of our system.

Our requirement for producing invoices and credit notes in multiple languages is currently outside the scope of the KashFlow system – which is why these functions are now within the remit of our internal systems.

Even though KashFlow boasts a wide range of integrated payment gateways – there’s integrated and integrated. The part which most matters to our business is the processing of subscription or repeat billing of credit cards – often referred to as Continuous Authority by payment gateways and merchant account providers.

The normal process is for the payment gateway to control the repeat billing process – but this leads to a number of compromises. One of these compromises is that the payment gateway is obliged to inform the client of each instance of payment being taken. This results in the client (currently) receiving an almost incomprehensible email from WorldPay and another from us about their purchase. Most clients have no idea who WorldPay is or why they should be getting duplicate emails from them – all in all it’s a mess.

KashFlow can also control the repeat billing process, but it cannot do so with all of it’s payment gateways – and does not offer the functionality we’re looking for in conjunction with our preferred payment gateway – Protx.

For this reason, we decided to side-step the payment gateway connections inside KashFlow and integrate our own systems with Protx.

Now that KashFlow isn’t doing invoicing and isn’t doing payment processing – we’re simply using it as an online bookkeeping tool with our Internal systems updating it via its API about orders, invoices, payments and credit notes. Our accounts people will use KashFlow directly for expense management and financial reporting.

ActiveMerchant

This piece of the system is perhaps the most puzzling. Why not interface our internal systems directly with the Protx API? why insert another step in the process?

ActiveMerchant provides a common interface to a number of payment gateways. The ones of most interest to us are Cardstream and Protx because they both have repeat billing features which we want to make use of.

There are two main reasons for inserting ActiveMerchant between our own system and the Protx gateway.

1. Easy to change payment gateways – Although we’re not anticipating a change away from Protx currently, it’s nice to know that it would be a relatively trivial process if we connect our system to ActiveMerchant, rather than directly to Protx.

   If we were already using ActiveMerchant to connect to WorldPay (although they don’t actually have that option, currently) then it would be much less painful to move away from them now. Once bitten, twice shy.

2. Easier to programme the API – Our own systems utilise the Ruby on Rails framework – and so does ActiveMerchant. This means that our programmers will find the ActiveMerchant API much more familiar and easy to work with than one not sharing a common scripting language and framework such as the Protx API.

ActiveMerchant does offer other advantages, but these two are why it’s in our order processing loop – flexibility and ease of coding.

Protx

Having decided to use ActiveMerchant, we had to choose a payment gateway supported by and integrated into ActiveMerchant.

The list of supported gateways is quite comprehensive but, suffice it to say, Protx won with a combination of offering the right features at the best price. The most significant of these features is that Protx allows our own systems to control the repeat billing process, without the need for us to store credit card details.

The PCI security requirements for a system which stores credit card details are (quite rightly) very stringent. This is one of the main reasons that payment gateways exist – to offer the highest level of security and encryption for the storage and transmission of credit card details.

For repeat or subscription billing, Protx store the credit card details of the client and provide our system with a token to use for future transactions. This enables our system to request payment using the token, without our need to store credit card details.

Some concerns about PCI compliance remain, however.

Streamline merchant account

The final link in the chain is our bank account where we actually receive funds from client credit cards.

Our choice of merchant account was dictated by those supported by Protx – our choice of payment gateway. For recurring billing to work, Protx need to understand the method of Continuous Authority used by the bank. Protx support continuous authority with merchant accounts from Barclays and NatWest (aka Streamline).

We had already made enquiries to Streamline because our current payment processor, WorldPay, actually uses a Streamline merchant account. The people at NatWest therefore had direct access to our trading history which made it easier for them to offer us a competitive rate and to complete the paperwork formalities a little quicker than normal.

At the time of writing, we’re still waiting to hear back from Barclays about our application for a merchant account with them. It would be nice to have a second merchant account waiting in the wings for the future.

How to save 40% on WorldPay credit card fees