Build Mobile App Prerequisites
This section is specific to integrating mobile card readers with your mobile application, and describes how to configure your mobile app to work with card reader hardware. Your mobile app will need to configure the following:
✘ not applicable
|Item to Configure||RP457c AudioJack||Moby 5500|
|End User Interactions||✓||✓|
When building your mobile app, consider any and all end user interactions which processing a transaction may involve. For instance:
- Signature collection
- Adding tip
- Attempt a new authorization
All the interactions which you plan for end users to engage in must be built into your app’s UI.
Your mobile app will need to obtain certain permissions from the user’s mobile device in order to work with mobile card readers. The details of this are somewhat specific to iOS and Android.
Microphone permission is required to access the audio jack. If your app does not request audio jack permissions up front, and then at some point decides it does want to offer the RP457c AudioJack, your app will need to be re-released.
The way permissions are presented to an app user are specific to iOS and Android:
- iOS: User will be prompted for permission the first time your app starts the card reader.
- Android: Before Android M, users will not be prompted. Starting from Android M, you will have to include code to prompt the user for permission before starting the card reader.
The card reader won’t work if users decline microphone permission, so your mobile app should implement blocking UI to prevent mobile app use without microphone access, and explaining why microphone access is needed.
Location permission is optional, as you may turn it off at any time. That said, WePay relies on location as part of our fraud detection tools, which include noting a device’s location when transactions are made.
Although technically optional, not getting this significantly hinders WePay’s risk management ability. Please discuss with your account manager if you are not able to provide this permission.
As outlined in the Card Present SDK package, collect notification permissions in order to perform bluetooth pairing on this device.
The Card Present SDK provides battery level information. You should provide some way in your app to show users what the current battery level is.
If your app programmatically enables speakerphone mode, then you must ensure that the speakerphone is turned off before starting a transaction. Otherwise, the Card Present SDK manages volume on the device so that the audio jack connection functions. It automatically increases volume levels for best performance.
When a transaction is started, a (normally inaudible) signal is sent to the headphone jack of the phone, where the reader is expected to be connected. If headphones are connected instead of the reader, they may emit a very loud audible tone on receiving this signal.
Because the RP457c AudioJack connects via audio jack, there may be two issues to consider, depending on the mobile device (phone or tablet) your merchant is using :
- No audio jack: generally an adapter will work. WePay has tested the iPhone 7 adapter supplied with the phone and it works. WePay is continuing testing on other models and will update documentation accordingly.
- Volume: Each device has different volume levels. The WePay Card Present SDK includes profiles for many devices. However, there is always a chance that a new phone model is not supported yet by the Card PresentSDK. In the case of Android, there are many more devices than ROAM can reasonably test and profile. For this reason, there is a calibration ability within the WePay Android Card Present SDK that allows users to profile their own device. This almost always leads to supporting a device.
WePay cannot guarantee support with devices not on ROAM’s support list, but WePay does work closely with ROAM to get the latest devices profiled and added to the WePay Card Present SDK.
The audio plug is near the side of the device, and mobile devices vary where the headphone jack is located. As a result, the device may naturally face “forward” or “backward”. This can lead to inserting the card for swipe or dip backwards.
WePay suggests that partners take note of the orientation on the most common mobile devices, and visually indicate to users the right way to swipe/dip, perhaps as part of a first time use experience.
Receipts are required for card present payment processing.
Electronic receipts can be delivered via email or phone, which your platform must build into your mobile app UI.
Paper receipts require the use of a receipt printer, and there are bluetooth options available on the market.
Next Up: Acquire Mobile Card Readers
Acquire Mobile Card Readers and develop user flows.
- Evaluate hardware offerings
- Decide how to fulfill merchant orders
Questions? Need help? Visit our support page!