• Features
  • Shop
  • Pricing
  • User Guide
  • Support
 0 Kč
Login / Registration
  • CS
  • RO
  • DE
  • SK
  • HU
  • PL
  • EL
  • Features
  • Shop
  • Pricing
  • User Guide
  • Support
  • CS
  • RO
  • DE
  • SK
  • HU
  • PL
  • EL
BUY

API

  • Transaction Sales (iOS)

Introduction

  • Before you begin
  • Receipt visual
  • Download
  • Legal Disclaimer
  • Integration support
  • Certification & Test Scenarios

app2app API

  • Introduction to app2app API
  • 1. Transaction registration
  • 2. Payment Request [transactionRequestV2]
  • 3. Get the status of the transaction
  • 4. Get transaction details
  • Code examples
  • Return codes
  • Check the installed application
  • Client ID
  • Settings in Android
  • Release notes

Cloud API

  • Introduction to Cloud API
  • Transaction flow
  • Transaction sale
  • Transaction cancellation
  • Close batch
  • Master API account

iOS API

  • Transaction Sales (iOS)
  • Transaction Cancellation (iOS)
  • Day close execution (iOS)
  • Introduction to iOS API
View Categories
  • Main page
  • User Guide
  • API
  • Cloud API
  • Introduction to Cloud API

Introduction to Cloud API

The goal of this API is to run tasks from any external device or cloud solution in the GP tom application. We expect that it will allow you to connect almost any solution to GP tom over the Internet. Cloud API works by allowing you to use API to create end-device tasks with the GP tom application. For now, you can use transactional tasks, but other types of tasks will be available in the future.

Meaning of tasks

The meaning of a task within this API means that you can create an unlimited number of tasks that will be processed by the GP tom solution (backend + frontend). The goal of the payment device (terminal or mobile phone) is to complete the task. However, the result of the task is in no way related to the result of the payment. It only tells that the task is in progress, completed or failed.

Why do we use tasks?

In our solution, you can create many tasks for one terminal in parallel. We believe this method can be beneficial for some use cases where requests can be generated from more than one location. Thanks to this, we are able to receive tasks at any time and manage the queue on the end device by the user (not valid in semi-integrated mode).

How to use the cloud API

There are two use cases for how you can work with Cloud API on an endpoint device:

Assisted mode

Applies when the user operates the device and selects the job to be processed by GP tom . Once the new task is sent to the device, a push notification will be displayed if the application is running in the background. When the user taps on it, the activity is immediately triggered. Either way, the list of tasks available in the app can be used to manage them.

Automatic mode

Applicable when the device is located opposite the dealer (like a classic POS terminal connected to the cash register). If the application is permanently in the process, the tasks are processed automatically – as soon as the device receives the task, it is automatically processed (if there is no other activity – in this case, the task is processed immediately afterwards).

But in principle, it is up to you which case suits you better. The difference is only in the use of application.

What tasks do we support

At API we support the following tasks. We believe they will be sufficient for your needs. We recommend implementing all three of these types.

Sale

A sales transaction is used when you want to immediately charge the cardholder's card for the goods or services you purchase.

SALES FLOW

Transaction cancellation

Use this feature to cancel a sales transaction that has already been made. You can cancel any card transaction within 93 days of the original date. This method is not applicable to cryptocurrencies.

CANCELLATION FLOW

Close batch

The purpose of the batch is to consolidate the volume of transactions into one package. Closing the batch checks that the terminal and the authorization host have the same sum of transactions. When you start the close day, the authorization center closes the existing batch and opens a new one.

CLOSE DAY FLOW

Since we try to provide you with the most detailed specification, a basic summary can be found on this portal, for more details and the possibility of testing some methods, you can find advanced specifications under the link below.

LINK TO DETAILED DEFINITION

Transaction progress

To give you a better overview of how task and transaction progress is used, below you will find the lifecycle of tasks and transactions:

Steppe
Description
Task status
Transaction detail
1
Once the system successfully accepts the task (content, the format is correct). The task is forwarded to the device.
CREATED
NOT AVAILABLE
Steppe
Description
Task status
Transaction detail
2
The device starts the payment part. If successful =INIT_OK if an error occurs, the INIT_ERROR is displayed.
INIT_OK INIT_ERROR
NOT AVAILABLE
Steppe
Description
Task status
Transaction detail
3
When the transaction is successfully initiated, the IN PROGRESS status is returned. Includes transaction screens (card touch, authorization, result). If the user cancels the payment process, the status changes to CANCELLED. If any error occurs during the transaction, the ERROR status is used.
IN PROGRESS CANCELLED ERROR
NOT AVAILABLE
Steppe
Description
Task status
Transaction detail
4
Once the transaction is completed with any result (approved, rejected), the job status changes to COMPLETED. Only when the status of the job is COMPLETED, you can request transaction details and its outcome.
COMPLETED
STATUS AVAILABLE

Below you will find a guide on what the next step should be based on the status received:

Status
Description
How to behave
CREATED
Your task has been created and will continue - IN PROGRESS
call GET /v1/tasks/{taskID} to update the status until completed
Status
Description
How to behave
INIT_OK
The payment process has started successfully and the payment can begin.
call GET /v1/tasks/{taskID} to update the status until completed
Status
Description
How to behave
INIT_ERROR
The payment process failed to initialize. Check for the error you received.
Follow the error instructions.
Status
Description
How to behave
IN PROGRESS
Task processing is in progress. Possible output can be: CANCELLED, ERROR or COMPLETED.
call GET /v1/tasks/{taskID} to update the status until completed
Status
Description
How to behave
CANCELLED
The job was canceled by the user.
you should run a new task because the task was canceled by the user
Status
Description
How to behave
ERROR
An error occurred while processing the job.
Follow the error instructions.
Status
Description
How to behave
COMPLETED
Once you get this status, your task has been completed and the result is available.
you should continue with TRANSACTION DETAIL
How do you like this tutorial?
Content
  • Why do we use tasks?
  • How to use the cloud API
  • What tasks do we support
  • Transaction progress

About the product

  • Features
  • Install the app
  • Releases
  • Support
  • Blog

For developers

  • Introduction to integration
  • app2app API
  • Cloud API
  • Integration according to the type of terminal
  • Integrated companies
  • Download

About the company

  • Contact
  • Information Protection Statement
  • Site Terms of Use
  • General Terms and Conditions
  • GDPR

User Guide

  • Install the app
  • Run the application for the first time
  • Payment by card
  • Cancellation of payment
  • Biometrics
  • In-app support