Ask HN: How are lean startups easily accepting CC payments?
124 comments
We're using Braintree here at Loggly, and like it quite a lot. The API has a neat little Python library that we use on our backend, and is pretty well documented.
The indirection involved in posting billing forms to them means you wind up doing some interesting gymnastics if you want to include a billing form as part of a larger user signup form. You may want to check the JS on our paid signup page -- go to https://www.loggly.com/register/#woodpecker do an inspect element on the submit button, and expand the inline script a few lines down. The script creates an (unfunded, inactive) user on the server, receives a token pointing to this user to use in posting to braintree, and then posts the braintree form.
The indirection involved in posting billing forms to them means you wind up doing some interesting gymnastics if you want to include a billing form as part of a larger user signup form. You may want to check the JS on our paid signup page -- go to https://www.loggly.com/register/#woodpecker do an inspect element on the submit button, and expand the inline script a few lines down. The script creates an (unfunded, inactive) user on the server, receives a token pointing to this user to use in posting to braintree, and then posts the braintree form.
Thank you for the heads up on the technical aspects of integration. Will take a peek at the JS.
Wow! The glowing reviews of Braintree really got my interested in them. So I went to their site. The best I've seen yet! Really top notch. Info flows clearly and plainly. Love it... except I'm in Canada. They don't service Canada.
So, anyone got a Braintree-like company in Canada they can reco?
So, anyone got a Braintree-like company in Canada they can reco?
If you want to integrate with Spreedly, I'll do it for $500. Just say you saw this post here on HN
assuming you already have a merchant account and gateway (which takes like a day to get approved, assuming you don't have your social security card on hand)... you can get integrated with Recurly in two days of intense concentration.
but if you just want to start taking customers' cash ASAP, you can do that with a paypal hosted button in about 5 minutes.
WPP lets you accept credit cards w/ paypal - no paypal acct necessary - and there's tons of sample code out there that's basically copy and pasteable, and lots of code monkeys are familiar with the intricacies of paypal integration.
but if you just want to start taking customers' cash ASAP, you can do that with a paypal hosted button in about 5 minutes.
WPP lets you accept credit cards w/ paypal - no paypal acct necessary - and there's tons of sample code out there that's basically copy and pasteable, and lots of code monkeys are familiar with the intricacies of paypal integration.
>> which takes like a day to get approved
Which bank did you use? My experience has been that if you're doing ANYTHING other than e-commerce, it's a long uphill struggle. I've tried Chase, B of A, and Wachovia.
Which bank did you use? My experience has been that if you're doing ANYTHING other than e-commerce, it's a long uphill struggle. I've tried Chase, B of A, and Wachovia.
citibank business account
Take a look at 2checkout, they have some recurrent billing functionality out-of-box.
I'm using Paypal Pro payments + Recurly. Between the ease of opening an account and ease of integration it made the slightly higher charges well worth it. Recurly doesn't have drop in django integration, but I'll eventually clean up and open source the subscription/registration app I'm using.
I am doing something similar with Spreedly. There is a Django app for it, but the API code is pretty messy (what do you imagine get_info() does?) If anyone is interested, I can post my API wrapper to github.
I'd be interested in your open-source Django app. Sounds like a great idea.
I too would be very interested in seeing your Django app!
Might want to check out: Chargify, Spreedly or Recurly
I also read a great post on setting up payments the right way, on the cheap, but I can't find it now. Will post if I do.
One nice thing about PayPal is you can use them for Offline, Web and Mobile payments - there are pros and cons to consider, might want to contact a few companies and explain your needs.
I also read a great post on setting up payments the right way, on the cheap, but I can't find it now. Will post if I do.
One nice thing about PayPal is you can use them for Offline, Web and Mobile payments - there are pros and cons to consider, might want to contact a few companies and explain your needs.
most of the payment gateway integrations can be done in 1 or 2 days. For the main ones like authorize.net/braintree/etc, you have tones of libraries and snippets all over the web.
check activemerchant if you use ruby.
check activemerchant if you use ruby.
Been very happy with Chargify, except that it's expensive, especially at the start. However, it's scaled incredibly well with us. It's easy to update subscriptions, look up transactions, and basically do everything we need to do.
It's vastly, vastly better than our experience with Amazon SimplePay/FPS
It's vastly, vastly better than our experience with Amazon SimplePay/FPS
I'm using Braintree combo-ed with Recurly. Makes it simple to start accepting subscriptions. I'm a big fan of recurly and if I ever feel like coding my own, I can use Braintrees. I built my own subscription payments for Paypal before and to be honest I'd never want to use that code again. Subscriptions have a lot more headaches then appear at first glance.
Braintree has their own system for recurring payments too; what made you decide to use Recurly instead?
Knew the guys and realized how easy their product is to drop in with no setup. Full interface for any non coder to use easily. Braintree's setup and site aren't that easy or simple. If I want to put in the work, I'll fully switch to Braintree
My personal strategy has been to start out with paypal because it's super easy to integrate, and then when you have enough sales, upgrade to something like braintree. That way you wait until proof of concept and revenue before you put down money on a better solution.
+1
PayPal is _absurdly_ easy to set up and start collecting money.
You do though, need to understand that Papal's main business advantage over banks is their automated fraud prevention/detection - if you do anything that might come close to triggering their automated systems, you need to watch out. In my experience, that's almost always been accepting payments significantly before shipping something that can be tracked. Pre orders often get accounts locked. Non physically shipped products (thing "digital downloads" - software, music, or ebooks) often get accounts locked.
If you're not doing that kind of thing, or if you're doing it and are prepared to put up with Paypal holding on to your money until they believe your customers are happy, then PayPal is a reasonable solution (we have a client who starts accepting pre-orders for e new edition of his book every October, and PayPal hang on to _all_ money put into his PayPal account until 3 or 4 weeks after the books start shipping in early January. This has been going on for 4 years now, exactly the same every year, but the client is perfectly happy with that situation, he's mainly accepting pre-orders as a way to more accurately guage how many copies to print in the first run, he doesn't need to have the money up front but it's a great way for him to know really firm minimum order numbers for the first print run. It's only when he gets drunk over Xmas/new year and starts ringing PayPal up and screaming "give me my fucking money!" at anyone who answers the phone that it's a drama, unfortunately _that's_ been going on for 4 years now too...
Tl;dr, use PayPal to start with. Never leave more money in the PayPal account than you're prepared to lose. Never leave that money in a bank account linked to PayPal either. Make sure you've got a backup payment method at least planned, that you can switch in sufficiently quickly that you don't go broke between when PayPal cuts off your money and the new payment system is in place (that means get your merchant account and Internet merchant ID applications in process _now_, not after you have a PayPal problem.)
PayPal is _absurdly_ easy to set up and start collecting money.
You do though, need to understand that Papal's main business advantage over banks is their automated fraud prevention/detection - if you do anything that might come close to triggering their automated systems, you need to watch out. In my experience, that's almost always been accepting payments significantly before shipping something that can be tracked. Pre orders often get accounts locked. Non physically shipped products (thing "digital downloads" - software, music, or ebooks) often get accounts locked.
If you're not doing that kind of thing, or if you're doing it and are prepared to put up with Paypal holding on to your money until they believe your customers are happy, then PayPal is a reasonable solution (we have a client who starts accepting pre-orders for e new edition of his book every October, and PayPal hang on to _all_ money put into his PayPal account until 3 or 4 weeks after the books start shipping in early January. This has been going on for 4 years now, exactly the same every year, but the client is perfectly happy with that situation, he's mainly accepting pre-orders as a way to more accurately guage how many copies to print in the first run, he doesn't need to have the money up front but it's a great way for him to know really firm minimum order numbers for the first print run. It's only when he gets drunk over Xmas/new year and starts ringing PayPal up and screaming "give me my fucking money!" at anyone who answers the phone that it's a drama, unfortunately _that's_ been going on for 4 years now too...
Tl;dr, use PayPal to start with. Never leave more money in the PayPal account than you're prepared to lose. Never leave that money in a bank account linked to PayPal either. Make sure you've got a backup payment method at least planned, that you can switch in sufficiently quickly that you don't go broke between when PayPal cuts off your money and the new payment system is in place (that means get your merchant account and Internet merchant ID applications in process _now_, not after you have a PayPal problem.)
Are any of the solutions out there comparable to BrainTree? It's easy to process CC's, even recurring, but it's a pain to do PCI compliance. If the CC info hits your server, you're in PCI scope. BrainTree has the browser send the info direct to them, then redirects with a token you can use to check information and perform charges.
Anything else out there like that? That is, all the flexibility of being able to run charges programmatically, without the overhead of being PCI compliant?
Anything else out there like that? That is, all the flexibility of being able to run charges programmatically, without the overhead of being PCI compliant?
I believe Spreedly's new http://spreedlycore.com is supposed to do this.
I am no expert on this, but from what I gathered of previous discussions of this topic, is that if you are serving the form HTML, you need some form of PCI compliance, even though the CC never hits your server. This makes sense as any XSS attack would allow an attacker to lift the CC straight from the page.
Some processors ofter an option that allows you to redirect to a page that they host for the cc information, and then back to your page for checkout.
As I mentioned above, Authorize.Net's CIM (Customer Information Manager) works in a similar way -- you send the credit card info from your website to Authorize.net (and never store it in between) and you get a token back which you can store, and which you can use to make charges later.
But if the CC info ever hits your server, your server, apps, etc. fall into scope. Not storing it just gets you out of a small part of PCI.
I use Stripe for Gumroad and it's amazing. Unfortunately, it's still private for now.
+1 for Stripe.
I've coded with both Authorize.net's and First Data's APIs, and Stripe is much, much better in comparison.
I've coded with both Authorize.net's and First Data's APIs, and Stripe is much, much better in comparison.
You're crazy not to go with Stripe. The only thing that's better than the awesomeness of the guys that run it is the API.
Just said the same thing elsewhere but I'm very happy with Stripe and strongly recommend it.
Anyone else think this thread reads like a stripe bot love-fest?
We've migrated from authorize.net to stripe.com and we love it.
such an awesome domain name! (stripe.com)
can anyone get me an invite :-)
can anyone get me an invite :-)
+1 for Stripe
Anyone can send me a invite?
If you want something simple without writing much code, go with PayPal. You'd expect some "horror stories" from a payment processor with 232 million accounts. Virtually all of them involve someone doing something that'd raise flags at any merchant account provider or bank, it's just that people think PayPal isn't a bank so they should be able to get away with anything. 10,000 horror stories still leaves 99.99% of users happy.
If you want to accept credit cards on your own site, you need to learn about PCIDSS compliance, you need to apply for a merchant account, and you need to a payment gateway that works with that merchant account.
It's well within reach of a lean startup. The application is usually a page or two long, you'll get approval from the underwriting bank within a week or so, and most MAPs also resell the payment gateway accounts so they set that up for you and you get everything at once. The fixed costs will be a statement fee and a gateway fee, $20-30 a month total.
It's terribly difficult to understand the fees you'll be paying with a merchant account. They're far more complex than whatever you get quoted will lead you to expect, and it's absolutely common for providers to change the fees on a monthly basis such that after a year you have no idea what you're paying. There can be dozens of classes of credit cards each with different rates when you charge them. My only advice for dealing with that is to try not to tie your code to your processor so that, when you grow enough for the fees to matter, you can shop around for a better deal.
You don't get to take shortcuts with the PCI stuff. The fine for a credit card being compromised from your server because you weren't PCIDSS compliant start at $500,000 per incident (paid to Visa/MC) plus legal fees and costs to provide credit monitoring to the victims.
If you accept credit cards directly on your site, you'll be required to fill out a self-assessment questionnaire and have a compliance scan against your server run on some basis. For most ecommerce setups, it'll be quarterly. What that costs depends on your merchant account provider; some contract with and pay a compliance company for you, others you have to pay some or all of the costs yourself, which can be a couple hundred dollars a year. SecurityMetrics seems to be the most popular service for the scans.
The technical part is easy. An Authorize.net integration will take you a couple hours at most. There are libraries for the popular payment gateways in every programming language known to man, and prebuilt shopping carts will have plugins/modules/whatever written by people already.
It's just like any other API. You POST some data to some server to make a charge/authorization/refund/etc and get a response to parse. If your app integrates with Twitter, you've already done much harder work than integrating a form with a payment gateway.
If you want to accept credit cards on your own site, you need to learn about PCIDSS compliance, you need to apply for a merchant account, and you need to a payment gateway that works with that merchant account.
It's well within reach of a lean startup. The application is usually a page or two long, you'll get approval from the underwriting bank within a week or so, and most MAPs also resell the payment gateway accounts so they set that up for you and you get everything at once. The fixed costs will be a statement fee and a gateway fee, $20-30 a month total.
It's terribly difficult to understand the fees you'll be paying with a merchant account. They're far more complex than whatever you get quoted will lead you to expect, and it's absolutely common for providers to change the fees on a monthly basis such that after a year you have no idea what you're paying. There can be dozens of classes of credit cards each with different rates when you charge them. My only advice for dealing with that is to try not to tie your code to your processor so that, when you grow enough for the fees to matter, you can shop around for a better deal.
You don't get to take shortcuts with the PCI stuff. The fine for a credit card being compromised from your server because you weren't PCIDSS compliant start at $500,000 per incident (paid to Visa/MC) plus legal fees and costs to provide credit monitoring to the victims.
If you accept credit cards directly on your site, you'll be required to fill out a self-assessment questionnaire and have a compliance scan against your server run on some basis. For most ecommerce setups, it'll be quarterly. What that costs depends on your merchant account provider; some contract with and pay a compliance company for you, others you have to pay some or all of the costs yourself, which can be a couple hundred dollars a year. SecurityMetrics seems to be the most popular service for the scans.
The technical part is easy. An Authorize.net integration will take you a couple hours at most. There are libraries for the popular payment gateways in every programming language known to man, and prebuilt shopping carts will have plugins/modules/whatever written by people already.
It's just like any other API. You POST some data to some server to make a charge/authorization/refund/etc and get a response to parse. If your app integrates with Twitter, you've already done much harder work than integrating a form with a payment gateway.
Here's my horror story, let me know if you can figure out where I raised a flag because I can't. I was using Website Payments Pro with Spreedly for over a year, when I applied for access to their Adaptive Payments APIs. After getting approved a few days later, all of my spreedly subscriptions started failing with the error that I had to include the CVV. You can't store CVVs so it was now impossible to process recurring subscriptions with WPP.
Multiple calls to PayPal were useless. They told me that when I applied for adaptive payments, they reviewed my entire account and decided to require that I always include CVVs. In over a year, I had almost no chargebacks so fraud shouldn't be the reason.
The next day I applied for Authorize.net and was accepted the following day. It's about about the same price as when I was with PayPal, but with none of the hassle.
In summary, if you want credit card based recurring subscriptions, PayPal is just as expensive, significantly more restrictive, has terribly designed APIs, a sandbox environment that doesn't work as often as it does, and is kind of like smoking next to a barrel of gun powder.
Multiple calls to PayPal were useless. They told me that when I applied for adaptive payments, they reviewed my entire account and decided to require that I always include CVVs. In over a year, I had almost no chargebacks so fraud shouldn't be the reason.
The next day I applied for Authorize.net and was accepted the following day. It's about about the same price as when I was with PayPal, but with none of the hassle.
In summary, if you want credit card based recurring subscriptions, PayPal is just as expensive, significantly more restrictive, has terribly designed APIs, a sandbox environment that doesn't work as often as it does, and is kind of like smoking next to a barrel of gun powder.
I asked software vendors we work with who had previously used PayPal for their e-commerce to list any issues or limitations they experienced when using PayPal. The following outlines some of the issues that they experienced. No doubt there are countless happy PayPal clients out there as well, these are just issues some have run into that everyone should at least evaluate.
“PayPal’s reporting is extremely limited.”
“Virtually impossible to use for serious businesses without extensive external code or a system to manage customer flow/cross/upsells.”
“You spend too much precious time on e-commerce tasks and way too little time on marketing and dev.” “For business-to-business products, clients do not take you seriously as a potential supplier if PayPal is your main payment method.”
“PayPal has very strict rules about the orders they are willing to let through, so merchants end up with fewer orders going through/lost revenue. They are quite picky about declining certain credit and debit cards other services would otherwise accept.”
“I log into my PayPal account and what do I see? “For my protection” they have limited the ability of my account to withdraw or send money but most severely, they also disallowed the account to receive payments! Frantically, I go to MacGraPhoto’s buy page, click buy and see a message “The seller can’t receive payments at this time”. At about the same time I get an email from a potential customer that says that he can’t buy the bundle. In the server log I see other people trying buy the bundle and leaving. Lost sales. Not good. Not good at all. My PayPal’s page lists lots of things that I need to provide to PayPal regarding my personal identity and regarding the sales. Some requests are totally not relevant to the case or to our business…And, it’s totally impossible to directly talk to the people who actually decide…I receive another email from PayPal. The subject was new: “PayPal appeal denied”…So, now the money (most of which is not even ours but of our bundle members) is held for 6 months. Sure, they are “making every effort to minimize any disruption to your business”. Sure, no disruption at all…Needless to say, I didn’t get any response not after 72 hours and not after a week. I called support again and was told that they won’t respond me because my appeal was denied and they don’t reopen cases…I won’t be using PayPal to sell anything from now. They have grown too big to be efficient and caring for their customers. Quick to make totally disruptive decisions and to dismiss legitimate businesses without really taking a look at what it is…They took the liberty to totally halt our business, to cause lots of lost sales and a major cash flow blow only because we got successful with one promotion, after being their customers for a long time. Right, they “regret any inconvenience this may cause”. They are “making every effort to minimize any disruption to your business”. If you’re selling anything and use PayPal as your only payment option, I urge you to reconsider. They can cut your oxygen supply right at peak of your success, of course “for your own protection”…we decided to leave PayPal as our e-commerce service at Apparent Software and moved to FastSpring.”
“No branding on PayPal order pages means fewer purchases! My order page needs to blend in with the rest of my site or too many people will bail on us”
“No fulfillment support”
“Revenue is lost because a decent number of customers are located in countries PayPal won’t accept payments within for whatever reason.”
“As much as I like rolling my own solutions, it’s too complicated to offer quantity discounts, coupon codes, and multiple currencies on top of the PayPal API alone.”
“Tax responsibilities are on the client, ugh.” (US and EU VAT)
“Huge problems with spam filters on PayPal — we automatically send out logins once an order is processed yet a higher percentage is not received than is received.”
“They have virtually no fraud screening.”
“(PayPal is) more difficult to set up – documentation spread all over the place, and forum answers sometimes misleading”
“There is no support for discount codes/vouchers (this really surprised me)”
“No experience with (PayPal) customer service yet- but I’ve heard bad things”
“Their system is very clunky, as far as looking up orders, pulling reports, checking a history etc…”
“PayPal heavily favors the purchaser not the vendor selling, as in chargebacks or disputes etc.”
“I don’t get notification of orders on a consistent basis, I have to login and check orders daily”
"We sell off multiple sites with the same PayPal account and the reporting to figure out which sites generated which sales is a nightmare”
“Lacks professionalism”
“Their UI stinks, it takes me a while to figure out how to do things in their system”
“I have heard too much about PayPal’s abuses to trust them. When I see something where the only payment option is PayPal, I select a different option: not buying.”
“No ability to offer upsells (at least that I can figure out)”
“PayPal’s reporting is extremely limited.”
“Virtually impossible to use for serious businesses without extensive external code or a system to manage customer flow/cross/upsells.”
“You spend too much precious time on e-commerce tasks and way too little time on marketing and dev.” “For business-to-business products, clients do not take you seriously as a potential supplier if PayPal is your main payment method.”
“PayPal has very strict rules about the orders they are willing to let through, so merchants end up with fewer orders going through/lost revenue. They are quite picky about declining certain credit and debit cards other services would otherwise accept.”
“I log into my PayPal account and what do I see? “For my protection” they have limited the ability of my account to withdraw or send money but most severely, they also disallowed the account to receive payments! Frantically, I go to MacGraPhoto’s buy page, click buy and see a message “The seller can’t receive payments at this time”. At about the same time I get an email from a potential customer that says that he can’t buy the bundle. In the server log I see other people trying buy the bundle and leaving. Lost sales. Not good. Not good at all. My PayPal’s page lists lots of things that I need to provide to PayPal regarding my personal identity and regarding the sales. Some requests are totally not relevant to the case or to our business…And, it’s totally impossible to directly talk to the people who actually decide…I receive another email from PayPal. The subject was new: “PayPal appeal denied”…So, now the money (most of which is not even ours but of our bundle members) is held for 6 months. Sure, they are “making every effort to minimize any disruption to your business”. Sure, no disruption at all…Needless to say, I didn’t get any response not after 72 hours and not after a week. I called support again and was told that they won’t respond me because my appeal was denied and they don’t reopen cases…I won’t be using PayPal to sell anything from now. They have grown too big to be efficient and caring for their customers. Quick to make totally disruptive decisions and to dismiss legitimate businesses without really taking a look at what it is…They took the liberty to totally halt our business, to cause lots of lost sales and a major cash flow blow only because we got successful with one promotion, after being their customers for a long time. Right, they “regret any inconvenience this may cause”. They are “making every effort to minimize any disruption to your business”. If you’re selling anything and use PayPal as your only payment option, I urge you to reconsider. They can cut your oxygen supply right at peak of your success, of course “for your own protection”…we decided to leave PayPal as our e-commerce service at Apparent Software and moved to FastSpring.”
“No branding on PayPal order pages means fewer purchases! My order page needs to blend in with the rest of my site or too many people will bail on us”
“No fulfillment support”
“Revenue is lost because a decent number of customers are located in countries PayPal won’t accept payments within for whatever reason.”
“As much as I like rolling my own solutions, it’s too complicated to offer quantity discounts, coupon codes, and multiple currencies on top of the PayPal API alone.”
“Tax responsibilities are on the client, ugh.” (US and EU VAT)
“Huge problems with spam filters on PayPal — we automatically send out logins once an order is processed yet a higher percentage is not received than is received.”
“They have virtually no fraud screening.”
“(PayPal is) more difficult to set up – documentation spread all over the place, and forum answers sometimes misleading”
“There is no support for discount codes/vouchers (this really surprised me)”
“No experience with (PayPal) customer service yet- but I’ve heard bad things”
“Their system is very clunky, as far as looking up orders, pulling reports, checking a history etc…”
“PayPal heavily favors the purchaser not the vendor selling, as in chargebacks or disputes etc.”
“I don’t get notification of orders on a consistent basis, I have to login and check orders daily”
"We sell off multiple sites with the same PayPal account and the reporting to figure out which sites generated which sales is a nightmare”
“Lacks professionalism”
“Their UI stinks, it takes me a while to figure out how to do things in their system”
“I have heard too much about PayPal’s abuses to trust them. When I see something where the only payment option is PayPal, I select a different option: not buying.”
“No ability to offer upsells (at least that I can figure out)”
Authorize.net also offers a hosted option so that the merchant doesn't have to deal with the burden of PCI compliance. In other words, the merchant (you) never sees the credit card number.
http://developer.authorize.net/api/sim/
http://developer.authorize.net/api/sim/
Authorize.net's AIM gateway also allows the flexibility to authorize now and capture later - without the webapp needing to store the credit card info.
Pretty nice if you want to do things like "we'll bill your credit card only when item ships", etc.
Pretty nice if you want to do things like "we'll bill your credit card only when item ships", etc.
Everyone _should_ do that, as CCs generally take a dim view on charging before something actually ships.
Yes - which is why what webapps do is only authorize AND charge when something actually ships. Most payment gateways (including Authorize.net's other products like SIM) support this workflow.
The reason is because, to do something like AIM or CIM, payment gateways need to store CVV numbers as well, resulting in a very expensive level of PCI compliance.
I'm not extremely well versed with fraud semantics, but IMHO placing an authorize on a card reduces the risk of fraud, refusing to pay, etc.
The reason is because, to do something like AIM or CIM, payment gateways need to store CVV numbers as well, resulting in a very expensive level of PCI compliance.
I'm not extremely well versed with fraud semantics, but IMHO placing an authorize on a card reduces the risk of fraud, refusing to pay, etc.
As does E-xact:
http://www.e-xact.com/hosted-checkout/
http://www.e-xact.com/hosted-checkout/
They also have CIM, Customer Information Manager, where you send the credit card info (thus never storing it yourself) and you get back a token. Anytime you need to charge that card, you charge the token instead. PCI compliance is then on Authorize.net
Even if you aren't storing card information you still are subject to PCI compliance if the card information passes through your application/server. In the case where you are processing but not storing you would need to complete the SAQ-C questionnaire and still probably be subject to quarterly scans (the self-assessment where are you storing data is SAQ-D)
https://www.pcisecuritystandards.org/merchants/self_assessme...
https://www.pcisecuritystandards.org/merchants/self_assessme...
Pretty much every gateway has some kind of tokenization solution (or reference transaction solution) that accomplishes the same thing. They all call it something different and try to make it seem like it is unique, which can be confusing.
Unless you're also using one of those subscription-as-a-service startups to host the payment forms, no, PCI compliance is on you with CIM. The payment information passes through your server, so you're 100% required to meet all 200+ of the requirements of the standard, quarterly scans of your servers, etc. Secure storage is only one small subset of the requirements.
I have been considering FastSpring (http://www.fastspring.com), which has recently added subscription payments as a feature. I'm interested to hear about anyones experiences with them.
I believe you are referring to http://saasy.com/
It is a bundled payment gateway+merchant. You don't have to get PCI compliant and you don't need a merchant account (no min transaction volumes, fight chargebacks for you etc).
The down side is they only offer hosted payment pages and not suitable for everything... You need a finite set of goods/services you want to sell (eg monthly plans). You can't automate the process if you're building an online store where your customers can upload items for sale (eg AppStore).
It is a bundled payment gateway+merchant. You don't have to get PCI compliant and you don't need a merchant account (no min transaction volumes, fight chargebacks for you etc).
The down side is they only offer hosted payment pages and not suitable for everything... You need a finite set of goods/services you want to sell (eg monthly plans). You can't automate the process if you're building an online store where your customers can upload items for sale (eg AppStore).
The terminology of payments is so weird:
Payment processors refer to their business customers as "merchants".
Entrepreneurs ALSO refer to their payment processors as "merchants".
Payment processors refer to their business customers as "merchants".
Entrepreneurs ALSO refer to their payment processors as "merchants".
SaaSy is a service from FastSpring, just to clarify. To see what people say about FastSpring, try searching online or you can view what they're saying here:
http://www.fastspring.com/clients.php
Some samples: "I'm going to come out and say it: FastSpring is awesome. I haven't experienced customer service this good in my life. Every query I've had, from stupid questions to difficult questions to bug reports has been dealt with brilliantly." - Daniel Kennett, kennetnet
“FastSpring is definitely the best company I have ever interacted with (note: the best company ever, not just related to e-commerce).” - Ruman Stankov, Triland Inc.
Some samples: "I'm going to come out and say it: FastSpring is awesome. I haven't experienced customer service this good in my life. Every query I've had, from stupid questions to difficult questions to bug reports has been dealt with brilliantly." - Daniel Kennett, kennetnet
“FastSpring is definitely the best company I have ever interacted with (note: the best company ever, not just related to e-commerce).” - Ruman Stankov, Triland Inc.
We use BrainTree - who really worked with us more than others with our non-CC optimal payment risk (manufacturing custom parts). Although, I don't like that they're phasing out their ACH/EFT services...
I don't have much real world experience with card processing, but the last time I looked, RBS worldpay offered a nice subscription models. I was planing to delve into that, but the project I was involved in fell apart, and there was no need for me to pursue more info.
I believe that since they would handle everything transaction wise, you don't have to worry about being PCIDSS compliant.
I believe that since they would handle everything transaction wise, you don't have to worry about being PCIDSS compliant.
google "square".
[deleted]
CMIIW, but square is for physical world transactions (that is, you swipe the card).
We went through this recently and decided that Braintree was a nice one stop shop. Great hand holding through the set up process and lots of api/library support out there.
You can always decide to put Chargify on top of that if you want. Bonus -- if you end up getting a merchant account with your existing bank you can swap that in later. (Though you probably will get a better rate w/ Braintree).
You can always decide to put Chargify on top of that if you want. Bonus -- if you end up getting a merchant account with your existing bank you can swap that in later. (Though you probably will get a better rate w/ Braintree).
Chargify does not work with Braintree v2 API, as far as I know.
I'm going to be launching soon with PayPal's Digital Goods Express Checkout dealio. In theory, integration is simple, but I've found the documentation to be lengthy, incomplete, and just plain wrong in some cases. I've had speedy support responses, though. The Sandbox is handy, if clunky.
If Braintree had a micropayments option I would almost certainly have tried to go with them.
If Braintree had a micropayments option I would almost certainly have tried to go with them.
Stripe
One option is Clickbank.
No need for a merchant account and they easily handle affiliate commissions (if that's something you want).
Downside is that people will see Clickbank.com on their credit card statement, not your merchant name (but that's the same with a basic PayPal account as well).
Upside is they have a very good track record at processing recurring payments successfully (much better than PayPal) and they don't freeze your account like PayPal or Google Checkout does.
No need for a merchant account and they easily handle affiliate commissions (if that's something you want).
Downside is that people will see Clickbank.com on their credit card statement, not your merchant name (but that's the same with a basic PayPal account as well).
Upside is they have a very good track record at processing recurring payments successfully (much better than PayPal) and they don't freeze your account like PayPal or Google Checkout does.
I know you mentioned not liking Amazon for the sign-up step, but in practice I haven't noticed much of a fall-off because of it. I use Amazon's Flexible Payments Service for taking small payments (<$2), and I've been pretty happy.
About 10% of the people who click the "buy it" button on my product get to the Amazon sign-in/registration page and then bail. Abandoned funnels always sting, especially so close to completion, but is a 10% abandonment rate worse than it would be for a more direct credit card payment system? I doubt it, though I admit that I don't have any solid data to support that assertion. Might be worth trying.
About 10% of the people who click the "buy it" button on my product get to the Amazon sign-in/registration page and then bail. Abandoned funnels always sting, especially so close to completion, but is a 10% abandonment rate worse than it would be for a more direct credit card payment system? I doubt it, though I admit that I don't have any solid data to support that assertion. Might be worth trying.
[deleted]
Hi there,
I'm one of the founders of Chargify. Whether or not you choose to use us (our focus is the management of recurring billing, products, coupons, proration, etc.), here is an article I wrote to help startups and SMBs understand payment gateways and merchant accounts:
http://support.chargify.com/kb/merchant-accounts-payment-gat...
If you just need to accept credit card payments of any sort, this is the foundation you'll need. PayPal Website Payments Pro is their version of gateway + merchant account, but frankly, after seeing hundreds of merchants choose this or that solution, I recommend other gateway/merchant account combos.
I hope it's helpful info.
Thanks.
--- Lance
I'm one of the founders of Chargify. Whether or not you choose to use us (our focus is the management of recurring billing, products, coupons, proration, etc.), here is an article I wrote to help startups and SMBs understand payment gateways and merchant accounts:
http://support.chargify.com/kb/merchant-accounts-payment-gat...
If you just need to accept credit card payments of any sort, this is the foundation you'll need. PayPal Website Payments Pro is their version of gateway + merchant account, but frankly, after seeing hundreds of merchants choose this or that solution, I recommend other gateway/merchant account combos.
I hope it's helpful info.
Thanks.
--- Lance
There's a lot of good options and great providers, each having their pros and cons dependent on where you are in your lean startup "lifecycle".
About Simplified Ecommerce: We specialize in subscriptions and our goal is to support a merchant throughout their entire lifecycle; finding product- market fit before they have a merchant account (similar to clickbank or fastspring), affiliate marketing to accelerate their growth, transitioning to their 1st merchant account and switching or adding merchant accounts as they scale.
Throughout their lifecycle, adding or switching a merchant account is as simple as submitting new merchant account credentials. All their custom hosted payment pages, integrations, pricing plans, affiliate relationships, reporting...remains intact. All customer data is stored in our independent level 1 PCI compliant gateway vault and is fully portable.
Our primary market is the non developer. Although Recurly, Spreedly/ Spreedlycore, Chargify and others have great, robust API's, we offer simple copy & paste "Buy Now link" type integrations. Merchants can customize hosted payment pages, switch merchant accounts, add subscription plans and set up affiliate programs in minutes, with just a few clicks. We also provide the consumer interface so subscribers can cancel, up or down grade their subscriptions without any additional integration or programming by the merchant.
I'd love to hear your feedback and happy to answer any questions. We are planning to expand our private beta in the next couple months, contact me if you're interested- Colin at SimplifiedEcommerce.com
About Simplified Ecommerce: We specialize in subscriptions and our goal is to support a merchant throughout their entire lifecycle; finding product- market fit before they have a merchant account (similar to clickbank or fastspring), affiliate marketing to accelerate their growth, transitioning to their 1st merchant account and switching or adding merchant accounts as they scale.
Throughout their lifecycle, adding or switching a merchant account is as simple as submitting new merchant account credentials. All their custom hosted payment pages, integrations, pricing plans, affiliate relationships, reporting...remains intact. All customer data is stored in our independent level 1 PCI compliant gateway vault and is fully portable.
Our primary market is the non developer. Although Recurly, Spreedly/ Spreedlycore, Chargify and others have great, robust API's, we offer simple copy & paste "Buy Now link" type integrations. Merchants can customize hosted payment pages, switch merchant accounts, add subscription plans and set up affiliate programs in minutes, with just a few clicks. We also provide the consumer interface so subscribers can cancel, up or down grade their subscriptions without any additional integration or programming by the merchant.
I'd love to hear your feedback and happy to answer any questions. We are planning to expand our private beta in the next couple months, contact me if you're interested- Colin at SimplifiedEcommerce.com
Horror stories you may have heard aside, I've setup PayPal's website payments pro for many clients, with tremendous success. Never had any trouble with them, and my PayPal rep has always been reachable by phone and very helpful.
Additionally, I've used their recurring payments product (extra $30/month tacked on to Website Payments Pro). Its also really easy. You just send the transaction ID from a previous payment instead of the CC data , and PayPal looks it up in their vault.
Only shitty part with PayPal is you have to offer payment via paypal.com as an option ("Express Checkout"), which means you get to code an extra checkout flow! But maybe you were going to offer PayPal as an option anyway, so that's moot.
Authorize.net is great too, especially if you already have a merchant account setup with your bank. Their API is also super easy, and supported out of the box by most shopping carts.
I've chosen not to use Recurly or Spreedly. Handling money is a bitch, I want a partner with deep domain knowledge who lives and breathes payments. Keep in mind if you store your billing data with one of these guys, and they close up shop - you're fucked. Do you want to depend that heavily on a business with no 800 number and < 10 staff?
At the end of the day though, you'll have to make the call yourself. You've got no reason to believe me, the blog posts you've read, or anyone else you don't know personally. This is your business, your life - you can't just punt this one to the crowd.
Additionally, I've used their recurring payments product (extra $30/month tacked on to Website Payments Pro). Its also really easy. You just send the transaction ID from a previous payment instead of the CC data , and PayPal looks it up in their vault.
Only shitty part with PayPal is you have to offer payment via paypal.com as an option ("Express Checkout"), which means you get to code an extra checkout flow! But maybe you were going to offer PayPal as an option anyway, so that's moot.
Authorize.net is great too, especially if you already have a merchant account setup with your bank. Their API is also super easy, and supported out of the box by most shopping carts.
I've chosen not to use Recurly or Spreedly. Handling money is a bitch, I want a partner with deep domain knowledge who lives and breathes payments. Keep in mind if you store your billing data with one of these guys, and they close up shop - you're fucked. Do you want to depend that heavily on a business with no 800 number and < 10 staff?
At the end of the day though, you'll have to make the call yourself. You've got no reason to believe me, the blog posts you've read, or anyone else you don't know personally. This is your business, your life - you can't just punt this one to the crowd.
Only shitty part with PayPal is you have to offer payment via paypal.com as an option ("Express Checkout"), which means you get to code an extra checkout flow! But maybe you were going to offer PayPal as an option anyway, so that's moot.
As I remember it, you also have to have a direct Paypal link on your cart page (if you have one) - that bypasses any checkout process you might have (though you can redirect them back for address etc after). A bit of a pain all told!
As I remember it, you also have to have a direct Paypal link on your cart page (if you have one) - that bypasses any checkout process you might have (though you can redirect them back for address etc after). A bit of a pain all told!
Does Paypal website payments pro offer transparent redirect like Braintree?
Braintree is great, the API, docs, and client libraries are all great. I'm using it for a subscription based product and couldn't be happier with the choice, even if the minimum fees are a little higher than most, if you aren't going to be able to cover a $75 minimum per month then you probably have bigger issues with your business plan than your payments provider.
The fact that they give data portability is great and the "transparent redirect" is super convenient, knowing that i have practically nothing to worry about from the PCI DSS side of things. If I ever get to the point of needing it (which I may soon) it looks like they have the ability to manage multi-merchant accounts from the same system http://www.braintreepaymentsolutions.com/services/multi-merc...
Although I have heard great things about Stripe, really want to check that out soon. Also, after looking at the prices for Chargify or Recurly, it really doesn't seem to be that much of a value add for something that can be easily accomplished with the Braintree API.
The fact that they give data portability is great and the "transparent redirect" is super convenient, knowing that i have practically nothing to worry about from the PCI DSS side of things. If I ever get to the point of needing it (which I may soon) it looks like they have the ability to manage multi-merchant accounts from the same system http://www.braintreepaymentsolutions.com/services/multi-merc...
Although I have heard great things about Stripe, really want to check that out soon. Also, after looking at the prices for Chargify or Recurly, it really doesn't seem to be that much of a value add for something that can be easily accomplished with the Braintree API.
Are you processing any international charges with BrainTree? In tsz's post he mentioned that they don't help with that until you are doing serious volume of sales and then they will handle international charges for you.
No, no international charges with BrainTree and none in the foreseeable future. If that is a concern then it might be good to look at other options, I'd assume you'll face similar difficulties with other processors (I could be wrong).
We've processed CCs from Beijing to Bali using Braintree. And we're not doing what I'd consider 'serious volume.'
We're going for Braintree as well. Have heard many great things about them.
There are many payment gateway's out there (for example an Australian one is http://www.eway.com.au - never used them/no affiliation) that let you process payments via API.
I'd be inclined to pick something like that rather than use Paypal.
I'd be inclined to pick something like that rather than use Paypal.
Paypal Pro is better than people assume. The rates are ok.
There are lots of Paypal horror stories, but Paypal is actually on the side of merchants more than most merchant account providers. Yeah, chargebacks suck, but you have to deal with them with or without Paypal.
Also, with Paypal Pro you get your money right away; a lot of merchant accounts require you to wait a month or more before withdrawing your money.
I'm not doing subscriptions with Paypal Pro though.
There are lots of Paypal horror stories, but Paypal is actually on the side of merchants more than most merchant account providers. Yeah, chargebacks suck, but you have to deal with them with or without Paypal.
Also, with Paypal Pro you get your money right away; a lot of merchant accounts require you to wait a month or more before withdrawing your money.
I'm not doing subscriptions with Paypal Pro though.
As a developer based in Singapore, it seems that PayPal is the best option. Would like to ask the international developers what options have they used and to the US based companies - when are you bringing your awesome services internationally?
Spreedly Core is a simple API-based product for processing payments and is PCI compliant via transparent redirects (like Braintree). If all you're doing is processing one-time charges, it might be a good option to consider.
Basically, your payment form posts to SpreedlyCore, which posts back to your server with a token. Your app can then perform the basic payment actions, including validation of the user's posted payment data (minus the sensitive info, of course).
The service supports several gateways, and you never see the customer's payment details. The API simplifies dealing with responses. The biggest pain is that it's XML-based.
Regardless, I got it up and working in about a day, and I am slow. :)
It's very easy to use, and though new, the team is very responsive, and the API follows most conventions of their Spreedly subscription service, which is more mature.
The only thing you need to bring is an SSL cert, but you were gonna do that anyway. :)
Basically, your payment form posts to SpreedlyCore, which posts back to your server with a token. Your app can then perform the basic payment actions, including validation of the user's posted payment data (minus the sensitive info, of course).
The service supports several gateways, and you never see the customer's payment details. The API simplifies dealing with responses. The biggest pain is that it's XML-based.
Regardless, I got it up and working in about a day, and I am slow. :)
It's very easy to use, and though new, the team is very responsive, and the API follows most conventions of their Spreedly subscription service, which is more mature.
The only thing you need to bring is an SSL cert, but you were gonna do that anyway. :)
Payment processing is hard, so please give it more than a "cursory glance". Put yourself in the shoes of a brand new customer - they have lots of questions regarding your trustworthyness, billing process, refunds, pro-rating, discounts, invoicing and more. It's your job to alay those fears and be flexible in meeting their needs.
Paypal is great to get started but my experience is that you'll take a hit to your cashflow at some stage. They'll freeze your account, chew up a lot of your time and make you angry. That's part of the cost of doing business with Paypal, so if you need cashflow, accountability and legal protections then go with a bank.
In the early stages, don't be afraid to do a chunk of your billing work manually (producing invoices, providing refunds, calculating pro-rated charges etc). This will give you important insight into customer pain-points and you'll learn a lot about online payments too.
Paypal is great to get started but my experience is that you'll take a hit to your cashflow at some stage. They'll freeze your account, chew up a lot of your time and make you angry. That's part of the cost of doing business with Paypal, so if you need cashflow, accountability and legal protections then go with a bank.
In the early stages, don't be afraid to do a chunk of your billing work manually (producing invoices, providing refunds, calculating pro-rated charges etc). This will give you important insight into customer pain-points and you'll learn a lot about online payments too.
I am using cheddargetter and gravity payments for a soon to be launched site. www.turlytag.com
Chase Paymentech. End of story. If you need to do recurring it's trivial to write - no need for these subscription companies.
My opinion on this: it is very difficult for me to add value via coding the world's best possible rebilling user experience and backend admin code. It is orders of magnitude easier for me to add value via either marketing (which I need to do more of) or adding features to the product that get it in the hands of more customers.
This strongly suggests that I should not be writing billing code, ever.
You need a bunch of pieces to do billing. I use Paypal Website Payments Pro to physically charge people's credit cards, and Spreedly to tell them when to do it. I interact with Spreedly through a REST API that is wrapped with a Ruby gem. My entire interaction with them is one form, three model actions (which handle account creation, status change, and expiry), and a callback for when customer status changes. This took me a few hours to implement, once. Aside from a bug on my side (not charging Mastercards because I am illiterate and failed to read their documentation correctly), it has been pretty flawless.
This seems to come up way, way too often. Would anybody be interested in a blog post about how to do it in a practical, pain-minimizing manner?
This strongly suggests that I should not be writing billing code, ever.
You need a bunch of pieces to do billing. I use Paypal Website Payments Pro to physically charge people's credit cards, and Spreedly to tell them when to do it. I interact with Spreedly through a REST API that is wrapped with a Ruby gem. My entire interaction with them is one form, three model actions (which handle account creation, status change, and expiry), and a callback for when customer status changes. This took me a few hours to implement, once. Aside from a bug on my side (not charging Mastercards because I am illiterate and failed to read their documentation correctly), it has been pretty flawless.
This seems to come up way, way too often. Would anybody be interested in a blog post about how to do it in a practical, pain-minimizing manner?
It doesn't take much to improve the billing experience over sending someone to an external website, to pay with payment pages that are minimally customizable to match your site.
You lose the ability to tweak and test one of the most important parts of the customer acquisition experience. There's a >10% conversion rate gap between different checkout flows I've tested on one of my ecommerce sites.
I've written my own subscription code for Authorize.net; it's around 200 lines, pretty straightforward (take the form data, POST to authnet to create a customer profile, POST to authnet to create a payment profile to store the card, POST to authnet to authorize the first payment, display any errors, otherwise save the reference token to the database and display a thank-you). It'd be smaller if you used a library like ActiveMerchant. Rebilling is a 15 line script as a nightly cron job.
I've also done integrations with Spreedly and Recurly. I didn't find they saved me any time; I had to write lots of code to send them information about the customers and process all their postbacks that you simply don't have to write if you do the charges yourself. Recurly was also changing its pricing and publicly arguing with its customers at the time, which killed my trust in the company.
Outsourcing your subscriptions to one of these startups is a business risk. They will forever be able to hold your cash flow hostage if they want to. If, however unlikely, your account is suddenly closed or they raise prices beyond what you can afford, you not only have to rip out all the integration you did and find another way to bill customers, but you will lose some of your customers while you're explaining why they can't manage their subscriptions at whatever.com anymore and begging them to fill out another payment form so you can continue billing them through someone else.
You lose the ability to tweak and test one of the most important parts of the customer acquisition experience. There's a >10% conversion rate gap between different checkout flows I've tested on one of my ecommerce sites.
I've written my own subscription code for Authorize.net; it's around 200 lines, pretty straightforward (take the form data, POST to authnet to create a customer profile, POST to authnet to create a payment profile to store the card, POST to authnet to authorize the first payment, display any errors, otherwise save the reference token to the database and display a thank-you). It'd be smaller if you used a library like ActiveMerchant. Rebilling is a 15 line script as a nightly cron job.
I've also done integrations with Spreedly and Recurly. I didn't find they saved me any time; I had to write lots of code to send them information about the customers and process all their postbacks that you simply don't have to write if you do the charges yourself. Recurly was also changing its pricing and publicly arguing with its customers at the time, which killed my trust in the company.
Outsourcing your subscriptions to one of these startups is a business risk. They will forever be able to hold your cash flow hostage if they want to. If, however unlikely, your account is suddenly closed or they raise prices beyond what you can afford, you not only have to rip out all the integration you did and find another way to bill customers, but you will lose some of your customers while you're explaining why they can't manage their subscriptions at whatever.com anymore and begging them to fill out another payment form so you can continue billing them through someone else.
dan, because you are holding the CC information on your site and POST'ing it out to external services at authorize.net, did you have to do any work for the "PCI" compliant/privacy stuff I see?
I read a few posts on forums that if the customer financial data is ever on a page you wrote, you come under the realm of at least some PCI compliance because of a possible XSS attack getting that information out of your forms.
That made the hosted "checkout" pages seem a lot more attractive to me... curious how you handled this.
I read a few posts on forums that if the customer financial data is ever on a page you wrote, you come under the realm of at least some PCI compliance because of a possible XSS attack getting that information out of your forms.
That made the hosted "checkout" pages seem a lot more attractive to me... curious how you handled this.
You're right, doing it yourself requires PCI compliance. I've done all that work and my servers get a compliance scan every quarter. That's just tangential to patio's argument (that it's technically difficult to offer a better billing experience than an outsourced service).
Thing is, everything PCIDSS says you have to do when payment data passes through your servers is security 101. If you're not already doing 90% of these things, you're just waiting to be hacked anyway. Instead of thinking of it as a burden for payment processing, think of it as something every professional online business should have been doing anyway.
Thing is, everything PCIDSS says you have to do when payment data passes through your servers is security 101. If you're not already doing 90% of these things, you're just waiting to be hacked anyway. Instead of thinking of it as a burden for payment processing, think of it as something every professional online business should have been doing anyway.
"PCI Compliance" is like keeping a drivers education book in your glove compartment. It's good because every once in a while you find it and it makes you think about safety. Unfortunately it does absolutely nothing to actually make you safer.
Lots of bark, absolutely no bite. There is not a single case where a bank will shut you off and stop getting your processing fees.
Lots of bark, absolutely no bite. There is not a single case where a bank will shut you off and stop getting your processing fees.
I do believe a blog post about how to practically implement such things into a framework (say Rails or Django) would do well.
I don't know about the GP's project, but I implemented my own for historious by using PayPal's recurring payments feature. I store the user's subscription expiration date in their profile, and when the PayPal rebilling notification comes, the date is just reset by X days, which is stored in the PayPal "extra data" field (signed, of course).
Doing the charges yourself is exactly the same, except you have a nightly cronjob to find the accounts that expire today and rebill them. I don't think there's enough material in this to warrant a post.
Doing the charges yourself is exactly the same, except you have a nightly cronjob to find the accounts that expire today and rebill them. I don't think there's enough material in this to warrant a post.
Just in case anyone is wondering, the parent comment earned 26 points (which is one of my highest point counts to date).
This is one of those instances where I wish everyone (specifically patio11) could see how much karma bryanh's comment has.
I didn't mean to upvote you, I misclicked.
I disagree with most of what patio11 said, and have found (like bryanh) that using ActiveMerchant with Auth.net was no harder than when I tried Spreedly.
As such, I'd pass on patio11's advice and instead just get an authorize.net account, integrate that, and forget about it for the next five years.
I disagree with most of what patio11 said, and have found (like bryanh) that using ActiveMerchant with Auth.net was no harder than when I tried Spreedly.
As such, I'd pass on patio11's advice and instead just get an authorize.net account, integrate that, and forget about it for the next five years.
Do the credit card numbers ever travel via your server? Even temporarily in memory? If so you are liable for PCI-DSS section C, which is a LOT of hoops to jump through.
Spreedly saves you from that.
Spreedly saves you from that.
It took us a couple hours to be in compliance with section C. If memory serves, we dealt with a vendor who did a scan, made us install AV software on our Linux boxes, and one or two other minor process adjustments. It wasn't a big deal.
Given Spreedly's current prices of the lesser of $0.20/transaction or 2%/transaction, this minute quantity of work is currently providing us with a return of approximately $12,000/mo. (We had over 60,000 transactions in March.)
Cost: approximately 3 man-days.
Benefit: currently sitting at approximately 1 man-year/year and growing.
It's true that if we'd gone of business within 25,000 transactions, we would've been better off with Spreedly, but given the time, energy and money that we were committing to the business, optimizing for that case seemed absurd. As such we made a small bet that we'd succeed, and that bet is currently generating enough savings (as compared to using Spreedly) to cover an FTE. Some people might say it's a rounding error on the revenue (and I suppose that's true) but I view it as a small bet that is paying off at an enormous multiple.
Given Spreedly's current prices of the lesser of $0.20/transaction or 2%/transaction, this minute quantity of work is currently providing us with a return of approximately $12,000/mo. (We had over 60,000 transactions in March.)
Cost: approximately 3 man-days.
Benefit: currently sitting at approximately 1 man-year/year and growing.
It's true that if we'd gone of business within 25,000 transactions, we would've been better off with Spreedly, but given the time, energy and money that we were committing to the business, optimizing for that case seemed absurd. As such we made a small bet that we'd succeed, and that bet is currently generating enough savings (as compared to using Spreedly) to cover an FTE. Some people might say it's a rounding error on the revenue (and I suppose that's true) but I view it as a small bet that is paying off at an enormous multiple.
As I understood it you have to have written procedures and policies, with fully secure change control and logging for section C ?!?
You need a written security policy, but that was pretty close to pro forma. The compliance firm wrote us one which we disseminated appropriately.
You basically just need to follow some reasonable security standards. Firewalls, ssh/ssl admin terminals, no shared credentials, and then follow a basic security policy.
You basically just need to follow some reasonable security standards. Firewalls, ssh/ssl admin terminals, no shared credentials, and then follow a basic security policy.
Thanks, that sounds a lots less complicated than the advice I was given.
The only situation where I can imagine it being a pain is if you aren't already following good security procedures.
If your ops/DevOps guys are experienced pros, they're probably going to be pretty close to compliant, just out of habit. That said I guess it's not terribly hard to envision a scenario where there's no firewall, bad user access controls, and a host of other crap that could be painful to fix if you only have junior-level ops talent.
If your ops/DevOps guys are experienced pros, they're probably going to be pretty close to compliant, just out of habit. That said I guess it's not terribly hard to envision a scenario where there's no firewall, bad user access controls, and a host of other crap that could be painful to fix if you only have junior-level ops talent.
I don't understand how Spreedly is somehow providing you a "return". They sit on top of your payment gateway so you pay everything you would've paid withluan in-house integration, plus Spreedly's fees. Coding your own subscription billing is a one-time thing as well. Where are you saving money?
It may be a one-off cost but writing a billing system is still a few weeks work. Pro-rataing on upgrades/downgrades, support for one-off overage fees, refunds, credits. Plus dealing with the fallout when you get a decimal place wrong in a tax calculation and accidentally charge a customer a hundred times what you were supposed to (guilty).
One of my clients paid $700 for Spreedly kickstart plus their percentage transaction fees, plus a couple of hours for me to integrate it. Significantly less money then three or four weeks of my time to write a billing app from scratch.
One of my clients paid $700 for Spreedly kickstart plus their percentage transaction fees, plus a couple of hours for me to integrate it. Significantly less money then three or four weeks of my time to write a billing app from scratch.
Maybe the math works out like that when you bill four weeks for a two day job. Startups can and do find programmers that write robust billing code with those features in a day or two. I've done it more than once. I run both ecommerce sites and subscription web apps -- the billing code handles upgrades, downgrades, pro-rating, one-off overage fees, refunds and credits. Once you've done it once, doing it again and testing for another site is a few hours work.
[deleted]
I was specifically noting that I was getting a return by not using Spreedly, as compared to having used it. My apologies if that was unclear.
Perhaps point values should be shown for your post and all of your children, so you can see what people think of the responses to your post (and the submission author can see points for everything since he's the essentially the root node).
This may have been recommended in the other thread, but I don't recall it.
This may have been recommended in the other thread, but I don't recall it.
[deleted]
I started FeeFighters, which is like Kayak for merchant accounts.
I have seen a lot of misery from folks who used the recurring API of the gateways (such as auth.net, braintree, etc).
If you are going to do recurring payments either roll your own using tokenization (its not that hard if your billing logic is simple), or use Recurly/Spreedly/Chargify.
A big advantage that a lot of people don't immediately recognize is that using R/S/C gives you a really good CRUD for your users/subscriptions/payments/etc. Building out that interface properly isn't a good way to spend your time (spend it on customer facing stuff!).
I have seen a lot of misery from folks who used the recurring API of the gateways (such as auth.net, braintree, etc).
If you are going to do recurring payments either roll your own using tokenization (its not that hard if your billing logic is simple), or use Recurly/Spreedly/Chargify.
A big advantage that a lot of people don't immediately recognize is that using R/S/C gives you a really good CRUD for your users/subscriptions/payments/etc. Building out that interface properly isn't a good way to spend your time (spend it on customer facing stuff!).
Especially important for lean startups when considering payment providers for subscriptions is the ability to "take your customers with you" as you grow. When using Paypal, Clickbank, Fastspring/ Saasly, they are the merchant of record, so they "own" the customer data. If you ever want to move to a different provider, get your own or switch merchant accounts... the customers that signed up with these providers will need to signup for a new subscription and submit their CC data again to transition them to your new provider. The other option is you can continue to use these old providers for your existing subscribers, and use your new providers for new customers, but that adds a bunch of complexity for technology, customer support...
This isn't a unique issue with "merchant of record" companies, gateways like Auth.net have a real issue with this too, check out: http://community.developer.authorize.net/t5/Integration-and-...
http://www.braintreepaymentsolutions.com/blog/open-letter-to...
This isn't a unique issue with "merchant of record" companies, gateways like Auth.net have a real issue with this too, check out: http://community.developer.authorize.net/t5/Integration-and-...
http://www.braintreepaymentsolutions.com/blog/open-letter-to...
It's SaaSy.com, as opposed to Saasly :)
I saw this company http://www.memberdesk.com/ give a presentation last night to tieaz. http://www.tieaz.org/2011/04/13/rapid-angel-pitch-winners/ (they were not the pitch winners).
Caveat emptor, I am merely passing the link along, but I believe what they are trying to provide is making subscription membership easy.
Caveat emptor, I am merely passing the link along, but I believe what they are trying to provide is making subscription membership easy.
Sounds like SaaSy.com may be what you're looking for. You can see a comparison of SaaSy, Chargify, Recurly, etc. here:
http://saasy.com/matrix.php
SaaSy is all-inclusive, and once you see the list of features and comparison chart you realize that the basic services like Chargify, Recurly, Spreedly, etc. are actually missing 90% of the solution you'll need, leaving most of the software development and administrative work for you to do over the next couple of years. As opposed to leaving everything to SaaSy and being able to instead focus on growing your business.
For basic integrations, you can launch your subscription service in about 3 days and have the solution fully outsourced and handled by SaaSy, from your global taxes to chargebacks, payments, PCI, order and payment support, global currency payments, localized language-based order pages, fraud prevention, branded order and customer subscription page, cross-selling, subscription trial periods, etc. The list goes on and on, as SaaSy is truly an all-inclusive e-commerce and subscription management service that frees you up to focus on your business, and keeps you out of the complex e-commerce infrastructure business.
To see TechCrunch's take on SaaSy ("Online Subscription Billing Is Still A Hassle, SaaSy Aims To Change That"), see: http://techcrunch.com/2011/03/17/online-subscription-billing...
SaaSy is all-inclusive, and once you see the list of features and comparison chart you realize that the basic services like Chargify, Recurly, Spreedly, etc. are actually missing 90% of the solution you'll need, leaving most of the software development and administrative work for you to do over the next couple of years. As opposed to leaving everything to SaaSy and being able to instead focus on growing your business.
For basic integrations, you can launch your subscription service in about 3 days and have the solution fully outsourced and handled by SaaSy, from your global taxes to chargebacks, payments, PCI, order and payment support, global currency payments, localized language-based order pages, fraud prevention, branded order and customer subscription page, cross-selling, subscription trial periods, etc. The list goes on and on, as SaaSy is truly an all-inclusive e-commerce and subscription management service that frees you up to focus on your business, and keeps you out of the complex e-commerce infrastructure business.
To see TechCrunch's take on SaaSy ("Online Subscription Billing Is Still A Hassle, SaaSy Aims To Change That"), see: http://techcrunch.com/2011/03/17/online-subscription-billing...
Is anyone here using Money Bookers?
Just wondering -- how many of the solutions discussed here are available in the EU?
[Breaking this into multiple comments, because it is too long. The subsequent parts will be replies to this]
We've been accepting credit cards for about 10 years, but I've recently been looking into all of this because (1) I'm pretty sure we are getting reamed on fees by some of our current providers, and (2) we are starting a new line of business under a different brand name and want to set up credit card processing for it.
The following brain dump of what I've found out might contain some things of use to you.
First of all, don't feel bad if you find payment processing confusing. I've found no site or combination of sites that is able to explain what actually goes on and who all is involved in credit card processing. Braintree has some good attempts at explanations, but they are not complete. Other resources I've found explain some of the other parts.
Two things complicate this. First, many companies provide many different services. If a company is providing both payment gateway services and merchant account services, they tend to merge those in any documents they write, because they want you to end up using them for both. Second, there is inconsistent terminology. Different companies sometimes use different names for the same thing.
Anyway, putting together all that I've been able to figure out so far, these are the entities that have their hand somewhere in your credit card processing. I would love corrections to this. I think I'll try to put together at some point some nice diagrams in OmniGraffle and put this up on the web (after any corrections are applied). When I first use a term I'll put it in quotes, and than put it in all caps in subsequent items.
I'll write this as if you are using separate companies for everything that can be separate.
1. Your "customer".
2. The "issuing bank". This is the bank that issued the credit card to the customer.
3. You, the "merchant". I assume no explanation is necessary for this item. :-)
4. Your "regular bank". This is the place you have your normal business account, and doesn't have anything particular to do with credit cards. It's just a place you keep your money.
5. The "credit card associations" are organizations like VISA and MasterCard. VISA and MasterCard are owned by the ISSUING BANKS. I'll get into their role in a bit.
6. Your "acquiring bank". You have a "merchant account" with them. When a transaction settles, this is where the money from the ISSUING BANK ends up. The ACQUIRING BANK then transfers the money to your REGULAR BANK, after deducting their fees. The ACQUIRING BANK is a little confusing because it is not really a bank. Their main role in this dance is to provide you with a line of credit in essence. If you sell a bunch of goods, the transactions settle, and you grab the money out of your REGULAR BANK and disappear without bothering to ship product, it is the ACQUIRING BANK that ends up coughing up the money when your CUSTOMERS call their ISSUING BANKS and demand that their charges be reversed. (Accordingly, this means that your ACQUIRING BANK is going to give you the biggest financial colonoscopy in this process).
7. A "member bank" is a financial institution that had a relationship with a CARD ASSOCIATION that allows them to function as an ACQUIRING BANK for cards from that association.
8. An "ISO/MSP". Those stand for "Independent Service Organization" and "Member Service Provider". These are essentially affiliates of MEMBER BANKS. They can sell you a MERCHANT ACCOUNT from the MEMBER BANKs they are associated with. I believe that ISOs and MSPs are basically the same. ISO is the term VISA uses, and MSP is the term MasterCard uses. You might think it would be best to get your MERCHANT ACCOUNT directly from a MEMBER BANK, but from what I've read it is often actually cheaper from an ISO/MSP. Also, just because an entity is a bank doesn't mean it is a MEMBER BANK. For instance, if you go down to a REGULAR BANK like BofA or Wells Fargo, they will happily sell you a MERCHANT ACCOUNT, but they will be doing so as an ISO/MSP for some MEMBER BANK.
9. A "front end processor". This is an entity that is hooked up the the CARD ASSOCIATION networks and can actually conduct credit card transactions. Your ACQUIRING BANK has a relationship with the FRONT END PROCESSOR.
10. A "back end processor". This is an entity that can actually initiate the transfer of money (via the Federal Reserve system) from the ISSUING BANK to your ACQUIRING BANK. Collectively, I've seen many people call the combination of FRONT END PROCESS and BACK END PROCESSOR a "payment processor".
11. A "payment gateway". This is what your shopping cart actually talks to, or (if you are actually physically accepting cards and swiping them) what your terminal is connected to. Its job is to accept requests from your cart ("Charge $49.95 to 5105105105105100") and then communicate with the FRONT END PROCESSOR that has a relationship with your ACQUIRING BANK in order to get the transaction conducted.
We've been accepting credit cards for about 10 years, but I've recently been looking into all of this because (1) I'm pretty sure we are getting reamed on fees by some of our current providers, and (2) we are starting a new line of business under a different brand name and want to set up credit card processing for it.
The following brain dump of what I've found out might contain some things of use to you.
First of all, don't feel bad if you find payment processing confusing. I've found no site or combination of sites that is able to explain what actually goes on and who all is involved in credit card processing. Braintree has some good attempts at explanations, but they are not complete. Other resources I've found explain some of the other parts.
Two things complicate this. First, many companies provide many different services. If a company is providing both payment gateway services and merchant account services, they tend to merge those in any documents they write, because they want you to end up using them for both. Second, there is inconsistent terminology. Different companies sometimes use different names for the same thing.
Anyway, putting together all that I've been able to figure out so far, these are the entities that have their hand somewhere in your credit card processing. I would love corrections to this. I think I'll try to put together at some point some nice diagrams in OmniGraffle and put this up on the web (after any corrections are applied). When I first use a term I'll put it in quotes, and than put it in all caps in subsequent items.
I'll write this as if you are using separate companies for everything that can be separate.
1. Your "customer".
2. The "issuing bank". This is the bank that issued the credit card to the customer.
3. You, the "merchant". I assume no explanation is necessary for this item. :-)
4. Your "regular bank". This is the place you have your normal business account, and doesn't have anything particular to do with credit cards. It's just a place you keep your money.
5. The "credit card associations" are organizations like VISA and MasterCard. VISA and MasterCard are owned by the ISSUING BANKS. I'll get into their role in a bit.
6. Your "acquiring bank". You have a "merchant account" with them. When a transaction settles, this is where the money from the ISSUING BANK ends up. The ACQUIRING BANK then transfers the money to your REGULAR BANK, after deducting their fees. The ACQUIRING BANK is a little confusing because it is not really a bank. Their main role in this dance is to provide you with a line of credit in essence. If you sell a bunch of goods, the transactions settle, and you grab the money out of your REGULAR BANK and disappear without bothering to ship product, it is the ACQUIRING BANK that ends up coughing up the money when your CUSTOMERS call their ISSUING BANKS and demand that their charges be reversed. (Accordingly, this means that your ACQUIRING BANK is going to give you the biggest financial colonoscopy in this process).
7. A "member bank" is a financial institution that had a relationship with a CARD ASSOCIATION that allows them to function as an ACQUIRING BANK for cards from that association.
8. An "ISO/MSP". Those stand for "Independent Service Organization" and "Member Service Provider". These are essentially affiliates of MEMBER BANKS. They can sell you a MERCHANT ACCOUNT from the MEMBER BANKs they are associated with. I believe that ISOs and MSPs are basically the same. ISO is the term VISA uses, and MSP is the term MasterCard uses. You might think it would be best to get your MERCHANT ACCOUNT directly from a MEMBER BANK, but from what I've read it is often actually cheaper from an ISO/MSP. Also, just because an entity is a bank doesn't mean it is a MEMBER BANK. For instance, if you go down to a REGULAR BANK like BofA or Wells Fargo, they will happily sell you a MERCHANT ACCOUNT, but they will be doing so as an ISO/MSP for some MEMBER BANK.
9. A "front end processor". This is an entity that is hooked up the the CARD ASSOCIATION networks and can actually conduct credit card transactions. Your ACQUIRING BANK has a relationship with the FRONT END PROCESSOR.
10. A "back end processor". This is an entity that can actually initiate the transfer of money (via the Federal Reserve system) from the ISSUING BANK to your ACQUIRING BANK. Collectively, I've seen many people call the combination of FRONT END PROCESS and BACK END PROCESSOR a "payment processor".
11. A "payment gateway". This is what your shopping cart actually talks to, or (if you are actually physically accepting cards and swiping them) what your terminal is connected to. Its job is to accept requests from your cart ("Charge $49.95 to 5105105105105100") and then communicate with the FRONT END PROCESSOR that has a relationship with your ACQUIRING BANK in order to get the transaction conducted.
You get billed by your PAYMENT GATEWAY and your ACQUIRING BANK. (Open question: if you got your MERCHANT ACCOUNT through an ISO/MSP, I am not sure if you are billed directly by your ACQUIRING BANK, or if your bills will come from your ISO/MSP). For pretty much all practical purposes, these are the only entities you directly care about, I think.
Here's what I've gathered is the actual flow of a payment. It is possible to do an "authorization", which in geek terms just puts a temporary lock on the funds at the ISSUING BANK which you then follow up with a separate "capture" transaction to finish the sale, or you can do a combined authorize and capture. Let's assume the latter.
1. CUSTOMER places order on MERCHANT's web site.
2. MERCHANT sends the information to PAYMENT GATEWAY.
3. PAYMENT GATEWAY talks to PAYMENT PROCESSOR.
4. PAYMENT PROCESSOR talks to the CARD ASSOCIATION.
5. CARD ASSOCIATION talks to the ISSUING BANK, which decides if it should approve the transaction.
6. The result goes back to the PAYMENT PROCESSOR, and then back to the PAYMENT GATEWAY, and back to the MERCHANT (and you presumably inform the CUSTOMER of the result, too).
7. The PAYMENT GATEWAY keeps track of all the approved transactions. At the end of the day, it takes all of these, and passes them to the PAYMENT PROCESSOR for "settlement". It is the BACK END PROCESSOR that deals with SETTLEMENT, by using the Federal Reserve system to initiate a transfer from the ISSUING BANK to the ACQUIRING BANK. (Open question: does the PAYMENT GATEWAY talk directory to the BACK END PROCESSOR for this, or does it talk to the FRONT END PROCESSOR, which talks to the BACK END PROCESSOR?).
8. A few days later, the money actually ends up at ACQUIRING BANK, they take out their fees, and deposit the remaining amount in your REGULAR BANK.
(Open question: is the ACQUIRING BANK involved anywhere before step #8?).
Now let's talk a bit about fees. The CARD ASSOCIATION takes a percentage. There are over 100 different rate categories the CARD ASSOCIATIONS have, based on all kinds of details about the transaction. Porn? Higher rate. Restaurant? Higher rate. No zip code? Higher rate. CUSTOMER using a rewards card? Higher rate. (You didn't think the ISSUING BANK paid those rewards, did you?) And so on and so on. This percentage is called the interchange rate. This only applies to approved transactions. You don't pay on declines (which can be significant for a business using recurring billing). You do not pay this directly to the CARD ASSOCIATION. It will be on your bill from your ACQUIRING BANK. This is often called the "discount".
The ACQUIRING BANK takes a per transaction charge. $0.30 is typical for VISA and MasterCard. You pay this for both approvals and declines. A typical ACQUIRING BANK is also going to hit your with a bewildering list of other charges that apply to some of your transactions but not others. Some of these will be fixed per transaction fees. For example, I'm looking at our bill from one of our ACQUIRING BANKS right now, about about 90% of the VISA transactions had something called a "VISA AVS FEE" of $0.01 added.
Others are percentages. 5% of our VISA transactions had something called a "VISA INTERNATIONAL ACQUIRING FEE". This looks like it was 0.45% of the amount charged. There was also a VISA INTERNATIONAL SERVICE ASSESSMENT fee of about 0.4%. I believe these fees happen when someone outside the US orders our product using a VISA or MasterCard. E.g., when a Canadian buys our product. I see MasterCard is only hitting us for one 0.4% fee for these, not two like VISA sneaks in.
(You also get screwed on charge backs from foreign customers using VISA and MasterCard. If you sell a Canadian something for $50, and they do a charge back, you'll find the charge back amount is something like $55. The bastard ISSUING BANK makes you pay the $5 they charged their CUSTOMER on the first transaction for doing currency conversion).
ACQUIRING BANKS have two different ways to deal with the INTERCHANGE rate. One way is called "interchange plus" pricing. The way this works is that they charge you whatever the CARD ASSOCIATION rate was for that transaction, plus their fixed fee. I've read that this option is generally only available to high volume MERCHANTS. For the rest of us, we get "tiered pricing". The way this works is the ACQUIRING BANK defines a set of tiers, typically called "qualified", "mid qualified", and "non-qualified" for a three tier system, and assigns a rate to each. For instance, the rates might be 2.3%, 2.6%, and 2.9%. The ACQUIRING BANK will take each transaction, and charge you the lowest tier that exceeds the INTERCHANGE rate for that transaction. The difference between INTERCHANGE and the tier rate goes to the ACQUIRING BANK, of course.
I suspect that some ACQUIRING BANKS kind of mix "interchange plus" and "tiered" pricing. The bill I'm looking at is hitting us for a 2.32% "discount", and then hitting us with an extra 2.4% on ones they call "non qual" and 0.9% on "commercial-rewards" cards. The "non qual" sounds like it is part of tiered pricing, but the separate ding for rewards cards, and the ding for international acquiring mentioned earlier, sound like things that would be factors in setting the interchange rate. Or these could just be how they do their tiers. In the summary they split the bill into two parts, "Discount Due" which is just the 2.32%, and "Fees Due" which is everything else.
As many who have looked at credit card processing have noted before, this is apparently not designed to be clear. If you can't figure out what things cost, it is hard to figure out if you can save money elsewhere.
The PAYMENT GATEWAY also charges. Their fees tend to be a lot more reasonable--typically a simple $0.10 per transaction. Looking at the PAYMENT GATEWAY bill for the PAYMENT GATEWAY we use for transactions destined for the ACQUIRING BANK I was using for my above examples, it is one page, with basically one line that says we had X transactions, and since their first 1000/month are free, we owe for X-1000, which is $X/10-100.
Remember when I said earlier that some companies play more than one role? If your PAYMENT GATEWAY is also your ACQUIRING BANK (or is the ISO/MSP that got you your ACQUIRING BANK), they often include the PAYMENT GATEWAY service for free as part of the package.
Now let's talk for a few moments about how you actually talk to the PAYMENT GATEWAY. You mentioned a lack of expertise to integrate with Authorize.Net or Braintree. I suspect it is a lot easier than you think it is. To integrate with Authorize.Net, you just do a routine post to a CGI. They give examples in ASP, C#, ColdFusion, Java, Perl, PHP, and VB.NET. I just looked at the PHP sample--it is literally just fill out a form and call curl. They have PHP, Ruby, C#, and Java SDKs, too.
Braintree is almost trivial, from what I've seen. (We haven't used them yet, but are considering them for our new product, so I've looked at their API). You want to charge a card from PHP? Include one PHP module Braintree provides, and then you just call one simple function to charge a card. The only flaw I can see in Braintree's API is that they don't have a Perl interface, and our back end software that processes orders is in Perl.
In the above I was assuming a model whereby you collect the card information via a post to your cart, and then something on your server makes the call to Authorize.Net or Braintree. There is another way, perhaps more suitable for you.
In this way, your cart does NOT post the credit card to your server. It posts to Braintree (I'll just do Braintree for this more, although the others all support something similar). Braintree's servers directly receive the information from the CUSTOMER, and do the transaction, and then they respond to the CUSTOMER's browser with a redirect that takes the browser back to your site. It includes information about the fate of the transaction, so you can respond appropriately.
The beauty of this is that you never touch the card, which really really really simplifies PCI compliance, and it looks pretty easy to implement.
Here's what I've gathered is the actual flow of a payment. It is possible to do an "authorization", which in geek terms just puts a temporary lock on the funds at the ISSUING BANK which you then follow up with a separate "capture" transaction to finish the sale, or you can do a combined authorize and capture. Let's assume the latter.
1. CUSTOMER places order on MERCHANT's web site.
2. MERCHANT sends the information to PAYMENT GATEWAY.
3. PAYMENT GATEWAY talks to PAYMENT PROCESSOR.
4. PAYMENT PROCESSOR talks to the CARD ASSOCIATION.
5. CARD ASSOCIATION talks to the ISSUING BANK, which decides if it should approve the transaction.
6. The result goes back to the PAYMENT PROCESSOR, and then back to the PAYMENT GATEWAY, and back to the MERCHANT (and you presumably inform the CUSTOMER of the result, too).
7. The PAYMENT GATEWAY keeps track of all the approved transactions. At the end of the day, it takes all of these, and passes them to the PAYMENT PROCESSOR for "settlement". It is the BACK END PROCESSOR that deals with SETTLEMENT, by using the Federal Reserve system to initiate a transfer from the ISSUING BANK to the ACQUIRING BANK. (Open question: does the PAYMENT GATEWAY talk directory to the BACK END PROCESSOR for this, or does it talk to the FRONT END PROCESSOR, which talks to the BACK END PROCESSOR?).
8. A few days later, the money actually ends up at ACQUIRING BANK, they take out their fees, and deposit the remaining amount in your REGULAR BANK.
(Open question: is the ACQUIRING BANK involved anywhere before step #8?).
Now let's talk a bit about fees. The CARD ASSOCIATION takes a percentage. There are over 100 different rate categories the CARD ASSOCIATIONS have, based on all kinds of details about the transaction. Porn? Higher rate. Restaurant? Higher rate. No zip code? Higher rate. CUSTOMER using a rewards card? Higher rate. (You didn't think the ISSUING BANK paid those rewards, did you?) And so on and so on. This percentage is called the interchange rate. This only applies to approved transactions. You don't pay on declines (which can be significant for a business using recurring billing). You do not pay this directly to the CARD ASSOCIATION. It will be on your bill from your ACQUIRING BANK. This is often called the "discount".
The ACQUIRING BANK takes a per transaction charge. $0.30 is typical for VISA and MasterCard. You pay this for both approvals and declines. A typical ACQUIRING BANK is also going to hit your with a bewildering list of other charges that apply to some of your transactions but not others. Some of these will be fixed per transaction fees. For example, I'm looking at our bill from one of our ACQUIRING BANKS right now, about about 90% of the VISA transactions had something called a "VISA AVS FEE" of $0.01 added.
Others are percentages. 5% of our VISA transactions had something called a "VISA INTERNATIONAL ACQUIRING FEE". This looks like it was 0.45% of the amount charged. There was also a VISA INTERNATIONAL SERVICE ASSESSMENT fee of about 0.4%. I believe these fees happen when someone outside the US orders our product using a VISA or MasterCard. E.g., when a Canadian buys our product. I see MasterCard is only hitting us for one 0.4% fee for these, not two like VISA sneaks in.
(You also get screwed on charge backs from foreign customers using VISA and MasterCard. If you sell a Canadian something for $50, and they do a charge back, you'll find the charge back amount is something like $55. The bastard ISSUING BANK makes you pay the $5 they charged their CUSTOMER on the first transaction for doing currency conversion).
ACQUIRING BANKS have two different ways to deal with the INTERCHANGE rate. One way is called "interchange plus" pricing. The way this works is that they charge you whatever the CARD ASSOCIATION rate was for that transaction, plus their fixed fee. I've read that this option is generally only available to high volume MERCHANTS. For the rest of us, we get "tiered pricing". The way this works is the ACQUIRING BANK defines a set of tiers, typically called "qualified", "mid qualified", and "non-qualified" for a three tier system, and assigns a rate to each. For instance, the rates might be 2.3%, 2.6%, and 2.9%. The ACQUIRING BANK will take each transaction, and charge you the lowest tier that exceeds the INTERCHANGE rate for that transaction. The difference between INTERCHANGE and the tier rate goes to the ACQUIRING BANK, of course.
I suspect that some ACQUIRING BANKS kind of mix "interchange plus" and "tiered" pricing. The bill I'm looking at is hitting us for a 2.32% "discount", and then hitting us with an extra 2.4% on ones they call "non qual" and 0.9% on "commercial-rewards" cards. The "non qual" sounds like it is part of tiered pricing, but the separate ding for rewards cards, and the ding for international acquiring mentioned earlier, sound like things that would be factors in setting the interchange rate. Or these could just be how they do their tiers. In the summary they split the bill into two parts, "Discount Due" which is just the 2.32%, and "Fees Due" which is everything else.
As many who have looked at credit card processing have noted before, this is apparently not designed to be clear. If you can't figure out what things cost, it is hard to figure out if you can save money elsewhere.
The PAYMENT GATEWAY also charges. Their fees tend to be a lot more reasonable--typically a simple $0.10 per transaction. Looking at the PAYMENT GATEWAY bill for the PAYMENT GATEWAY we use for transactions destined for the ACQUIRING BANK I was using for my above examples, it is one page, with basically one line that says we had X transactions, and since their first 1000/month are free, we owe for X-1000, which is $X/10-100.
Remember when I said earlier that some companies play more than one role? If your PAYMENT GATEWAY is also your ACQUIRING BANK (or is the ISO/MSP that got you your ACQUIRING BANK), they often include the PAYMENT GATEWAY service for free as part of the package.
Now let's talk for a few moments about how you actually talk to the PAYMENT GATEWAY. You mentioned a lack of expertise to integrate with Authorize.Net or Braintree. I suspect it is a lot easier than you think it is. To integrate with Authorize.Net, you just do a routine post to a CGI. They give examples in ASP, C#, ColdFusion, Java, Perl, PHP, and VB.NET. I just looked at the PHP sample--it is literally just fill out a form and call curl. They have PHP, Ruby, C#, and Java SDKs, too.
Braintree is almost trivial, from what I've seen. (We haven't used them yet, but are considering them for our new product, so I've looked at their API). You want to charge a card from PHP? Include one PHP module Braintree provides, and then you just call one simple function to charge a card. The only flaw I can see in Braintree's API is that they don't have a Perl interface, and our back end software that processes orders is in Perl.
In the above I was assuming a model whereby you collect the card information via a post to your cart, and then something on your server makes the call to Authorize.Net or Braintree. There is another way, perhaps more suitable for you.
In this way, your cart does NOT post the credit card to your server. It posts to Braintree (I'll just do Braintree for this more, although the others all support something similar). Braintree's servers directly receive the information from the CUSTOMER, and do the transaction, and then they respond to the CUSTOMER's browser with a redirect that takes the browser back to your site. It includes information about the fate of the transaction, so you can respond appropriately.
The beauty of this is that you never touch the card, which really really really simplifies PCI compliance, and it looks pretty easy to implement.
Now let us talk about recurring billing. I have not used any recurring billing service, so can't comment on how those work, but here are some thoughts on handling it yourself.
First, there is the obvious way. Store credit cards yourself, and then you can run new transactions through when it is time to re-bill someone. You don't want to do this. This gets you all the way into the PCI cesspool. In fact, if you are a single developer, and there is no one else in your company, I'm not even sure it is possible to do this. PCI requires that for key operations on the encrypted credit cards that you use some kind of scheme that requires more than one person to authorize any operation. (We use Shamir's cool secret sharing algorithm to make it so no one person has access to the keys). Hard to do this when there isn't another person!
The second way is to use something called a "reference transaction". When you do a transaction, there is a transaction ID associated with it. Subsequently, you can do new transactions and instead of supplying the credit card number, you can tell the PAYMENT GATEWAY that you want to use the same credit card as a prior transaction, and supply the transaction ID of that prior transaction. (I believe you have to also supply the amount of the referenced transaction with some gateways). So, if you just keep track of the transaction ID of the last successful charge on a card and the amount, you can use that for your re-billing transactions. (Keep track of the last success, because you generally can't use a transaction more than a year old as reference transaction).
The main downside that I see for reference transactions is that you are stuck with that PAYMENT GATEWAY for subsequent transactions on that card. (Open question: if you use the same PAYMENT GATEWAY for more than one MERCHANT ACCOUNT, is the reference transaction tied to the original MERCHANT ACCOUNT, or is it just tied to the PAYMENT GATEWAY. I think it is just tied to the GATEWAY, because the way I've read it works is that the PAYMENT GATEWAY actually stores the credit card). For some businesses, you want multiple MERCHANT ACCOUNTS, and you want the ability to decide on a per transaction basis which one to use to bill or re-bill a customer, and so reference transactions won't work unless you have a suitable transaction at each gateway. (The reason for this is ACQUIRING BANKS can get skittish--remember they are the ones assuming the risk that you are going to stay around. If anything unusual happens to your business, ACQUIRING BANKS sometimes suddenly slap harsh limits on you).
The third way is to use Braintree and use their "vault" service. That costs $20/month plus $0.01 per card stored/month. Basically when you put a card in the vault (which you can do by setting a flag when you charge the card), they remember it for you. They give you a token that you can use on subsequent charges to represent the card.
You might wonder how this differs from using reference transactions at other PAYMENT GATEWAYS. After all, if PAYMENT GATEWAYS normally keep the full card information for each transaction, and let you do reference transactions, why should it cost extra for that service at Braintree. I think the key is that Braintree will let you get the cards out of the vault if you want. That's one of their big selling points--nothing you do with them locks you in.
As I said, we don't use any third party recurring billing service. When we got started, there really weren't any services specializing in that like there are now. There were recurring options at some of the gateways, but they were pretty simple, and unfortunately we had complicated plans, and let customers upgrade and downgrade between them leading to all kinds of ugliness that didn't fit in with any sane recurring billing system.
One other thing to be aware of with recurring billing (whether handled yourself of via a third party). Both VISA and MasterCard a service that allows MERCHANTs to get updated information on credit cards. For instance, suppose you try to re-bill someone, and it is declined. The last expiration date you had for their card was six months ago. You can query the updater service, and if the card has a new expiration date, or if the account has a new card with a new number, they might tell you the new information. They don't always tell you--the possible responses are (1) here's the new expiration date!, (2) here's the new card number and expiration date!, (3) the account is closed, or (4) no information is available. It costs nothing to submit a batch of cards to the update service, and something like $0.12/card for which updated information is returned, and they require you to run your entire database of stored cards through the service periodically.
I believe there are some restrictions on who can actually use this service, as it would obviously be a great boon to people who are doing credit card fraud. Ask any recurring billing service you are considering if they have any support for the updater service. If you can get access to it, it should easily pay for itself. We've found that it increased our success rates for recurring billing by around 2% or so.
Finally, let us consider foreign currency. Braintree offers a truly impressive number of currencies that they can accept payments in, and an impressive number of currencies you can have your settlements in. Unfortunately, you have to be doing something like $3 million a year (I assume they mean in the particular foreign currency you want to accept) before they will deal with you. (You need a separate merchant account for foreign currency, and the MEMBER BANK providing the foreign currency merchant accounts isn't interested in us small guys).
We use WorldPay for foreign sales (specifically the part of them that was once a separate company called Bibit). They will deal with much smaller companies than Braintree, but they have some pretty high fixed monthly fees--high enough that you'd almost surely want to get your business going well in the US before considering adding foreign support with WorldPay.
Based on all I've seen so far, I'd go with Braintree, for three reasons:
1. Assuming they are telling the truth on their site (and they get mentioned enough that if they were not on the level, surely someone would have posted about it), their prices are both very reasonable and actually understandable. You will pay one of the two tier percentages per transaction plus $0.30 + $75/month + $20/month (for the vault) + $0.01/month (per credit card in the vault) + $0.10 per recurring subscription billed. The only unknown in your costs will be what percentage of your transactions get the 2.29% rate and which percentage get the 2.89% rate.
You can find places that advertise less than 2.29%, but that will be just for the bottom tier of their tiered billing, and most will also stick on a ton of other fees (recall my example earlier from one of our bills from one of our ACQUIRING BANKs).
2. They offer both MERCHANT ACCOUNTS, PAYMENT GATEWAY, and a recurring billing system, so you will only have to deal with one company.
3. If you decide someday that you'd rather be elsewhere, you aren't under a contract so can quit with no penalty, and you can get your CUSTOMER's card data out of their vault to feed into whatever other provider you switch to (or to store yourself if you have gone insane).
Good luck!
First, there is the obvious way. Store credit cards yourself, and then you can run new transactions through when it is time to re-bill someone. You don't want to do this. This gets you all the way into the PCI cesspool. In fact, if you are a single developer, and there is no one else in your company, I'm not even sure it is possible to do this. PCI requires that for key operations on the encrypted credit cards that you use some kind of scheme that requires more than one person to authorize any operation. (We use Shamir's cool secret sharing algorithm to make it so no one person has access to the keys). Hard to do this when there isn't another person!
The second way is to use something called a "reference transaction". When you do a transaction, there is a transaction ID associated with it. Subsequently, you can do new transactions and instead of supplying the credit card number, you can tell the PAYMENT GATEWAY that you want to use the same credit card as a prior transaction, and supply the transaction ID of that prior transaction. (I believe you have to also supply the amount of the referenced transaction with some gateways). So, if you just keep track of the transaction ID of the last successful charge on a card and the amount, you can use that for your re-billing transactions. (Keep track of the last success, because you generally can't use a transaction more than a year old as reference transaction).
The main downside that I see for reference transactions is that you are stuck with that PAYMENT GATEWAY for subsequent transactions on that card. (Open question: if you use the same PAYMENT GATEWAY for more than one MERCHANT ACCOUNT, is the reference transaction tied to the original MERCHANT ACCOUNT, or is it just tied to the PAYMENT GATEWAY. I think it is just tied to the GATEWAY, because the way I've read it works is that the PAYMENT GATEWAY actually stores the credit card). For some businesses, you want multiple MERCHANT ACCOUNTS, and you want the ability to decide on a per transaction basis which one to use to bill or re-bill a customer, and so reference transactions won't work unless you have a suitable transaction at each gateway. (The reason for this is ACQUIRING BANKS can get skittish--remember they are the ones assuming the risk that you are going to stay around. If anything unusual happens to your business, ACQUIRING BANKS sometimes suddenly slap harsh limits on you).
The third way is to use Braintree and use their "vault" service. That costs $20/month plus $0.01 per card stored/month. Basically when you put a card in the vault (which you can do by setting a flag when you charge the card), they remember it for you. They give you a token that you can use on subsequent charges to represent the card.
You might wonder how this differs from using reference transactions at other PAYMENT GATEWAYS. After all, if PAYMENT GATEWAYS normally keep the full card information for each transaction, and let you do reference transactions, why should it cost extra for that service at Braintree. I think the key is that Braintree will let you get the cards out of the vault if you want. That's one of their big selling points--nothing you do with them locks you in.
As I said, we don't use any third party recurring billing service. When we got started, there really weren't any services specializing in that like there are now. There were recurring options at some of the gateways, but they were pretty simple, and unfortunately we had complicated plans, and let customers upgrade and downgrade between them leading to all kinds of ugliness that didn't fit in with any sane recurring billing system.
One other thing to be aware of with recurring billing (whether handled yourself of via a third party). Both VISA and MasterCard a service that allows MERCHANTs to get updated information on credit cards. For instance, suppose you try to re-bill someone, and it is declined. The last expiration date you had for their card was six months ago. You can query the updater service, and if the card has a new expiration date, or if the account has a new card with a new number, they might tell you the new information. They don't always tell you--the possible responses are (1) here's the new expiration date!, (2) here's the new card number and expiration date!, (3) the account is closed, or (4) no information is available. It costs nothing to submit a batch of cards to the update service, and something like $0.12/card for which updated information is returned, and they require you to run your entire database of stored cards through the service periodically.
I believe there are some restrictions on who can actually use this service, as it would obviously be a great boon to people who are doing credit card fraud. Ask any recurring billing service you are considering if they have any support for the updater service. If you can get access to it, it should easily pay for itself. We've found that it increased our success rates for recurring billing by around 2% or so.
Finally, let us consider foreign currency. Braintree offers a truly impressive number of currencies that they can accept payments in, and an impressive number of currencies you can have your settlements in. Unfortunately, you have to be doing something like $3 million a year (I assume they mean in the particular foreign currency you want to accept) before they will deal with you. (You need a separate merchant account for foreign currency, and the MEMBER BANK providing the foreign currency merchant accounts isn't interested in us small guys).
We use WorldPay for foreign sales (specifically the part of them that was once a separate company called Bibit). They will deal with much smaller companies than Braintree, but they have some pretty high fixed monthly fees--high enough that you'd almost surely want to get your business going well in the US before considering adding foreign support with WorldPay.
Based on all I've seen so far, I'd go with Braintree, for three reasons:
1. Assuming they are telling the truth on their site (and they get mentioned enough that if they were not on the level, surely someone would have posted about it), their prices are both very reasonable and actually understandable. You will pay one of the two tier percentages per transaction plus $0.30 + $75/month + $20/month (for the vault) + $0.01/month (per credit card in the vault) + $0.10 per recurring subscription billed. The only unknown in your costs will be what percentage of your transactions get the 2.29% rate and which percentage get the 2.89% rate.
You can find places that advertise less than 2.29%, but that will be just for the bottom tier of their tiered billing, and most will also stick on a ton of other fees (recall my example earlier from one of our bills from one of our ACQUIRING BANKs).
2. They offer both MERCHANT ACCOUNTS, PAYMENT GATEWAY, and a recurring billing system, so you will only have to deal with one company.
3. If you decide someday that you'd rather be elsewhere, you aren't under a contract so can quit with no penalty, and you can get your CUSTOMER's card data out of their vault to feed into whatever other provider you switch to (or to store yourself if you have gone insane).
Good luck!
tzs, your write (tomb) was unbelievably helpful... just finished reading all of it.
As you walked through all the examples I was slowly leaning towards BrainTree and as you kept going through the reasoning I felt like I concluded at the same place you did by the end; sounds like the perfect thing to launch with and if I want better sub handling I can always add something like Recurly later.
I have no love for merchant account banks after reading all that.
I had no idea where the "points" on reward cards were coming from, very sneaky!
Fascinating read, I can't imagine how long it took to write up. I really appreciate that.
As you walked through all the examples I was slowly leaning towards BrainTree and as you kept going through the reasoning I felt like I concluded at the same place you did by the end; sounds like the perfect thing to launch with and if I want better sub handling I can always add something like Recurly later.
I have no love for merchant account banks after reading all that.
I had no idea where the "points" on reward cards were coming from, very sneaky!
Fascinating read, I can't imagine how long it took to write up. I really appreciate that.
I'm glad it helped. Keep in mind that I don't know if I have it right. I marked several open questions, and I probably missed many. I'm still hoping someone with better information will offer corrections.
Use SaaSy and you don't have to think about any of this. Not so with any of the other recurring billing services though.
At 5.9%+$0.95 or 8.9% flat? Good luck with that. Unless you can explain to me why anyone would be willing to pay near double what anywhere charges... Seriously, your site doesn't explain this well. Why do you charge near double (or even triple on the flat rate)?
Needing to use your own merchant account means 3.5-4% in costs that you don't pay at all when you use SaaSy. SaaSy includes this cost in the pricing.
For those desiring a more complete explanation...
Regarding pricing, it's true there are less expensive-appearing services (though don't forget that without SaaSy handling everything for you you'd still have to pay 3.5-4% in e-commerce merchant fees for every order, once you factor in the true costs), but they end up costing you far more when you factor in software development costs and the years you will spend if you go it alone or use an existing basic service that appears to cost less. Remember, it's not just building what you think you need today, it's also adding on to it endlessly as your needs grow and change, and then there's the maintenance. That's just the tech development side, what about dealing with taxes, say in the EU if you have any EU customers, or a dozen other similar issues you'd otherwise be on your own to figure out and then develop a solution for? Take a look at this matrix to see what the cheaper, more basic solutions are missing that SaaSy provides for those launching or running existing SaaS businesses, and you'll see why SaaSy is actually quite a deal relative to the basic recurring billing services: http://saasy.com/matrix.php
In addition to saving you all the time, money, and hassle of building your own e-commerce system, the incremental profit you'll earn from utilizing our features for growing your average order size, lifetime value, and optimizing your conversion rate far outweigh the higher fees. Each feature you take advantage of can increase your revenue by a few percent, and it doesn't take too many increases of 2-4% here and there to add up to an overall profit improvement that far outweighs the few extra points that Saasy's all-in-one service costs. For example, cross-selling; upselling; add-ons; bundling; discounts & promotions; order pages in local currencies and languages; Facebook/Twitter referral management; a breadth of payment methods available for your customers; an order page customized to fit the rest of your site or designed to fit your preferences; the ability to test and tweak different order page structures and merchandising ideas; reseller management; analytics; outside help with PPC, SEO, affiliate, and general web marketing; fraud protection, and the list goes on. And then there's the impact our phenomenal customer service will have on your churn rate and the word-of-mouth sales it generates to have so many "wowed" end users out there talking up the customer experience of working with you. SaaSy also reduces your internal support expenses as they relate to order and payment customer support, since we handle that for you.
If you're up for spending up to a couple of years building and improving on an e-commerce infrastructure, SaaSy isn't for you. But if time to market is important and you'd rather focus on developing your product/service and doing sales and marketing instead of dealing with the distracting complexities of building your own e-commerce system either from scratch or by building all the needed functionality around one of the cheaper, more basic solutions, then you'll want to take a close look at SaaSy.
When you view our features list and the competitive matrix, think through the costs of developing your own infrastructure over the next few years vs. what your development team could instead be focusing on, factor in that you're not going to need to pay the 3.5-4% in e-commerce merchant fees for every order which you would be doing otherwise, consider not only the reduced expenses but the new revenue you'll now be able to generate, and you'll start to see why our rates are actually quite a deal, saving you money, helping you to significantly grow your revenue and to thrive relative to your competitors.
Regarding pricing, it's true there are less expensive-appearing services (though don't forget that without SaaSy handling everything for you you'd still have to pay 3.5-4% in e-commerce merchant fees for every order, once you factor in the true costs), but they end up costing you far more when you factor in software development costs and the years you will spend if you go it alone or use an existing basic service that appears to cost less. Remember, it's not just building what you think you need today, it's also adding on to it endlessly as your needs grow and change, and then there's the maintenance. That's just the tech development side, what about dealing with taxes, say in the EU if you have any EU customers, or a dozen other similar issues you'd otherwise be on your own to figure out and then develop a solution for? Take a look at this matrix to see what the cheaper, more basic solutions are missing that SaaSy provides for those launching or running existing SaaS businesses, and you'll see why SaaSy is actually quite a deal relative to the basic recurring billing services: http://saasy.com/matrix.php
In addition to saving you all the time, money, and hassle of building your own e-commerce system, the incremental profit you'll earn from utilizing our features for growing your average order size, lifetime value, and optimizing your conversion rate far outweigh the higher fees. Each feature you take advantage of can increase your revenue by a few percent, and it doesn't take too many increases of 2-4% here and there to add up to an overall profit improvement that far outweighs the few extra points that Saasy's all-in-one service costs. For example, cross-selling; upselling; add-ons; bundling; discounts & promotions; order pages in local currencies and languages; Facebook/Twitter referral management; a breadth of payment methods available for your customers; an order page customized to fit the rest of your site or designed to fit your preferences; the ability to test and tweak different order page structures and merchandising ideas; reseller management; analytics; outside help with PPC, SEO, affiliate, and general web marketing; fraud protection, and the list goes on. And then there's the impact our phenomenal customer service will have on your churn rate and the word-of-mouth sales it generates to have so many "wowed" end users out there talking up the customer experience of working with you. SaaSy also reduces your internal support expenses as they relate to order and payment customer support, since we handle that for you.
If you're up for spending up to a couple of years building and improving on an e-commerce infrastructure, SaaSy isn't for you. But if time to market is important and you'd rather focus on developing your product/service and doing sales and marketing instead of dealing with the distracting complexities of building your own e-commerce system either from scratch or by building all the needed functionality around one of the cheaper, more basic solutions, then you'll want to take a close look at SaaSy.
When you view our features list and the competitive matrix, think through the costs of developing your own infrastructure over the next few years vs. what your development team could instead be focusing on, factor in that you're not going to need to pay the 3.5-4% in e-commerce merchant fees for every order which you would be doing otherwise, consider not only the reduced expenses but the new revenue you'll now be able to generate, and you'll start to see why our rates are actually quite a deal, saving you money, helping you to significantly grow your revenue and to thrive relative to your competitors.
I haven't setup payment processing since around 2002 or 2003, but it sounds like things have improved considerably. Back then, around the only option was Paypal. To get that to work (in any sort of automated fashion), you had to utilize their API and write your own custom code to process all of the communication with Paylal and your site and your database and to update accordingly (to acknowledge payments, subscriptions, user status change, re-ups, etc).
It wasn't as complex as I had feared it was going to be, but it was far from simple and farther from ideal. Especially since they had a habit of changing the API and the automated services over time.
I also never liked that you had to kick users out to the Paypal site at some point, to facilitate the payment.
It wasn't as complex as I had feared it was going to be, but it was far from simple and farther from ideal. Especially since they had a habit of changing the API and the automated services over time.
I also never liked that you had to kick users out to the Paypal site at some point, to facilitate the payment.
I don't think the payment process is anything that you can just glance over. The CMS I have written accepts two forms of payment, SagePay and Commidea.
There are lots of good examples for SagePay in most languages. I found Commidea to be the worst integration I have ever had to do.
If you use SagePay iFrame as I do then you do not ever touch the credit card, it all is handled in an iFrame and they authorise the card etc. This gets you round the PCI DSS requirements.
All you need is a couple of pages to handle post backs etc to tell SagePay where to send the authorisation details etc.
The problem you will have is with membership. If you're in the UK then its hard to get a bank or merchant to allow you to take 1 year memberships and take payment for them. If for whatever reason your site fails after 6 months then it is the bank who has to pay back the membership money. For this reason, I use Paypal for membership items
There are lots of good examples for SagePay in most languages. I found Commidea to be the worst integration I have ever had to do.
If you use SagePay iFrame as I do then you do not ever touch the credit card, it all is handled in an iFrame and they authorise the card etc. This gets you round the PCI DSS requirements.
All you need is a couple of pages to handle post backs etc to tell SagePay where to send the authorisation details etc.
The problem you will have is with membership. If you're in the UK then its hard to get a bank or merchant to allow you to take 1 year memberships and take payment for them. If for whatever reason your site fails after 6 months then it is the bank who has to pay back the membership money. For this reason, I use Paypal for membership items
My 3 year old site depends on recurring billing so this is something I've researched pretty well. If you have many non-US customers, as I do, the short story is that PayPal is really your only option. All alternatives depend on credit cards, which are not nearly as common outside the US.
I am aware of the horror stories around PayPal but I haven't had any serious problems in the last few years and I do hundreds of (recurring) transactions per day with them.
That said there is a pretty long list of annoying bugs in PayPal's recurring billing solution and most of the bugs have been in there for years. The technical bugs you can work around, but the "usability" bugs are quite annoying:
* If a user changes his credit card it will cancel all his subscriptions, unless he follows a specific set of steps that he won't find out about until it's too late
* If a user want to change a subscription and uses a different account to log into PayPal than the one he signed up with he gets the unhelpful error message that his "subscription has expired"
* If a user has two or more subscriptions and tries to change one PayPal will present him with a list of which one to change. This is a list of cryptic numbers. If he picks the wrong one it is near impossible to correct without canceling and resubscribing
* There is no way to pro-rate a subscription: if someone makes an annual payment for bronze tier and a day later decides to switch to silver tier PayPal will not charge the new price until a year from now.
I could go one. There are also internationalizations issues but I guess those only apply when you are outside the US like I am. (E.g. If you are outside the US then all the amounts in messages to your customers get formatted with a comma as a decimal separator, even if your customers are in US and you have your language set to US English). I've filed a bunch of bug reports over the years but I've never gotten a bug actually fixed.
I am aware of the horror stories around PayPal but I haven't had any serious problems in the last few years and I do hundreds of (recurring) transactions per day with them.
That said there is a pretty long list of annoying bugs in PayPal's recurring billing solution and most of the bugs have been in there for years. The technical bugs you can work around, but the "usability" bugs are quite annoying:
* If a user changes his credit card it will cancel all his subscriptions, unless he follows a specific set of steps that he won't find out about until it's too late
* If a user want to change a subscription and uses a different account to log into PayPal than the one he signed up with he gets the unhelpful error message that his "subscription has expired"
* If a user has two or more subscriptions and tries to change one PayPal will present him with a list of which one to change. This is a list of cryptic numbers. If he picks the wrong one it is near impossible to correct without canceling and resubscribing
* There is no way to pro-rate a subscription: if someone makes an annual payment for bronze tier and a day later decides to switch to silver tier PayPal will not charge the new price until a year from now.
I could go one. There are also internationalizations issues but I guess those only apply when you are outside the US like I am. (E.g. If you are outside the US then all the amounts in messages to your customers get formatted with a comma as a decimal separator, even if your customers are in US and you have your language set to US English). I've filed a bunch of bug reports over the years but I've never gotten a bug actually fixed.
I'm not the biggest fan of PayPal (reading enough horror stories over the last decade tends to cool you on some companies), but if it's the best option out there I'll use it.
I'm curious what the other single-person startups or small team startups that don't have the expertise to do full integrations with authorize.net/Braintree/etc. are doing to collect recurring/subscription payments?
I am hoping I'm missing some amazingly simple "all in one" company out there where a user can just enter credit card details and be done. I'm avoiding Amazon Payments and Google Checkout because of the required "create an account" step that a few companies have blogged about mucking up their follow-through with new customers.
Any tips would be much appreciated.
Links for reference (for anyone else in this boat) Intuit's full solution: http://payments.intuit.com/products/online-credit-card-processing.jsp
PayPal's full solution: https://www.paypal.com/us/cgi-bin/webscr?cmd=_wp-pro-overview
BrainTree's full solution: http://www.braintreepaymentsolutions.com/services/recurring-billing
If anyone is using any of these successfully for subscription-based payments I'd love to hear about it. I spoke with someone at Recurly who (fairly?) pointed out that subscription management isn't the primary feature of any of these services, so some of the implementations are awkward; on that note I'm not ready (since I have little idea of how this business will do) to purchase more management layers like Recurly into my billing process until business picks up.