Stripe: instant payment processing for developers

That sounds great! Can't wait to get started. I've been dreading building out the recurring payments portion of our website, but reading about Stripe is easing the stress. The docs and are excellent and the approach is very sensible.

thirded

I'm not sure I understand the PCI implications of using the API. If I use the Create a New Charge example on the homepage in my code, aren't the credit card details going through my server?

*Edit: Nevermind. After reading through the API, I learned you can use a token instead of the card details.

My point is that to switch from PayPal and 2CO (which is what I use now + as is working just fine for me) I need more benefits then..

1) Getting to set up and manage another new account.

2) The pleasure of getting to rewrite (and test + debug) my backend payment process.

3) Getting a slightly cleaner API (that I'm never going to see after I implement it).

4) Saving an extra dollar on every transaction (of a $125 sale).

5) Working with a relatively new, and in that effect, inexperienced payment processor.

1 and 2 are not benefits to me at all. 3 and 4 I don't care about because they are marginal at best. 5 is a killer.

So why would I use Stripe?

> I can set up Stripe to handle processing for me completely transparently, and still without passing credit card data through my servers.

Same as it is now.

> I've been using PayPal because it's cheap and easy, but they screw up many foreign payments (that have worked fine when run through Stripe), the whole "eCheck" thing confuses the hell out of people, and that whole "no, you don't have to create a PayPal account" thing. It's just unprofessional.

Without experience, Stripe will screw up even more. If not on this part, then definitely on other parts. It's just the way it works.

Nothing differentiates Stripe for me from the rest of the bunch and I'm not going to fall over backwards putting in more work to switch to Stripe just because someone says the API is cleaner.

Give me an actual benefit and I'll consider.

I'm not disagreeing with your example, but isn't that a much wider problem? After all, any business or individual can set up a web site, stick an official-looking form on it, and harvest card details. They don't need any sort of payment processing infrastructure to do that, and clearly nothing PCI DSS says can protect against all malicious strategies for compromising card details.

My understanding was that the parts of PCI DSS we're considering were intended to cover carelessness where a legitimate business collects customer details but then leaves them vulnerable due to internal security failings. If the details don't hit the internal network, those failings can't happen, so it is reasonable to exclude them from the scope of the corresponding parts of PCI DSS.

Beyond that, I'm not sure I see any difference between the embedding scenario and the common practice of redirecting to a payment service's own web pages when a customer reaches a certain point in the order process. If you're exposing a vulnerability that lets an attacker compromise the embedding, they can almost certainly compromise the redirect in the equivalent case as well, and in reality it is unlikely that most customers would notice even if there were clues to give away the attack in some cases.

I'm also not sure what you mean by keeping your main environment outside the scope of a PCI audit. For the payment gateways we've been looking at that offer both hosted and embedded integrations, it is common that the hosted one has minimal audit requirements but the embedded one comes with certain audit obligations for your web site even if you're relying entirely on their system to handle the card details.

Now, if this isn't a mandated practice in PCI DSS, then I do see your point; I've always assumed it is, since everyone we've looked into seems to do it, but in fairness I haven't just looked it up today. However, if that is part of PCI DSS then in fact sites using the embedding strategy are subject to more rigorous scrutiny than those that simply redirect, even though essentially the same attack vectors are probably available for both.