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

321–330 of 369 posts

Re: Stripe: instant payment processing for developers

#321

Post by [deleted] »

Silhouette wrote: post #145
keeran wrote: post #118

Earlier quoted context omitted.

I've held off developing / launching a few small biz ideas because of the state of payment providers in the UK - ready and waiting to help you test when you're over here :)

I concur entirely (and have spoken with my MP about it). However, as far as I can tell, anyone using any of the more established "big name" billing services to collect payments for a UK company is almost certainly breaking at least one law on a "your business is at risk" scale. Stripe would have to be very special to do better. The usual culprits are VAT (I have yet to find a billing service that would actually allow…

[deleted]

Re: Stripe: instant payment processing for developers

#322

Post by tptacek »

Silhouette wrote: post #315
tptacek wrote: post #311

Earlier quoted context omitted.

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…

The disconnect I perceive here is that you seem to hope there's some technical solution that can factor out an unhardened storefront from a hardened payment processor. That would be nice, but I don't think it can be done today.

Fortunately for developers, PCI's response to this problem seems to be "LA LA LA I CAN'T HEAR YOU".

Re: Stripe: instant payment processing for developers

#324

Post by Silhouette »

tptacek wrote: post #322
Silhouette wrote: post #315

Earlier quoted context omitted.

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…

The disconnect I perceive here is that you seem to hope there's some technical solution that can factor out an unhardened storefront from a hardened payment processor. That would be nice, but I don't think it can be done today. Fortunately for developers, PCI's response to this problem seems to be "LA LA LA I CAN'T HEAR YOU".

> The disconnect I perceive here is that you seem to hope there's some technical solution that can factor out an unhardened storefront from a hardened payment processor.

On the contrary, I don't believe that can be done effectively within the architecture we have today. I just don't believe it can be done effectively for hosted integrations that redirect to the service provider either, so I don't see that the embedding approach is any worse than what was already in widespread use.

Moreover, given that it is unrealistic not to provide hosted payment services (since the overheads of doing everything in-house are prohibitive for almost any small business), I think the only useful response is to impose some basic level of audit on any site that is integrating with an external card payment system. But now you're more into economic/commercial/legal arguments than technical ones, because you have to consider what level of oversight is reasonable (given that any fool can set up a fraudulent site regardless of what you do, how much extra burden is it really sensible to impose on legitimate merchants), how it can be enforced (particularly if the site visited by the end user has no direct legal/commercial relationship with the card services companies), and whether there is a sensible balance between functionality/security and actually being able to operate in the first place as a merchant (which is a balance that the UK currently gets absurdly wrong, though I don't think the scenario we're discussing is why).

Re: Stripe: instant payment processing for developers

#325

Post by ThaddeusQuay2 »

It seems great, until you read the fine print, which I did, in its entirety, and what I saw is quite chilling, in terms of fees, fines, and other undefined costs incurred when things go horribly wrong.

"When a Chargeback is issued, you are immediately liable to Stripe for the full amount of payment of the Chargeback plus any associated Fees, fines, expenses or penalties (including those assessed by the Networks or our payment processors). You agree that Stripe may recover these amounts by debiting by means of ACH debit of your Bank Account associated with your Stripe Service Account, debiting your Reserve Account, or setting off any amounts owed to you by us. If we are unable to recover funds related to a Chargeback for which you are liable, you will pay us the full amount of the Chargeback immediately upon demand. You agree to pay all costs and expenses, including without limitation attorneys’ fees and other legal expenses, incurred by or on behalf of us in connection with the collection of any unpaid Chargebacks unpaid by you."

https://stripe.com/tos

I >dohttp://news.ycombinator.com/item?id=3039782

Re: Stripe: instant payment processing for developers

#326

Post by boucher »

kilink wrote: post #323

Any plans for supporting a DBA (doing business as) field as part of the API? Having only one identity associated with the Stripe account wouldn't cut it for us.

For now, we recommend just setting up multiple Stripe accounts; it's a feature I'm sure we'll add in the future.

Re: Stripe: instant payment processing for developers

#327

Post by boucher »

ThaddeusQuay2 wrote: post #325

It seems great, until you read the fine print, which I did, in its entirety, and what I saw is quite chilling, in terms of fees, fines, and other undefined costs incurred when things go horribly wrong. "When a Chargeback is issued, you are immediately liable to Stripe for the full amount of payment of the Chargeback plus any associated Fees, fines, expenses or penalties (including those assessed by the Networks or ou…

As you noted in your post, these terms are standard (and, essentially, required of us) in this industry. And as people suggested, chargebacks are not a big deal. They are far less common than people think, and usually they are resolved quite easily; all it takes is good communication.

Re: Stripe: instant payment processing for developers

#328

Post by kilink »

boucher wrote: post #326
kilink wrote: post #323

Any plans for supporting a DBA (doing business as) field as part of the API? Having only one identity associated with the Stripe account wouldn't cut it for us.

For now, we recommend just setting up multiple Stripe accounts; it's a feature I'm sure we'll add in the future.

In our particular case we would need somewhere between 50 or more accounts, so it's just not feasible. Having it as part of the charge API would be ideal. Glad to hear you're considering adding it as a feature.

Re: Stripe: instant payment processing for developers

#329

Post by ThaddeusQuay2 »

boucher wrote: post #327
ThaddeusQuay2 wrote: post #325

It seems great, until you read the fine print, which I did, in its entirety, and what I saw is quite chilling, in terms of fees, fines, and other undefined costs incurred when things go horribly wrong. "When a Chargeback is issued, you are immediately liable to Stripe for the full amount of payment of the Chargeback plus any associated Fees, fines, expenses or penalties (including those assessed by the Networks or ou…

As you noted in your post, these terms are standard (and, essentially, required of us) in this industry. And as people suggested, chargebacks are not a big deal. They are far less common than people think, and usually they are resolved quite easily; all it takes is good communication.

I appreciate the answers given to my question from several days ago. I appreciate that all of the loopholes need to be covered, using >standardusually< not a big deal. My concern is about extremes, particularly those which come out of malicious intent, perpetrated against me, through no fault of my own. With the way that these "one-sided" agreements are structured, it appears to be quite easy for me to launch an attack against a small startup's credit processing account, with the likely result being termination of said account, mostly due to the perception of risk which I will have created in the minds of the people who implement the TOS to which the startup agreed. If I can do this to someone's startup, then someone can do it to mine, and I can't be the only person who has thought of this kind of stuff.

Re: Stripe: instant payment processing for developers

#330

Post by boucher »

ThaddeusQuay2 wrote: post #329
boucher wrote: post #327

Earlier quoted context omitted.

As you noted in your post, these terms are standard (and, essentially, required of us) in this industry. And as people suggested, chargebacks are not a big deal. They are far less common than people think, and usually they are resolved quite easily; all it takes is good communication.

I appreciate the answers given to my question from several days ago. I appreciate that all of the loopholes need to be covered, using >standard usually< not a big deal. My concern is about extremes, particularly those which come out of malicious intent, perpetrated against me, through no fault of my own. With the way that these "one-sided" agreements are structured, it appears to be quite easy for me to launch an att…

And yet, have you ever heard of this happening? I don't mean to minimize your questions; I think there is some amount of trust involved. We're able to tell the difference between someone running a fraudulent business and someone who is being essentially DOSd. Simply having chargebacks is never going to automatically cause your account to be terminated.
Post reply on HN