Sola introduces cloud-driven card-present payments on PAX terminals

Sourced news briefing

Sola announced on 14 October 2026 that PAX is its preferred terminal platform and introduced Sola Terminal on supported PAX Android hardware. The company describes cloud driven card-present payments through a single software integration. Its release distinguishes launch capabilities from planned eWIC support and schedules demonstrations later in October. The following independent analysis examines terminal rollout, store operations and support. The announcement does not establish that every device, merchant category or regional configuration is automatically supported.

Independent merchant analysis: evaluate the store workflow first

A terminal replacement changes more than the device on a counter. Staff may need to initiate a sale differently, select a location, handle a cancellation or provide a receipt through another system. Before reviewing hardware features, map the current checkout workflow. Identify where employees wait, repeat information or ask a supervisor for help. The useful business case should address those actual problems rather than assume that a newer terminal necessarily improves every interaction.

Consider a hypothetical retailer with a fixed checkout and a mobile sales assistant. The two roles may need different device placement, charging arrangements and receipt options. A shared software platform can simplify some administration while leaving those physical differences intact. Test the proposed devices in the actual setting, including counter space, customer reach and staff movement. A demonstration in a quiet meeting room does not reproduce a busy store.

The product catalogue also affects payment operations. Returns, discounts, split orders and tax adjustments should reach the terminal with the correct amount. The customer should see what they are approving, and the till should receive a reliable result. If staff manually rekey amounts between systems, identify the resulting error risk and reconciliation work. Integration value is strongest when it reduces those specific gaps without obscuring the sale record.

Independent merchant analysis: know which device is receiving the request

Cloud control makes the connection between software and terminal a central operating question. A payment request should reach the intended device at the intended location. Businesses need a clear inventory linking terminal identity, store and checkout position. Staff should understand how to recognise the correct device before presenting it to a customer. A naming convention that makes sense to engineers may be confusing to a cashier managing several counters.

Moving a terminal between locations should follow a supported procedure. The business may need to update assignments, verify connectivity or confirm the correct merchant configuration. Do not assume that physical movement is the only required step. Test a planned relocation and document what store staff can do themselves. This reduces the chance that a replacement device appears functional while sending records to the wrong location or creating support confusion.

Access to device management should be proportionate. A cashier may need to take payment, while a manager can authorise refunds and a central team controls configuration. Define those roles before deployment. Shared credentials can make it difficult to identify who changed a setting or initiated an adjustment. The actual permission model should be reviewed with the provider, including how access is removed when an employee changes role or leaves.

Independent merchant analysis: prepare for connectivity problems

An internet connected checkout needs an explicit response when connectivity fails. Ask which functions remain available, which transactions must stop and what staff should tell customers. Do not assume offline acceptance from the presence of a physical terminal. The supported behaviour depends on the device, software and acquiring arrangement. Store instructions should reflect that actual configuration rather than a generic belief that a terminal always works independently.

Uncertain results are particularly difficult during an outage. A customer may have interacted with the device while the till has not received confirmation. Staff need a method to check the original attempt before requesting another payment. A second charge can turn a brief interruption into a refund complaint. Include this scenario in training, with the precise support route and evidence required to establish the transaction's state.

Power, charging and local network arrangements are ordinary but important dependencies. A mobile device needs a place to charge and a process for replacing a depleted unit. A fixed checkout needs reliable cabling and a clear response to a local equipment failure. These issues are not solved by centralising software. Assign store responsibilities so small physical problems do not become prolonged payment interruptions during peak trading.

Independent merchant analysis: manage the hardware lifecycle

A deployment plan should identify supported models and the period over which the provider expects to maintain them. Ask about software updates, replacement procedures and end of support communications. Avoid treating a hardware standard reference as a complete guarantee of future suitability. The merchant needs confirmation for its specific device and configuration, including any relevant obligations communicated by its acquirer or service provider.

Receiving and replacing devices should be controlled. Keep an inventory, record which unit was issued to each location and train staff to report an unexpected replacement request. The business should use the provider's authorised supply and support routes. These are practical asset management recommendations, not allegations about the announced hardware. A reliable inventory also helps finance and operations understand spare stock, repair costs and deployment progress.

Update timing should reflect the store's operating hours. A centrally managed change may affect several locations at once. Ask how releases are tested, communicated and recovered if a problem appears. A phased rollout can reveal workflow issues before every checkout is affected. The merchant should know which team decides whether to continue deployment and how stores report evidence without relying on informal messages that are difficult to track.

Independent merchant analysis: test more than an ordinary sale

A useful acceptance plan includes a completed sale, a customer cancellation, a declined attempt, a refund and an uncertain response. Where the business uses additional supported functions, test those separately with the approved configuration. Keep planned future capabilities outside the launch checklist. A feature appearing in a roadmap should not become part of staff training or customer advertising until the provider confirms that it is available for the merchant.

Finance should reconcile activity by store, terminal and business date using the reports the operation will actually receive. Examine how a late transaction or refund appears in the next day's reporting. If the till and payment platform use different cutoffs, document the difference. Otherwise a technically successful deployment may create recurring reconciliation questions that staff mistakenly attribute to missing payments.

Measure the effect on customers and employees after launch. Checkout duration, uncertain results, supervisor interventions and support calls can reveal whether the new arrangement helps the store. Compare similar trading periods rather than attributing every change to the device. Use feedback from cashiers as well as central teams. They often see the practical friction that a successful payment demonstration and an aggregate transaction report cannot show.

Include receipt readability in the store trial. Customers should be able to identify the merchant, amount and purchase reference without needing staff interpretation. Clear receipts also help support locate a transaction when a customer returns.