If you are wondering how Stripe could even start with just 7 lines of code, it's a bit misleading:
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.
I.E. the simplicity of the Stripe platform (taking only 7 lines of code for developers) was how they succeeded, not that they built a startup at first with just 7 lines of code.
Nope. The Stripe advantage over PayPal is that Stripe operates more like a merchant account, where the buyer sees the seller's name on the credit card statement. PayPal injects itself into the checkout process, Stripe is basically a white label. Stripe also has easier underwriting. I suspect Stripe is taking more business from merchant accounts/gateways than PayPal, because they are different markets.
As someone that selected stripe to process orders for a product were were launching somewhere around 2012, it was because of the APIs and developer sandbox.
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.
That's the least of it. Paypal automatically puts you on a 21-60 day rolling reserve once you hit a certain level. Small businesses can and have had 30%+ of their revenue unavailable for two months. That's your entire profit margin gone. It makes it impossible to grow a small business. And of course they will not respond to anything for months if ever. And it never gets better! Companies with millions in revenue still get these problems.
Paypal has no place being used by anyone trying to start a company. They are awful.
Before Stripe - I had to take a loan out, and make the switch to Authorize.net so I could get my company off PayPal and its 60 day reserve - otherwise it would have folded. They were perpetually holding tens of thousands of dollars at all times.
They'll do that sooner or later. Everyone in the money-handling industry has to randomly lock-up funds and not tell you why, because that's what anti-money-laundering laws require.
Ok, but there's a difference between doing that because you are required to by law, and doing it because you've chosen to adopt appalling business practices.
PayPal had a developer sandbox back in 2010 when I wrote our client code. Honestly I don't remember it being difficult or tricky. The worst aspect was their confusing documentation which tended to mix up various different services and APIs such that it was hard to figure out which was the current, appropriate one. Perhaps that was the Stripe advantage: a single obvious course of action to take.
One of my best upvoted stackoverflow answers is about a paypal sandbox bug (or "undocumented feature") where it would disregard the port in the pingback url.
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.
I suspect also that the marketing folks re-branded the various services on a regular basis so you weren't even sure if two different names for something actually referred to the same thing.
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.
In a series of calls with the top tier of support at Paypal, no one was able to even answer which API was the best to use. I was told not to use SOAP (or NVP), because they're ancient, not to use REST because it wasn't ready yet, and that the Braintree API around PayPal would never support the features we were trying to implement.
Ease of development was our number one reason to use Stripe for sure. We did end up adding Paypal after and it was a pain to work with.
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.
> The Stripe advantage over PayPal is that Stripe operates more like a merchant account, where the buyer sees the seller's name on the credit card statement. PayPal injects itself into the checkout process, Stripe is basically a white label.
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.
The Stripe advantage over PayPal is that
Stripe operates more like a merchant account ...
Stripe is an ISO with First Data Merchant Services (FDMS, I believe now owned or controlled by Wells Fargo) doing the actual processing and, as such, assumes a different legal role than PayPal (which is a VAR for Paymentech). This is how Stripe is, as you say, "basically a white label."
We moved from PayPal to Stripe. Yes, integration was much easier, because of the simple and effective API and great documentation (good examples with your own data included - brilliant!).
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.
And don't underestimate the power of new and... different. Many founders pass on markets they think have no room for innovation or new entrants, only to leap into some small marketless crevice.
> The real break through for stripe was it was an alternative to PayPal with a modern UI.
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.
The PayPal form also involved redirecting all your users over to PayPal. Stripe has always integrated into your site/service which is part of what made that form so nifty.
Wait, the /your-server-side-code bit seems like the most difficult. Did Stripe not implement this aspect as well? I would have no idea how to securely process credit card transactions server-side.
If I remember how they worked (last did stripe integration a ways back), the script instruments your form's submit event to do an (ajax if possible) POST to stripe's server, which processes everything, and returns back a (merchant specific) "token" representing a redeemable charge to the customer. The form is then posted to your server, but all it gets is the "token", which it can then use your private merchant key to redeem behind the scenes with their server.
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).
Correct, and the big reason for that is it means you don't have to be PCI compliant since the card never touches your server, only stripes. That's why Stripe blew up, Paypal had no such offering for allowing you to use your own checkout form but not have to pass the card through your server.
That product seems to have a marketing problem. I've heard plenty of PayPal horror stories over the years, but this thread is the first time I've ever heard of Payments Pro.
I think they did eventually. I remember trying to use Stripe for a project during college (2012ish) that involved building a website with a REST integration in C#. My rtfm'ing skills were much worse back then so I could be wrong, but yeah, you had to do a bunch of server-side implementation and make calls to their API. It seemed quite challenging to me at the time, but looking back, it really wasn't. They've gotten rid of that extra step now though. You can just drop in the javascript and their html form with api keys and you're ready to go.
More like how turning on lights is easy for billions of people because someone else did the hard work of the power lines, generators, switches, light bulbs, etc.
Actually, it would be more like all of that stuff already existed, but it was a woeful and Byzantine process to get all of it lined up for your particular lightbulb.
It was a bit interesting to see, and perhaps not at all surprising, that they've been around since 2010. And they crossed the billion-dollar-valuation threshold 4 years later.
There's a few misconceptions in the article beyond that.
and the more modern bits are written by banks,
credit card companies, and financial middlemen,
none of whom are exactly winning hackathons for
elegant coding.
Hackathon code is never elegant... it's always piecemeal at the end in order to get it "done."
Which is already a better picture than what most people have when I tell them I attended a hackathon: "So you all get together to try and hack the security system of a company?"
I don't think it's misleading, it's just that there are different preconceptions based on the audience. If there was an article about "How two brothers turned a 3 oz piece of metal into a billion dollar startup" and it was a highly machined part that fit a really useful case in the auto industry, we would rightly assume they were talking about what they sold, and that a lot more work went into actually making and perfecting it. If the same article was read by machinists, they might take issue with it like people are taking issue with this headline, but that's because of the context they are perceiving it in.
It is misleading. It deemphasizes what can be learned from the article. What helped this company get traction was ease of use, the 7 lines of code made it easy to use, and also, that the reason this company even got off the ground is the 2 brothers and their focus on getting the company to where it is. It seems to me that whatever they would have chosen to do would have had some success.
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.
I feel like I just wasted 15 minutes digging for that and being disappointed that their MVP wasn't a 7-liner. Guess I should have come to the comments first.
The typical interpretation of "turned 7 X into Y" isn't "7 X plus another million X turned into Y". Last night I turned a pat of butter into a steak dinner. Never mind I also started with a steak, thats an irrelevant detail.
I'm thinking for the layman who doesnt code which Bloomberg also targets, this distinction is pretty negligible so in a way its not totally clickbait because its still seven lines of code, for developers it seems to be the code you write whereas the title could go anyway
Also really appreciate Stripe, registered for Delaware with them
To the layman, I imagine this reads as either "they spent a few minutes writing one paragraph and made $9B" or "they agonized for years over something as small as a single paragraph that was worth $9B"; neither of these are reasonable interpretations. It is only to the advanced technical reader that I think there is any hope of them interpreting it in the correct manner.
It participates to negating the difficulty of building and delivering a product, thereby giving said laymen a sense of entitlement over "undeserved wealth".
I don't know Patrick, but he has personally jumped in here on HN where appropriate, publicly given out his own email address to handle issues, etc., and continued to do so even after Stripe achieved a $1b+ valuation. While most of their billionaire Silicon Valley contemporaries are very hard people to root for, I am rooting for these guys. They seem like genuinely good people whose success is well deserved, and so far they have not let it go to their heads.
Patrick is awesome! He asked me to have lunch after I tweeted feature suggestions about Stripe. Indeed, which founder of a billion dollar company does that (or has time for that)?
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.
My hope is they will not be acquired and will keep this stand-alone as a true alternative rather than be eaten and then to lose all their advantages. Acquisitions of companies like this usually spell the end of the line. Here's to hoping Stripe will IPO and will go on to acquire who could now potentially acquire them.
Card issuers (VISA, MC), Amazon, Microsoft, major banks, Ebay, Paypal, Due, Payline, Paysquare. A leveraged buy-out would enable many more potential takers.
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.
I interviewed with Stripe early this year, and whilst sadly we couldn't go forward due to the fact that I'm British and was too late for an H1B - it was one of the most pleasant interviews I have ever had.
Why do you think Stripe will get acquired (and soon)?
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.
Raise 100M, 20M is set aside for salaries/bonuses. As long as the numbers work and people believe you, investors like people who want lots of money, because they know they are going to work their asses off to make a profit.
I agree on every single point. I've been amazed reading threads on here where Patrick jumps in and offers his help. I've never met them, but Patrick and John seem like wonderful people. I'll always root for them!
So far I didn't use their service, but I fondly remember their security CTFs, which were lots of fun, and very well run. Still hoping for another incarnation of those...
I read them and see how all these smart entrepreneur types dicked around in class reading books, just like me, except they turned out to be geniuses, and I ended up just derping around Asia and frittering away my youth.
Survivorship Bias [0]. It happens to be that a certain type of rebellious/free thinking personality is the most likely to end up making a successful tech company; but that doesn't mean everyone who exhibits that trait succeeds.
Haha, same here. I always used to feel so justified for all the time I spent reading scifi novels in class instead of paying attention, cause all these millionaires were doing it too... and here I am, a junior developer facing a layoff, 5 years into my career. Such success!
Most of it is fluff anyway. You could conveniently remember your own history in a different way if it helped to gain an "entrepreneur" label. No one's going to bother calling them out on it even if it weren't true.
I've plinked around with Lisp implementations for quite a while, and remember the press he got back in 2004 for Croma. This was before all of the startup stuff of the last 12 years, so at the time it was just a story of a really smart high school student doing something awesome with a style of programming language I really liked.
The article: "Surely the smartest redhead in Ireland,” read one headline about 16-year-old Patrick being named Young Scientist of the Year for developing a programming language and artificial intelligence system."
Are "redheads in Ireland" stereotyped as being particularly smarter or stupider than other Irish? That's the only way I can make sense of that headline - it makes as much sense to me as "the smartest black-haired person in Ireland"
Because redheads are so unbelievably common in Ireland, calling him the "smartest redhead in Ireland" is a clever little joke that draws a contrast between his exotic intelligence (building an AI system, desigining a programming language) and his incredible ordinariness (having red hair in Ireland).
No -- "smartest red head in Ireland" just an arbitrary qualifier and a throwaway comment -- if anything it just emphasizes the number of red heads in Ireland.
10% of Irish people are redheads while about a half carry the gene apparently. I'd be willing to bet the dark haired brother has forearms covered in freckles
I obviously can't speak for him, but macros do complicate things, particularly when ahead-of-time compilation gets involved. There's also the issue that macros have some of the same sorts of issues as inline functions - because they're expanded in place, they can introduce hidden forms of coupling.
Though not the primary focus of the article, this struck a chord with me:
> 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 used to do something similar, I had quite a few bad teachers in college on some very interesting classes, I would cut class to go to the lab and study the same subject being taught there.
I hadn't worked with payment systems for a number of years, but recently added Stripe to a quick MVP I built (bitcoinvoice.com). It took two hours. I couldn't believe how easy it was, and how nice the UX of the whole thing was.
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.
I had pretty much the same experience. I programmed an API to talk to a payment gateway connected to a chase merchant account some years ago. It was not fun. When I setup Stripe I was confused when it was done and there weren't 25 more steps before it works.
The article mentions this but for me the truly great aspect of stripe is that they targeted the developer. I have dealt with several payment systems and most of them have poor documentation and getting them to work is a lot of trial and error. They appear to be monoliths who survive because management has chosen them.
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)
> Over the past couple of weeks, Stripe began handling a large, though undisclosed, portion of Amazon’s transactions. Neither company will address the scope of the deal—which was only revealed by Stripe’s addition of Amazon’s logo to its website—but it could help Stripe greatly increase its transaction volume.
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?
Amazon's overall goal is to take a cut of pretty much every piece of economic activity. Taking a cut off of every payment made on the internet outside of their own stores is an objective greatly aided by a stripe acquisition
You have to look at it from both sides though: If I started a business with Stripe as a processor, it's in Stripe's best interest for my business to grow as much as possible, because the higher my volume, the more they make. They'll want a good cut, but their goal is a long term relationship. It's not the same thing with Amazon: Every piece of intel I give them is an opportunity for them to eat my business.
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.
International or some other payment type Amazon doesn't support well or at all in their own payment system seems like the lowest hanging fruit.
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.
For me, Stripe was a revelation because they eliminated fixed monthly costs. When I ran a side project that took credit cards, I found the cheapest option to be a $20/month merchant account + $20/month to Spreedly. Others had a few months free trials, etc. but ended up being more expensive over the first year.
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.
So much this. When I started Leavetrack[1] in 2011, it was so difficult to get setup for recurring payments. I was using Chargify to handle the recurring payments/credit card storage, a company in New Zealand (I am in the UK) to handle the interface to my merchant account in the UK. Total costs:
- 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. :)
Re: migrating customers: I just grandfathered all paying customers to a perpetual free plan. Weren't that many of them. Sadly that app never gained traction. You'd think reliable up/down monitoring of unlimited servers at $4/month would be a good deal.
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 ;) ).
I love this. Simplicity and speed is what I fight for everyday at work but it seems I am the odd man out in my field. Everyone just wants to write over-engineered solutions that can launch space rockets with extra extra modularization you know just in case the Hubble fails again and of course fear of what may happen "in the future" in case "we ever need to scale".
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.
> Over the past couple of weeks, Stripe began handling a large, though undisclosed, portion of Amazon’s transactions.
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.[1]
Since, as you point out, they're probably not making money on the processing directly, maybe there is another reason Stripe would find it useful to process a large amount of transactions...
The biggest thing for me with Stripe was that I no longer needed a card redemption agreement. Before that I had to deal with both my bank and the provider and it was a bureaucratic mess.
I still wonder how Stripe managed to get around that.
Isn't part of the innovation the fact that almost all users can click through that part of the process instead of spending lots of time in bureaucracy?
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.
Is there some major liability that people are agreeing to when they accept the T&Cs?
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).
How well does Stripe handle expired cards? The payment gateway we use now allows sending an expiration date of 0000 on submissions that are marked as being a recurring or installment payment. This attempts the transaction without doing an expiration date check [1].
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"?
[1] 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.
To add a bit of insight: most Payment-Service-Providers actually pay big retailers to be listed on their site, as it improves trustworthiness and brand awareness. So the Amazon deal might not be as favorable to Stripe as it might sound.
>>>> "Stripe made its debut in 2011 .... had spent two years testing their service and forming relationships with banks, credit card companies, and regulators so customers wouldn’t have to".
Can somebody help throw light on:
how Paypal was lagging in 2011 when compared to stripe ?
-OR-
how Collisons went forming better relationship with bank to build a system better than Paypal ?
Stripe is an ISO with First Data Merchant Services (FDMS, I believe now owned or controlled by Wells Fargo) doing the actual processing and, as such, assumes a different legal role than PayPal (which is a VAR for Paymentech).
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.
Paypal's white label product was unusable (literally for some companies). Their banking relationships did not need to be better than Paypal's to have a better white labeled, developer centric payments gateway than Paypal.
I am just now in the process of completing a migration from Paypal PayFlow (Recurring Profiles) to Stripe (Subscriptions)
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
The complexity was more in our customers application logic then in Stripe. Stripe understandably enforces quite a few sensible limits that 'normal' usage probably wouldn't hit. For us the 2 biggies were:
* 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.
Dear Stripe team! I am trying to activate my Stripe account but after I press the "Activate Account" button, keep getting "An unknown error occurred" message.
Wrote about this in the "Feedback" form, but haven't heard back. Please help.
My comment/question isn't about Stripe per se, but rather the surcharges of payment processors in general. It seems like 2.9% + .50 is about average, but then I see a site like https://sendmoneytoschool.com/ and they are charging a $1.00 processing fee for credit card payments to put lunch money in my kids' school account.
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?
It depends a lot on the card type, the location, the volume of the business and it’s risk profile, but eventually can get to a pricing scheme called interchange+, which is a fixed fee (generally <15¢) on top of the cost to process cards for your provider (so fee from the issuing bank + network fee).
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.
Thanks. I wasn't familiar with this. That's definitely significantly cheaper (transaction cost wise at least), but even then doesn't leave enough room to profit on the transaction fee alone so I'm assuming they must be charging the schools for the service and partially subsidizing with the convenience fees.
"“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. "
Is there any service that will handle the backend of the Stripe integration for me? I'm talking about simple charging per product, ex. selling ebooks. Or Squarespace like websites are the only solution here?
The article is inspiring at first glance but could cause a new programmer to overlook effort and possible expenses associated with building such a website. For instance, if the programmer has either front- end or back- end programming skills but not both they will need to hire someone to build half of the program. Still, lacking one or both skills they would need to have an engineer or coder available to manage any potential bugs in the program and field user requests.
"There’s such an improbability to their story -— that these brothers from a little village would come to build what could well be one of the most important companies on the internet.”
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.
This headline really cheapens their accomplishments. It's not enough to start a successful business with a lot of work but it has to be just seven lines of code or over the weekend.
> 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 ...
I can say with high confidence that this is not the case. Amazon processes through Paymentech on their Salem platform. Effectively, this is the Stratus side of the house which is optimized for high-volume batch oriented customers.
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.
Yup, amazon has been all about acquisitions and broadening their horizons lately. When they acquired twitch, they had regulations put in place first test if things would stick. Then twitch was acquired after. Seems they're probably doing the same with Stripe.
I setup my brother's small business stripe integration, and I wrote and tested the API calls to charge customers. Stripe doesn't know anything about his business except transaction sizes, and a bunch of info they definitely can't resell (TIN) or is already public knowledge (business name, billing address). I doubt they have anything helpful for pricing, though they might be able to analyze gross transaction rates and geography. I have never checked what their contractual obligations are with that data, I imagine if they started sharing it that would get out pretty fast, and result in them losing customers rapidly.
Payment systems are mostly about fraud protection, as PayPal discovered in their early days. The default case is simple. It's dealing with problems that's expensive.
