Easy Charging of Credit Cards with Spreedly

When we built SQuiD (easy project management for link building), we had a problem in that the client was on a limited budget and yet the site had to charge people subscriptions for usage. Which, if we wrote that part ourselves, would take all sorts of time to research, implement, and (most importantly) not screw up. When you take people's credit card numbers there is no such thing as a small security breach.

Luckily my teammate, Joseph Leddy, remembered hearing about Spreedly -- all they do is "Make Selling Subscriptions Easy." We decided to use Spreedly and it saved us a ton of time (and consequently money). Here's 9 reasons why I loved working with Spreedly:

1. Free to start and test with!
Spreedly doesn't charge any money to sign up and run tests against their API. You start paying only as soon as you're ready to start collecting real money.

2. Ridiculously test friendly
You can create a pretend (test) area that you can charge accounts to. It looks and behaves exactly like the real version, even down to the managing of your pretend subscriptions. When you're running the site on your local machine you can follow a full path to Spreedly (with stubbed out credit card processing) and back to your local server.

3. Super easy Rails integration
This the all the code I needed to integrate with Spreedly:

class Subscriber < ActiveResource::Base
 self.site = "https://secretapitoken:X@spreedly.com/api/v3/test"
end

That's it. Now I can call:
Subscribe.find(id)

and get back a Spreedly object I can interrogate.

4. No storing credit card numbers on my site
Don't have to worry about purging them from the logs, encrypting them, storing them in a secure place, or whatever. My site never sees credit card data so I don't have to care about it at all.

5. I don't have to track time left on a subscription
Spreedly will tell me when the customer's run out of time.

6. Nice notification when subscriptions have changed
I expose a controller action to Spreedly and they send me a list of Subscriber ids that have changed, when they've changed. If they can't reach me through some fluke of the internet they keep trying until they do.

7. Good documentation
Very easy to follow.

8. Great customer service
They usually got back to us in 15 minutes or so. Really.

9. Versioned API
We launched with version 3 of the API. They've since gone to version 4, but since there's a "v3" in that "self.site" above I don't have to worry about that. I can upgrade on my schedule.

Comments

Anonymous said…
And what do you do if you want to transition to a different company or service for handling of your recurring billing? Make all your customers re-submit their billing information?
March 24, 2009 at 9:23 AM
Jake Scruggs said…
We can pull all of the customer's information through the API anytime we want. We'd have arrange with Spreedly for a secure transfer of the credit card data -- which they agreed they would do.
March 24, 2009 at 1:11 PM
Unknown said…
Thanks for the Spreedly props Jake! You've totally made the team's day!
March 24, 2009 at 7:15 PM
Anonymous said…
That's good to know. I had browsed their sight and was unable to find any mention of exporting data.
March 25, 2009 at 12:12 AM
Post a Comment

Popular posts from this blog

What's a Good Flog Score?

I've been using Flog to measure the complexity of my Ruby code and I was wondering how others interpret Flog numbers. I'll go first with my opinions: Score of Means 0-10 Awesome 11-20 Good enough 21-40 Might need refactoring 41-60 Possible to justify 61-100 Danger 100-200 Whoop, whoop, whoop 200 + Someone please think of the children (note: these are scores for an individual method) The 20 - 60 range is interesting to me. Sometimes the complexity of what you're doing will justify the score and other times the method is in desperate need of refactoring. The highest Flog score I've seen in the wild was in the 300's. What's you're personal high and what do you think of my rankings? In other news, I've redesigned the look of my blog so if you only see my post through a reader you might want to stop on by, take a look, and tell me what you think.
Read more

SICP Wasn’t Written for You

The number of software luminaries who sing the praises of “ Structure and Interpretation of Computer Programs ” (referred to as SICP) is such a long list that you might think only a crazy person would take issue with it. However, to ignore SICP’s problems and continue to blindly recommend it seems just as crazy. SICP was the textbook for MIT’s introductory programming class and was a bit of a departure from other into to computer science textbooks at the time.  Wikipedia sums it up nicely:  “Before SICP, the introductory courses were almost always filled with learning the details of some programming language, while SICP focuses on finding general patterns from specific problems and building software tools that embody each pattern.”  Which sounds awesome, but does essentially say that abstract principles will be introduced before the nuts and bolts of a language.  If you think about that for a minute, you may see where the problems will be. When I was training to be a...
Read more

Point Inside a Polygon in Ruby

Recently my team needed to find out if a point was inside a given polygon and, as usual, we found some code on the internet that did what we wanted. And, as usual, there wasn't much explanation as to what it was doing. Here's the code (after we converted it to Ruby): 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 def contains_point? (point) c = false i = -1 j = self .size - 1 while (i += 1 ) < self .size if (( self [i].y <= point.y && point.y < self [j].y) || ( self [j].y <= point.y && point.y < self [i].y)) if (point.x < ( self [j].x - self [i].x) * (point.y - self [i].y) / ( self [j].y - self [i].y) + self [i].x) c = !c end end j = i end return c end end So, you know, it works and I'm grateful to somebody for posting it but we had no idea how it works. So we wrapped 2 tests around it (one where the point is not in the polygon and another where it is...
Read more