Spreedly Core - API powered payments w/o burden of PCI compliance | Hacker News Reader

Spreedly Core - API powered payments w/o burden of PCI compliance

spreedlycore.com

32 pointsbradleyjoyce27 comments

I heard about this from the team a few weeks ago, and am excited to take it for a test drive with BCC sometime after my development schedule gets less nuts.

Basically, instead of doing the traditional "send people off to Paypal to pay" routine, you have a form on your site which posts to a Spreedly server. Spreedly then redirects the user to you. You validate the token (similar to catching someone from an OpenID provider) and, if successful, do whatever was required to effect your purchase.

From the user's experience, it sure looks like they were on your site the entire time, but their payment details only ever touch Spreedly's servers. You interface with Spreedly on the backend to do any sort of charging logic that you want -- subscriptions, one-off charges, weird business logic specific to your application, whatever. (This is the main value add over the regular Spreedly subscriptions thing, which works very well if your subscriptions work exactly like Spreedly subscriptions and, apparently, less well otherwise.)

Since the data never touches your servers, you never need to go through PCI compliance work.

The big win I perceive for my business is that my checkout forms will only ask for name, credit card number, and CCV, hopefully increasing conversions versus Google Checkout / Paypal.

Friendly reminder:

You'll still need your own SSL for your checkout page, even though you're posting to https://spreedly.com

That's what I thought.

I really hope that they make sure and point this out in bold font in all the docs.

Right now I don't see a mention of it anywhere and if people start to use this without SSL on their checkout page, there's going to be big trouble.

Totally correct, and we need to re-iterate the SSL requirement in a few places. Thanks for pointing that out.

Can't you do some degree of enforcement--even a reminder--by checking the referer header? Might not want to rely on it by refusing to process if it's not there, but perhaps making another hoop to jump through to try to make it easier to do it the right way. Like, a different API call for backend transactions that doesn't require a referer.

You still have the odd user cloaking it, though.

What Spreedly is offering (transparent post to payment processor, redirect back to retailer) is the same as what Braintree is already offering with PCI compliance built in.

That said, we're not happy with Braintree since they messed up an account transfer of ours.

The biggest point I'd like to make is that it sucks once you've got your customers in a recurring plan (Spreedly, Braintree, PayPal, etc). If you're not storing their card numbers, the attrition rate should you choose to change processors is unknown and possibly greatly damaging.

Our philosophy is one of "you own the data". We've done dumps for customers of our Subscriptions product, and we'll gladly do them for Core customers as well.

We see this as one of the significant value adds of Core - avoiding lock-in, including lock-in to Core itself.

Make this an option, escrow if requested.

> Since the data never touches your servers, you never need to go through PCI compliance work.

Is that actually true? My understanding is that since the HTML form is still served up by your site, you'll still need to go through PCI compliance (although it will be easier with no data stored), since a compromise of your server would compromise card data.

From the email they sent out to current spreedly customers: "while you can already do this with our Subscriptions Payments API, doing so places the burden of PCI compliance on your shoulders. Core keeps the PCI burden on our side and allows you to focus on growing your business."

not sure exactly how the specifics of this will work...

Our understanding after talking to multiple QSA's about the transparent redirect is that it allows the merchant to legitimately claim that they do not "store, process, or transmit" credit card data, which means they only have to fill out SAQ-A.

And trust me, you definitely want to fill out SAQ-A.

Spreedly CEO here...

So, we weren't quite ready to land on the front page of HN, but mission accomplished - we now have a whole list of smart people to invite into the beta, so thanks to bradleyjoyce for giving us that nudge.

I'm going to work through the questions that have come up in the discussion - good prep for the FAQ page I need to write - but feel free to email me directly if you have any other questions or just want to chat about Core (my email address is in my profile).

I'm very excited that someone's finally doing this. They have the two key parts down that nobody else seems to offer for small/medium businesses:

- A PCIDSS compliant payment information store that's above the level of the payment gateway. The big win is that if you decide to switch gateways (or are forced to switch gateways, because you switched merchant account providers and can't always just relink your gateway to a different bank), you can still keep charging recurring payments to your customers without asking them for their payment info again.

- You can take the info with you if you decide, for some reason, to stop using Spreedly Core. And I trust they actually have the process in place for doing so, because it's coming from the Spreedly guys that have been doing this for a while already, not someone new.

We do indeed have the process in place for sensitive data exports - it's a bit involved, as it has to be, but we've done it more than once for our Subscriptions product.

Your copy needs work. Most importantly, you need to state what Spreedly Core is before the vague marketing gobbet. Even,

"Spreedly Core is <5-10 word description>. // With Spreedly Core you can focus on who you want to charge when, and we'll take care of the rest. [...]"

Our copy needs so much work. Wasn't really counting on hitting the front page of Hacker News today...

Good call on having the pithy 5-10 word description - that's on my short list now.

I've never done consumer facing payments so I don't quite understand what are they selling here.

Why not use Paypal directly for example (since that's one of the gateways they support)?

My question might sound silly but in B2B you just use wire transfers. So, I don't see the need to stack up too many layers for payments when each layer wants some money for the service they provide.

Is their main feature the fact you could switch gateways -- ie. they are selling an API wrapper?

There are a few key value props:

* Your PCI compliance burden is significantly reduced. * Card storage is a seamless process, and at the end of the day you own the card data. * You can easily switch gateways (or balance across multiple gateways). * Our API doesn't suck, which doesn't sound like much until you've had the misfortune to implement against a few gateway API's.

And there are other value props we'll be rolling out as time progresses - there's a lot of cool things we can do to improve the life of anyone collecting money online.

For german users a similar service is offered by 1&1 (iPayment, with "silent CGI"-mode). The form on the site is sent to the ipayement servers and those verify the transaction data, call a URL on your servers with the unique transaction token and success/error message, and only redirect the user back to your site after the callback is finished. Works pretty well, the credit card data never touches your server but the user doesn't notice that he left your site.

This is awesome! I've been waiting for this for a while. Now I don't need to route through PayPal or any other nonsense. Nice and easy, just the way it should be.

How would this work for things like 3-D Secure where you need to be redirected to the card issuer's website ?

It doesn't work/help yet, but improving the 3D-Secure process is in our sights. And it could definitely use improving.

Could we get some indication of what gateways are supported during the beta?

as it's an extraction of http://spreedly.com, I imagine they would support the same gateways listed here: http://spreedly.com/info/payment-gateways

That's correct; we'll rapidly (and I mean rapidly) add any of the gateways on that list to Core as beta customers request them. And we can probably add gateways that aren't on that list - just drop us a line to double-check. In the meantime you can kick the tires with the Test Gateway today.

I want this so much.

That sounds amazing if true, however the design is not trust inspiring.

There's a lot of content still to get up, and a lot of design polish still to be applied. We're not quite ready for a public launch yet, thus the "these guys are just getting started" ghetto look. That said, our Subscriptions product (https://spreedly.com) has been around for 3+ years and is still going strong, so we're in this for the long haul.

Reply on news.ycombinator.com