API
Log In Support
  • Clear

    • Get Started

      • Overview

      • Platform Sign Up

      • API Basics

    • Integration

      • Setup Platform

      • Onboard Merchants

      • Enable Merchants

      • Process Payments

      • Payout Merchants

      • Manage Payment Operations

      • Test and Launch

  • Link

    • Get Started

      • Overview

      • Platform Sign Up

      • API Basics

    • Integration

      • Setup Platform

      • Onboard Merchants

      • Process Payments

      • Manage Payment Operations

      • Test and Launch

    • CARD PRESENT SOLUTIONS

      • Get Started

        • Overview

      • Terminals

        • Acquire Terminals

        • Onboard Terminals

        • Authorize Cards

        • Process Payments

        • Test and Launch

      • Mobile Card Readers

        • Build Mobile App Prerequisites

        • Acquire Mobile Card Readers

        • Pair A Device

        • Authorize Cards

        • Process Payments

        • Test and Launch

      • Card Present Resources

        • Provide Receipts

    • API Reference

    • Resources

      • Payment Life Cycles

      • Server to Server Integration

      • Platform Legal Certification

      • Security Certification

      • Risk Certification

      • CIP and KYC Certification

      • Card Network Rules

      • Disputes Deep Dive

    • Cookbooks

      • Build Payment Support Tools

      • Reporting

      • Implement Merchant IC+ Pricing Model

      • Recurring Billing

      • Level 2 & Level 3 Processing

      • Style Credit Card iFrames

      • Support Merchants Outside the United States

      • Connect Merchants With SSO

      • Design A Retry Strategy

    • Release Notes

Home / Card Present / Mobile / Build Mobile App Prerequisites

 

Build Mobile App Prerequisites

In This Section
  • Firmware Updates
  • Receipts
  • End User Interactions
  • Permissions
  • Battery Level
  • Volume
  • Unsupported Devices
  • Orientation

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:

✓ applicable
✘ not applicable

Item to Configure RP457c AudioJack Moby 5500
Firmware Updates required
Receipts required
End User Interactions ✓ ✓
Microphone Permissions ✓ ✘
Location Permissions ✓ ✓
Notification Permissions ✓ ✘
Battery Level ✓ ✓
Volume ✓ ✘
Unsupported Devices ✓ ✘
Orientation ✓ ✘

 


Firmware Updates

 

Occasionally (0-1x per year), Ingenico will release a required firmware update in response to security patches, updated card network rules, etc, which cannot be resolved via the SDK. Your mobile application must provide merchants with a UI to download and install firmware updates.

Use the firmware update version and category parameters on the card reader info method in the SDK to know when a firmware update is required. The category parameter will contain one of none, recommended, or required. When a new version is required, begin your own testing and development on the new version, release any changes needed, and then make the update available to your merchants.

Firmware updates are almost always optional (recommended category), and upgrading in those cases is up to you. WePay does, however, highly recommend being on latest version as much as possible to take advantage of enhancements and fixes.


Receipts

 

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.

For further receipt requirements, see the Card Present receipt guide, and the Card Present card network rules regarding receipts.

Signature must be collected on electronic and paper receipts for NFC/contactless transactions. In addition, merchants who accept tips and/or wish to validate the terms of sale (such as “all sales final”) are encouraged to collect signatures on receipts.


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.


Permissions

 

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

 

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

 

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.

Notifications

 

As outlined in the Card Present SDK package, collect notification permissions in order to perform bluetooth pairing on this device.


Battery Level

 

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.


Volume

 

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.

Warning

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.


Unsupported Devices

 

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.


Orientation

 

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.

 


Next Up: Acquire Mobile Card Readers

Acquire Mobile Card Readers and develop user flows.

  • Evaluate hardware offerings
  • Decide how to fulfill merchant orders

 

Acquire Mobile
Card Readers

 


Questions? Need help? Visit our support page!

Company

  • About
  • Careers
  • Blog
  • News & Events

Resources

  • Knowledge Center
  • Terms of Service
  • Privacy Policy
  • Security
  • Support

Developers

  • Documentation
  • Engineering Blog

Customers

  • Case Studies

Product

  • Link
  • Clear
  • Core
  • Contact Sales
© 2020 WePay Inc.