Handheld payment processing lets a technician, market seller, or mobile business collect payment where the work happens. The choice involves more than a small device: the app must connect the charge to the right sale, handle interruptions, and leave a record that can be reconciled later.
Start with the whole field visit. Confirm the invoice amount, present the payment method, check the result, issue a receipt, and match the transaction to the job. Then test what happens when the signal drops, the customer changes their mind, or the device is lost.
Compare three ways to accept a card in person
On a small screen, scroll the table sideways to read all columns.
| Setup | Useful when | Check before choosing |
|---|---|---|
| Dedicated handheld terminal | Staff need a device devoted to payment and possibly receipts or an integrated sales app. | Supported payment methods, battery life, cellular plan, app integration, and replacement service. |
| Phone or tablet with a separate reader | The job or sales app runs on an existing mobile device. | Reader pairing, supported phone models, two batteries, connection recovery, and a secure carrying setup. |
| Tap to Pay on a supported phone | Contactless acceptance in the phone’s payment app fits the customer and workflow. | Device, operating system, country, app, card and PIN support, and a fallback for unsupported payments. |
Tap to Pay turns a supported merchant phone into a contactless acceptance device; a customer wallet app is a different role. Apple’s Tap to Pay on iPhone guide describes acceptance through participating payment apps without an additional reader. Availability and requirements depend on the supported device, app, and market. A phone’s ability to pay at a checkout does not establish that it can accept business payments.
A payment link or keyed entry is another workflow, not an automatic equivalent to an in-person tap or chip transaction. Ask the provider how each method affects fees, fraud controls, evidence, and dispute handling. Choose a fallback deliberately rather than asking staff to photograph cards or write down card details.
Distinguish poor signal from approved offline operation
Wi-Fi, cellular service, and a paired reader are different connections. A phone may still communicate with its reader while lacking internet access. A terminal may have Wi-Fi but no cellular plan. Test at the actual work locations and document which status indicator staff should trust.
Some supported systems securely store offline transactions and forward them when connectivity returns. That is not the same as receiving a final successful payment result. Stripe’s Terminal offline-payment documentation shows both the local storage stage and later success-or-decline response. Its support varies by payment method, reader, and integration; the fact that one configuration supports offline operation does not make another eligible.
Before enabling offline acceptance, confirm the provider’s limits, reconnection deadline, supported cards, prerequisites, and allocation of losses if a transaction cannot be collected. Set your own exposure limit per transaction and per device. Train staff to distinguish an offline record from an online approval, and check pending records after reconnection. Do not reinstall an app or reset a device containing unforwarded payments without following the provider’s instructions.
If the arrangement does not support offline acceptance, use an agreed alternative such as a later invoice through the approved system. Tell the customer what happens next. If a result is uncertain, look up the original transaction before trying again; a second attempt can create a duplicate charge.
Worked example: the transaction mix changes the cost
Invented pricing, not a provider quote: assume 200 monthly transactions averaging $75, a fee of 2.5% plus $0.10 per transaction, and $30 per month for software. Monthly payment volume is $15,000. The modeled cost is ($15,000 × 0.025) + (200 × $0.10) + $30 = $425, or 2.83% of volume.
If the same $15,000 instead comes from 600 transactions averaging $25, the model becomes $375 + $60 + $30 = $465, or 3.10%. The fixed per-transaction charge explains the difference. Hardware purchases, data service, taxes, disputes, currency conversion, refund-related charges, and other contract fees are excluded from both examples.
Request a comparison using your actual payment methods and transaction sizes, including keyed or online payments if used. Separate device purchase or rental, software, processing, settlement options, and support. An advertised percentage alone is not the complete operating cost.
Follow the payment through to the bank
A successful authorization, capture, provider balance, and bank payout are distinct stages. Timing depends on your provider and configuration. Stripe’s payout documentation distinguishes settlement timing from the payout schedule; check your own processor’s terms rather than assuming money is available as soon as the terminal approves a sale.
Store the processor transaction reference with the job or order number. Reconcile gross charges, refunds, fees, adjustments, and the resulting payout, allowing for timing differences. A bank deposit may combine multiple trading days or exclude funds that are still pending. Do not mark an entire invoice paid solely because a payment attempt was created.
Restrict refund permissions and use the original transaction when the provider supports it. Check the amount remaining available to refund and record the reason. Explain the expected refund timing without promising an exact bank posting date. When staff report a duplicate, verify both transaction states before issuing a correction.
Test the field workflow before rolling it out
Ask your acquirer or processor which approved hardware, software, and configuration apply to the setup. PCI SSC’s Mobile Payments on COTS standard addresses payment acceptance using commercial devices such as phones. A standards claim about one component is not a substitute for verifying the deployed solution and your merchant responsibilities.
Pilot a normal sale, a declined payment, a lost connection, an uncertain result, a refund, end-of-day reconciliation, and a lost-device response. Use provider test facilities for controlled failure tests, then a small authorized live transaction and refund to confirm the real funds flow. Check receipts, job references, role permissions, device locks, updates, and spare power.
Write a short field checklist that a person can follow under pressure. The best setup is the one whose ordinary operation and failure paths your staff can understand, not simply the device with the most features.