Hacker News new | past | comments | ask | show | jobs | submit login
Hard Times in Silicon Valley? Not for the Payments Startup Stripe (nytimes.com)
79 points by Reedx 30 days ago | hide | past | web | favorite | 42 comments



Gather round kids. There was once a day where processing payments online was something that you signed up for with a fax machine, or a merchant processing salesperson. You might even walk into a bank to get a merchant account, then they would sell you an online gateway for $20-99/month plus transaction fees. If you were lucky, it was Authorize.net, not some 5th party proprietary garbage with a ColdFusion SDK. Not to say Authorize.net was any fun at all to work with, but at least there was a Ruby Gem for it that mostly worked. Payment processing was hard. PCI audits sucked. Millions of full credit cards were stored in MySQL, unencrypted because it was left to the developer to engineer security. REST API? Hah. Hope you know SOAP and XML, and you're using the correct schema version.

Stripe made untold pain and suffering disappear. Congrats to them for getting rewarded for doing so- they have unlocked billions worth of economic value by making that process easier.

PS. Here's a fun little quote from the Authorize.net docs today, 2019-09-19:

The Authorize.Net API, which is not based on REST, offers JSON support through a translation of JSON elements to XML elements. While JSON does not typically require a set order to the elements in an object, XML requires strict ordering. Developers using the Authorize.Net API should force the ordering of elements to match this API Reference.

Do you know how to force a JSON object's elements to be specifically ordered? I don't.


Is simple. You construct the blob of JSON by hand, just cat some stings together (or implode with "\n"). Then it's real easy to duplicate keys too. (JK, it's stupid).

Fun fact tho, the PostgreSQL jsonb data type sorts the keys, and seems to put shorter key names first, then keys with the same length in lexographix order - neat!


Geez --- dug up 15 year old code that called Authorize.net. It was a DLL and the response looks like it was a comma separated string --- probably predates their XML API.

At least the credit card #s were encrypted before storing them to MySql :).

https://github.com/jmathai/photos/blob/master/includes/class...

FYI ... I'm not looking for a code review.


Dsig technologies, such as JSON Web Signature, require "canonicalization" (C14N), in order for the hashes to be consistently generated and then signed and verifiable.

Here is one approach: https://tools.ietf.org/id/draft-rundgren-json-canonicalizati...


I integrated a storefront with Authorize.net about 6 years ago. The API was dead simple: a URL endpoint with lots of query string parameters. It ended up being ungodly long, but it was much easier than PayPal.


That’s pretty funny. FYI, object order in JavaScript is a bit complicated, but in practice these days it will maintain the order of key declaration and insertion.


ha, good. Yes, authorize.net made some things easier, especially around a time when Rails was picking up and a handy ruby gem called activemerchant was available -- going on to power a related/not-related giant, Shopify.


It's pretty much because that API is written by someone who hates his/her job


What about Braintree?


I am always going to regard seeing the simplicity of the first Stripe payment widget, realizing it was amazing, and not immediately breaking down the door to work there as a major career mistake.

That mistake will only be one upped by seeing the signs in the windows in Palo Alto of the original Google logo and then typing it in at home, being amazed, and not breaking down the door to work there. :)


Ha! Jerry Yang used to camp out at my place or my friend's house in Tokyo when he went to a VLSI seminar as a, I guess, poor VLSI PHD candidate/student.

We used to chat late at night, and I would say: "Jerry! Nobody is going to advertise on your and Dave's bookmark list!

Oops.


Isn't it more "hard times for Silicon Valley companies that don't make money and/or makes losses that grow with increased users"?


Indeed, it would seem that some companies are successful while others are not!


Crazy!


The most egregious such company (WeWork) actually being an NYC company.


Uber and Lyft both make losses that are directly proportional to their usage. Eg more users or more trips will only ever increase their losses.

WeWork makes a lot of money for the CEO - I recall he used a large amount of money he cashed out during earlier rounds to buy the building that We leases.


That's equally genious and stupid. WeWork has to be successful to be able to pay the lease. If WeWork is successful then he can continue to make money from WeWork via being a CEO. He should have 'diversified'.


It's even better - people clearly need office space, so even if WeWork fails he can lease to other people.

If WeWork fails to pay for their lease he can take them to court - and I would not be surprised if there are some fun creditor priorities in the bankruptcy terms of the lease agreements.

Seriously, I appreciate screwing the VC funders, but it does kind of demonstrate the kind of guy he is.


If WeWork fails it will likely be because people don’t need office space (i.e. a recession).


Much like Uber and Lyft, we work runs at a loss that scales with usage. In the event that continually losing ever increasing amounts of money somehow results in bankruptcy all of the people currently leasing office space will probably try to lease the building space directly.


WeWork is somewhat different. Its deflated valuation is because of a creative governance and self-dealings, rapid growth, and a tech-like valuation. If they paused expansion, they're basically Regus with better decor and more risk in a recession. Fundamentally, their business is viable, even without growth.


If you want to be geographically technical about it, Stripe is not a Silicon Valley company, but rather a company in a nearby city called San Francisco. Both Stripe and WeWork do seem to follow the "silicon valley model", however.


Okay, fair enough. Hard times for most of Silicon Valley then ;)


Google was founded right before the dotcom bubble burst.

Yeah, we are still headed for a downturn/correction/crash or what have you.

But valuable companies will continue to be.


Stripe "sells shovels". People want to exchange money, that will always be a basic tenet of commerce, and Stripe facilitates that. Bravo Stripe.


Stripe goes a step further, and makes it easy for the shovel-sellers and the shovel-buyers to get what they want. Good on 'em!


How does everyone deal with sales tax/VAT collection with Stripe? If selling software licenses for example. It seems like you have to use a third-party solution [1] and wondering why Stripe doesn't provide such a service themselves.

[1] https://stripe.com/docs/orders/tax-integration


We introduced the Tax Rates API earlier this year to help with this: https://stripe.com/docs/billing/taxes/tax-rates. It doesn't do everything just yet, but we're getting there!


Hey that's great! Thanks, will give this a go.


Stripe has an actual product that businesses actually use. They aren't playing the underpants gnome game of:

1.) Light money on fire to grow

2.) ???

3.) Profit!


I'm so glad to see this article and the other front page one on Stripe. I see so many stories about "WTF" unicorns like WeWork and Uber, so it's great to see a company that provides real value, creating products that lots of other companies are willing to pay for, and that seems like it has such genuine founders and a great culture.


To be fair, WeWork has an actual product that businesses actually use too.


Selling dollars for 95c is a game anyone can play.


... anyone that can seduce VCs, speak charismatically and preferably has a prior track record.


Including the Federal Reserve.


So do Uber and Lyft--this isn't the dot-com bubble. Their issues is they all have quirks that were blissfully ignored pre-IPO. All these companies are running proven business models that can work.


There is a reason why a little known company called Adyen is a $25b company on its own. Despite being less developer friendly they have contracts with way more big money enterprise firms...your Facebooks and Googles and Ubers of the world.

Stripe might be great for small companies or regional ones but there are many reasons why they haven’t won over high volume global enterprise cos yet.


Amazon isn’t a big company? How about Target? Digital Ocean, Slack? Lyft?

https://stripe.com/customers#b2b-platforms

This list isn’t exhaustive, it’s just a few of the companies that have OK’d being put on the list.


Depends on the company, but absolutely no way that Stripe processes all of Amazon or Target’s payments. It is a minority of payments, at best. And the WSJ article explains that Lyft is trying to in-house payments away from Stripe to save money.

I’m not trying to rag on Stripe by the way, but I have worked in payments at one of these large tech cos that did not work with Stripe. They didn’t start trying to target enterprise customers as their initial target base, and there are simply things that enterprise customers expect more than developer friendliness when it comes to choosing a gateway or processor. That’s all.

For some context for why Stripe is not necessarily suited for enterprise see what Finix Payments is doing https://www.finixpayments.com/ - the value prop resonates much more with enterprise...would say they are basically a developer friendly Anti-Stripe.


Amazon has direct integrations for payments in the US and most major countries, but farms out payment processing in certain low volume regions to Stripe.

Optimize a region's payment processing as volume increases is what Amazon is doing internally...


It's weird to see Adyen referred to as a "little known company". Here in the Netherlands everyone knows Adyen, but most people have never heard of Stripe.


Adyen also actually do physical card terminals hooked up to an API, which for Stripe is currently invite-only and only available in the US and Canada.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: