Cheap Recurring Payments with Stripe and AWS Lambda
normal-extensions.com
normal-extensions.com
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.
It always amazes me how people do not understand the fundamentals of retailing.
I should have specified that even accounting for that difference 30% feels excessive considering your app, and the existence of it on their app store, also benefits their system (assuming your app is not completely pay locked).
It wasn't that long ago that Apple was using as a marketing tool, the number of App's on the app store.
They literally marketed number of apps downloaded just yesterday in WWDC.
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.
Once you hit scale it might be worth switching, but for many smaller sites Stripe is much more viable.
I'm not pretending it's for everybody, again, I'm just shocked that "oh we'll use Stripe because it's easy and cheaper than PayPal" is the group mentality (esp here).
Depending on which Stripe features you make use of and would have to re-implement yourself it may even make Stripe more affordable up to a couple of hundred thousand in revenue.
That makes it very attractive for side projects or bootstrapped companies, and side projects and bootstrapped companies often grow in to larger things, and at that point, changing out the payment processing is low on the list of priorities.
It always surprises me how quickly people are willing to adopt stripe without even making this calculation on their own and considering competitors.
I suspect since they are YC funded they give discounts to other YC companies which makes it a more viable option and helps foster the ultra positive stripe sentiment you see on HN. I think there are a lot of people who eat up the hype without doing any real analysis of their own.
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?
Most credit card companies _don't_ want you to do that because charging more to pay with a credit card makes using your credit card a less enticing idea. IIRC, this stuff is usually handled in your contract with the credit card processor.
The last company that I worked for that used a credit card processor other than Stripe, the rules were something like:
* 2-3% of the transaction is the processor's keep
* You are allowed to charge a surcharge, but _only_ if it's a flat fee. You cannot add a 2-3% fee to cover the credit card charges, nor can you have some sort of "flat-fee schedule" where the flat-fee changes based on the amount being charged (e.g. charges of $1 - $100 get a $0.50 fee, but charges $100+ get a $5 fee). You can only do something like $0.50 fee to all charges.
* You cannot charge a different price for products when they are purchased via credit card.
This is obviously good for the card companies and to a degree the digital payments landscape as a whole.
I do however see how it can be a problem for small merchants who can't negotiate for better rates with MAPs due to lack of volume. A 2 - 3% fee is quite significant seeing as though many retailers will have a 7-12% net margin. For a merchant not to be able to push the cost to a customer even if it is just part of it would be difficult for a business to sustain. There are other costs that merchants are dealing with such as cost of packaging and as such, a 2-3% fee is no mean feat.
Now that you've mentioned stripe; I am in the process of setting up an Australian company with stripe; so far the docs are easy to digest and it seems waaay easier (and cleaner) than my previous experience with paypal.
Depends on the state. It's no longer illegal federally, but many states, including the four largest states[0], still prohibit it. And if they pass the fees on, they have to pass it on for all credit cards, due to the specifics of a court settlement a few years back.
In addition, any merchant that accepts American Express is also prohibited from passing on fees for any credit card, because Amex prohibits passing on fees, and you can't pass fees for Visa/Mastercard and not Amex (see above).
So, very few merchants actually do.
[0] California, Colorado, Connecticut, Florida, Kansas, Maine, Massachusetts, New York, Oklahoma and Texas
Are you saying it _was_ actually illegal federally at some point or that no one had successfully brought a suit against the credit card companies' conditions until recently?
I didn't know about the state laws. That sure sounds like regulatory capture. It's hard to think of a legitimate reason for the state to do that.
Do majority of MAPs in the US have this condition in their terms? And which MAPs don't have this condition?
They are not allowed to charge customers more for paying via credit card that for paying via cash. This is the law in some states, and in addition many merchant contracts stipulate it as well.
Sometimes you'll see merchants offer a "cash discount", which is technically prohibited too, but small merchants can sometimes fly under the radar if it's not too blatant.
Now I get it. I'm not for it but I get it.
I dealt with a local mechanic (small shop) earlier this year who, when it came time to settle the bill, said he will do debit/check for no fee, or a 2% fee for a credit card. In addition, some local gas stations advertise cash rates for fuel, which are slightly discounted vs credit cards.
It's an interesting practice that I don't mind. Ultimately it provides transparency and options to consumers who may be unaware of interchange rates and such that factor into day-to-day transactions.
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.
But publishes no pricing and you have to click for a quote (fill in form for a call back). Really transparent!
Also when they quote low rates for Visa and MC are they including the rewards cards which carry higher fees and make up a majority of the transactions?
> starting at 0.59% + £0.20 adapted to industry type and risk level
> Highest level of processing uptime (99.9%)
It's not that high...
Also, it says about 10 years of experience, but site is seems to be really working only since 2016. And SSL certificate is just "let's encrypt", which is fine for most, but for payment processor I'd expect something more serious.
Edit: Seeing there is also a currency conversion fee (is there something similar on stripe?). I mean with currency conversion+paydoo regular rates you get close to Stripe rates!
But yes, there is work involved in implementing each provider. Stripe has some but it is generally nicer to use. £100k of volume and you'll probably pay for that additional development time in Y1.
But also consider that you shouldn't irrevocably tie yourself to a single processor. Don't rely on them to do your business for you. Sometimes they're dicks. I know that applies more when we talk about PayPal and much less in the "real" merchant processing world, but it still happens. Having the ability to switch out processors is objectively useful so (eg) tying your basket UI into Stripe's checkout js lib looks nice, is super easy... But what happens if they start withholding funds? If all your emails are tied into their system, it's weeks of development to stop using them. Do business-critical stuff yourself and you're much more flexible to do sensible things in the future.
Regarding international rates, these are hard to compare because their claims are apples to oranges. Stripe say they go off their "banking partners'" daily rates and that those are approximately 2% above mid-market levels. Paydoo says they're 2.49% fixed above market levels. I suspect they're pretty close in practice. Stripe does let you accept multiple currencies (for free) if you have the bank accounts for it though. Not sure if Paydoo allow the same. Their wording suggests not... But if that's the deal-breaker, talk to them about it.
Edit: Weird that they don't appear to service bricks and mortar retail. They can be much more secure (cardholder present, PIN entered, telephone verified) and therefore lower risk.
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.
For now, adding countries that have the best combination of low fraud and least difficulty or barrier to entry is the best choice. Romania doesn't have the former relative to Germany and Austria, as such, it's not on the list.
There are a lot of laws involved when you wish to become a financial operator and that can be a real pain for Stripe to handle in each country separately. PayPal managed to do this. For example PayPal operates as a bank in Europe to be able to conform to laws.
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.
I can't give numbers for our ROI, but we spend far less time providing payment/subscription support, and pay a flat extra cost to Chargebee for the added abstraction layer they provide so it's easy to evaluate -- worth roughly 100 subscribers/month, and since shifting to Chargebee we gained more than that number within the first month beyond our regular month/month growth.
-=-=
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.