Vega
A POS system with M-Pesa in Kenya does two jobs in one motion: it records the sale and it moves the money. The customer taps a prompt, the till hears about it, and the receipt closes the loop. When those steps happen without retyping, your day gets shorter and your numbers get cleaner.
Most shops already accept M-Pesa — on a personal phone, propped next to the till. The problem is not acceptance; it is distance. The sale lives in one record and the payment lives in another, and nobody joins them until an evening when everyone is tired.
That gap is where money leaks. Payments get recorded twice, refunds vanish into chats, and the day’s M-Pesa total never quite matches the till. A proper POS system with M-Pesa in Kenya closes the gap by making the payment part of the sale itself.
This guide covers the decision the way an owner should run it: how the connection actually works, the five tests that expose weak integrations, reconciliation, refunds, costs and the questions that separate demos from reality. Ask for live payments in every demo, not screenshots. A POS system with M-Pesa in Kenya either proves itself with your own phone in the room or it doesn’t.
Everything here applies whether you ring up ten sales a day or three thousand, at one counter or across branches. Take notes in every demo, because memory flatters exactly the weaknesses you will meet later. The right POS system with M-Pesa in Kenya earns its keep on the first busy day; the wrong one shows its cracks there too.
What a POS System with M-Pesa in Kenya Actually Does
Underneath the logos, the job is simple to describe and hard to do badly. A POS system with M-Pesa in Kenya connects the sale on the till to the payment on the phone, so one event produces one record. No retyping, no screenshots, no evening detective work.
The first job is asking for money. The cashier totals the sale, chooses M-Pesa, and the customer’s phone receives a payment prompt with the exact amount. Nothing is typed twice, which means nothing is mistyped.
The second job is hearing back. When the customer enters their PIN, the confirmation should travel back to the till and mark that exact sale as paid. The receipt can then show the method, the reference and the time.
The third job is filing. Every confirmed payment should attach itself to the sale, the cashier and the day, building a record you can audit later. Good POS system with M-Pesa in Kenya candidates make that attachment automatic and visible on the receipt.
The fourth job is matching. At close of day, the system should line up its own sales against the money that actually arrived. This reconciliation, not the payment prompt, is where the real value hides.
The fifth job is reporting. Cash, M-Pesa and card should appear in one summary, not three notebooks. Ask each POS system with M-Pesa in Kenya vendor to demonstrate all five jobs in one continuous demo, using your phone and your products.
Watch what happens when things go wrong during that demo. A cancelled prompt, a wrong amount, a double payment — strong POS system with M-Pesa in Kenya setups handle each one with a clear screen and a clear record. Weak ones improvise, and improvisation at the till becomes losses in the ledger.
One question sits under all five jobs: does the integration run itself, or does it need a babysitter? Some setups demand constant attention — refreshing screens, copying references, fixing stuck records. Ask every POS system with M-Pesa in Kenya vendor what their integration does on an ordinary day with nobody touching it.
Why Taking M-Pesa on the Side Alone Fails
The common arrangement is well known: a till for records, a shop phone for M-Pesa, and goodwill in between. It works at first. Then the volume grows and the two records drift apart, one sale at a time.
The drift shows up as matching work. At close of day, someone scrolls the phone’s messages and copies amounts into a book, hoping the totals agree. A connected POS system with M-Pesa in Kenya ends that ritual by matching payments to sales as they happen.
The side-phone method also opens fraud windows. A payment can be confirmed on the phone but never reach the books. A refund can be issued twice, or once and pocketed. Without a link between sale and payment, nobody can prove anything either way.
Disputes are worse. A customer swears they paid; the record says otherwise; the evidence is a text message on a phone that also carries family chats. POS system with M-Pesa in Kenya records tie the payment to a sale, a time and a reference, which turns arguments into lookups.
Then there is speed. Typing the amount into the phone while the customer waits adds half a minute to every sale, and mistakes add more. At peak hours, those minutes are customers walking out.
There is also the reporting blindness. Money that never enters the till record never enters the reports, so your real revenue lives somewhere between the notebook and the phone. A proper POS system with M-Pesa in Kenya puts every shilling from every method into one set of numbers.
None of this means the shop phone must disappear. It remains useful for supplier payments and the odd transfer. But customer payments at the counter belong inside the system of record, and POS system with M-Pesa in Kenya integrations exist precisely to put them there.
How the Connection Actually Works
Strip the marketing away and the integration has three moving parts. The till sends a payment request, M-Pesa processes it, and the result travels back to the sale. Every demo should show all three parts working live.
The request stage matters most for speed. The cashier should press one button and the customer’s phone should light up with the exact amount. If the process involves typing the amount into a separate device, the integration is wearing a costume.
The return stage matters most for truth. The confirmation must land on the exact sale that raised it, with the M-Pesa code attached. Ask each POS system with M-Pesa in Kenya vendor to show you the matching record immediately after a live payment — not at the end of the demo, when there has been time to tidy up.
There will be failures, and that is normal. Phones are offline, customers cancel, networks drop mid-PIN. The mark of a serious integration is what the till shows during those seconds: a clear pending state, a clean retry, and no half-paid ghosts in the records.
Ask specifically about stuck payments. What happens if the customer pays but the confirmation never reaches the till? A well-built POS system with M-Pesa in Kenya setup detects the orphan, offers a match, and logs the fix with a name on it.
Finally, ask who maintains the plumbing. Integrations ride on connections that change, and someone must keep up. POS system with M-Pesa in Kenya vendors who maintain their own link and say so in writing are safer bets than those who depend on a third party nobody can name.
Day One: Five Tests to Run on Any Demo
Demos are choreographed unless you take the wheel. Walk in with five tests, run them yourself, and use your own phone with real shillings. Ten minutes of honest payments beats an hour of slides.
Test 1: Pay a live sale by M-Pesa. Total a real item, choose M-Pesa, and pay from your own phone with a real amount. A genuine POS system with M-Pesa in Kenya setup shows the prompt landing with the right figure and the confirmation attaching itself to that exact sale.
Test 2: Cancel the prompt halfway. Start the payment, then cancel it on the phone before entering the PIN. The sale should return to unpaid cleanly, with the attempt logged. Watch for systems that leave the sale hanging in a paid-but-not-paid state nobody can resolve.
Test 3: Refund to the same phone. Process a full refund on the sale you just paid and follow the money back to your phone. Any POS system with M-Pesa in Kenya worth buying produces the refund record, the reason and the name of the approver without being asked.
Test 4: Pull the day’s money match. After the live payments, open the payment summary and look for cash and M-Pesa side by side. The figures should agree with what actually happened in the room, to the shilling. This one screen is the product.
Test 5: Kill the internet mid-payment. Switch off the connection just before a payment and watch what the till does. Serious POS system with M-Pesa in Kenya candidates keep selling, queue the records, and reconcile when the line returns. Nervous ones freeze and hope.
Score each test out of five and run the same five with every vendor. The comparison sheet does the arguing for you.
Bring awkward cases too: a customer with insufficient funds, a split bill, a sale paid half cash and half M-Pesa. POS system with M-Pesa in Kenya systems that survive your awkward cases on day one are the ones that survive your shop on day three hundred.
Selling When Power and Internet Fail
Outages are not an edge case in this market; they are a Tuesday. The question is what a POS system with M-Pesa in Kenya does when both the lights and the line disappear together. Ask it in the first five minutes of every demo.
Sales should continue offline. The till keeps a local copy of prices and products, rings up sales, and prints receipts while disconnected. Records queue on the device and upload in order when the connection returns.
Payments are the delicate part. An M-Pesa payment needs the network, so the honest answer involves two paths: sales continue offline on cash or credit, and queued M-Pesa payments catch up when the line returns. Watch how the demo explains the gap — hand-waving here predicts hand-waving later.
Ask what happens to a payment that was confirmed on the customer’s phone seconds before the internet died. Did the till hear about it before the drop, or is the money in limbo? Good POS system with M-Pesa in Kenya integrations reconcile the orphan automatically; careless ones leave it for you to find next week.
Receipts keep customer confidence while systems heal. Confirm that receipts print normally offline and carry the information your customers expect. A POS system with M-Pesa in Kenya that downgrades to a calculator during outages costs you the hours you most need.
Power is the quieter half of the problem. A tablet with a healthy battery rides through short cuts; a router and printer need a small UPS. The software story and the power plan together decide whether a dark afternoon is an inconvenience or a closure.
Finally, ask how the day’s books survive the chaos. When the connection returns, the queued sales, the offline payments and the delayed confirmations should settle into one honest total. POS system with M-Pesa in Kenya vendors who describe that settling process with specifics are showing you their engineering, not their brochure.
How a POS System with M-Pesa in Kenya Connects: STK Push, Till and Paybill
There are three ways customer money reaches a till, and they are not equal. STK push sends the prompt to the customer’s phone automatically. A till-number flow asks the customer to pay to your business number themselves. A paybill flow is the loosest of all. POS system with M-Pesa in Kenya buyers should know which one a vendor actually means.
STK push is the strongest for speed and accuracy. The amount travels with the request, the customer only confirms, and the reference comes home automatically. It removes typing, which removes the mistakes typing causes.
Till-number flows are common and workable. The customer pays to the number, and the system matches the incoming payment to the open sale by amount and reference. Ask how the match happens when two customers pay the same amount within a minute — the answer reveals the engineering.
Paybill connections are the loosest. Money arrives into a collection account, references are messy, and matching often becomes a human job. A POS system with M-Pesa in Kenya built on paybill alone should explain exactly who does that matching and when.
Whatever the route, the receipt must agree with the phone. Customers notice when the till says one thing and their message says another, and trust leaks at the counter.
Ask each vendor to name their route plainly, in one sentence. Then ask what happens at each failure point: cancelled prompts, wrong amounts, timeouts. An honest POS system with M-Pesa in Kenya vendor answers with the flow, not with the word “seamless”.
One more comparison settles it: watch the same 500-shilling sale go through all three routes if the vendor offers them. Time each one and count the taps. POS system with M-Pesa in Kenya connections earn their fees one saved tap at a time, and the timing shows.
Staff Accounts, Overrides and Audit Trails
Money attracts improvisation, so the system must make honesty easy and tampering awkward. That starts with accounts. Every person touching payments should log in as themselves, every shift, no exceptions.
Shared logins are the first hole. When three cashiers use one account, a missing M-Pesa payment has no author and no story. POS system with M-Pesa in Kenya setups with proper user accounts tie every payment, refund and manual mark to a name.
Permissions come next. Cashiers should record payments; supervisors should edit them; only managers should mark a payment as received by hand or approve refunds. Ask to see those levels demonstrated with a real cashier account, not the owner’s master login.
The dangerous power is manual matching. The ability to attach a payment to a sale by hand is also the ability to attach the wrong one on purpose. POS system with M-Pesa in Kenya systems should log every manual match with the matcher’s name, the old state and the new one.
The audit trail turns all of this into evidence. Open it in the demo and look for payment events: prompts sent, confirmations received, refunds approved, overrides used. A readable POS system with M-Pesa in Kenya audit log turns a Tuesday dispute into a five-minute lookup.
Then adopt the weekly habit. Fifteen minutes every week reviewing refunds, manual matches and voids catches patterns while they are small. The POS system with M-Pesa in Kenya record makes the review possible; only the calendar makes it happen.
One quiet question deserves asking: who at the vendor can see your payment data? Support staff with access should be logged and limited like your own team. The rule travels: no anonymous actions, anywhere in the chain.
Reconciliation: The Whole Point of a POS System with M-Pesa in Kenya
The payment prompt is the demo; reconciliation is the product. At close of day, three numbers should agree: what the till says you earned, what M-Pesa says arrived, and what the bank eventually holds. POS system with M-Pesa in Kenya reconciliation exists to make those three numbers meet without an evening of detective work.
Ask to see the matching screen in the demo. Each M-Pesa payment should sit beside its sale, matched by reference, with any unmatched items flagged and explainable. The flags matter more than the matches — they are how problems surface while they are small.
Transaction charges belong in the picture too. M-Pesa fees arrive separately, and the books should record them as costs, not as mysterious shrinkage. Ask where the system puts them.
Timing differences are normal and the system should expect them. A payment confirmed at 9:58 pm may land in the bank the next day; a good POS system with M-Pesa in Kenya setup tracks the difference instead of hiding it. Ask how the day closes when money is still in flight.
Then ask who reads the output. The reconciliation summary should be short enough to read standing up: total by method, unmatched count, refunds, charges. If the report needs a training course, it will not get read.
Insist on the exception list, not just the totals. The habit that protects the money is reviewing unmatched items daily, and a POS system with M-Pesa in Kenya that surfaces them automatically makes the habit cheap. One glance, one list, one decision each evening.
Do this arithmetic once for yourself: multiply the minutes spent matching by hand each evening by thirty. Then price the integration against that. The comparison usually ends the debate.
What a POS System with M-Pesa in Kenya Costs Each Month
Payment integrations arrive with their own price tags, and they hide in three places: the software subscription, the integration itself, and the transaction costs. Know all three before comparing quotes. POS system with M-Pesa in Kenya pricing only makes sense when the whole stack is on the table.
The subscription is the visible part — monthly or annual, rising with devices and branches. Ask whether M-Pesa integration is included in that figure or billed separately. Both models exist, and the difference can double the effective cost.
Setup and integration fees are the hidden part. Some vendors charge once to connect, some bundle it, some quietly bill for “activation” per device. A POS system with M-Pesa in Kenya quote that lists integration explicitly is easier to trust than one that discovers the fee later.
Transaction charges are the third stream, and they mostly belong to Safaricom, not to the vendor. What the vendor controls is whether the system records those charges as costs in your reports. Ask to see where they land.
Renewals deserve the same suspicion here as everywhere. Year-one discounts that correct sharply in year two are common, so ask for the standard renewal price in writing on day one. POS system with M-Pesa in Kenya vendors with published price lists are showing you respect; the ones who “will send the quote later” are not.
Then weigh the bill against the leak it closes. Hand-matching costs minutes every evening, missed matches cost money monthly, and disputes cost goodwill permanently. An integration that catches even one orphan payment a month usually pays for its keep.
Keep the one-page comparison: subscription, integration fee, per-transaction costs, renewal price, support inclusions. Ask every POS system with M-Pesa in Kenya vendor to fill it before the demo ends. The blanks are where budgets break.
Reports to Demand Before You Sign
Reports turn payments into decisions, and five of them carry the weight. The first is the money summary: cash, M-Pesa and card side by side for the day, week and month. POS system with M-Pesa in Kenya reporting should produce it without filters being set.
The second is the payment method mix. Knowing what share of trade moves by M-Pesa drives decisions about float, banking runs and even counter layout. The report should split by day and by hour, because peaks tell their own story.
The third is the exceptions report: failed prompts, cancelled payments, unmatched money, stuck records. This is the health monitor of the integration. Ask to see a day with failures in it — sample data never shows real trouble.
The fourth is the refunds log: every reversal with its reason, its approver and its trail back to the original sale. A POS system with M-Pesa in Kenya that reports refunds cleanly is a system you can audit in minutes.
The fifth is the tax view: sales by method with VAT summarised the way filings want them. Payments and invoices are different records, and your accountant will care about both. Confirm the exact format with them before signing.
Two practical checks finish the list. Every report should export to Excel or CSV for deeper work, and the daily money summary should reach your phone by email or WhatsApp without anyone pressing send. POS system with M-Pesa in Kenya reporting should meet you where you already read things.
Finally, ask who builds the reports — the system or a person. Scheduled, automatic reports survive busy weeks; hand-built ones survive nothing. POS system with M-Pesa in Kenya setups that email the money summary before you ask for it are showing you their habits.
Refunds, Reversals and Disputes
Refunds are where payment integrations earn respect or lose it. Money went out by M-Pesa; now it must go back, traceably, with records on both sides. Ask for the full refund story in every demo.
Same-day reversals are the cleanest path. When a sale is reversed quickly, the transaction can often be undone before settlement, and the customer walks away settled. Ask whether the system supports this and who is allowed to trigger it.
Older sales need a different route: refund as a new transaction, tied to the original record. Watch one performed live. A capable POS system with M-Pesa in Kenya shows the refund, the reason, the approver and the link to the original sale on one screen.
Then there are the awkward cases. The customer paid the wrong number, the amount was correct but the sale was voided, the reversal window expired. Every one of these has a path in a mature system and a shrug in an immature one.
Disputes deserve their own habit. When a customer claims a payment the record does not show, the lookup is the reference code, and the trail should end the conversation politely. POS system with M-Pesa in Kenya records that carry the M-Pesa code on the receipt win those conversations before they start.
Approval levels matter double here, because refunds are money leaving. Cashiers should request, managers should approve, and both actions should be logged. POS system with M-Pesa in Kenya audit trails that separate the request from the approval are the ones that survive an honest disagreement.
Write your own refund policy before the system goes live: who approves, what evidence, what timelines. Then configure the software to enforce it. Policy that lives in settings instead of on posters actually holds.
eTIMS and Your Payment Records
Invoices and payments are different animals, and the taxman cares about both differently. eTIMS concerns itself with the invoice: what was sold, at what tax rate, to whom. The payment method is your operational data. A POS system with M-Pesa in Kenya keeps the two linked so both stories agree.
Watch the flow in the demo: a sale produces a compliant invoice, the M-Pesa payment attaches to it, and a credit note can be issued if the sale reverses. All three steps should be visible, not described.
Then ask the boundary questions. Partial payments, deposits and split payments each have a treatment, and “it depends” is a fine answer if it comes with the detail. Confirm the specifics with KRA and your accountant, because county and sector rules differ.
One caution deserves its own line: do not let payment convenience bend the tax record. The invoice must reflect the sale, not the easiest way to close it. POS system with M-Pesa in Kenya setups that keep the invoice sacred and the payment attached are the ones that age well under audit.
Ask to see the offline story for tax documents too. Invoices raised during an outage, transmission retries and the confirmation trail all matter on the day an inspector asks. POS system with M-Pesa in Kenya vendors who volunteer this unprompted have usually been through one.
Security Basics for Mobile Money at the Till
Payment security is mostly unglamorous habits, and the system should make them easy. Three layers matter: the accounts, the devices and the money itself. Weakness in one undoes the other two.
Accounts first, as always: individual logins, PINs that are not birthdays, levels that match responsibility. Change credentials the day anyone leaves. A payment system with shared logins is a drawer without a lock.
Devices next. Tablets auto-lock, browsers log out, and no shop phone stays logged into a paybill portal overnight. Ask the vendor what session controls exist, and then actually switch them on.
The money itself has its own patterns of trouble. Fake payment messages, screenshots of stolen confirmations, reversals after goods leave, and the classic wrong-number refund. Every one of these is checkable at the point of sale if the till shows the verified confirmation rather than the customer’s word.
Float management belongs here too. Money collected by M-Pesa should move to the bank on a schedule, not sit in a wallet where it is one password away from trouble. Decide the sweep rhythm and let the reports enforce it.
Close the loop with the weekly review: refunds, manual matches, exceptions, after-hours logins. Fifteen minutes, same day every week. The cheapest audit you will ever run.
Hardware the Setup Needs
The good news is that M-Pesa integration does not demand exotic hardware. The integration lives in the software, so the questions are the familiar ones: what device runs the till, how solid the connection is, and what prints the receipts. POS system with M-Pesa in Kenya setups run fine on standard Android tablets or ordinary computers.
Connection quality is the real hardware story. A weak router at a busy counter causes more payment grief than any software ever will. Ask what internet setup the vendor recommends, and whether they will say so in writing.
Printers and drawers follow the usual rules: supported models listed publicly, spares on the shelf, cables dressed away from spills. POS system with M-Pesa in Kenya vendors should confirm compatibility before delivery day, not after.
Add a small UPS for the router and printer, and the counter survives short outages without drama. Keep serial numbers and receipts of every device in one folder. Support calls go twice as fast when you can name the model and the failure.
Switching Over: The First Week with Integrated Payments
The cutover week decides whether the integration becomes a habit or a headline. Plan it like a launch, because it is one. The software is ready; the humans need the rhythm.
Before day one: till details loaded and tested with one real payment, staff accounts created at the right levels, and the refund path rehearsed once with real money. Nothing builds confidence like a dry run that works.
Run the phone-on-the-side method in parallel for one week, deliberately. Double records for a few days is the price of a safety net. At the end of the week, compare the two — the differences are your training list.
Train at the till, in short sessions, with real payments. Ten minutes with actual shillings beats an hour of slides. Make your most sceptical cashier the first expert, because sceptics convert teams faster than managers do.
Close each day with the reconciliation screen: totals by method, unmatched count, refunds. Fix confusions the same evening while they are small. By the second week, retire the side phone completely and let the system’s records be the only records.
Expect slower queues for three days and say so out loud. Speed returns once fingers learn the flow. What never returns is the evening matching ritual — and that is the whole point.
Seven Mistakes Buying a POS System with M-Pesa in Kenya
Most disappointing integrations follow the same seven patterns, and none of them are technical. They are buying habits. Read them here and tick them off in every demo you sit through.
One: accepting the words “we work with M-Pesa” without a live payment. Words are free; a prompt landing on your own phone is evidence. Any POS system with M-Pesa in Kenya worth shortlisting will say yes to that test on the spot.
Two: comparing subscription stickers and ignoring integration fees, setup charges and renewals. The whole stack is the price. Ask for it line by line before the demo ends.
Three: letting the team share one payment login. Shared accounts are how missing money loses its story. The POS system with M-Pesa in Kenya you pick should ship with individual accounts and levels turned on from day one.
Four: skipping the refund test. Refunds are the hardest flow in any payment setup, and a demo that avoids them is answering the question anyway. Watch one live, start to finish, with a name attached to the approval.
Five: ignoring failure behaviour. Cancelled prompts, timeouts and stuck payments are normal events, not scandals. Ask what each one looks like on the screen and in the audit log.
Six: not reconciling daily from the first week. The habit is cheap while records are clean, and painful once they rot. Start the evening ritual on day one, even in a quiet week.
Seven: treating the tax side as somebody else’s problem for later. Invoices, credit notes and payment records should agree from the first sale onward. Ten minutes of tax flow in the demo prevents a season of corrections after go-live.
Ten Questions to Ask Any Vendor
Walk in with this list, score every answer from one to five, and ask for the sensitive ones in writing. The scores turn a smooth demo into a comparable candidate. Numbers settle arguments that adjectives cannot.
Show me a live M-Pesa payment on my own phone, now. The yes or no is the first score.
What exactly happens when the customer cancels the prompt or the network drops mid-payment? Listen for pending states, retries and records, not reassurance.
How does the system match payments to sales — by reference, by amount, or by a human at the end of the day? Then ask who fixes the misses.
Can I watch a refund to M-Pesa, start to finish, including the approval and the audit record? Refusals are answers too.
What does the integration cost beyond the subscription — setup, per device, renewals? POS system with M-Pesa in Kenya pricing should survive this question without asterisks.
Where do M-Pesa transaction charges appear in my reports? Charges recorded as costs are management; charges missing from reports are shrinkage.
What happens to my payment records if I cancel the service? Export formats, timelines and exit costs, in writing.
Which connection do you actually use — STK push, till number or paybill — and why is it right for my volume? POS system with M-Pesa in Kenya vendors who explain trade-offs honestly are safer than those who only sell.
What does the system do during a power and internet outage, and how does the day’s money settle afterwards? Ask for the specific flow, with timings.
Can I call two customers of my size who switched this year? Any confident POS system with M-Pesa in Kenya vendor hands over references without being asked twice.
Lay the scored sheets side by side when the demos are done. The gaps show up fast. Choose the vendor whose answers you would be happy to explain to your accountant.
Frequently Asked Questions
Quick answers to what owners ask most about mobile money at the till.
How much does a POS system with M-Pesa in Kenya cost?
Expect three cost layers: the software subscription, a possible integration or setup fee, and M-Pesa transaction charges that belong to the network rather than the vendor. Ask for all three in one written quote, including the renewal price. Whole-stack numbers are the only ones worth comparing.
Do customers still get a prompt on their phone?
With STK push, yes — the payment request arrives on the customer’s phone with the exact amount, and they only confirm with their PIN. Other flows ask the customer to pay a number themselves and match the payment afterwards. Ask which one the demo is actually showing.
What if a customer pays but the till doesn’t record it?
Mature systems detect the orphan payment and offer a match against the open sale, with the fix logged. Ask the vendor to demonstrate this exact case in the demo. How orphans are handled is the difference between engineering and improvisation.
Can refunds go back to the customer’s M-Pesa automatically?
Yes, in capable systems, with an approval step and a trail back to the original sale. Same-day reversals are the cleanest route; older sales refund as new transactions. Watch one performed live before you believe it.
Does it work with paybill and till numbers?
Most integrations support till numbers well, paybill more loosely. Paybill money arrives into a collection account and often needs human matching, so ask who does that work and when. The honest answer tells you the daily workload.
Who pays the M-Pesa transaction charges?
The charges belong to the mobile money network, not the POS vendor. What varies is whether the system records them as costs in your reports. Ask to see where they land, because charges that vanish from reports become unexplained shrinkage.
Does it work when the internet is down?
Sales continue offline on cash or credit, and records sync when the line returns. M-Pesa payments need the network, so honest systems queue and reconcile them afterwards. Ask how a payment confirmed seconds before an outage gets matched.