collision

If you're using Sofort, then there's an off-site redirect involved and it's no longer as simple as entering two numbers.

You can already charge UK customers, but I presume you mean UK customers in GBP. This is on our roadmap to add. (Most of the heavy lifting is already done for the reverse in the UK.)

We're working on it.

We'd love to hear from you. We're hiring in the US, UK and in a few other countries.

https://stripe.com/jobs & jobs@stripe.com

We don't support making our daily transfers via wires, but if you have a US-routable USD bank account we can transfer USD to that without conversion.

Yes.

We realized we weren't using Stripe in-house at Stripe, so we decided to fix that.

We're going to add support for this.

It's user-dependent. Stripe provides users with some protections (e.g. against card-testing), and then users will verify their platform's sellers in a way that makes sense for them. Lyft and Sidecar collect drivers' licenses from drivers, and only pays them out in proportion to the amount they drive. Homejoy trains cleaners, and each user rates the cleaner. And so on. Fraud is heterogenous by nature.

(I work at Stripe.) When you create a seller via the API, both Stripe and Balanced do the exact same thing: verify the identity of seller. You can run a marketplace on either.

Edit: I'm using the words seller and recipient interchangeably: https://stripe.com/docs/api#update_recipient

Yeah, getting the statement text right makes a big difference. FWIW, Payouts was mostly designed for user-facing services (Lyft, Exec, Homejoy et al) where they want their own name to appear on card statements. If you're using Connect, each seller would have their own Stripe account and could have different card statement text.

The Google Groups webface is also getting good enough that you can keep up with some lists without having to actually subscribe to them via email.

A number of people at Stripe have families or have other social attachments. We try hard to ensure we're not making lifestyle assumptions when we hold social things. Some of this involves giving good advance notice, other times it's around timing. Trivial example: recently, we moved an internal talk series from dinner time to 4pm, so that people who don't stay for dinner aren't excluded. I think explicitly keeping things like that in mind helps.

Don't worry -- even if you don't get to play this week, we'll be releasing the levels afterwards so you can run them yourself at home.

It's definitely not intended that beginners can easily finish, but we hope that everyone can get something out of it. We were actually fairly happy with the conversion rate from start to finish last time. If everybody finishes, it presumably means the later levels weren't hard or interesting enough.

We hope that people new to web security can solve the first few levels with some work and inspection, and the later levels with hints from others or a significant amount of research into the topics.

At the end of the day, the point of the exercise is to expose realistic vulnerabilities for fun and education. We try to make them similar to how they'd be in the wild.

"Insure" can also take the latter meaning; I think it's an American/British thing. The New Yorker uses "insure" for both meanings, and it trips me up every time.

Significant market share is enough for antitrust to be a concern. You don't need a monopoly, and indeed most companies engaging in anti-competitive behavior don't.

Stripe returns address verification (AVS) results when you add a card, so you can reject mismatched addresses if you so choose.

To be clear, we're only against ticketing systems that worsen the experience for the user. Ticketing systems on the backend are great, but having an automated mail system spew at you is a less-than-ideal experience. Email from real humans is what I want as a user of a support system.

We're actually using OSQA on the backend which, as you might guess, is open-source.

http://osqa.net

Ergotron: http://www.ergotron.com/

We think a lot about risk, and actually do more verification than traditional merchant-account providers. We just don't make you do busywork like mailing us a voided check or a utility bill.

We certainly believe that the approach is sustainable, and the data so far strongly supports this.

I tried Clicktale, and it didn't work very well. I gave up half way through.

Observer (http://observer.no.de) seems like a good new solution.

Possibly of interest: http://izettle.com/

It's entirely up to you: there's no mention of Stripe. Most of our customers simply put their domain on the statement.

> Maybe if you're charging millions of dollars, you should use a regular merchant account.

You should probably still use Stripe in this case. (Some people already are.) We scale up pretty well. Everything that you get with a merchant account (correct statement text, money held in your name), you get with Stripe.

Additionally, there are some advantages for large businesses that would make Stripe more attractive than a merchant account: transfer reporting and detailed reconciliation tools make a big difference to people doing high throughput.

This is a technicality, but there's a difference between a Ponzi scheme and a pyramid scheme. A Ponzi scheme needs an information asymmetry: investors don't know that their money is being used to pay off previous investors. A pyramid scheme is open about the way it works and the pyramid nature, but people invest anyway.

Since Groupon's investment and revenue strategies are known to all, this would be closer to a pyramid scheme than a Ponzi scheme.

Wait, so what's the answer? Is there a mid-runway bench?

"On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?'"

$30, actually -- Pages, Numbers and Keynote are all $10 each.