Why? If a customer is subscribed to a "plan", and their payment fails it is retried three days later, then five days later, then eight days later, and if all three payments fail they're quietly unsubscribed without any notification being sent to you!
I have a toy project which has paying customers and last month realized I'd had people using my SaaS for over a year without having paid me. A few failures in a row meant they were unsubscribed, and since I didn't read the reports every month I didn't notice.
I reworked my payment system now, to subscribe to webhooks and ensure I find out promptly in the future.
Not a huge deal at my volume, but a surprise I could have lived without.
https://stripe.com/docs/webhooks
https://stripe.com/docs/subscriptions/lifecycle
The webhooks are important because stripe doesn't email you about failed payments you need to do that on your own.
And the default for a 3 time failed subscription over a 15 day period is to remove the subscription which you can easily change to keeping it but labeling it unpaid among other things.
1. The Stripe webhooks are really great but...
2. ...you've absolutely got to pay attention to them like a hawk, because Stripe views that as the primary/best way of communicating critical details with you.
It's great when you get used to it/have built up support to handle their webhooks correctly, but it can be a bit confusing/daunting to start with.
The user who had a years free service I wrote down a little - they should have paid around £140, and I suggested we'd be good if they paid £100.
Perhaps I went too easy on them, but I was trying to be nice and it wasn't their fault I'd not been paid, not directly. The other couple of users ranged from 2-8 months of non-payment, or so, and I agreed with each that I'd bill them the full amount as a one-off charge.
Why are so many of you so happy to throw so much cash away to process money? I know Stripe is lovely to integrate but as a business you have to shop around.
In the UK (and EU) card processing is much cheaper. Stripe is closer to 2% but if you shop around, you'll find somebody who'll offer you 0.8-0.9%, give you free terminals and no monthly contract fees.
Edit for those asking: Worldpay and Handepay are the best rates I've seen recently. Both for online and off. But again, don't just cluster around one company, harass a few yourself. They're willing to compete.
I highly suggest reading up on interchange fees for various cards before taking a swipe at Stripe.
2.9% + $0.30 is absolutely rediculous to pay to transfer money, but blame the card companies. You simply can't get cheaper flat pricing on card transactions. Even online debit interchange fees are rediculous.
So if you do want cheaper, you need to try and find a provider that charges based on the underlying interchange fee. And then once you do so, you need to account for the variable rates in your accounting (can be a pain depending on your situation, especially if you don't know the interchange until the customer enters their card number), and even then, you're probably saving at max 1%, but likely a good bit lower on average.
You could always opt with ACH, but the more reliable way of authorizing ACH these days is using a service like Plaid that has the user log into their Bank on your site. Which is super sketch if it's the first time I'm purchasing on your site. I really wish Dwolla was able to upturn the industry ($0.25 flat fee for transfers was brilliant), but who wanted to sign up for yet another account to purchase stuff...
Payments suck.
The services I need to run the back-office operations of my business including bookkeeping, invoicing, receipts, business metrics, customer support etc. all use Stripe data and APIs. Writing our own integrations, or worse, trying to poorly replicate some third party service, would be money poorly spent. It would take a very large transaction volume for it to make any sense to spend engineering time here, and arguably the end result will be qualitatively worse than just going with the market leader. Even if that calculation does come out positive, you still have to consider whether the engineering time wouldn't provide an even higher ROI by being invested into your core product instead.
It doesn't take a large transaction volume to justify the engineering cost at all. We're talking entire percentages of revenue. The ROI justification is going to be a hard one to beat in this case.
I believe you still can break their hosted payment form if you provide your telephone number with leading zero.
We spent a lot of developer time getting that 0.05% rate difference to work. Yes, that's a lot over a year, but we were constantly discovering undocumented error codes and "interesting" corner cases. The processor went down often enough that we actually ended up configuring a backup payment gateway on top of it (manual failover -- and yes it was well used). A year later and we still didn't have all the bugs ironed out.
Additionally the "PCI Scan" through the bank couldn't handle a DNS name, only a fixed IP address. This was one among many other issues with the PCI scan that ended up wasting weeks of developer time. In the end they literally gave up on scanning the site and just gave it a pass.
Believe it or not (I didn't at the time) there's actually more to card processing and banking than just a rate. You definitely get what you pay for.
We had, at lockheed, hired a contracting company that would receive all our corp cell bills, go through them and go after the carriers for errors and savings and they just kept a percentage of the savings that we made from their efforts... it worked out well for both parties.
I'm not saying everybody will get those rates, just that I'm surprised that people settle for 3% without a fight. At scale, that's a huge amount of money for a little convenience.
Worldpay starts around 2.75% + £0.20 per transaction; I'm sure you can negotiate them down, but not THAT low. Not if you're asking them to provide the merchant account AND process online/card not present payments. You're not getting a merchant account + payment gateway for less than a 1% fee. Not without stupidly massive volume, anyhow.
The reality is Stripe's rates are actually competitive; they're not wildly expensive, and they're not even the most expensive.
Honestly, I have two clients with Wordpay at ~0.85%, no contract fees. Volume isn't crazy either. I can't tell you if they caught WP at a particularly giddy phase but I guess they're trying to compete again. They've been around for 28 years and these whippersnappers like Stripe must be starting to hurt their bottom line.
EU seems to want to get rid of this practice, I wonder if it becomes a company expense, that we will see companies caring more about the processing fees.
One would think that it is a business' business to figure out how much to charge a customer. A willing customer will pay, an unwilling one won't. How is it a question of legality?
Even if a business is doing $500k of charges a year, I'd guess it's probably not worth the time to save $5k a year... there are usually more impactful uses of time. And when businesses get to high volumes, where integration costs become much smaller as a percent of revenue, then Stripe will give you a better deal.
FirstData is one of the primary companies in the market, and the rates you get from Pineapple are "interchange optimized". Means you pay 2.9% for AMEX, but ~1.5% for VISA, Discover, etc.
For B2B and even B2C, it's a fantastic savings if you're willing to do just a tiny bit more legwork than Stripe requires.
> starting at 0.59% + £0.20 adapted to industry type and risk level
I wonder why we don't see much more competition though.
I integrated with it for one of our sites and now have to integrate with cybersource for another and the difference in documentation alone is night and day.
If you're running server instances 24x7 for an application that is doing < 25 requests/minute on average, you would probably find your hosting costs come down (perhaps to zero) and your reliability would increase considerably if you moved to Lambda-style applications.
serverless.io is a decent framework to get started (allows for local dev and testing, manages deployment) and is agnostic in terms of deployment target: AWS, IBM, Google coming soon, etc.
The only reason we're not rolling it out everywhere at work is because it assumes all developers are deploying directly from their term with god-like CloudFormation access. Nope, nope, nooope. We just need to build the deploy pipeline for it, and then off we go.
To me it seems like the only sweet spot for lambda on a large scale would be for those that have consistent usage of a small instance that have some extra functions that need to be highly scalable and are very inconsistent.
In the original article the author suggested on a successful subscription a write to the MailChimp API (because that's the product). In that example, MailChimp is the DB. You don't have to run a copy of a DB locally if you architect things like that. Obviously if the call fails, you need to think about what you fall back to, which is why error handling is such a critical piece of the the Lambda ecosystem - as it should be for every ecosystem, really.
Romania has some problems and companies like Stripe have to decide whether it is worth it to them to open up to a country that would in turn most likely (at least initially) yield relatively small volume in real transactions and a disproportionate amount of volume in fraud.
From the Romanian point of view this sucks because those Romanians that would make something nice and use this to move themselves and by extension Romania forward don't get the chance to do so.
Personally I think the initial problem is with Romania, if rampant fraud and corruption were not so widespread then other service providers would feel more secure in opening up to the country and giving it a higher trust level.
But given the way Romania practices politics I do not see any major improvement happening any time soon, which is a huge pity. I love the country and I love the people but the business climate and the government are terrible.
Actually, I don't exactly understand what Stripe do to "prepare" for the launch in a country? They are expanding very gradually, and there are payment processing companies which basically blanket-cover almost whole world. For example Stripe still marks Germany, Austria, New Zealand etc as "preview", and they were not available some time ago, but fraud and corruption definitely is not a problem there.
The only real alternative is PayPal at this moment.
Also you can provision AWS from the browser using a CloudFormation template and a Launch Stack URL [2].
[1]: https://github.com/christophercliff/flatmarket. [2]: https://github.com/christophercliff/flatmarket#automated-dep...
The main value is central customer and subscription database, which muxes multiple payment methods: Credit Card (via Stripe), Amazon payments, and Paypal. This alone has doubled our monthly paying customer growth.
Next it allows us to create invoices, subscriptions and customers data to put in the same database for customers from other channels -- mostly this is our iOS users who have to subscribe via iTunes (due to Apple TOS) -- now we can manage their data in the same place.
It is also an integrated coupon management system, hosts custom styled payment/subscription management pages (as opposed to just a tiny payment widget like Stripe), supports more flexibility like trial periods, switching between subscription plans, adding credits to a user's account.
We've moved all our non-iOS customers to Chargebee for about 6 months now, and really happy with it.
I moved from Chargify to Stripe about a year ago (to save on cost) and the biggest challenge was getting customers to re-enter their card details for Stripe.
I offered a coupon for 50% off a month's subscription to entice them to do so but still resulted in a couple of months of paying both Chargify and Stripe while I chased the errant customers.
-=-=
Having said that, before you jump into making free payment forms for your static site, keep PCI compliance in mind. (even if stripe is rendering form using js).
As an example; https://www.sendmoneytoschool.com.
The site is used to pay online with a credit card for your children's school lunch and it typically charges a $1.50 "convenience fee". It is my understanding that they are not charging schools for the use of this service (I may be mistaken); at Stripe or PayPals fee rates this service would be losing money. Every $100 would incur at least a $2.00 fee. Here a low cost processor like Worldpay and Handepay would allow for a profit; albeit a very small one.
And also, phone calling usually involves walking out to the street so I can get reception, yell my social security number in front of a bunch of strangers walking by, and somehow verify my account number and various transactions from my account which I can't do without going back inside, logging in from a computer and checking them, and then having the call dropped because I went inside. Or having my phone battery cop out halfway through being put on hold.
I hate phone calling. It's easier to bike to my property manager's office 12 times to drop off checks than make a single phone call to my bank to set up something that should be doable from a web page.
I use Simple bank and they can automatically mail out checks on your behalf, if you set it up.
You'd still need some way to authorize subscribers on your website, no? Therefore, you couldn't create a serverless subscription blog/website... unless I'm missing something.
