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

361–369 of 369 posts

Re: Stripe: instant payment processing for developers

#361

Post by sukuriant »

jtheory wrote: post #300
bprater wrote: post #201

Earlier quoted context omitted.

You may want to seriously consider working on fleshing out this plan now. Paypal supposedly has thousands of people working in fraud control. When word gets out that Stripe makes it "dead simple" to process credit cards without a merchant account, the vampires will come out to play. And I'm truly excited for a service like yours. We need this. But be prepared.

PayPal isn't just a payments processor, so they have many more fraud scenarios to worry about than Stripe. You can't use Stripe unless you have a bank account set up to receive funds, and you can't use Stripe to pay for things -- i.e., you can't launder fraudulent money by buying a ton of stuff online and having it shipped to an abandoned house. In Stripe there's a very simple money trail, plus there's a week's delay…

I became concerned with reading this statement. We need a lawyer to understand liability for laundering with regard to systems like Stripe

Re: Stripe: instant payment processing for developers

#362

Post by leon_ »

vertis wrote: post #261
barrydahlberg wrote: post #227

Earlier quoted context omitted.

I would love to see someone drag it kicking and screaming outside of the US. :(

Providing international support is probably in the 'too hard' basket.

Too hard or not - it's a critical feature. They can lure me with the most advanced APIs and super low fees. If they can't treat international customers (on the consumer side at least) like domestic ones then it's a deal breaker.

There are enough alternatives that have support for things like the Euro. They maybe don't have a fancy API but they work well enough and I can accept credit card payments from Uzbekistan in their local currency.

Then there's the part where they only accept US developers. While I can understand that again there's enough alternatives (FastSpring for example) who don't mistrust me because I'm living in the EU and will do payment processing for me.

I understand they wanted to launch ASAP with a MVP but maybe they cut down the wrong features. For me they are now another lazy payment processor who won't accept international customers and they will have to do some work to get rid of that stigma.

Re: Stripe: instant payment processing for developers

#363

Post by ragesh »

superasn wrote: post #336
boucher wrote: post #105

Earlier quoted context omitted.

We totally get it. We're working on expanding to other countries right now, it's one of our top priorities.

Please think of India when you do. Paypal recently botched big-time in India (search paypal pan card) and there is a big hole that needs to be filled. We have a volume of about $500k and with Paypal failing us big time, we've ourselves been searching like crazy for the past one week for a good payment processor. Alertpay was looking most promising until I came across this post. Unfortunately, since stripe is US only,…

Just curious -- why is PAN a problem? Is it hard to get a PAN for your business?

Re: Stripe: instant payment processing for developers

#364

Post by jtheory »

boucher wrote: post #314
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.

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.

All of these things fall into the same boat, security-wise -- so by my interpretation, the PCI rules make sense here.

If the attacker can insert their own code that says "hi there, we may have to close the site unless we can get some donations ASAP - please help!" followed by a form for CC data, that's that. It doesn't matter if they normally accept payments by redirecting to PayPal, or if they use an iFrame, or the Stripe JavaScript approach. It's all the same at that point, security-wise.

So let this be Bucket A, for websites where CC info doesn't touch their servers -- this is their risk profile. If a site in Bucket A is compromised and it takes a month before the complaints add up and the host shuts them down, that's a month's worth of stolen credit cards (this is not "worst case", but let's assume the thieves aren't terribly patient and start selling card info soon after stealing it).

Bucket B is for sites where the CC info DOES touch their servers. For them, CC data may be recorded on the server (intentionally into a data store, or even accidentally into log files of some kind). This is a different security risk. A site in this category could be compromised, and in half an hour 10 years worth of their credit card info could be stolen.

To steal 10 years worth of CC data from a site in Bucket A is naturally much more difficult.

If you've got to draw a line somewhere, that's a reasonable one.

Re: Stripe: instant payment processing for developers

#365

Post by jtheory »

boucher wrote: post #152
seanstickle wrote: post #148

Does Stripe allow delayed payments? That is, people put in their credit card details, Stripe authorizes the card but doesn't capture the amount charged, then we can approve/decline the transaction, and then Stripe can capture or void the transaction? We have a situation where we need, for legal reasons, to verify that people giving us money are allowed to do so, and we really don't want to have to reverse the charge…

We don't support what's typically known as separate auth and capture in the payment industry (though we may in the future). Typically, we recommend just capturing the card information by attaching it to a customer object, and then making a charge later. If you're charging a really high amount, or for some reason need a 100% guarantee that the charge will succeed, then right now you'll have to make the charge and then…

Note, though: when you refund the charge, the fees you paid aren't refunded to you.

This was the one downside of Stripe for me, vs. PayPal (though it's pretty minor -- I only have a handful of refunds a year... but I offer them all the time, and I've always liked feeling free to do that).

Re: Stripe: instant payment processing for developers

#366

Post by jtheory »

sukuriant wrote: post #361
jtheory wrote: post #300

Earlier quoted context omitted.

PayPal isn't just a payments processor, so they have many more fraud scenarios to worry about than Stripe. You can't use Stripe unless you have a bank account set up to receive funds, and you can't use Stripe to pay for things -- i.e., you can't launder fraudulent money by buying a ton of stuff online and having it shipped to an abandoned house. In Stripe there's a very simple money trail, plus there's a week's delay…

I became concerned with reading this statement. We need a lawyer to understand liability for laundering with regard to systems like Stripe

If you're laundering money, you might want to consider in-house legal expertise, as well as in-house payments processing expertise.

If you're not laundering money, then (all other things being the same), you should prefer Stripe over PayPal, since it would be quite hard for someone to use Stripe for this purpose, hence they will have fewer money-launderers to deal with, hence you have less risk that you'll set off some obscure alarm and they'll lock up your account for months.

In any case, if you sell anything (online or off) you may want to learn a bit about the various risks and liabilities. Fraud does happen, and some businesses are at far higher risk.

I'm not sure the average lawyer will help much, though. They can tell you "yup, if someone buys a diamond from you with a stolen credit card and you ship it, you will not get to keep that money even if the diamond isn't recovered" (but don't you know that already?).

The more important advice is technical, and it's about all of the things you can do to reduce the risk of that ever happening to you.

Re: Stripe: instant payment processing for developers

#367

Post by sidwood »

boucher wrote: post #11
almost wrote: post #8

US only at the moment. Anyone know if they have plans for the UK? I would dearly love to say goodbye to PayPal forever.

We're definitely working on expanding to other countries. There's no definite timeline just yet, but it's one of our top priorities.

+3 for the UK.

Re: Stripe: instant payment processing for developers

#368

Post by dgoujard »

boucher wrote: post #11
almost wrote: post #8

US only at the moment. Anyone know if they have plans for the UK? I would dearly love to say goodbye to PayPal forever.

We're definitely working on expanding to other countries. There's no definite timeline just yet, but it's one of our top priorities.

+1 for France

Re: Stripe: instant payment processing for developers

#369

Post by HistoricalWalks »

boucher wrote: post #11
almost wrote: post #8

US only at the moment. Anyone know if they have plans for the UK? I would dearly love to say goodbye to PayPal forever.

We're definitely working on expanding to other countries. There's no definite timeline just yet, but it's one of our top priorities.

Germany please!
Post reply on HN