In-person payments
Select a device architecture for your product, then plan enrollment, transaction handling, testing, and rollout.
Choose the architecture
Start with the software environment and the customer interaction. Device appearance alone does not determine the integration. These are the documented NMI families; confirm the specific model, country, processor, and account configuration with Betterpay before ordering hardware. Product environment Device family Integration route Mobile contactless acceptance Tap to Pay on iPhone or Android Native mobile SDK Mobile chip, tap, or swipe VP3350 iOS / Android SDK Web-based countertop POS Lane/Series Customer-Present Cloud API Kiosks and self-service Self/Series Windows / Linux device SDK
Map your payment boundary
Recommended application design: keep order creation and fulfillment separate from the device interaction. Save a payment attempt before starting the reader so a restarted app can recover the relationship between an order and its transaction. device Create an order reference and calculate the payable amount from trusted product data. Associate the attempt with the merchant, location, and selected device. Display the device or SDK prompts while payment is in progress. Record the final gateway outcome and any required confirmation step. Release the order only after the payment workflow reaches the state your business accepts.
Design a recoverable experience
The following are application design recommendations, not gateway status names. Application state Recommended behavior Ready Allow a new attempt only when the assigned reader is available. Waiting for customer Show a clear amount and keep duplicate payment controls disabled. Outcome unknown Preserve the reference and reconcile before attempting another charge. Confirmed outcome Show the receipt or explain the next permitted action.
Prepare your rollout
Treat your first installation as a pilot with a reproducible device and app configuration. Keep an inventory of device identifiers, locations, software builds, and configuration changes. Exercise cancel, decline, device disconnect, app restart, and ambiguous-result recovery. Provide operators with a recovery path that does not rely on repeatedly pressing Pay. Reconcile the pilot against gateway records before expanding to more merchants. The device guides describe different SDK and Cloud API paths. Do not combine a mobile SDK confirmation flow with a Cloud API request simply because both collect an in-person payment.