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.