We don’t normally release features on a Sunday, but this one just couldn’t wait!  I’m excited to tell you about “Predictive Charging”, our latest feature which is sure to improve the experience for all Chargify merchants and customers!

You may have read (and noticed) that we’ve been working to improve the speed and stability of our systems lately.  Thanks to these efforts, we’ve reduced our average response time by over 75% in the past few months.

There’s one large hurdle, though, that remains in the way of improving the speed of signups even more: the external gateways where we send credit cards for charging.  During a signup, we send the credit card to the gateway and have to wait on a response before we can give feedback to the customer.  This is frustrating, because sometimes the gateways can take 6 to 10 seconds to respond.  That’s why we’ve introduced Predictive Charging for our hosted signup pages.

One of the main things we’re working on at Chargify these days is improving the user experience, especially with regards to the speed of the site and the API.  If you’ve been with us for a while, you’ve probably seen things slow down quite a bit over time.  If you’re new, Chargify probably just seems slow most of the time.  I’m here to tell you that we don’t find the current state acceptable, and we’re working on it.

As a developer, I tend to like clean, concise URLs that map directly to my RESTful resources.  Want to view a subscription?

GET /subscriptions/77

Want to edit it?

GET /subscriptions/77/edit

The URLs for Chargify hosted pages followed this convention.  Updating credit card details loosely maps to editing the subscription to change the payment information.  So, we had:

GET /h/subscriptions/77/edit/abcdef0123abcdef0123abcdef0123abcdef0123

With the ‘h’ part meaning our “hosted” namespace, and the gibberish at the end being a secret token.

Now, if I were a layperson, and IF I happened to glance at the URL for the page I was about to enter my credit card on, which one of the following would be more likely to give me warm fuzzies?

We’ve just released a new feature that allows you to add “components” to your products which your customers can purchase and be charged according to the quantity chosen.  This is great for offering things like the following to your products:

• IP Addresses - say your basic service offers 1 custom IP address for free, and extras can be purchased for $1 each
• Extra Projects - say your project management service allows users to purchase extra “projects” a la carte.  The first 5 cost $5 each, the next 5 cost $3 each
• Charge flat fees based on a number of customers (like how Chargify works).  0-50 customers is $0, 51-500 is $49, etc.

What the heck are components?

We’ve built a new framework that is going to give you a lot of flexibility in defining your products, and we’re calling these “components”.  If you think of the traditional “product matrix” you used to see on most websites selling a service, you would usually see their plans (or products) in the columns and row after row of optional and included things.  Well, in Chargify these “things” are called “components” - they are the building blocks of your products that you use to add options, upgrades, and add-ons to enhance your offerings.

The following simplified graphic shows what I’m talking about.

We released several new features for Chargify this week that definitely deserve mention.

Multi-Site Support

Before, when you created a Chargify account, you were given 2 “sites”: 1) your “live” account and 2) your “test” account.  This structure was somewhat limiting, both for us and our customers.  We re-architected how Sites (now with a big “S”) work, and now, you can create as many Sites as you want, and you can move them in and out of test mode.

Each Site has its own Customers, Subscriptions, and Settings.  This means each site configures its own:

• Subdomain
• Gateway settings
• Email Templates (more on that later)
• Dunning Settings

This also opens us up to support other sorts of things in the future that aren’t compatible when you only have 1 production site… like multiple currencies.  (We haven’t committed to a roadmap for multi-currency, but we do know the need is there and we want to make sure we’re ready).

We sent out a survey recently to those on our Beta waiting list (thanks for all your responses!) and one thing that I noticed from the comments was that not everyone is aware of the API libraries/wrappers that have emerged so far for the Chargify API. The Chargifiy team has published one for Ruby/Rails, and I’m aware of another one for Ruby and one for Python.

The full list is always our support site, but here’s a quick run through.

Its been a while since the last blog update on Chargify, so allow me to fill you in. Things have been progressing rapidly and we’ve gotten great feedback from our beta testers. A big thanks to all of you!

Not a beta tester yet, but want to be? We hear you! If you’re not already signed up, head on over to http://chargify.com/pricing-and-signup and click the big “Sign Up for the Beta” button.

Development and the private beta of Chargify is proceeding rapidly and we’re getting great feedback from lots of our beta testers.

Recently, we’ve released a few major updates and we plan to release another major update by the end of the week. This update includes, among other things, access to all of your product information via our API which has been one of our most requested features.

Monday was a wild one for the Chargify team – we launched our product in the DemoPit at the TechCrunch50 in San Francisco. We did not win the “Audience Choice” vote (votes are cast through poker chips placed in to DemoPit presenters’ jars), but the day was full of affirmation nonetheless.

Most people simply “got it” when we explained what we are doing. We particularly resonated with developers who have tried to integrate a billing system, and investors/stakeholders who have seen their developers flounder when it comes to smoothly accepting recurring payments.

A particularly great moment for us came when Mr. Michael Arrington himself rode up on his Segway, chatted with our CTO and co-founder David Hauser for a few moments, then dropped his chip in our jar and rode off. I can only guess that someone else tipped him off to what we’re doing, so many thanks to that person.