12 comments

[ 2.7 ms ] story [ 35.1 ms ] thread
Cool article. Need screenshots :-)
Agreed, visual examples of integrations would spice up article
Agreed, except... we actually don't have a UI to show. The transparent redirect approach that Core takes means that we'd just be showing you our customers' payment pages, which while spiffy, don't really tell you anything about the integration. Which is kind of the point - our goal is to be invisible.
Can we use this with normal spreedly :-) ? I have always been a little unsure of the differences between core and non-core?

(Ben from Olark)

Today there isn't any integration between our classic Subscriptions product and Core (though we do have some customers using them side by side regardless). It's something we'd very much like to do, but it's not at the top of the list yet.
What specific parts of PCI-DSS do they cover?
Spreedly Core isn't for handling specific requirements per se, but changing the entire scope of compliance. Basically, if you're only only doing card-not-present transactions and you never store, process or transmit cardholder data, you qualify for SAQ A. The full eligibility requirements for SAQ A consists of the following:

  * Your company handles only card-not-present (e-commerce or mail/telephone-order) transactions;
  * Your company does not store, process, or transmit any cardholder data on your systems or premises, but relies entirely on third party service provider(s) to handle all these functions;
  * Your company has confirmed that the third party(s) handling storage, processing, and/or transmission of cardholder data is PCI DSS compliant;
  * Your company retains only paper reports or receipts with cardholder data, and these documents are not received electronically; and
  * Your company does not store any cardholder data in electronic format.
You misspelled Spreedly as Speedly in the article.
My first reaction after going to the parent website (http://spreedly.com/) was that I don't understand what spreedly does exactly or why I would use it (vs. my paypal or 2CO account).

I'm guessing that Spreedly offers an API/front-end that 1) stores the credit card info for immediate (and future) billing + subscription purposes, then 2) sends the transaction to my paypal, and 3) offers some type of a billing/subscription panel I can use to manage everything.

The money stays in my paypal, and spreedly then bills my own CC for the use of the service.

I see the usefulness of the independent API and control panel, but...

Is that data (customer CC info) really transferable from spreedly to let's say more than 1 other provider right now (like Braintree)?

I know the spreedly guys, as well as outside devs who independently adopted spreedly. Everyone I know has said what a pleasure it has been to use the Spreedly API.

If you want a feature list, you can always go hit their site: http://spreedly.com/info/features

The data is absolutely transferrable today - we've had multiple customers leverage that transferability to switch (or augment) their gateway with just a configuration change.

Of course, it's not just about data portability; API consistency is a big deal as well. If PayPal (for instance) decides to lock down your account and not let you transact any longer, you don't just have to worry about getting your data out, you are also looking at another whole implementation cycle around a new API. Even if it's just a day of work (and usually it takes longer), that's a day you could've spent on your product instead of mucking around with gateway API's.

There are of course libraries that help make gateway API's more consistent, but as a committer on what is in my opinion one of the best - ActiveMerchant - they only get you so far. For instance, Core gives you transparent redirect on top of any gateway we support. That means lowered PCI compliance requirements and a great experience for your customers, and there isn't a library out there that can do that for you.