Live data from Hacker News

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

spreedlycore.com

21–29 of 29 posts

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

#21
post #3

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 prov…

> 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.

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.

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

#22

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…

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.

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

#23

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…

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.

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

#24

Your copy needs work. Most importantly, you need to state what Spreedly Core is before the vague marketing gobbet. Even, "Spreedly Core is . // 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.

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

#26
post #2

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.

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

#27
post #5

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.

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

#28

Earlier quoted context omitted.

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 st…

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.

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

#29
post #4
post #3

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 prov…

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

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.

Post reply on HN