There are two entirely separate problems hiding behind a quickbooks credit card fee calculator. One is what card acceptance costs when payments run through Intuit. The other is how to record the fee so your books agree with your bank deposits. Different answers, both below.
Question one: what it costs to take cards there
Intuit publishes its own payments pricing, it differs by how the card is taken, and it is on their site rather than in this article. Read it there, because a rate copied into a blog post is only correct until the next revision.
What is worth knowing regardless of the figure is the shape. There is usually a percentage, often a fixed amount per transaction, and sometimes a monthly plan sitting behind them. Card-present is priced below keyed and online, as it is nearly everywhere, because the dispute risk is lower.
Our own published rate is 2.50% + $0.10 on an in-person sale and 2.90% + $0.25 keyed or online. Sample pricing applies to new accounts applying directly; pricing is subject to underwriting, MCC and the merchant agreement; rates may differ and are subject to change.
To compare it with anything else, convert both to an effective rate on one month of your own volume and transaction count. That conversion is what our credit card processing fee calculator exists to do, and the anatomy of a card bill is pulled apart on our processing fees page.
Question two: recording the fee so the books balance
This is the one that actually costs people time, and it comes down to a single decision: gross or net.
If a customer pays a hundred dollars and the processor keeps its cut, your bank sees less than a hundred. Book only what arrived and your revenue is understated all year and your card costs are invisible. That is the trap.
The convention most bookkeepers use is to record the full sale as income, record the processing charge as its own expense, and let the deposit equal the difference. Your revenue is then real, your fee expense is visible on the profit and loss, and the bank reconciliation works because the two lines net to the deposit.
Batch deposits complicate it slightly. When a day of sales lands as one deposit, the fee may be deducted from the batch or billed monthly in a lump. Match your recording to whichever way your processor actually settles, and confirm the approach with your accountant rather than with a forum post.
What a quickbooks credit card fee calculator will not do for you
It will not reconcile anything. It gives you a number, and a number is not a bookkeeping method.
Three things it also will not tell you. Whether the fee was deducted per batch or billed monthly, which changes where it appears in your accounts. What your refunds did, since a refunded sale may not return the whole fee. And whether the deposit you are staring at covers one day of sales or three, which is the usual reason a reconciliation refuses to balance on a Monday.
Those answers come from your merchant statement, not from a calculator.
When the register and the books disagree
Start with the timing rather than the amounts. Card batches settle on their own schedule and a weekend can arrive as one deposit on Tuesday. Half of all reconciliation problems in a small store are a date, not an error.
Then check the categories. Sales tax collected is not revenue. Lottery, money orders and similar pass-through items are not revenue either, and a system that dumps them into sales will misstate every margin you look at. Our lottery integration page covers keeping those separate at the register, which is where it has to happen.
Then check the register itself. If the POS cannot export a clean daily summary by category, your bookkeeping is manual forever. That is a system problem rather than an accounting one, and it is worth pricing properly on our POS system cost page.
Whether to process cards inside your accounting software at all
For a service business invoicing a few clients a month, keeping payments where the invoices live is genuinely tidy. For a counter business ringing hundreds of small baskets a day, the register is the system of record and the accounting software should be receiving a clean daily summary from it.
The question then is not which one processes the cards. It is whether your POS exports into your books without somebody retyping totals every morning. Ask any vendor to show you that export working before you sign anything, on real data rather than a demo.
If you want a look at your current setup and where the retyping is happening, tell us about your store.
Frequently asked questions
Should I record the gross sale or the net deposit? Recording the gross sale with the processing charge as a separate expense keeps your revenue accurate and makes what you pay to accept cards visible. Netting hides both. Whichever your accountant prefers, be consistent all year, because switching methods mid-year makes period comparisons meaningless.
Where should processing fees sit on the profit and loss? Most small retailers keep them as an operating expense with a name they can find, such as merchant fees or card processing. Some put them in cost of sales. Either can be defended. What matters is that they are one identifiable line rather than scattered through bank charges where nobody looks at them.
Do refunds give the fee back? It depends entirely on the provider, and the published policies genuinely differ from one to the next. Read the refund section of your own provider’s current support documentation before you assume anything, then make sure your bookkeeping matches the real behaviour. Stores with regular returns feel this line more than they expect to.
My deposits never match my daily totals. Where do I start? With settlement timing. Batches close at a set time and weekends often land together, so a deposit rarely equals one calendar day. Line up the batch reports against the deposits before you look at individual sales. The mismatch is usually a boundary, not a missing transaction.