Our latest project Rusic is coming along really well. So well in fact, we’re looking at starting to charge users for some of the more advanced features we’ve been introducing.
In order to do this we’ve spent over two weeks building a recurring billing system using Realex’s Realvault system and a great Realex RubyGem (thanks to Paul Campbell). The idea being we can store card information in RealVault and bill accounts when they subscribe and then every month after that. Unfortunately, it hasn’t been quite that straightforward.
Rusic is hosted on Heroku, a brilliant and flexible cloud hosting platform (seriously, check it out!) that runs on top of Amazon’s EC2. This allows us fire up more processes if the site gets a spike in traffic, and makes the system more robust (if a process, or “dyno” goes down, Heroku automagically fire’s up another for us). However, one side effect (yes, side effect – not downside) of this is that any outgoing requests (say, to a payment gateway) could come from any one of the thousands of IP addresses Amazon EC2 uses.
The conflict in this whole scenario comes from Realex’s “allowed IP address” list. In order to send (some) requests (but not others?!) to Realex’s RealVault system, the request has to come from a server with an IP address in a pre-determined list. This works fine if you’re on a good-old dedicated server with a fixed IP, but we’re not. We were aware that Realex did allow you to add IP address ranges to this “allowed IP list” so we sent them Amazon’s mammoth list from this page:
https://forums.aws.amazon.com/ann.jspa?annID=1097
After a lot of them insisting they’d added them correctly and us insisting they hadn’t (they hadn’t), along with a further week of back and forth (we had to correct them on how their own system works a few times) we were told it wasn’t possible:
Unfortunately, Realex does not currently have a solution in place whereby we can accept transaction requests of this nature.
The issue has been raised with our Product Team and they are working towards a fix. However, I do not have an ETA for this.
Realex are working towards goals which will see us becoming more cloud friendly in the future.
(FYI Realex, if you handle IP address ranges on a daily basis it’s probably worth learning what a netmask is).
So we were back to square one. We’d already invested a lot of time building Realex specific logic and didn’t want to throw that away. Our options were:
- Integrate with a more cloud friendly gateway like Braintree (and throw away a lot of code).
- Move hosting provider to a dedicated non-cloud solution (more expensive and less flexible).
- Proxy SSL encrypted XML payment requests through one of our other dedicated servers (sounds scary!).
In the end we went with the third option – which turned out not to be that scary after all! There are 3 basic requests we need to be to set up a recurring billing process and take the first payment.
- Create a “Payer” – a representation of an individual and their billing address
- Create a “Recurring card” – the stored credit card details within RealVault
- Perform a “receipt in” – using unique references to the Payer and the Recurring card, actually charge the card a certain amount.
Fortunately, it’s only the “receipt in” (arguably the request with the least sensitive information) that’s IP restricted. So we kept the sensitive credit card processing requests as they were and just proxy the “receipt in” through a Rackspace server with a static IP. This was done using a neat little 20 line PHP script and cURL.
And it works! It’s a little slower than it would otherwise be, but only by a fraction of a second (and most of the time we’re doing the billing in the background).
It’s a shame Realex are so behind the times on this as they’ve been really good for us up until now with great support, quick setup, fast remittance and generally good value – but I’d bet we won’t be the last customer to have this issue (although, apparently we are the first!). It’ll pay in the long term to come up with better security methods than IP restriction. As they said, being cloud friendly is something they’re working towards so we’re looking forward to seeing what they come up with (and not having to proxy XML requests!).
