Cheap Recurring Payments with Stripe and AWS Lambda(normal-extensions.com)
normal-extensions.com
Cheap Recurring Payments with Stripe and AWS Lambda
http://normal-extensions.com/2017/05/05/simple-recurring/
130 comments
Both webhooks and looking at your subscription settings are important. Here's some documentation on how to do both.
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.
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.
Another pro-tip: you can install the Stripe iOS app and get realtime payment success/failure notifications. Not good if you have 10,000+ customers but useful if you have <1000 customers.
Yes, my experience has been that for basically everything:
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.
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.
Out of curiosity, did any of these customers return?
I had three users who were really affected, and all of them paid up. None of them "left" really, they were receiving a service from me, just not paying for it.
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.
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.
~3%, dirt cheap?!
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.
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.
If you are processing card present transactions, you shouldn't use Stripe, which is priced for online transaction fees.
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.
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.
Stripe has an extensive ecosystem of services that integrates with it, literally hundreds (https://stripe.com/works-with).
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.
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.
[deleted]
Integrating with a merchant payment gateway isn't rocket science. A few weeks is easily worth the cost (it doesn't take that long, either, most have decent enough APIs or SDKs that may not be stripe quality but still are simple to integrate with).
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.
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.
[deleted]
The point was that there are N other services you use when running a subscription service, that all integrate out of the box with Stripe and not at all with the cheaper alternative.
I agree with debaserab2. We use both PayPal Merchant Processing and Stripe. PayPal processes for us at 2.2% + $0.30. We use Stripe for the smaller charges where the $0.30 is prohibitive. There are many other options out there too. For any business to stay competitive it's important to keep costs down. Merchant fees are an easy one, do some research. For small businesses, the integration work isn't that hard. I suppose below a certain threshold it just isn't worth worrying about, but I would be wary of being too locked in with stripe or any other business for that matter.
re worldpay - they may be cheap, but you get what you pay for. Their backend still does not support SNI for payment callbacks. I had to debug once my client's integration with their hosted payment form (the one under https://mms.cardsaveonlinepayments.com) - and during debugging I have seen things like this: http://hiciu.org/2016-02-06-010735_1920x1043_scrot.png http://hiciu.org/2016-02-06-010743_1920x1043_scrot.png.
I believe you still can break their hosted payment form if you provide your telephone number with leading zero.
I believe you still can break their hosted payment form if you provide your telephone number with leading zero.
+1 even their website isn't https...
(even for their contact-us page and quote page)
Also I think we just took it down...
Ahhh - this brings back memories. On a more significant note, our student association was able to get a merchant account up and running with them with _significantly_ less work than trying to re-enable our PayPal account after we hit their 'verification ceiling', and the fees worked out vastly cheaper although we did opt for a fixed monthly payment + lower per transaction cost. This was some years ago (in the UK) but I really second the argument that much cheaper rates can be had by simply shopping around (of course like any business/financial decision you'll want to factor in dev time / service levels etc etc) and getting a real merchant account isn't really that difficult.
I worked with an ecommerce shop for a while that wanted to go with the cheaper payment processor through their bank.
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 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.
I will second this. After using Worldpay for 5+ years decided to shop around for better rates - none! Depending on the level of integration you may have some issues during setup but once live it all goes smoothly. And just 10p fixed for processing debit card transactions! Nothing else comes even closer
The short answer is because time also costs money, whether it's your own or your employees -- both for setup and ongoing maintenance. Price is an important, but not the only part of the equation here.
Sounds like an opportunity for a person with a domain expertise could make a good living doing this for companies.
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.
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.
Hah. If you think 3% is bad, I'd love to know what you think about the 30% that Apple takes for in app purchases. You are forced to use their system (or your app gets rejected), so you have no option but to use their payment methods. Highway robbery if you ask me.
The difference is that Apple is providing you with tonnes of publicity and easy access through the app store, and is ensuring that your product works with all of their users. They are adding way more value than just convenient payments.
Isn't $100/year enough for the access and making sure that product works fine. For publicity, it's two way and nowhere should take 30% if there is a free market for app store.
Back in the day when software was sold in boxes in retail stores, I guarantee those retail stores were taking well north of 30%.
Because they've stocked the products and paid for them, and threw away/discounted everything they did not sell. Vendors could only get <30% if taking back unsold merchandise.
It always amazes me how people do not understand the fundamentals of retailing.
It always amazes me how people do not understand the fundamentals of retailing.
For subscriptions, it drops to 15% after one year: https://developer.apple.com/app-store/subscriptions/
This is true, and that is definitely a difference worth pointing out.
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.
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.
> 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.
They literally marketed number of apps downloaded just yesterday in WWDC.
Is that for offline processing in a lowest risk industry? Curious as never seen a client get such a rate. Esp once acquirer fees for online payments are factored in (UK experience only)
I've never seen rates that low for recurring payments. Swiped cards in a brick-and-mortar, sure. The kind that batch nightly. But not for a SaaS where someone types in a card and you keep charging it for the next 36 months.
Recurring payments is a minimal risk after the first payment processed. If you're going to set up recurring, having an ACH transfer from bank account is going to be cheapest, or debit card paid via ACH.
Both. Moderately low risk, moderate volume.
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.
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.
Because people don't start off at scale, and because setting up a merchant bank can be a difficult hassle (more so if you're looking to accept multiple currencies), and because the cost of implementing features provided by stripe exceeds the amount lost in extra fees.
Once you hit scale it might be worth switching, but for many smaller sites Stripe is much more viable.
Once you hit scale it might be worth switching, but for many smaller sites Stripe is much more viable.
It's hassle. Much less than it used to be. It's also 2-point-whatever percent of all your revenue. The tipping point isn't as far out as you might think.
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).
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).
If you're doing less than a hundred thousand a year in revenue, you will likely save in development costs what you would pay in fees (3% x $100,000 = $3,000 = ~week of development costs).
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.
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.
If anything I think your estimation underscores the point that it quickly becomes worth the investment to shop for a cheaper payment option.
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.
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.
The positive sentiment is because they are a credit card processor that has a good API and supporting libraries. For some payment processors you are stuck with "here is our Java Middleware and this is the only thing you are allowed to use."
Yeah, I understand that's the root of it, but I've never understood how that positive sentiment remains so dominant when you start digging under the hood and realize that you're paying a percentage of your revenue for what amounts to a slick API or integrations. You don't need to be a financial genius to understand how little that adds up. It's always surprised me given the Hacker News crowd tends to like to dig into the details on most things.
> 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.
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.
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.
> but not THAT low
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.
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.
Currently it is legal for companies in the EU to ask the customer to pay the processing fees, some call it surcharging.
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.
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.
I must say that I'm genuinely surprised by this phenomenon.
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?
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?
It's a question of "do you charge 3% more for credit card payments to cover the charges from the credit card companies, but leave off that fee for non-credit card payments?"
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.
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.
>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.
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.
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.
Well, you're also missing things like the onerous process that some of the processors would have you go through to sign up. While I haven't been the person to actually setup a Stripe account, my impression is that it's pretty light-weight. From what I remember the business people having to go through to sign up for a merchant account with a processor (for a 100% online business) back in ~2010, it was practically like signing up for a mortgage. There was also back-and-forth between different "levels" of employees on the other side of things. At one point, IIRC the process even stalled because their end stopped responding to enquiries from our company. On top of that we were forced to use their Java middleware crap even though we weren't a Java shop. They made you feel like they couldn't care less about your business.
Well, the onboarding process in the past you've described seems like hell. May be merchants should simply accept to bite the bullet on this one and accept it as part of the cost of doing business.
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.
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.
It's not actually illegal in the US to pass the processing fee to the customer, it's just against the contract you have to sign to get a merchant account. I don't know if the EU has a law or regulation prohibiting such contracts, but it seems possible.
> It's not actually illegal in the US to pass the processing fee to the customer, it's just against the contract you have to sign to get a merchant account.
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
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
> It's no longer illegal federally
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.
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.
Correct me if I'm wrong; what you're saying is that merchant account providers have terms that dictate to merchants how they should price their products i.e. as a merchant you cannot pass the fee? (It seems incredibly stifling for the merchant to me but may be you can enlighten me on why it is in the interest of MAPs to have such a condition)
Do majority of MAPs in the US have this condition in their terms? And which MAPs don't have this condition?
Do majority of MAPs in the US have this condition in their terms? And which MAPs don't have this condition?
> Correct me if I'm wrong; what you're saying is that merchant account providers have terms that dictate to merchants how they should price their products i.e. as a merchant you cannot pass the fee?
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.
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.
>They are not allowed to charge customers more for paying via credit card that for paying via cash.
Now I get it. I'm not for it but I get it.
Now I get it. I'm not for it but I get it.
Legality aside, which other posters have covered:
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.
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.
I believe in the united states it is simply against the terms of service of the card provider. I imagine the law isn't "allowing" customers to pay processing fees, it's simply preventing the provider from setting those terms.
No longer true. Merchants can charge CC users in the US a surcharge.
Is there a current book that you can recommend to understand this very arcane business of credit card processing?
Unfortunately not. Online resources, experience, and payment processing consultants are the options available.
If you're a low volume business, then the difference of 1% probably isn't worth much headache. I can't comment on how easy those services are to integrate, but I've personally found Stripe super easy.
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.
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.
Would you mind sharing those companies? I'm especially curious since Stripe is not supported in my Country.
I'd suggest Pineapple Payments. They are a new company based upon the CardConnect platform, which was just acquired by FirstData.
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.
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.
From the Pineapple website: "We believe in transparent, simple pricing that is always customized to fit your usiness. Refreshing, right?"
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?
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?
https://www.paydoo.com/pricing is one example,
> starting at 0.59% + £0.20 adapted to industry type and risk level
> starting at 0.59% + £0.20 adapted to industry type and risk level
Phwoar!
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.
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.
That's really interesting. Do you have more examples? Thank you for the suggestion. Stripe is only the best known and is well integrated with other systems. When you use something like Paydoo you have to write e.g. your invoice email system yourself (and for stripe there are third party services which can handle that for you). So Stripe has benefits regarding the ecosystem around it.
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!
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!
Many —I'd perhaps even stretch to "most"— processors have at least the basic functionality like email receipts and, to at least some degree, recurring payments. They're staples of e-commerce.
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.
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.
Looks great, maybe even too good.
> 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.
> 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.
Have edited. Even if the rates you find aren't as good locally, still shop around and play them off each other to get a better rate.
It's unbelievable how easy this is with Stripe in comparison to PayPal. I had to do the latter a week ago and it was horrible [1]. It's no wonder Stripe is so successful.
[1]: https://fman.io/blog/paypal-for-saas-99-problems/
[1]: https://fman.io/blog/paypal-for-saas-99-problems/
Isn't that why they made Braintree
Not sure if you're implying that PayPal "made Braintree" or just that someone made it, but PayPal didn't acquire Braintree until 2013, after being founded in 2007 [1].
[1] https://en.wikipedia.org/wiki/Braintree_(company)
[1] https://en.wikipedia.org/wiki/Braintree_(company)
[deleted]
Use Braintree and have to say I like it. Paypal are a tad evil though.
Certainly, it's not rocket science either.
I wonder why we don't see much more competition though.
I wonder why we don't see much more competition though.
Stripe charges 2.9% + $0.30 per transaction, the others mentioned have a monthly fee and then lower transaction fees. So Stripe isn't remarkably cheap.
Depends. Developing intregrations has a cost, and until you're processing enough to offset the difference, using something other than Stripe is bad business.
It is not cheap. It is however, remarkably well designed and easy to integrate with, provides excellent support via their freenode channel and allows for most of the outside of normal range issues to be easily handled on their dashboard.
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.
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.
For those who are unaware : Stripe charges significantly less for within EU transactions ( like 1.4% or something ).
This is what people are missing on Lambda. It's pay-to-play, and for 90% of the sites out there, they're paying too much in comparison.
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.
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.
But are they really paying too much? I can't think of a lot of products out there, especially those that have a recurring subscription, that don't required some sort of database. So you need a server running a database anyway. It seems that the subscription logic would be a very negligible addition to the instance you have to be running anyway.
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.
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.
There are multiple alternatives to running your own DB service, and again, all pay-per-use.
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.
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.
In this case you should really just dump the subscription on a queue (SQS) and process the payment to mailchimp on a different thread that can deal with errors.
For data storage, you can use aws DynamoDb (NoSQL), which has some generous monthly free tier.
You could use DynamoDB and S3 for persistence if you're taking the AWS route.
Did you mean serverless.com? serverless.io is a parked domain...
This is doubly true with their generous free tier. It applies per-region so for some tasks you can spread workloads out across regions and reduce costs. Cronitor runs about 6 million multi-second lambda invocations a month for $20.
[deleted]
It's serverless.com
I've been using Laravel Spark [1] for recurring payments built on top of Stripe, and at a 100$ one-time fee for Spark and a small server setup (that I needed for the service in the first place) I think it's a cheap option for recurring payments, too.
[1] https://spark.laravel.com/
[1] https://spark.laravel.com/
I did something similar with aMember a few years back. Supports many payment processors; a one time fee. API, etc.
https://www.amember.com/
The problem is that Stripe is still not usable in the half of the world, including my country, Romania.
I've lived for some time in Romania and I think I can see both sides of the issue here.
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.
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.
But if Stripe allows Romania it most probably will be used by local companies for worldwide internet payments, so local fraud and corruption won't be affecting Stripe per se.
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.
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.
Laws vary, and they still have to build out the infrastructure to support whatever bank they use in a given country and the laws and implementation differ dramatically.
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.
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.
But why do they need to use a bank in Romania and create some infrastructure for that? Can't they just use some bank in eurozone to gather money from customers and send out payments to the users in their local Romania bank, or something like that? There are payment providers which do that.
I think that it is more complicated then this.
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.
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.
You can use Atlas cant you?
It is a bit overkill to establish a US company just to be able to accept payments.
The only real alternative is PayPal at this moment.
The only real alternative is PayPal at this moment.
Check out fastspring.com
We are using share*it: https://www.mycommerce.com/
Mostly same as your suggestion.
What is Atlas in this context?
Stripe's offering to set up a company in the US, with bank accounts and everything.
https://stripe.com/atlas
https://stripe.com/atlas
[deleted]
I maintain a small open source library for managing payments websites that uses this architecture [1]. My Lambda costs have been about $0.04 per transaction.
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...
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...
I never got around getting the true value prop of recurring solutions such as chargebee etc when used on top of stripe. Stripe already provides excellent recurring subscription payments api out of the box, so why use any of these services. Am I missing something ?
We transitioned from Stripe to Chargebee importing our Stripe stuff. It was a solid 2 man-months of engineering (of our 4-person company) and we questioned the cost through the process, but it has really paid off. Stripe was a great starting point for us to collect direct payments, but as we grew Chargebee has proven very worthwhile.
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.
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.
Have you done any formal ROI on the move to Chargebee?
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 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.
Chargebee had a one-time free customer database import process from Stripe, does Chargify/Stripe not support any kind of customer import/transfer?
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.
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.
The idea is that you are not locked in by one specific payment provider. Stripe is awesome but I only want to use it for processing actual charges. The business logic for subscriptions, invoices etc. should be managed by my own system (chargebee etc) so that I can switch to another provider tomorrow if needed.
Or take it a step further: https://news.ycombinator.com/item?id=12161235
Sometimes they offer this: UI on top of API, generated invoices (PDF/email).
Thanks for article. Though I known about Lambda for long time, but this is one nice example, how Lambda can be used. Now I am planning to use to develop some zapier like integrations.
-=-=
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).
-=-=
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).
I've seen several comments on here about how high a percentage is being charged by credit card processors and this is something I've wondered about for a while. There are some sites where I feel like I must be missing something.
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.
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.
This is pretty cool but to be pedantic this is actually API Gateway proxying requests to AWS Lambda not just a Lambda function. Zappa and other Serverless Frameworks sort of obfuscate the fact that API Gateway is setup in front of Lambda but that is what is happening here. Again, cool example.
I can see many cases where there is need for more control. Yes, we can start and end manually, but is it acceptable to be that flaky with payments. I mean, I have managed my personal server in pretty ad-hoc way and more often than I expected there are some problems with something. I don't think I can trust myself with lambda.
Now if only my property manager could get with the beat and take electronic payments ... I still have to bike over to their office and drop off a physical check every month because they don't take anything else.
Credit card payments usually have a 2-3% processing fee. Your property manager doesn't want to pay that, thus you pay via check.
Can you use bill pay from your bank?
I think so, but it requires me to call them to set up, I hate calling and being put on hold.
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.
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.
Most banks allow you to setup bill pay online. The bank will mail a check on your schedule. No need for phones.
I wish. Both of my banks bring up messages saying to call customer service when I click on their respective Bill Pay links. So much for "online" banking. We're back in the 80's.
Some banks will even send the check on your behalf.
I use Simple bank and they can automatically mail out checks on your behalf, if you set it up.
I use Simple bank and they can automatically mail out checks on your behalf, if you set it up.
This is simple and cool.
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.
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.
The example given in the article is a pay-to-subscribe mailing list run on Mailchimp where you can use an API call to add the paying user to the list.
id rather use XRP
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.