Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stripe: instant payment processing for developers

stripe.com

Post reply on HN
Print view View original

311–320 of 369 posts

Re: Stripe: instant payment processing for developers

#311

Post by tptacek »

Silhouette wrote: post #309
m0nastic wrote: post #252

Earlier quoted context omitted.

I'm obviously not tptacek, but I take his statement to mean that currently, PCI finds the following scenario acceptable: You have a site that takes payment info. Rather than process that information directly and store it you decide to use a service like this to silo out payment processing. This keeps your main environment outside of the scope of a PCI audit (as the only systems in scope for PCI are systems which eith…

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…

If you're a single XSS vulnerability away from transparently capturing credit card vulnerabilities, but there is no requirement anywhere in PCI DSS that your application be in any way hardened against XSS vulnerabilities, all PCI DSS has done is move the target slightly.

Re: Stripe: instant payment processing for developers

#312

Post by dminor »

m0nastic wrote: post #252
Silhouette wrote: post #247

Earlier quoted context omitted.

Perhaps you could elaborate, rather than posting vague innuendo about "how browser security works"? What specific danger do you see in the embedding scenario that could not arise anyway if the host system were compromised sufficiently to interfere with the embedded material?

I'm obviously not tptacek, but I take his statement to mean that currently, PCI finds the following scenario acceptable: You have a site that takes payment info. Rather than process that information directly and store it you decide to use a service like this to silo out payment processing. This keeps your main environment outside of the scope of a PCI audit (as the only systems in scope for PCI are systems which eith…

> This gives credence to the people who argue that PCI isn't really a security standard, but just a way to shift blame after a breach.

Which it is!

What is really needed isn't a better PCI, but a better credit card system - one where a breach has little impact on credit card holders.

Re: Stripe: instant payment processing for developers

#313

Post by boucher »

powertower wrote: post #307
jtheory wrote: post #302

Earlier quoted context omitted.

Huh. If you don't care about bad APIs or high fees, what do you care about? You don't give any clues. I sell software and subscriptions online; I'm working on the switch over the Stripe because I really appreciated their cleaner API and low fees. 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 confuse…

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…

Though it's hard to tell if this is just part of the sarcasm, or a legitimate concern, let me clear it up: you can sell things anywhere in the world with Stripe, you simply need to sell them from a US business entity.

Re: Stripe: instant payment processing for developers

#314

Post by boucher »

tptacek wrote: post #311
Silhouette wrote: post #309

Earlier quoted context omitted.

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…

If you're a single XSS vulnerability away from transparently capturing credit card vulnerabilities, but there is no requirement anywhere in PCI DSS that your application be in any way hardened against XSS vulnerabilities, all PCI DSS has done is move the target slightly.

Though to be fair, if you've got an XSS vulnerability, you can also just change the URL of the off site payment page to a phishing site, which most people will probably fall for.

Re: Stripe: instant payment processing for developers

#315

Post by Silhouette »

tptacek wrote: post #311
Silhouette wrote: post #309

Earlier quoted context omitted.

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…

If you're a single XSS vulnerability away from transparently capturing credit card vulnerabilities, but there is no requirement anywhere in PCI DSS that your application be in any way hardened against XSS vulnerabilities, all PCI DSS has done is move the target slightly.

I completely agree, I'm just wondering how that's any different to any other hosted integration.

Perhaps I misunderstood your original point as being too specific to the embedding situation. Would you apply the same criticisms to the other common integration strategy based on redirects?

If your intended point was that any legitimate business taking credit card details via their web site should be subject to at least some basic level of audit, then I think we are probably in agreement (though I do have a thing about card companies imposing security rules on merchants but then trying to leave merchants with all responsibility for any fraud anyway, which is a totally one-sided deal).

[Edit: As an aside, I'm not sure how this would work in a case where the merchant is using an end-to-end solution, which Stripe seems to be, and has no direct relationship with any other financial services. Presumably the responsibility then has to fall on the payment service, which would have to impose some sort of reasonable audit procedure on all of its clients?]

Re: Stripe: instant payment processing for developers

#316

Post by boucher »

brandong wrote: post #304

I see the Getting Started developers intro, but I'm having trouble visualizing what this can look like purely from the customers side. Do you have any live implementations you can link to as an example of a Stripe integration?

Stripe doesn't communicate directly with your users, so there is no standard look from a customer's perspective. We're providing the tools to build your own payment forms hosted on your own website. Perhaps in the future we'll look into helping by communicating more directly to customers.

Re: Stripe: instant payment processing for developers

#317

Post by boucher »

avree wrote: post #270

Stripe looks awesome for small scale business. At large scale, Braintree still has cheaper pricing ( http://www.braintreepayments.com/pricing ) and the monthly cost is negligible.

Pricing is pretty hard to compare directly between something like Stripe and Braintree. In particular, there is no one clear answer, because it depends on your own mixture of AMEX cards, international cards, rewards cards, etc. We have some medium sized businesses on Stripe who have run the numbers and come out cheaper with us, but that won't be true for every merchant.

Part of what we believe to be valuable here is the simplicity of knowing exactly what your fees will be on every transaction, and in aggregate. There aren't any surprises.

Re: Stripe: instant payment processing for developers

#318

Post by powertower »

boucher wrote: post #313
powertower wrote: post #307

Earlier quoted context omitted.

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…

Though it's hard to tell if this is just part of the sarcasm, or a legitimate concern, let me clear it up: you can sell things anywhere in the world with Stripe, you simply need to sell them from a US business entity.

Misunderstanding on my part. Fixed.

Re: Stripe: instant payment processing for developers

#319

Post by martin1b »

acabal wrote: post #59

Man... I literally just bit the bullet and opened a merchant account and gateway at Auth.net last week, and the second I do, FeeFighters comes out with their own superior gateway, and Stripe launches. Talk about bad timing for me :(

Makes 2 of us. Just finished integrating with Auth.Net. Yep, bad timing IF this is as easy and secure as everybody says.
Post reply on HN