VP3350 mobile reader integration
Plan an iOS or Android reader integration with pairing, SDK events, confirmation handling, and a tested operator recovery path.
Prepare the reader and account
VP3350 supports encrypted chip, contactless, and swipe acceptance through the mobile SDK. Enable Encrypted Devices and create an API-source key. Select the correct Bluetooth, USB-C, or Lightning reader variant for the host. device
Install and connect
The reviewed SDK prerequisites are iOS 17.4+ or Android 12+. The package supplies sample applications and dependencies. On iOS, the accessory protocol is com.idtechproducts.neo. Android USB attachment requires granting device access. Charge the reader before the first connection. Initialize the SDK and configure the key, application identifier, and reader selection. Discover the reader and connect/configure it before starting payment. Handle SDK prompts and transaction completion callbacks. Confirm approved transactions when required, or void according to the transaction outcome.
Account for device behavior
A battery-powered VP3350 sleeps after 30 idle seconds; USB power maintains its connection. When changing from Lightning to Bluetooth, disconnect the Lightning reader first. Do not assume a previously selected reader is still ready when the user returns to checkout. Recommended: refresh readiness before enabling Pay.
Build the transaction state machine
Recommended application design: model device interaction and order fulfillment separately. The cashier may finish a screen action while the SDK still has a payment workflow to complete. Application responsibility Recommended implementation Prompt presentation Render the current SDK request without substituting an approval message. Order correlation Save your reference before device interaction begins. Confirmation failure Keep the payment attempt recoverable and reconcile it. Connectivity failure Avoid automatic replacement charges while the outcome is uncertain. Receipt handling Record delivery status separately from payment status.
Test and release
Gateway Test Mode avoids real processing. Production preparation includes TMS settings, device permissions, and reconciliation for any enabled deferred-authorization queue. Recommended: test permission refusal, Bluetooth loss, cable removal, reader sleep, and app restart. Recommended: repeat checkout with the exact handset/reader combination used by merchants. Recommended: pilot with staff who did not build the integration and observe whether recovery instructions are clear. Recommended: compare completed orders, confirmations, receipts, and gateway records before rollout. Offline or deferred processing is not a generic fallback for every failed connection. Enable it only with an agreed product policy and tested reconciliation behavior.