Accepting payments... subscription plans
So, I am a total newbie when it comes to payment processing, acceptance of payments, subscription plans, etc.
I've recently built out the SaaS offering and will be in beta with it through the end of the year. The service however has stabilized and I am ready for the payment part.
Before I ask my detailed questions, here is how I would like the payment processing to look like:
- All users will be charged a monthly fee, from $0/month through $550/month, depending on the plan they chose. I suspect majority of users will be on a $40/mo plan. There are 5 plans total.
- In addition to flat monthly plan cost, all users can be charged extra for over-usage if they go over the limits of their monthly plan. This fee will be calculated at runtime on a monthly basis
- Consequently, there maybe other additional features in the future that I would to add charges for
- My software is in .NET and runs in the cloud (Windows Azure)
- I /need/ to bill on a monthly calendar basis (1st through 31st). This is because over-usage is being tracked on a calendar monthly basis
- I would like to accept payments from customers from all over the world and not be tied only to US. (Why would someone not do this from the get-go?)
- I would like to NOT keep any CC/payment information myself and outsource all the processing to a 3rd party
- Users register on my site, pick a plan and I will use my API when they register for service. They will get a free trial. I would like them to enter their CC information sometime after they registered for an account and tried the product for a while.
I'm really interested in learning about two things if I can:
- Having never dealt with online payments & processing, where should I go to LEARN about the payment architecture for such a requirement as mine? What are the do's and don'ts? What are the gotchas? I'd prefer to not have 1000 URL's to browse through but 1-2 sites that contain all the basics.
- Any recommendations for a 3rd party vendor that would suit my particular requirements the best?
Thank you kindly
Charging Payments Credit Cards Billing
7 Answers
You can use a service such as CheddarGetter.com to simplify your transactions for subscriptions, but you will quickly learn that its best to build your own subscription system. It's easy, it gives you ultimate control, and worthwhile doing versus services that exists.
you will need:
1. Merchant account
2. Gateway ( I highly recommend Authorize.net)
3. A way to store customer cards (not on your server)
For a merchant account, contact Kirk Mcworther at flash ship merchant services. It will cost you around $40 per month, but you will get great rates, and in the long run could get interchange plus pricing.
The gateway gives you access to an API to process transactions. Authorize.net is very easy to code in C# with plenty of code examples. Authorize.net also offers you a credit card vault, where you dont store credit cards in your DB, and therefore dont have to worry about PCI compliance and extra security risks. They do this by tokenization, what it essentially does is send you back a token for each credit card you store in the vault, your system can then reference a stored credit card by token, rather than the card details.
Last, if you have a monthly service, serisously consider pro-rated billing.
Here is a scheme that I find works VERY well in B2B apps.
- Offer a trial, without a credit card required. We do this very similar to rackspace email apps, where we offer 14 days free trial. Since we built our own payment systems, we allow the customer to convert the trial to a real subscription at any point, but keep the remaining free days. You cannot do something like that with the subscription services that exist.
- We offer upgrades and downgrades, this is next to impossible to do with Paypal subscriptions (they limit the % of increase you can do), and with services for subscription billing its a hassle to code.
- Pro rate where you have your customers billed on the 1st of the month. For your 500 plan, if someone signed up today, they would be billed for only 14 days out of 31 days remaining in December (45% x 500), then full $00 on the first of the month. The reason pro-rated billing is great is it allows you to focus on your collection efforts early in the month, freeing up the rest of your time for marketing, building features, and retaining customers who let their cards expire, or cancelled. If you bill on a daily basis, its hard to focus on your other goals while random transactions appear. Also pro-rated billing helps you get a way better grasp of how your business is doing on a monthly basis.
Coding your own solution takes a few weeks worth of work, but its the best option for handling overages, late charges, etc. Plus the few cents you might spend per transaction using a 3rd party service add an unnecessary layer of overhead, and risk that if that service fails your income pipe is down.
Best of luck on your Azure app. I really think its a great idea, and would like very much to see it be a great success.
FB
-
+1 for detailed, relevant answer. :) – Susan Jones 14 years ago
-
Great tips on why to pro rate. – Zuly Gonzalez 14 years ago
-
Unless you are running a huge subscription site, or have a comitted accounting department that can handle payments on a daily basis (including those with expired CC's and those that fail), you really need to use pro-rated billing. Its very hard to manage a business when you are doing a million different things throughout the day. A few days of work, building your own billing system will pay off in the long run. – Frank 14 years ago
-
Frank, first, thanks for great answer. Im now back from vacation and am looking into this again. Im confused between process gateways and merchant accounts? I think in the beginning I'll just need a service to store CC's when users enter them (this needs to be automated from my site) AND a way for me to bill those users/CC's once a month (manually). Does that simplify what I need? Can you recommend a few sites here? Thanks! – Igorek 14 years ago
-
Hope you have a good holiday. Think of a merchant account as an engine to a car, and the gateway as the steering wheel. In essence the merchant account is what processes transactions with credit cards, but the gateway is an interface. Most gatways offer a human interface (authorize.net does) where you can manually process cards, they also offer an API if you were to automate things in the future. As for storing cards, the issue of PCI compliance comes into play. If you store your cards in your own database then you have to be PCI compliant. If you store them in your gateways db then – Frank 14 years ago
-
... you dont have to worry about PCI compliance. When you use an API to store credit cards this process is called tokenization. Tokenization does the following. Frank inputs his credit card into your app, or gives it to you on the phone. Your app or you physically key in the transaction to the gateway. The gateway saves the card, and returns a reference token. You can store this token in your database. In the future if you need to charge the same card, all you do is reference the token. You are then only storing tokens, and not credit cards. No matter what you will need a merchant – Frank 14 years ago
-
account and gateway account. My recommendation of Kirk at flagship for the merchant account and authorize.net for the gateway is well researched. (Kirk can setup both, and you will get a discount on Authorize.net by using him). Your merchant account will have a brief application. These apps are hard for startups, but kirk makes it easy. They will ask you what needs to show up on your customers bank statement (your Merchant Identifier usually your company name), and after some basic questions about how much you expect to process you are setup. – Frank 14 years ago
-
There is a monthly minimum fee, usually around $30. Then each transaction has two fees. A fixed fee of a few cents, (usually around a quarter). And a precentage of the total charge. This varies from 2-3 percent and get up to 25% for adult sites. As your reputation grows, your merchant bank will review your rates and lower them. If you ever become huge, then you can pay a high monthly fee and remove all the % charges. This is called Interchange Plus pricing. The reason i strongly recommend getting a good merchant broker such as kirk is because they fully understand the e-comm business – Frank 14 years ago
-
and hold your hand during the whole startup process and as your business grows. – Frank 14 years ago
If you like a tighter integration with your site and service I highly recommend using
They provide an Invocing API that works really well, and a multiple of external addons for everything from payments to CMS integration. It's really excellent.Arpit's answer is also good, if you want to rely more on an external supplier, and are not customizing much.
-
This is good for freelancers. – Frank 14 years ago
I don't know of a place that offers comprehensive explanations for this.
jumpstartcc.com will give you an overview of what's involved in credit card processing.
Basically, there are three parts to it:
- merchant account (you could get that at your bank)
- payment processor (e.g. Authorize.net, they will store CC details for you)
- subscription management service (Recurly, Spreedly, Chargify etc.)
I think there are services that provide all of this for you (e.g. BrainTree Payment Solutions).
All your requirements other than charging for over-usage seem straightforward, so you'll just need to understand which providers allow dynamic charges. Accepting payments from outside the US shouldn't be a problem as far as I know.
Go through these providers and as you gain more and more customers, you'll need to switch to other providers depending on your experience and needs.
- PayPal.com
- Kagi.com
- FastSpring.com
Other 3rd Party Billing Applications include:
They are all pretty comparable. Chargify and Recurly probably have the most backing.
Just to answer one part of your question:
I would like to accept payments from customers from all over the world and not be tied only to US. (Why would someone not do this from the get-go?)I too was looking to accept payments from customers all over the world (and am in a similar situation to yourself). This really depends on what you mean by accepting payments from all over the world. This can mean accepting payments:
- from customers that reside in any country in the world, or
- in different currencies used by your customers.
Now in the first situation this is handled by just accepting one of the common currencies (which I would put to being US Dollars, British Pounds, or Euro's) and letting the credit card networks automatically take the payment and convert it for you. This will cost a small extra percentage amount of the transaction, charged to either the customer or you, although it seems to be most often on the customer side. I'm unaware if the merchant also gets charged this, although it wouldn't surprise me.
As far as the second situation goes you'll need to put in a lot more extra effort as the whole payment processing pipeline will need to be done for each currency, and you'll need a merchant bank account that can handle all of the different currencies. These do exist, and it is possible to set this up, but it's a whole lot of extra work for a startup to do, and the accounts themselves are quite expensive - fee wise.
Now you might think that doing the second option - charging in different currencies - would be nicer on the end user, and to some extent it is. But speaking as someone from outside of the US, it doesn't matter that much, and it would matter a whole lot less for businesses.
