IP Applications Billing and Payments blog

Welcome to the IPA company blog. You'll see opinions here from a number of IPA employees on topics ranging from general SaaS and cloud happenings to specifics on PCI compliance and other subscriber management and recurring payments topics.
Scott Waldrum's Blog
Description:
No desc available

While here at IPA we regularly get excited about subscribers, recurring billing and payment processing, we understand the rest of the world doesn't always share our excitement. It seems everything the cloud topic touches these days is getting attention and subscription billing is now along for the ride!

IDC has just published a Cloud Billing research paper where they draw comparisons between telecom providers and emerging cloud infrastructure providers when it comes to billing for their services. For frequent readers of this blog you won't be surprised to hear that we completely agree with the thesis of the IDC paper. One of our favorite topics is pricing strategies (see our post on SaaS Pricing Strategies) for SaaS and Cloud subscription services and we often draw comparisons to the mobile phone industry.

At IPA we have a unique perspective on this topic. We cut our teeth handling subscription billing for the Telecom and ISP world and have moved into providing our on-demand recurring billing solution to SaaS and Cloud providers over the last 2 years. Comparing our experiences with our Telecom and ISP customers to the direction our SaaS and Cloud infrastructure customers are going we can offer some concrete examples of the fit:

  • Metering: Cloud infrastructure providers in particular but many SaaS application providers have highly metered services. The best way to link value with your pricing strategy is often through usage based pricing.
  • Subscription Plans and Pricing: A common criticism of purely metered services is the uncertainty factor. We see many providers now rolling out plans that bundle a certain amount of usage or provide unlimited usage for a fixed price. I've often pointed to GoGrid's pricing plans as a great example of this move toward the telecom model.
  • Reseller support: Virtually all of our SaaS and Cloud customers are rolling out channel strategies this year for their subscription services. As a result they are working through how to support their resellers from a marketing (think white-labeled or co-branded online storefronts) and billing (who owns the billing relationship?) perspective.
  • Partner Products: In the telecom world many of the products and services are not delivered by the telecom vendor themselves. SaaS and Cloud providers are beginning to bundle services from partners into their offerings and will be looking for their billing solutions to help with revenue settlement.

Clearly, there is a capability fit for providers of Telecom billing solutions to move into the cloud billing space (we ourselves are proof of it). The question we at IPA have is this:

Is there is a cultural fit between telecom billing providers and the growing cloud infrastructure providers?

Time to value: This is a key mantra of the SaaS and Cloud community. The model for selling Operational Support System (OSS) solutions, of which billing is one piece, to telecom vendors has included very long sales cycles, very long and expensive implementations and highly customized on-premise software.

Because our solution has always been delivered on-demand, and our pricing structure has very low implementation costs we've never felt like a traditional telecom software vendor. If our customers aren't making money, we aren't either.

Culture and Language: Not only is there a significant terminology/language gap between the telecom and the cloud infrastructure worlds but we also see a significant discrepancy in what each market finds important.

As we identified these issues, we brought people with SaaS backgrounds onto the IPA team and quickly devoted engineering resources to capabilities our new customers and prospects felt were important such as a rich UI experience.

Outside of our subscription billing capability fit, our on-demand philosophy and our willingness to quickly adjust to a new market have been the two biggest factors in our successful move into the SaaS and Cloud billing markets.

I'm certainly not going to say Telecom Billing vendors can't make the transition (look at us) but I strongly believe the functional fit of their products is only one of many factors they need to consider.


Do you need PCI Compliance to sell a subscription service in the cloud?

Our previous post on this topic "PCI Compliance, subscriptions and the cloud - Part 1" covered some of the debate out there as to the effect of the cloud on PCI Compliance and why we think the cloud has improved the situation for companies launching subscription services.

Unfortunately, you'll get different answers to this question depending on who you talk to. Our last post in the PCI Compliance series will tell you why.

Our answer is based on our experiences dealing with PCI Compliance as a service provider and customers that have asked us to help them with their own PCI Compliance efforts. 

The short answer is that subscription services in the cloud taking credit card payments must be PCI Compliant. There are generally two ways to get compliant and it comes down to how you handle the credit card and billing information:

1. Your service or marketing site handles, stores or processes cardholder information

In this case you've made a decision to host the forms that collect the cardholder data and possibly store it within your service to send recurring transactions to a payment gateway.

You will need to implement all the physical security, network security and application security required of the standard. Depending on transaction volumes you may have to pay for yearly audit visits from the assessors.

If you are hosted with a cloud provider that can not or will not meet the requirements (which is most of them right now) then you can't become compliant.

So, yes, hosting your solution in the cloud will be a problem for PCI Compliance if you go down this path.

2. Your service uses a PCI Compliant service provider to collect, store and process all subscriber cardholder data.

In this case, your service or marketing site does not collect or process cardholder data.

While you are still required to become PCI Compliant, that effort will likely be restricted to filling out a PCI Self assessment form in which you point to your service provider as handling the cardholder data. In this case, ensure your service provider does the following:
  • They have service provider Level PCI Compliance. Ask them if they have this level of compliance.
  • Your service provider's application or portal never allows anyone in your organization access to your subscriber's credit card information.

The proliferation of subscription services has really muddied the waters for online merchants. With traditional shopping carts and one-time purchases credit card information was rarely persisted.

As a result, many popular shopping cart frameworks have begun to add plugins for recurring payments but still require the merchant to collect and transmit the cardholder data for their new subscribers. This puts the responsibility on the merchant to meet the PCI Compliance standards.

Bottom line... If you are offering a subscription service, ensure you understand the effort involved to become PCI Compliant.

 As a provider of subscription services, if you've had experiences with PCI Compliance, we'd love to hear about them here.


Does the cloud help with or complicate PCI Compliance for subscription services? For a quick primer on PCI Compliance, check out our previous blog on the topic or our primer page.

Quite a few blog posts lately have been arguing that the cloud makes PCI Compliance more difficult, if not impossible. Don't look to the PCI Security Standards Organization for any answers, you won't find them. We'll tell you why later in our series on PCI compliance.

Back to the topic...

Way back in october, Chris Hoff wrote a tongue in cheek blog post on achieving PCI Compliance for a service that stores cardholder data running on Amazon's EC2 service. The Rackspace/Mosso announcement in march indicating that their Mosso service "Enables the spreadsheet store, an online merchant, to become PCI Compliant" touched off some debate on Chris Hoff's blog as well as those of other cloud security minded folks like Craig Balding and Ben Cherian.

The debate really centers around whether Rackspace/Mosso really enabled PCI Compliance. In this case,  achieving PCI Compliance should mostly be credited to the strategy of using a PCI Compliant service provider to collect, store and process all subscriber cardholder information. 

However, Rackspace/Mosso did in fact step up and work with the security scanners to ensure the storefront was scanned and secure. Amazon EC2 and most other cloud providers to date have not been willing to do this. Good on Rackspace for this, even if their marketing was aggressive here.

While I understand the argument and why folks like Chris Hoff have rightfully been raising the issue, we have a different view here at IPA as to the impact of the cloud on PCI Compliance.

We are a service provider that among other things, collects, stores and processes your subscriber cardholder data. Because we are a PCI Compliant service provider, we insulate you and your service from all the difficult, expensive requirements of PCI-DSS.

Why do we think the cloud has helped here?

We've been doing this for a long time. When we started handling all the recurring payments for ISP and Telco subscription services there were very few, if any,  on-demand services like ours. As online services, and more recently, cloud infrastructure services have proliferated, it has become  easier and certainly quicker to launch a subscription service. As a result, we've seen a whole lot of providers pop up in our space to service the cloud community.

As a result, you now have a variety of choices.  You no longer have to write the subscriber management and recurring payments capabilities yourself and go through the PCI Compliance efforts. Get them from the cloud, from service providers that are already compliant.








SaaS channels coming of age

Posted by: Scott Waldrum in SaaSChannelsBilling on

At IPA, we've been writing about the emergence of successful channel strategies within the SaaS community for some time. Late last year our VP of Sales, Kevin Lennox, wrote about the importance of channel strategies as SaaS companies penetrate the mainstream.

We've seen a number of announcements recently around channel strategies in the SaaS community.  Some, like the Microsoft reversal on who will own the billing relationship in the channel (microsoft or their VARs) make it clear that the large traditional ISVs with established channel strategies are actively implementing their SaaS strategies, even if they're a little rough around the edges.

Just yesterday, Intacct announced a channel relationship that will plant their SaaS offering directly in the mainstream of the SMB accounting and financial services industry. This is a very significant announcement from a pure-play SaaS provider.

IPA has an interesting vantage point of the happenings in the SaaS market with respect to channel strategies. We provide an on-demand subscriber management and recurring billing solution that has specific strength around billing recurring services with channel or reseller relationships. So, our customers and prospects run the gamet of SaaS startups, traditional ISVs launching SaaS services and successful pure-play SaaS companies.

In 2009, we've seen an enormous increase in the number of prospects in our pipeline that are  launching SaaS services into existing or newly created channels. Almost daily, we're talking to pureplay SaaS companies, but also traditional ISVs looking for subscriber management and recurring billing solutions that will support their channel strategies.

From where we sit, the Intacct announcement is only the first of many coming down the pipe. At IPA, we share Jeff Kaplan's view that 2009 will be the year of the channel.