Active Reload

I’ve received numerous questions about how Lighthouse is handling subscriptions. It’s not like subscription schemes are new or anything, but I suppose having more case studies out there can be beneficial.

When dealing with subscriptions for a service, there are several options you can pursue:

Paypal subscriptions

We launched Lighthouse with only Paypal subscription support. At that point, Active Reload was barely a registered LLC, so this let us get our foot in the door. Pros include it being free, and easy to setup an account. Also, Paypal sends back IPNs (Instant Payment Notification), that lets Lighthouse know when subscriptions are created/cancelled, and when payments are made. This is extremely nice for keeping track of late accounts. However, the actual signup process for your customers can be clumsy. This also locks out anyone that doesn’t use Paypal (Paypal accounts are required for the subscriptions, you can actually take a credit card for single payments). I’m just speculating, but I’d guess that Paypal subscription models would be better for consumer-oriented services. Lighthouse is used by firms, which may be more likely to use credit cards.

In the end, it was good for our young business to get up and going. We didn’t need SSL, a merchant account, or anything really. However, we didn’t want to lock out users without Paypal, so we allowed folks to trial the other plans without setting up payments. This lead to headaches later with folks forgetting to enter their payment info, and dealing with locked accounts. If you’re going to launch without all of your payment types supported, it’s probably best to go with the least restrictive one to start.

Going with a standard payment gateway

There are a lot of gateways out there that let you process cards per transaction. These work well for single transactions. Website A accepts card info on an SSL-protected page, makes a transaction, and forgets the sensitive info. However, a subscription service shouldn’t require monthly intervention. This brings up the incredibly sticky issue of storing customer info. James Duncan Davidson wrote an informative article on accepting online payments that talks about this in more detail. Storing credit cards places your company under a lot of risk. What are our options?

The DIY card store

One accepted method is implementing your own secure card store. You’ll need to understand the CISP regulations of course, and implement careful encryption schemes and security policies. This does get you a lot of flexibility though. You get two important features: custom payment schedules (taking into account trials, coupon codes, referrals, etc), and instant notification of new subscriptions or failed payments. You can automate the process of warning and closing accounts with declining payments, for instance. Like Paypal IPNs, this is a handy way to keep track of when accounts are paid and current.

Outsourcing security

Those benefits are hard to ignore, but I personally don’t like accepting that risk if I don’t have to. One promising alternative is using Trust Commerce, and their Citadel service. Citadel works as your dumb card store, accepting customer credit card info, and returning a unique customer ID. Your payment system can still implement custom payment schedules, and it still knows when payments are made. However, you’ve outsourced the security concerns to Trust Commerce. This is personally my favorite option out of the bunch.

But what about stock subscription services?

Several gateways (Authorize.net, Trust Commerce, Payflow, etc) offer their own subscription services as well. They usually support standard payment schedules, and handle all the charging for you. These services are very easy to setup, since all of the payment logic is handled already. But, you lose one important feature: the ability for your application to know when payments have gone through. If someone’s credit card starts expiring, your application would never know it, and that user’s account will keep on functioning.

Enter Paypal Website Payments Pro

So, what service did we go with? Website Payments Pro Payflow Edition (what a mouthful). Apparently, this is a rebranded version of the Verisign Payflow service. They provide a basic subscription service (but yes, we lose the application notification ability). Here’s how this has worked out so far:

The Bad

Being under the Paypal banner, I thought this would integrate nicely with our Paypal subscriptions (Website Payments Standard). Nope, that’s handled completely separately. Paypal subscriptions are managed in our Paypal account, and Payflow recurring billing profiles are managed in our Paypal Manager account.

The API docs were confusing also. Other gateways I’ve worked with simply use HTTP POST variables for everything. Though they typically provide API kits for several popular environments, it’s trivial to implement in virtually any development environment. Payflow implements a custom protocol, with an included SDK client. So, I have to compile/install something to use it? They also provide a custom XML interface, which is what we’re using. The excellent ActiveMerchant ruby library (used by Shopify) already implemented Payflow XMLPay, I just had to add methods for the recurring billing profiles. This means there are basically two sets of API docs, which stirs up confusion with support technicians thinking I’m using the SDK.

Being Paypal, WPPPE let us use our Paypal account as the merchant. This was all a snap to setup, but we noticed that every single payment was being declined once the trials started ending. The error was a “Field Format Error,” citing a missing CCV code. This spawned my ugly support experience.

First, I emailed Payflow support. With no answer, I tried opening a Paypal MTS ticket. They replied I needed special Risk Control access to accept credit card transactions without a CCV code, and that I should contact Payflow support to resolve my issue. It seems the Paypal and Payflow support areas are kept separate still.

With my emails still unanswered, I tried calling them directly. There was some confusion over the “Field Format Error,” and I had to confirm that I was sending my values in the correct format (the SDK apparently requires uppercase values, but not the XMLPay API). I also explained that I was not sending the CCV, since it’s not listed in the XMLPay API or the manual Payflow recurring billing profile forms. It’s my understanding that you should never store CCV’s, which is why the recurring billing profile didn’t even accept it. I was bounced back and forth between various departments until I found someone that knew what was happening. He confirmed that I did need Paypal Risk Control access and applied my account for it.

Having worked various helpdesk/support jobs, I try to be patient through the whole process. It’s annoying when messages get mixed up or you get bounced around among clueless technicians in the wrong department. What really gets me though, is that the WPPPE signup process made it very clear that I was setting it up to use Paypal as my merchant account (you can of course use a standard merchant account with your bank). Why not go ahead and apply my account for this Risk Control access ahead of time?

I really hope they get some of these issues worked out. I’d love to see tighter integration with the services. One support department to rule them all, etc. One excellent feature that I’d love would be IPN support from Payflow recurring billing. Lighthouse still has no idea when payments are declined, so locking them is still a manual process. If Payflow could somehow ping it the way that Paypal sends IPNs, things would be a lot easier.

The Good

As far as gateways go, they’re pretty much the same as far as I can tell in about every area except support. However, WPPPE’s Paypal integration gave it a little edge. Since I could use our Paypal account as the merchant, we didn’t need to apply for a merchant account through our bank. Signing up was less of a hassle. We get a single monthly rate with no setup fees, and had everything set up quickly. This is of course a moot point for established firms that probably have merchant accounts already.

With this in mind, I still think we may migrate to Trust Commerce at some point, or start using that for our next product. Using a standard subscription service gets you up and running quickly, but I’d like to move to a more flexible system at some point. I didn’t want this article to be overly negative, so I held off on writing it until it had a happy ending. I’m hoping this can help you out the next time you need to implement a subscription service.