With Stripe, all a startup had to do was add seven lines of code to its site to handle payments: What once took weeks was now a cut-and-paste job.
<form action="/your-server-side-code" method="POST">
It's a nice headline, but it really leaves out the tremendous amount of back-end work that went into making that front end easy to use.
<form action="/your-server-side-code" method="POST"> <script src="https://checkout.stripe.com/checkout.js" class="stripe-button" data-key="pk_test_6pRNASCoBOKtIshFeQd4XMUh" data-amount="999" data-name="Stripe.com" data-description="Widget" data-image="https://stripe.com/img/documentation/checkout/marketplace.png" data-locale="auto" data-zip-code="true"></script></form>
<form action=/your-server-side-code method=POST><script class=stripe-button data-amount=999 data-description=Widget data-image=https://stripe.com/img/documentation/checkout/marketplace.png data-key=pk_test_6pRNASCoBOKtIshFeQd4XMUh data-locale=auto data-name=Stripe.com data-zip-code=true src=https://checkout.stripe.com/checkout.js></script></form>
Paypal was ugly to work with, felt crufty, etc. Stripe had pip installable modules, awesome documentation (live code samples in docs and sandbox), and was easy to integrate into our tests.
Paypal has no place being used by anyone trying to start a company. They are awful.
https://news.ycombinator.com/item?id=14463971 (2 months ago)
Stripe launched a fraud detection tool in October 2016; not sure if this comment took that into account.
Just generally the sandbox was horrible, it had a weird 'double login' system where it often got confused between whether you were 'inside' the sandbox logged in as a fake user or outside logged in as your paypal account.
And you're right about their woefully confusing documentation, it was definitely hard to understand which payment flow you were trying to use and which was appropriate.
Maybe it's a bit different now, but I haven't looked back. :-D
PayPal tried to "modernize" their old crufty SOAP API with a REST-based API but ended up creating a separate half-functional, poorly documented, buggy layer on top of it that actually loses payments sometimes. I processed millions of payments through it and actually have their support people admitting the problems.
Their only hope is a reverse-takeover from Braintree. I'm not holding my breath; I've done my last PayPal integration. Forget all the "paypal will hold your money" concerns - the real problem is that they will loose your money in the wonky Rube Goldberg machine they've created to process payments.
The project just ended up getting scrapped.
Stripe was so reliable that we had clickety-test that used their real sandbox API to make sure in our CI that payment kept working.
Whenever someone brings up Stripe it always brings happy memories. I've never worked with a third party API that was as nice as theirs. Their Ruby SDK helped with that of course.
You're talking about PayPal Express, which is the PayPal form most of us are familiar with.
PayPal has a number of other services, such as Payments Pro, and PayFlow, which act just like a Credit Card Processor, ie. the customer has no idea it's PayPal on the backend - they enter their credit card info on your checkout form like normal and click submit. The customer's bank statement will state your company name, not PayPal.
Majority (all?) of the PayPal horror stories you hear are from folks using PayPal Express with large amounts of money coming from weird places. Payments Pro really is a different class of service, complete with your own representative you can call up 24 hours a day. You can also setup a nightly automated sweep of any funds to your real bank account.
EDIT: Nevermind: "Currently, PayPal Payments Pro is available in the US, UK, and Canada."
The Stripe advantage over PayPal is that
Stripe operates more like a merchant account ...
But we switched because PayPal just did not work. A significant percentage of card transactions failed for absolutely no reason, despite "good" customers (school teachers from first world countries), no chargebacks and no fraud. Cards would routinely magically work the next day, and in the end we came to believe PayPal arbitrarily failed card transactions to force people to set up PayPal accounts.
Moving to Stripe resolved this overnight. We'll never go back.
Paypal's documentation and the sandbox process is so atrocious that I had to question my own intelligence. Turns out the problem was with paypal and not my IQ.
Before Stripe, PayPal was some clunky API with a endless amount of different accounts with different pricing structures.
But in terms of information content, it's a horrible headline (for the reasons you so succinctly describe).
So you get an anonymous "charge" token that you can revoke if a later part of the checkout process fails, and CC data never touches your system.
(I think the markup for that was a little bit different than what was posted above though).
and the more modern bits are written by banks,
credit card companies, and financial middlemen,
none of whom are exactly winning hackathons for
Again, it highlights the point that it's not the idea, they're a dime a dozen, it's the people that implement the idea.
Also really appreciate Stripe, registered for Delaware with them
Another time, I had trouble getting the Stripe code to work and Stripe's former CTO Greg Brockman debugged my PHP code (!) to fix it for me. I'm not making this up.
The CEO wants to have lunch with me (a nobody) and the CTO debugs my code.
It's one of the few VC-backed companies I really root for.
Stripe has a great product, great service, solid business model (it can't get more simple than % on transactions really), great engineering (their USP is/was their API) and it seems they really support small and medium business owners (and bootstrappers especially).
My only hope is anyone who will acquire them (and I think this will happen soon) keeps the product at this level.
A card issuer is a person that issues a credit card, so major banks, and Amex who happens to be both a card issuer and card network.
Google, dozens of international companies (eg Softbank or SAP), Walmart, Target, Costco, IBM, Oracle, and numerous others.
Basically, several dozen companies are serious potential buyers. And that's before getting into the secondary list, which includes companies like Intel, AT&T, Verizon, Comcast, etc.
Well, you're got quite the Twitter following, probably nearly entirely in Stripe's target demographic :-)
But yeah, that is cool.
I personally think it'll stay a standalone company because its founders already have plenty of money (from Auctomatic and presumably from taking money off the table during Stripe's funding rounds) and seem intensely motivated to change the world by having a pivotal role in increasing the GDP of the internet (as stated in the article).
That, coupled with its (both the company and its founders) integrity, culture, and care & empathy for people (employees, investors, customers, partners, underserved and underestimated people and markets, and really almost anyone) seems to indicate to me that its core values and objectives will be best served and achieved as an independent entity.
I'm glad to see he has continued to do well.
What did I do wrong? I blame WoW :P
Super glad that Patrick has found so much success, and created what seems like an amazing organization.
> When bored in class, Patrick read books. “I would line up the angles so I was hidden from the teacher’s view,” he says, adding that he found out years later that an enlightened principal had instructed teachers to allow it.
I imagined the usual song and dance of writing a bunch of back-end code to handle all their weird requests, worrying about double checking everything in the requests to make sure nobody can spoof them, etc, etc. Ya know, the dumb stuff that takes hours to write, hours to test, and days to wait for support to get back to you because their test servers are broken.
And then I imagined waiting days for them to approve my account for live transactions, requiring scanned copies of my driver's license with me flashing some sort of gang sign while reciting page 452 of the 1993 re-print of Moby Dick.
Nope. Turned out they have a synchronous API for processing payment so I don't need to handle callbacks on the backend. Turned out the front end code was, yeah about 7 lines (more with a few tweaks). And their documentation injects your keys into the sample code for you (wow)! On top of all that ... they had Go sample code!
And when I went to enable my live account, I'm pretty sure all they asked for was name and address, maybe TIN. Nothing else. No wait. Just ... bam, I was enabled and could start accepting live payments.
It was perhaps the most pleasant API integration I've ever done.
There are _some_ rough spots. They don't really explain Radar, their fraud protection very well. It wasn't clear to me if it was automatically included and handled. shrugs. And though they advertised support for Bitcoin payments, it turns out you have to use their async API to accept Bitcoin payments. I was willing to accept zero-conf payments, so I figured I could just keep using their synchronous API, but I guess not.
Stripe provides excellent documentation and support (on #stripe in freenode). It just makes my life easier.
(I have never used Braintree so I can't comment on it)
So, reading into this, amazon presumably invested in stripe, then gave it some transaction traffic to juice the numbers to make an S-1 look better?
I guess that if Amazon threw a crazy enough amount of money at them, then sure, everyone has a price, but how is joining Bezos' empire helping them? There's very little synergy in the other direction, so the premium for such an acquisition would have to be very large.
When you put the premium there, along with how being acquired by Amazon makes the competition more attractive, makes me think that something like that is unlikely.
Amazon payments seemed like a huge opportunity to me at one point but I think they're sort of moving away from it. This could be a test that could trigger moving all payments to Stripe and eliminating the overhead of their own payments team. Wouldn't shock me.
Stripe, while being more expensive than these options per transaction, actually cost me a lot less to start out. While $40/month doesn't seem like a lot, for a hobby project that likely won't make that much money in the first months to a year, it's huge.
- c. US$40 per month for Chargify (which kept increasing)
- £20 per month for the payment gateway
- £25 per month + transaction fee for merchant account
So happy when Stripe landed in the UK and I could migrate to a flat fee per transaction which scaled with me. Migrating is hard as you need customers to re-enter card details but an offer of reducing their monthly subscription due to savings in processing costs helped that process. :)
We can work directly with your previous payments provider to import card details directly, which helps take the burden off when migrating (and keep things PCI-compliant ;) ).
Didn't occur to me to even ask :)
How about we just focus on the job at hand for now and worry about things like scaling and robust API/interfaces AFTER we actually acquire customers and start making the money.
Take this with a large, disclosed portion of salt. Amazon is big enough to pay essentially nothing in processor markup. Not to mention they sell their own payments service. If Stripe is actually handling any Amazon processing they are making no money on it, and quite possibly taking a loss to buy the volume.
Think Square's deal with Starbucks. They ended up losing $56M.
I still wonder how Stripe managed to get around that.
Is there justification for everyone who wants to process payments needing to understand that type of legal document? Is there some major liability that people are agreeing to when they accept the T&Cs?
I honestly just don't know anything about card redemption agreements and google wasn't very helpful.
The agreements between payment services and merchants are some of the most one-sided legal contracts you are ever likely to encounter. Unless you are a huge merchant, they are probably non-negotiable. Typically they grant the payment service and/or its associates the authority to literally take money straight out of your bank account, impose often unspecified levels of fees for vaguely defined transgressions, etc. They will also typically make the merchant responsible for almost anything that goes wrong in terms of fraud, other than perhaps a few specific exceptions where facilities like 3-D Secure were used.
Stripe seems to be little better than anyone else with much of this, though as I understand it that is partly because the card networks impose their own terms and intermediary services like Stripe are essentially just passing them on without having much say about it themselves either.
To give credit where it's due, I've never personally encountered Stripe actually abusing those sorts of terms, and getting signed up with them in the first place was dramatically easier than the alternatives available at the time other than possibly entry-level PayPal (+ accompanying horror stories, depending on who you ask).
Stripe's documentation says that they automatically use the credit card update services of Visa, MC, and Discover to update expiration dates of cards they are storing, so that you don't have to worry about keeping the expiration date up to date.
However, from what I've seen using the Visa and MC updater services, a significant fraction of issuing banks do not support them and when requesting updated information on those cards nothing comes back, and these cards often still actually work fine.
Does Stripe having something equivalent to 0000, so that one can say "try to charge this recurring payment on this card, even if we do not have the current expiration date and the updater service did not give a response"?
 The expiration date on a credit card is the date that the card itself expires, not the date that the account expires. For new orders, online or in-person, an expired card should be a red flag because a person actually placing a live order should have their latest card. Seeing an expired card live could mean it is a stolen card.
So, 14 lines of code?
Can somebody help throw light on:
how Paypal was lagging in 2011 when compared to stripe ?
how Collisons went forming better relationship with bank to build a system better than Paypal ?
The "two years testing their service" part is longer than a lot of ISO certifications, but that all depends. Ultimately, though, it's a lot easier to be certified as a VAR due to the fact that the processor (a bank usually, though can be an ISO) assumes more responsibility (risk/liability) in the relationship.
Regarding "forming better relationship with bank [sic]", it's not so much that one is has a better relationship than the other as it is their relationships are fundamentally different.
While Stripe's API documentation is MUCH easier to understand on the face there is a lot of undocumented complexity hidden away in there that was documented in Payflow Pro (mostly -- in a hard to find 400 page pdf).
In the end it is worth it for our specific use case. But like anything involving money over time it is much harder then it seems. Obviously, WAY more then "7 lines of code" to do it even halfway right.
I have to give massive credit to both organizations support engineers who helped us move the card details across without us ever seeing them. In the end they even ended up having to do a complex customer_id mapping for us to get it done in a way that allowed us to recreate the behaviour we had in PayFlow in Subscriptions
* There is a (undocumented?) limit of 25 subscriptions per customer. Our client sells a la carte services and some large customers have quite a bit more then 25 things. Subscription items partially solve this EXCEPT everything in a subscription must bill on the same-cycle and...
* Our client had a requirement to maintain the existing billing cycles for all customers (and enforce specific start dates for new subscription).
These two limits meant we had to bundle existing services into Subscriptions during the migration and use the "trial period" feature (as a "start_date") to force the billing cycle for each bundle. The worst case customer had I believe 18 different billing cycles for their services in the end so we got lucky. (we also had to figure out a way to name the bundles in the UI and the CC statement descriptor etc).
In the end this saves on transaction fees and reduces the clutter on their CC statements but cost quite a bit of development effort to do and makes the code managing "subscription" starts and stops a bit complex.
Wrote about this in the "Feedback" form, but haven't heard back. Please help.
Is there some way to get super low processing fees if you don't use something like Stripe? Or are they taking money from the school and the parents? I'm just wondering how low of a rate is is possible to get for your ecommerce credit card payments?
In the US this varies a LOT depending on the card type, but most consumer cards are approx 1% interchange + a small fixed fee. In Europe these interchange rates are regulated at 0,3% for consumer cards. There are cases of special schemes (eg. CB in France) where processing can be even cheaper.
This is very cool, kudos to the principal.
There are also some great third-party e-commerce integrations that are pretty simple to set up: https://stripe.com/works-with/categories/ecommerce
Shoot me an email at email@example.com and I'd be happy to help you get started.
But is it, in fact, improbable? If you believe Paul Graham, the most revolutionary ideas are always going to come from off the beaten path -- from some backwater, either of geography and/or of ideas.
That made me laugh.
But you are right: to create something really new, you must bring in a different perspective. Frequently, this is possible only as an outsider.
This is how NOT to do headlines.
So can you just call up the relevant department in the bank and start talking or do you need to know someone who knows someone in the bank.
> Stripe’s new partnership with Amazon. com Inc., the largest and most sought-after customer on the internet. Over the past couple of weeks, Stripe began handling a large, though undisclosed, portion of Amazon’s transactions.
Lots of questions about why Amazon would do something like that. Is it so they have a backup in case their systems go down? Or was Stripe actually able to get better rates than Amazon was, so this will save them money?
Or was Stripe actually able to get better
rates than Amazon was ...
Since Stripe is an ISO with FDMS, they will always have higher fees than a relationship with an "on-the-rails" bank for merchants with volume anywhere near Amazon.
IMHO, a more likely scenario is that Amazon is looking to acquire Stripe, take over the ISO relationships with their merchants, and leverage from there.