The difference between integrated and non-integrated payment processing comes down to one question: does your card terminal know what the order total is, or does a person have to tell it?
In an integrated setup, the payment device talks to the system that holds the order. The total crosses automatically, the sale is recorded against the right line items, and the day closes with register and batch totals that match. In a non-integrated setup the terminal is a separate machine on the same counter. Someone reads the total off one screen and types it into the other.
That is the whole mechanical distinction, and it sounds too small to matter. It is not, because the manual step is where mistakes, reconciliation time and a surprising amount of monthly admin come from. But integration is not automatically the right answer either. It narrows your choice of processor, costs more to set up, and for a small enough operation it solves a problem you may not have.
This guide is about making that call. It sits alongside two others: the roundup of credit card machines for businesses covers which hardware is worth buying, and the guide to credit card readers for small business covers the cheap phone-attached end of the market. Both of those decisions get easier once you have settled this one, because integration requirements eliminate hardware.
The Bottom Line
- Integrated means the terminal and the order system exchange data automatically. Non-integrated means a human retypes the total.
- The cost of non-integration is not the typing. It is the mismatches you hunt for at close, and the sales that end up attached to the wrong order.
- Non-integration buys real things: lower setup cost, free choice of processor, and the ability to swap processors without touching your software.
- Lightspeed reports that one merchant, South Bark Dog Wash, saw tips rise about 11% after moving to integrated payments. Prompting on the device beats asking out loud.
- For a delivery business the question changes shape: the order is created before the driver leaves, so the real issue is whether the terminal in the van knows the total.
Lower your delivery costs by 23%
How we reduce costs:
- No delivery vehicle expenses
- Optimized local routes
- Pay-per-delivery model
- Average 23% delivery cost reduction
What are integrated payments?
Integrated payment processing means payment acceptance is built into the software you already run (your POS, your online store, your order management system) rather than running through a separate, disconnected device.
The practical consequence is that one action produces all the records. A card tapped on an integrated terminal closes the ticket, decrements inventory, books the revenue against the right category and lands in the day’s report, with no second keystroke anywhere. KORONA POS describes the non-integrated alternative as exactly the opposite: the processor operates independently, and staff must read the total off the POS screen and type it into the terminal (KORONA POS, retrieved November 2026).
Integration is a spectrum rather than a switch. Three arrangements are common:
- Fully integrated. The POS sends the amount to the terminal and receives the result. Nobody types a number.
- Semi-integrated. The terminal handles the card data in isolation and reports back a token or a result, which keeps card data out of your systems and reduces your PCI scope while still removing the manual step.
- Standalone, by design. The terminal runs its own payment app with no POS connection at all. Stripe ships this as a documented mode: a prebuilt app that runs on the reader so you can take payments “without a connected POS” and without writing an integration (Stripe, retrieved November 2026).
That third option matters. “Non-integrated” is often treated as a legacy accident, but for plenty of businesses it is a deliberate and sensible configuration.
Integrated vs non-integrated payment processing, compared
| Integrated | Non-integrated | |
|---|---|---|
| Who enters the total | The software | A person |
| Setup cost and effort | Higher: certified hardware, configuration, sometimes development | Lower: plug in the terminal and go |
| Choice of processor | Limited to those your POS supports | Any processor you like |
| Switching processors | Often means reconfiguring or replacing hardware | Swap the terminal, change nothing else |
| End-of-day reconciliation | Register and batch totals agree by default | Compare two totals, investigate differences |
| Error exposure | Mistyped amounts eliminated | Transposed digits reach the customer’s card |
| Reporting | Sales tied to line items, categories, staff | Payment totals only, reconstructed later |
| Hardware flexibility | Constrained to the certified list | Whatever the processor sells |
Read down the “non-integrated” column and you will notice the advantages are all about freedom and the disadvantages are all about bookkeeping. That is the real trade, and which side wins depends almost entirely on volume.
What non-integration actually costs you
Three costs, in rough order of how much they hurt.
The reconciliation hunt. With two separate systems, closing the day means comparing the POS total against the processor batch and finding out why they differ. KORONA POS describes this directly: when the day closes, someone compares the two totals, and a mismatch starts a search. Ten minutes a day is forty hours a year, and it is forty hours of your least favourite work.
Wrong amounts reaching real cards. A transposed digit charges a customer $94 instead of $49. The refund is easy; the phone call, the trust, and the second transaction’s fees are not. This failure mode does not exist in an integrated setup because nobody is transcribing anything.
Reporting you cannot use. A standalone terminal knows that $312.40 was approved. It does not know that it was six loaves, two cakes and a delivery fee. If you want to know your margin by product line, that linkage has to be rebuilt by hand or it simply does not exist.
There is a benefit on the other side that is easy to undersell: an integrated device can prompt the customer. Lightspeed reports that South Bark Dog Wash saw tipping revenue increase about 11% after adopting integrated payments, with the owner noting that “tips have gone up about 11% with people tipping on retail purchases, not just grooming” (Lightspeed, retrieved November 2026). One merchant is not a study, but the mechanism is sound: a prompt on a screen asks every time, and a person does not.
When non-integrated payment processing is the better choice
Four situations where the standalone terminal is the right call.
- Low transaction count. If you take a handful of card payments a day, the reconciliation burden is minutes and the integration cost is real money. Integration earns its keep when the manual work becomes routine, not when it is occasional.
- You want to keep your processor. Integration ties you to processors your POS supports. If you have a rate you are happy with, keeping it may be worth retyping totals. Card-present rates vary by close to a full percentage point across providers.
- Your business is in a restricted category. Integrated processing options narrow in high-risk verticals, where many providers impose restrictions or higher fees. A standalone terminal lets you work with a processor who will actually take the account.
- Your “POS” is not software. Plenty of small wholesale operations run on order sheets, a spreadsheet and a phone. There is nothing for a terminal to integrate with, and inventing a POS to justify integration is backwards.
When integration is worth paying for
The threshold is less about revenue than about repetition. Integration starts paying when the manual step happens often enough to become a process somebody has to be trained on and checked for.
Two concrete triggers:
- Closing the day takes more than a few minutes. If reconciliation has become a task rather than a glance, the manual step has stopped being free.
- You need sales tied to products. The moment you want to know which items make money, or which customer accounts are actually profitable, payment totals are not enough.
Worth separating from this decision entirely: your processing rate. Integration does not change what you pay per transaction. What does change it is whether the card is physically present. Square’s published fees show in-person tap, dip or swipe at 2.6% + 15¢ against 3.5% + 15¢ for keyed-in and card-on-file payments (Square, retrieved November 2026). That nine-tenths of a point is about card presence, not integration, and it dwarfs most integration savings.
The delivery version of the problem: the order exists before the payment
For a business that ships goods, this question arrives in a different shape, and most advice misses it.
In a shop, the order and the payment happen in the same place at the same second. On a delivery route they are separated by hours and miles. The order is built in the morning (online, by phone, on a standing wholesale schedule) and the payment happens at a door, taken by someone who was not there when the order was created.
That changes what “integrated” has to mean. The useful integration is not between the terminal and a register, because there is no register. It is between the terminal and the order record: the driver’s device should already know that stop four owes $312.40, because somebody put that number in this morning and nobody should be reading it off a packing slip in the rain.
When that link does not exist, you get the counter problem without the supervision. A driver types a total from a printed sheet, alone, at speed, holding a crate. The error rate goes up and the chance of catching it goes down, because nobody compares anything until the batch lands the next morning.
Three practical routes out of it, in increasing order of effort:
- Charge before dispatch. The cleanest answer and the one most wholesale operations should take. Card on file, charged when the order is picked, and the driver carries no payment responsibility at all. The trade-off is the card-not-present rate.
- Use a terminal that pulls the order. Available if your order system and your processor are on speaking terms, which in practice means choosing them together rather than separately.
- Accept the manual step and shrink it. If the driver must type the total, make the figure impossible to get wrong: one number, large, on the top line of the paperwork, and no mental arithmetic for delivery fees or substitutions.
Most delivery businesses land on the first option and should. The terminal in the van is for exceptions: the customer who adjusts the order at the door, the account that will not give you a card in advance, the one-off retail drop.
How to decide, in four questions
- How many card payments do you take a day? Under roughly a dozen, non-integrated is defensible. Well over that, the manual step is now a job.
- Does closing the day involve investigating differences? If yes, you are already paying for non-integration in time.
- Is your current processing rate better than anything your POS supports? If the gap is large and your volume is high, keeping the processor may beat integrating.
- Do you need sales tied to products, or just totals? Line-item reporting effectively requires integration.
Answer those and the decision usually makes itself. Where it does not, bias toward the cheaper, reversible option: a standalone terminal can be replaced with an integrated one next year, while an integration you have built your hardware around is a harder thing to unwind.
Frequently asked questions
What is the difference between integrated and non-integrated payment processing?
Integrated payment processing connects the card terminal to the software holding the order, so the total transfers automatically and the sale is recorded once. Non-integrated processing keeps the terminal separate, so someone reads the total off the POS and types it into the terminal, and the two sets of records have to be reconciled when the day closes.
What are integrated payments?
Payments taken through a device that exchanges data with your existing software (POS, ecommerce platform or order system) rather than through a standalone machine. One customer tap updates the sale, the inventory and the day’s reporting together, with no second entry anywhere.
Is integrated payment processing worth it?
It is worth it when the manual step has become routine: more than roughly a dozen card sales a day, reconciliation that takes real time, or a need to tie revenue to specific products. It is not worth it when volume is low, when your current processor’s rate is materially better than anything your POS supports, or when there is no software to integrate with.
What are semi-integrated payments?
An arrangement where the terminal handles the card data on its own and reports only a result or a token back to your system. You still avoid retyping totals, but card data never enters your software, which reduces how much of your setup falls inside PCI scope.
Can I switch from non-integrated to integrated later?
Usually, but not always with the same hardware. Integrated setups require terminals certified for the specific POS, so switching often means new devices as well as new configuration. That is a reason to decide deliberately rather than to default, and a reason the reversible option is worth something.
The decision is about repetition, not technology
Neither arrangement is more professional than the other. A standalone terminal next to a till is not a sign of a business that has not caught up; it is a reasonable configuration that trades a little daily admin for a free hand in choosing a processor.
What tips the balance is how often the manual step happens, and whether anybody is watching when it does. In a shop, somebody usually is. On a delivery route, nobody is, which is why the integration question is sharper for a business that ships goods than for one that sells across a counter.
