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:
I'm really interested in learning about two things if I can:
Thank you kindly
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.
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.
If you like a tighter integration with your site and service I highly recommend using
Arpit's answer is also good, if you want to rely more on an external supplier, and are not customizing much.
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:
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.
One good subscription site is zuora.com
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:
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.