My company started charging for things in April 2012, but I made the decision to use Stripe months before that, something like January 2012. Only 4 months after you launched!
We only did 1500 transactions on our launch day, yet at the time it was enough to break your service for a little while due to load. Your customer service at the time was really great and you refunded all the transaction fees for our launch day and gave us a list of all the customers who had tried and failed to make transactions so we could contact them.
I don't think I realised at the time how small you guys were. We are lucky that you guys didn't fail, and I doubt that the me of today would have relied on such a young company. Certainly we could have moved to a different payment processor, but losing all the saved card data would have sucked a lot.
So great work on that!
Can you please give at least one example or suggestion?
When selecting a user to change the plan, the modal takes about 3-4 seconds to populate the new plan dropdown. The new plan dropdown is like 200px wide, which makes managing multiple plans pretty cumbersome.
The main dashboard view only has Gross Volume, with no way to switch to other views (ie, no way to take into account refunds)
Event view is pretty cumbersome for managing things, as it shows only 20 events at a time. Also, event filters apply to all of customer payments, not one ( so going to filters resets whatever customer you were looking at )
Logs are labeled with non human readable things like "200 DELETE /v1/customers/cus_2fdyjF3lV1FYyc/subscription"
There's no dedicated "Name" field for customer details though there is a name field that lives under card details.
Here's a secret URL for you: https://manage.stripe.com/events?count=100 :)
I agree with this. I was wondering "What Stripe UI improvements?" because I am largely happy with the UI (very much so, actually). But there are corner cases that could use some tweaking. This is definitely one.
The main dashboard could have some more information, or could be customizable, I agree. Not high priority for me but would be nice.
http://pciguru.wordpress.com/2013/06/30/developers-beware-st...
Adding a bit more to be crystal clear here. The merchants customer will only see the address in the address bar for the merchant and will be able to validate the merchants public cert. No customer I know of would view the source to make sure that the reference to Stripe.js is in the source.
Additional edit to address Silhouette's point. Yes, an attacker can modify the <a href to go to their site as well, but unlike an embedded script the customer does have a chance to call BS and back out of the transaction after growing concerned by the domain transfer & doing a Google search to see if it's legit. They don't have any chance in the case of an embedded script. Now if we go back to my original concern, it's that merchants are being told that they simply need to implement Stripe.js & enable HTTPS. Modifying that statement to something like this would be far better:
"Stripe minimizes the scope of PCI DSS by removing the need to implement and audit security controls surrounding the transmission, processing, and storage of card-holder data. This does not; however, absolve Merchants from compliance with the PCI DSS & in order to assist with that we offer the following..."
And then the merchant won't be following one of Stripe's two basic rules for staying PCI DSS compliant any more, will they?
That aside, of course you want to keep your server secure. But if you can't, as a matter of practical security and protecting cardholders in the real world, how would it be any better to have your site intended to transfer entirely to a payment service on their own domain rather than just loading JS from that domain? An attacker who has compromised the security of the files on a merchant's server can change an <a href='...'> that should transfer to the payment service so it goes to a hostile site just as easily as they can change a <script src='...'> that should load JS from a payment service so it loads JS from a hostile site.
I would be really interested in it.
On a side note I see Australia is in Beta :D which is great.
Thanks
And since I was a one man shop, I just had my users to send me checks at end of the month. I was not the best organized person back then. So let's just say there were quite few uncashed checks. Really wish Stripe was around them.
"Anyone accepting credit card payments must be PCI compliant. Stripe makes it easy to do so:
Serve your payment page over SSL, i.e., the page's web address should begin with “https”, not “http”.
Use Stripe.js or Checkout to accept payment information and transmit it directly to Stripe's servers.
And you'll be PCI compliant!"
https://support.stripe.com/questions/do-i-need-to-be-pci-com...
If it were only so easy. I guess there's no need for the merchant to have a PCI program, properly implement SSL/TLS, have anti-virus, change default passwords, protect agains SQLi, XSS, command injection or any number of other flaws which would give an attacker access to modify the Stripe.js code or the DOM for the page used for the collection of card information within the merchant's same origin. Nope, none of this is necessary because Stripe says that a merchant only needs to use HTTPS & implement their Stripe.js to be PCI compliant.
It's interesting that this isn't how the PCI council sees things:
https://www.pcisecuritystandards.org/documents/Tokenization_...
Also, if you'd like to drop me an email at [email protected], would be happy to chat about PCI more.
While the PCI compliance issue may not be quite as simple as Stripe's documentation has previously implied, nobody else seems to be able to identify the kinds of serious compliance issues that patcheudor keeps implying we're all suffering from by using Stripe and following their existing advice.
https://www.petekeen.net/life-of-a-stripe-charge
Subsequent discussion here:
http://pciguru.wordpress.com/2013/06/30/developers-beware-st...
I appreciate your interest in the security of Stripe, I think we definitely share the same goals here (making everything as secure as possible). However, I think there's some misunderstanding in some posts (and in the blog post):
> [...] the Stripe.js code is instantiated within the user browser by an HTTP response from the server infrastructure owned by the merchant When Stripe.js is included within the user's browser by a (mandated https, not http) request, it comes directly from Stripe's servers, not from "the server infrastructure owned by the merchant."
Stripe.js isn't served from the merchant. It comes directly from Stripe. Stripe.js helps keep payment card data away from a merchants own servers.
Keeping card data away from someone's machines doesn't mean that they don't need to comply with the Payment Card Industry Data Security Standards, but it does make things quite a bit simpler.
In most cases it means that they're eligible for one of the light-weight self-assessment questionnaires.
PCI compliance, of course, shouldn't be where people stop thinking about security though. You're absolutely right that if the pointer on the merchant's site is changed to a malicious site, that's where the payment data will go. The merchant needs to keep that pointer safe in the same way that if you're redirecting to a hosted payment form or elsewhere, you need to make sure that isn't tampered with either. (A hosted form has the advantage that at least a customer can view the SSL cert but if they don't recognize the domain (or if the domain is obscure anyway), that's not much good.)
Being compliant with the PCI standards is important but it doesn't cover all of the very, very important points of web security.
We do take security very seriously, and if you happen to find a valid security issue with our service, we pay bounties[1] for properly disclosed vulnerabilities.
If you have any other questions, or would like to wax poetic about security or PCI please don't hesitate to send the security team an email at [email protected] or to email me personally at [email protected].
I think he has a point here. Certainly if the merchants web site is compromised, Stripe's PCI compliance won't prevent or detect the loss of credit card data (since it never reached the point where Stripe could protect it).
Yes, this is certainly true. This is why we also use the dashboard to ask the relevant questions from the PCI self-assessment questionnaires. https://support.stripe.com/questions/do-i-need-to-be-pci-com... gives a brief overview, but this discussion is making me think that we need to write something longer and more definitive. There's a lot of confusion around PCI pretty much everywhere.
In short, the fact that stripe.js is delivered from stripe DOES NOT MATTER, because the user CAN NOT reasonably validate this behavior.
I know you're not dumb over at Stripe; I have a hard time believing that you're not willfully lying. After all, "disrupting" onerous industry security standards is to your competitive advantage.
Patch is right, you need to be PCI compliant and Stripe (despite their recent funding) is apparently misunderstanding the problem with their approach.
And frankly, PCI compliance be damned, can ya'all not see how the "redirect to page" way is more secure.
Stripe hiding behind "our code is fine, only if you get hacked is it a problem" is, quite frankly, disgusting blame redirection.
In terms of accusation, my goal here is to ensure that Stripe.com and others who are working in this space are being as clear as possible with their communication, that's it. Stripe is going to address statements like the one I pointed out on their site & hopefully as an industry we can get to a point where everyone is a bit more clear on what falls in and out of PCI DSS scope.
I have three comments though if you're willing to listen!
- I think your customer service department (although they do a good job) the quality has gone down, I often have to now wait several days for a reply. I guess this is the inevitability of growth though. In an ideal world it'd be nice to go back to when I got same day replies :)
- We're a UK business. We take payments in EUR/GBP/USD. Like EUR, it would be nice to be able to withdraw our USD to our USD account in the UK! At the moment we're forced to withdraw it to our GBP account which is expensive.
- It would be nice to be able to hold up withdrawls. At the moment our account is flooded with lots of payments, it would be nice to schedule all payments to be weekly/fornightly or a specific day of the month. Make our accounting process a lot easier and cheaper.
Thanks for all the great work, I've been excited ever since I've started reading about you and am a big fan! (I got a tshirt on the way as well for reporting a small glitch which I'm excited to receive!)
For accounting, we've found that better reporting tools usually solve the need for less frequent transfers. Would one of the options at https://support.stripe.com/questions/reconciling-transfers-w... make this easier on you? Feel free to email me if not so I can understand more about your setup. Every part of Stripe should be incredibly simple, including accounting, and I want to make sure we get this right.
Re support: you're right that the replies have been slower than they should be, though that's getting better. Basically, our userbase grew massively in 2013 and our support hiring didn't keep up with it. I spend all of my time on scaling the team, and we've more than doubled the size of the team in the past couple of months. More hires are on their way. I realize our internal machinations aren't very relevant—you just care that the result is excellent—and I'd like to be clear that we're working on this. You should expect to see significantly faster replies and more ways to get in touch with us over the coming months.
While you should already be seeing improvement in this area, feel free to get in touch with me directly at [email protected] anytime. I'd love to hear any other feedback, and am more than happy to help with whatever questions you have.
We desperately needed Stripe and you guys delivered so quickly. Much appreciated.
only quip: price! would love to see a different pricing scheme for cheaper products. $0.30 fixed fee is a lot for carts that are only a few dollars!