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.
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.
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).
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.
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:
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.