Application Review Process
| Issues to be avoided
| Application Development Best Practices
| Consumer Enrollment
Application Review Process
The Application review process includes a set of automated and manual verifications.
Automated verification covers tasks such as:
- Verification of application package signing
- Checking application package size and structure
After successfully passing the automated verifications, application is added to the review queue. If the application fails the automated verifications, an email notification with the details about the failure are sent to the Developer Admin who did submit the application.
Manual application verification process may cover tasks like:
- Security test to ensure the app doesn’t include any malware code
- Stability test to ensure the app doesn’t crash
- Performance test to verify the app doesn’t slow down the terminal
- Functional test to verify documented application features
- Quality, verifying the application provides positive end user experience
- Interoperability test to verify the app can be installed and run on targeted devices
- UI checks to verify that the application UI follows the UI guide lines, and the app does not include inappropriate language or images
- Verifying app complies with the legal requirement
Manual verifications will be carried out by two Verifone employees independent of each other. Both reviews must pass to publish the application.
After manual verifications are completed, the application is ‘Verifone signed’ and published in the Marketplace. Entitlement Services production environment will be set up for the application. An email notification will be sent to the Developer Admin to confirm app has passed certification and is published.
During the application review the application will be installed and run on a device. In order to use the application features, in connection of application submission developers are requested to provide test credentials to the application
The application review process for Android app also focuses on some Android specific scenarios. There are few customizations to be made on the Android applications based on the guidelines listed at Android App Requirement
section. The Android manifest file is supposed to follow some rules mentioned on Android Manifest Requirement
The application version value from the Android Manifest file should match with the version in the cp-conf folder's manifest 'appName.mft'.
If the application fails the certification process, an email notification will be sent to the Developer Admin with details about the failure.
Be prepared for application certification to take a while, up to two weeks depending on the app submission queue. If you have a certain deadline to be met, contact Verifone Developer Support in advance to schedule timely application review.
Issues to be avoided
While preparing for the application review please check how to avoid the most common issues found during the app reviews.
Developer shall provide adequate instructions for the merchant to use the application. Most common issues are related to how to configure the app before taking it into use, and how to use the application features. If the app user guide is large in size, app description in the app submission for should include a url to access the full user guide
Developer must ensure that the application includes all the features that the user guide, application description, screenshots and other documentation describes
Running the application in a DevKit
If your application is large in size, recommendation is to test the application in the DevKit device to ensure application does not crash in the target device. Verifone terminals have some limitations that pure Android or Linux devices may not have, and this may cause surprises
Android Manifest File
Verifone is intentionally restricting the use of Android configurations that can result on poor end user experience. Please study in detail related requirements here
Handheld use not designed
Application activity recreated when Carbon 10 device is raised from the base disrupting the ongoing user action. To prevent unwanted interruption follow the Google guidelines, more info here
Developer shall verify content on each application UI view is readable, and buttons and links are actionable. Especially if one is porting the app from other platforms into Verifone devices like mobile Android apps on Carbon 10/8 devices one shall verify app Ui is properly scaled for the larger display on the Carbon device
Developers usually have a test or staging environment for thei backend solution that is used during application testing. When submitting the app to be published in the Marketplace, on must ensure the app is using the production backend services.
Applications shall not unnecessary delay the payment flow. This is especially important in solutions like quick serve restaurants. As app design guidelines app shall not wait consumer input more than 3 seconds. If consumer has not given input within this timeframe, Terminal Commerce Application shall hand over responsibility back to the payment application.
If longer timeout value is preferred, merchant should be offered option to adjust it for example by including timeout configuration on app functionality behind the manual launch trigger. Default timeout setting should be three seconds.
Triggers having word "request" in the trigger name require a response notification to be sent to the payment application. Also in case the Terminal Commerce application does not take any action, the notification must be sent. Otherwise the payment flow may be delayed as the payment application waits for the response notification although the Terminal Commerce application has already exited. Developer must ensure that every exit point is covered, notification is sent before the exit command is executed.
Application UI not aligned with the payment application UI
Verifone will ensure smooth consumer experience. 3rd party applications should seamlessly blend within the payment flow. 3rd party applications shall follow the Verifone UI guidelines, for example to use the same touch buttons as the payment application is using.
HTTP error codes
In case of error situation, 3rd party application should provide user info about the encountered issue to help service personnel to assist merchant. As an example in case of connectivity issues the received HTTP error code should be shown to the user.
Application Development Best Practices
Check list for the App Submission Form:
Verifone UI Design Guidelines
- App’s name must be unique, not an existing well-known brand name owned by another company
- Provide accurate and appropriate descriptions; ensure that the content has no inappropriate language or spelling errors and describes the app well
- If your app uses cryptography and its use is not limited to the items listed in the app submission form, you must provide additional information for an accurate legal review of the app
- Support email address provided must be owned by the company publishing the app
- Website provided must exist and be owned by the publisher
- Phone number provided must be valid and must include the country code
- App icon must be unique to the company/app, not an existing well-known brand logo owned by another company
- App’s screenshots must describe the app’s primary functionality. Note: Inappropriate content shall not be included in the app
- App must include functionality defined in the app’s description and screenshots
- App should not contain prohibited permissions/actions in android manifest files.
- Developer should provide test credentials for the application if necessary.
- In order to review complete app flow, submission form should include proper & detailed description of the app.
should be followed:
- Transitions between the Payment and Terminal Commerce Apps must be seamless; the look and feel between the two must be aligned
- Make sure the UI elements and icons used are commonly used and easy to understand elements; for a standard UI behavior, make sure you don’t replace default UI elements with completely different elements
- Avoid redefining expected functions; example, blue button being used for negative actions like canceling and declining
- Notifications presented to the user must not include content unrelated to the app’s functionality
- App shall not include inappropriate or offensive content in text or images; there shall not be any typos or spelling errors in the content either
- Images and UI elements used must fit within the screen, or be seen via scrolling, at all supported display resolutions
- App’s functionality and UI must feel consistent across all supported display resolutions
- Application should ensure the device UI is updated at least once before time consuming JS execution, like use of XMLHTTPRequests, is started. This to indicate to the consumer application is running
The application should have a high quality level
- App should not crash on a simulator, on a test or payment terminal
- App should not unnecessarily slow down the payment flow
- App should not be unresponsive; users should be able to use the terminal within reasonable timeouts
- App should be able to make connection to external services, if those are used
for Commerce Application development should be followed:
- Application must add value to the consumer, merchant or estate owner, it must implement meaningful use case(s)
- App package must pass a virus scan
- Terminal Commerce App must only use external connections documented in the app submission form
- App must have proper timeout handling: timeouts specified for functionality where input is expected (by user, from network)
- App must exit accurately at all exit points
- Terminal Commerce App must not store large amounts of data in persistent storage; it's recommended to store a few tens of kBytes, not hundreds of kBs
- Terminal Commerce App must not store large amounts of data in ARGV array as this may cause issues with the app performance, Simulator usage and terminal memory consumption
- Resolution of used images must not be higher than the target device’s display resolution
- Trigger response must be sent before exiting the app; ensure the response payload format is correct
- App must verify the HTTP error codes it receives and show the error code to the user to help with debugging
- Users must not be confused to give credit/debit card number or card PIN number at any point
- Dynamic content is not allowed on Terminal Commerce apps; app must not try to fetch dynamic prompts through cloud data
- All software components included into the app must be useful; all unnecessary content must be removed
- Follows the OWASP secure coding principles; for further information on web application vulnerabilities and how to protect against them, visit OWASP "Top Ten"
- Handles errors gracefully and implements retries accurately; in particular, implement retries for a maximum of two times for infrastructure errors
- Limits the volume of data returned by asking only for the required information and doesn't make unnecessary calls
- Doesn't leak information about their configuration, internal workings, or expose privileged information through improper error-handling methods; attackers use these weaknesses to steal sensitive data or compromise the system altogether
- Complies with relevant laws and regulations corresponding with collecting consumer information
- Doesn't ask consumers to provide confidential information such as credit card details, social security number
- Doesn't echo characters inserted in the password or sensitive input fields; use of the 'password' attribute is recommended
- Authentication credentials should encourage use of strong password/passphrases
- Changing password functionality must require submission of the old password
- All authentication decisions should be logged with relevant metadata needed to pursue a security investigation
- Application must not contain sensitive business logic, plain text hardcoded secret keys or other proprietary information in its own code or directories as the confidentiality of the source code once installed on a device deployed on the field is not guaranteed
- Application must protect and encrypt all credentials used for accessing external services
- Application must declare each form with the attribute autocomplete="off" to avoid data from being cached and repurposed
Don't use the triggers and APIs for following purposes:
- Collecting statistical data to be used by anyone else than the user, unless user has given permission to share the data
- Deriving, completion, or success rates, unless the information is specific to the user logged into your application and only for that user's view
- Display a user's profile unless the information is specific to the user logged into your application and only for that user's view
Consumer Enrollment :
Applications should implement two-step process for enrolling /subscribing:
On the payment terminal the consumer can be offered an option to enroll, UI screen shown to the customer shall not indicate that it is mandatory to join.
- If the consumer decides to join, the application shall ask consumers phone number or email address.
- Consumer shall receive a SMS/email with a link to the full terms and conditions, as well a link to opt out.
- Enrollment shall not be completed before the consumer accepts the terms and conditionsIf enrolled customers will receive offers/ads via SMS/email, the app should inform the consumer during the enrollment about this.
On the application developer web site there shall be function to cancel enrollment by inserting the phone number or email address that was used to enroll
Consumers should have capability to opt out from receiving offers and ads, but can still remain enrolled.