Thank you for choosing our API for integration ! The goal of this documentation is to describe how you can connect to a payment app running on Android devices and the GP tom app. This API should help you easily integrate Android-based apps developed in-house. We believe that using our API will get you integrated in no time.
Prepare everything you need
Go to the "Downloads" section of this guide to download the latest application packages, demo applications and the AIDL library. The goal of the GP tom simulator is to avoid the need for test cards and to help simulate all payment outcome cases you may encounter in a production environment. We note that API is identical in test and production.
Currently, by sending an exact amount from your application, you can simulate the following behavior:
CARD SALE SUCCESS ACCEPTED
Your application receives a successful outcome of the transaction and successfully processes the transaction on your side.
CARD SALE FAIL DECLINED
Your application receives a negative transaction result and you process the transaction in the correct way on your side – you will see that the transaction has failed.
CARD SALE FAIL TIMEOUT
There will be a time out of payment on our part and in this spirit your application must display the result.
CARD SALE FAIL EXCEPTION
It simulates a situation where an exception occurs on our part – e.g. a technical failure. This is how you need to promote the result to the user.
Demo client application
If you'd like to see how integration with a 3rd party app works, you can download a demo client package that also includes source code that can help you understand how integration can be done on Android.
The AIDL library ensures communication between your application and ours – you need to add it to your development project. You can find the latest version in the download section.
The transaction flow is very similar for all transaction types and consists of the steps described below. To understand the sent payment results that can be received from the GP tom application, please refer to the "Return Codes" section of this chapter. In simplified terms, the transaction flow looks like this:
Before you can call in GP tom any request, you must make sure the user is logged in. All requests are then handled under the logged in user.
NEW Since version 1.2.0 of this API you can check the identity of the logged in user by sending the "clientID" value. Please refer to this article for more details and use case.
NEWS For Android 11, please make sure you take care of the visibility of the package – read more here. Otherwise, the app won't open automatically.
A bound service is a server in a client-server interface. A bound service allows components (such as activities) to bind to a service, send requests, receive responses, and even perform interprocess communication (IPC). Typically, a bound service persists only when it serves another component of the application and does not run in the background indefinitely. For more information on how to work with bounding services, visit the Android Developer Portal here - Bound Service.