Mobile Point of Sale (mPOS)

Mobile point of sale (mPOS) is a portable checkout and payment-acceptance setup built around a phone, tablet, handheld terminal, or mobile card reader. It lets a merchant record a sale and accept supported card or wallet payments away from a fixed counter.

An mPOS system can be as simple as an app paired with a reader or as integrated as a dedicated handheld device with inventory, receipt, and payment functions. “Mobile” describes the deployment model; it does not identify the processor, acquirer, payment network, or security standard.

Key Takeaways

• mPOS is a portable form of point-of-sale acceptance, not a separate payment rail.
• A mobile device may connect to an external reader or use supported built-in contactless capabilities.
• Consumer phones and tablets introduce device, app, wireless, loss, and update risks.
• Connectivity failure can leave transaction status uncertain even when the sales app remains available.
• Merchants should reconcile each mobile device, operator, sale, payment, batch, fee, and deposit.

Common mPOS Designs

COTS means commercial off-the-shelf. PCI Mobile Payments on COTS (MPoC) addresses security requirements for supported payment-acceptance solutions using smartphones or other commercial mobile devices. The name mPOS does not by itself establish that a product is PCI-listed or appropriately deployed.

How an mPOS Transaction Works

1. The merchant signs in to the approved sales or payment app.
2. The app records the item, price, tax, tip, discount, or service amount.
3. The customer presents a supported card, phone, wearable, or other payment credential.
4. The reader or mobile device captures payment data and applies the supported verification process.
5. The solution sends an authorization request through the gateway, processor, acquirer, network, and issuer path.
6. The merchant receives an approval, decline, or communication error.
7. The system issues a receipt and later submits eligible transactions for clearing and settlement.
8. The merchant reconciles sales, refunds, tips, batches, fees, and deposits.

Some business functions may work offline while payment authorization does not. A system should state clearly whether an offline status means “sale saved,” “payment queued,” or “payment approved under an offline rule.”

Worked Example: Field-Service Payment

A repair technician completes a $180 job at a customer’s home. The technician records the invoice on a company tablet and accepts a contactless card through the approved mPOS solution.

The device displays a communication error after the tap. The technician should not mark the invoice paid or request another tap until the system checks whether the first request reached the processor. Relevant evidence includes:

• employee and device identity;
• invoice and customer reference;
• amount, time, location, and entry mode;
• gateway or processor transaction ID;
• authorization, reversal, and retry status;
• electronic receipt; and
• settlement and bank-deposit record.

If the app stores the invoice offline, that does not prove the payment was accepted. If the first transaction was approved, an uncontrolled retry could create a duplicate payment.

mPOS vs. Nearby Terms

How to Evaluate an mPOS Setup

• Confirm the device, operating system, app, reader, and solution versions are supported.
• Determine whether the solution is listed or approved where required by the acquirer or payment program.
• Use managed business devices or define controls for any permitted personal devices.
• Restrict app installation, debugging, screen capture, local storage, and administrative access.
• Protect merchant credentials and require appropriate user authentication.
• Maintain device inventories, remote lock or wipe capability, and loss-reporting procedures.
• Secure Bluetooth, Wi-Fi, cellular, charging, and reader-pairing behavior.
• Test offline, timeout, reversal, duplicate, refund, and device-replacement scenarios.
• Reconcile by device, user, location, tender, processor batch, and deposit.
• Keep payment data out of notes, photos, texts, email, and unapproved support tools.

Risks and Common Mistakes

• Assuming every NFC-capable phone can safely accept payments.
• Installing merchant apps from an unverified source or leaving devices unpatched.
• Sharing one merchant login across multiple staff members.
• Losing a device that remains signed in or contains transaction and customer data.
• Pairing with the wrong reader or failing to verify reader custody.
• Confusing a saved sale with an approved payment during a network outage.
• Using public networks without the security controls required by the solution.
• Treating provider validation as proof that the merchant’s complete deployment is compliant.

Official Resources

• PCI SSC: Mobile Payments on COTS describes the MPoC standard and program for COTS-based payment acceptance.
• PCI SSC: Maintaining Payment Security outlines controls for devices, software, networks, and cardholder data.
• EMVCo: EMV Contactless Chip explains contactless payment interaction between compatible devices and terminals.

Applicable listings, device requirements, consumer protections, and merchant obligations depend on the solution, acquirer, payment brand, and jurisdiction.

FAQs

Related Terms

• Point of Sale: Merchant checkout event and sales-recording system.
• POS Terminal: Payment endpoint that can be fixed, portable, or integrated.
• Mobile Wallet: Customer-side wallet that can present a payment credential.
• Contactless Payment: Tap-based payment method supported by compatible mPOS solutions.
• Payment Gateway: Transaction interface used by many mobile and fixed acceptance systems.
• PCI DSS: Security standard relevant to covered card-data environments.

Educational Use

This article provides general financial education. It is not device, merchant, payment-security, legal, or compliance advice.