Zu Content springen
Deutsch
Mehr Unterstützung
Support
  • Es gibt keine Vorschläge, da das Suchfeld leer ist.

GP tom für Partner und tiefe Integrationen

Integrationsleitfaden GP tom – Test, Support und Abnahme

Integrationsleitfaden GP tom – Test, Support und Abnahme

Zielgruppe: Integratoren (insbesondere Kassensystem-Hersteller)

Inhaltsverzeichnis
Über dieses Dokument

Dieser Leitfaden führt Integratoren in vier Schritten durch den vollständigen Anbindungsprozess an GP tom – vom initialen Download über die technische Integration und das Testen bis zur abschließenden Zertifizierung. Er ist als Selbstbedienungsdokument konzipiert und ersetzt den persönlichen Face-to-Face-Support.

Wer diesen Leitfaden vollständig durcharbeitet, sollte am Ende eine produktiv einsetzbare, zertifizierte Integration vorweisen können – ohne dass im Verlauf der Integration ein persönlicher Termin mit einem Implementation-Manager zwingend notwendig ist.

Dieses Dokument beschreibt die Integration der App2App-API auf der Android-Plattform. Nicht behandelt werden die separat verfügbare iOS-API (für Tap to Pay on iPhone) und die Cloud-API (für Cloud-zu-Cloud-Szenarien).

Verbindliche Originalquellen u.a. (englischsprachig, immer maßgeblich bei Unklarheiten):

Produktvarianten von GP tom

GP tom wird in Deutschland in zwei Varianten angeboten, die sich im Akzeptanzumfang, aber nicht in der Integrationsschnittstelle unterscheiden:

Variante Komponenten auf dem Gerät Akzeptierte Kartensysteme Verarbeitungsweg
GP tom ohne Girocard GP tom App International Schemes (Visa, Mastercard, Amex) Direkt über GP tom App
GP tom mit Girocard GP tom App + GP tom Girocard Plugin International Schemes (Visa, Mastercard) und Girocard Alle Transaktionen über das Girocard-Plugin

DCC ausschließlich bei der Variante GP tom ohne Girocard verfügbar!

Die Girocard-Akzeptanz wird über ein separates GP tom Girocard Plugin bereitgestellt, das zusätzlich zur GP tom App auf dem Gerät installiert sein muss. Welcher Verarbeitungsweg genutzt wird, ist pro Terminal-ID festgelegt und wird von der GP tom App automatisch anhand der vom Händler bestellten Terminal-ID erkannt:

  • Ohne Girocard-Beauftragung: Alle Transaktionen werden direkt über die GP tom App verarbeitet.
  • Mit Girocard-Beauftragung: Alle Transaktionen – sowohl International Schemes als auch Girocard – werden über das nachgelagerte GP tom Girocard Plugin geroutet.
Was das für Integratoren bedeutet

Die Integration ist in beiden Fällen identisch. Sowohl die App2App-API Aufrufe, die Rückgabewerte und der Transaktionsfluss bleiben unverändert – die Integratoranwendung muss nicht zwischen den Varianten unterscheiden und keine zusätzlichen Codepfade für Girocard implementieren.

Konkret heißt das:

  • Einmal integrieren, beide Varianten bedienen – die Integratoranwendung funktioniert sowohl auf Geräten ohne Girocard-Plugin als auch auf Geräten mit Plugin.
  • Die Zertifizierung läuft über dieselben Testszenarien (siehe 6.2 Pflicht-Testszenarien, unabhängig von der Variante).
  • Welche Variante ein Händler einsetzt, wird beim Onboarding des Händlers entschieden und durch die Konfiguration auf GP-tom-Seite gesteuert – nicht durch die Integratoranwendung.
1. Überblick: Der Integrationsprozess in 4 Schritten

Die Anbindung an GP tom ist bewusst schlank gehalten und gliedert sich in vier aufeinanderfolgende Phasen:

Schritt Phase Ergebnis
1 Download Simulator und/oder Beispielintegration inkl. Quellcode aus dem Download-Bereich herunterladen
2 Zugangsdaten / TID anfordern Globale Zugangsdaten stehen auf der Website bereit. Die individuelle Terminal-ID wird per E-Mail an support@gptom.com angefordert
3 Integration a) umsetzen und b) testen Implementierung auf Integratorseite anhand der Dokumentation, bei Bedarf mit Slack-Support
4 Zertifizierung Offizielle Abnahme durch das GP tom Team und Veröffentlichung als Partner

Die Integration ist kostenfrei. Nach erfolgreicher Zertifizierung wird das Integratorsystem auf der GP tom Website als unterstützender Partner gelistet.

2. Voraussetzungen prüfen

Vor dem Start der Integration sollte sichergestellt sein, dass die technischen Mindestanforderungen erfüllt sind:

Generelle Voraussetzungen

Architektur-Voraussetzung

Die App2App-API ist für Android Anwendungen ausgelegt, die auf demselben Gerät wie GP tom laufen. Die Kassenanwendung ruft die GP tom App lokal auf dem Gerät auf – es handelt sich nicht um eine Cloud-zu-Cloud-Schnittstelle. Für Cloud-Szenarien existiert separat die Cloud-API (siehe Originaldokumentation).

Funktionaler Umfang der App2App-API

Über die API können folgende Operationen ausgelöst werden:

  • Zahlung auslösen (Payment Request)
  • Zahlung stornieren (Cancellation)
  • Zahlung gutschreiben (Unreferenced Refund)
  • Tagesabschluss / Batch Close auslösen
  • Transaktionsstatus abfragen
  • Transaktionsdetails abrufen (z. B. für Belegdruck)

Für jede Transaktion werden im Rückgabewert die Belegdaten geliefert, sodass der Integrator den Kundenbeleg auf der eigenen Seite erzeugen kann.

3. Schritt 1+2 – Download und Zugangsdaten

Bevor die eigentliche Integration auf Integratorseite beginnt, müssen zwei Vorarbeiten erledigt sein: das Herunterladen der Integrationsmittel und die Anforderung der individuellen Terminal-ID.

3.1 Schritt 1 – Download der Integrationsmittel

Im Download-Bereich https://www.gptom.com/en/docs/api/uvod/ke-stazeni/ stehen folgende Bausteine zur Verfügung:

  • Simulator-APK für funktionale Tests ohne echte Karten
  • GP tom PIN-App, die der Simulator und die App für die PIN-Eingabe benötigen
  • Sample-App inklusive Quellcode als Referenzimplementierung für den App2App-API-Aufruf
  • AIDL Library zur Kommunikation mit GP tom

Diese Tools gehören zur Grundausstattung jeder Integration und sollten direkt zu Projektbeginn besorgt werden.

3.2 Schritt 2 – Zugangsdaten anfordern

Damit Simulator und Sample-App in Betrieb genommen werden können, werden folgende Daten benötigt:

  • GP tom Zugangsdaten. Diese sind global gültig und stehen auf der Website bereit.
  • Individuelle Terminal-ID. Diese wird per E-Mail an support@gptom.com angefordert.

Vorgeschlagener Textbaustein:

Subject: Request for Access Data Simulator / Test Environment

Dear GP tom Team,

We are planning the integration of GP tom into our POS system (Company: [Name], Product: [Product Name], Target Market: [Market], Planned Integration Period: [Period]). We kindly request a terminal ID for the simulator.

Technical contact at our side: [Name, Email]

Best regards,

Nach Erhalt der Daten kann mit der eigentlichen Integration (Schritt 3a) begonnen werden.

4. Schritt 3a – Integration umsetzen

4.1 Dokumentation studieren

Die vollständige API-Referenz inklusive Codebeispielen und Rückgabecodes findet sich unter https://www.gptom.com/en/guides/api/app2app/.

Empfohlene Reihenfolge:

  1. Introduction to app2app API
  2. Transaction registration
  3. Payment Request (transactionRequestV2)
  4. Get the status of the transaction
  5. Get transaction details
  6. Code examples und Return codes

4.2 Ablauf App2App-API

Die Einhaltung des korrekten Transaktionsablaufs ist essenziell, um eine zuverlässige Verarbeitung sicherzustellen und mögliche Probleme bei der Transaktionsabwicklung zu vermeiden.

Verbindlicher App2App API Ablauf

Bitte stellen Sie sicher, dass Ihre Integration die folgenden Schritte korrekt umsetzt:

  1. Service binden – Stellen Sie eine Verbindung zum GP tom Service her.
  2. Transaktion registrieren – Initialisieren Sie die Transaktion über die Methode transactionRegisterV2.
  3. Transaktionsanfrage senden – Lösen Sie die Zahlung über transactionRequestV2 aus.
  4. Transaktionsstatus abfragen (poll) – Rufen Sie stateRequest wiederholt auf, bis einer der folgenden Endstatus zurückgegeben wird: 6 = COMPLETED, 7 = CANCELED, 8 = ERROR.
  5. Bei Status COMPLETED müssen Sie die Methode TransactionInquire aufrufen, um folgende Daten abzurufen:
    a. Transaktionsergebnis (genehmigt / abgelehnt) sowie
    b. Belegdaten

Abfrageintervall (stateRequest) min. 500 Millisekunden. getStatus erst angefragen, nachdem zur Integrator-App zurückgewechselt wurde.

Wichtig: Bitte verwenden Sie nicht die Methode transactionListener zum Abrufen des Ergebnisses. Diese Methode ist veraltet und wird in kommenden Releases entfernt.

4.3 Beispielanwendung als Vorlage nutzen

Im Download-Bereich (https://www.gptom.com/en/docs/api/uvod/ke-stazeni/) steht eine Sample-App inklusive Quellcode zur Verfügung, die den App2App-API-Aufruf auf demselben Gerät demonstriert. Diese eignet sich als Referenzimplementierung für eigene Entwickler.

Ebenfalls steht dort die benötigte AIDL-Library (Android Interface Definition Language) bereit – die formale Beschreibung, über die die Integratoranwendung mit dem GP tom Service auf demselben Gerät kommuniziert.

4.4 Pflichtprüfungen in der eigenen App umsetzen

Bei der Zertifizierung wird unter anderem geprüft, ob die eigene Anwendung das Vorhandensein der GP tom App auf dem Gerät zuvor überprüft. Diese Prüfung sollte daher von Anfang an Teil der Integration sein – die entsprechende Methode ist in der API-Dokumentation unter Check the installed application beschrieben:

https://www.gptom.com/en/docs/api/app2app/app-check/

4.5 Belegpflichten beachten

Die API liefert alle pflichtrelevanten Belegdaten zurück. Es liegt in der Verantwortung des Integrators, diese Daten vollständig und konform auf dem Kundenbeleg auszugeben. Die Konformität ist Bestandteil der Zertifizierungsprüfung. Die auf dem Beleg anzuzeigenden Informationen sind in dem Bereich beschrieben:

https://www.gptom.com/en/docs/api/uvod/vizual-uctenky/

Bitte beachten Sie die Anforderungen zur Belegerstellung bei DCC-Transaktionen.

4.6 Android-Manifest konfigurieren

Damit die Integratoranwendung die GP tom App auf dem Gerät korrekt erkennen und an deren Service binden kann, sind drei Anpassungen in der eigenen App nötig: Package-Visibility, das richtige Binding-Package für Test bzw. Produktion und ab Android 14 ein zusätzliches Flag beim Service-Binding.

Package-Visibility (Android 11+)

Ab Android 11 sind installierte Pakete fremder Apps standardmäßig nicht mehr sichtbar. Damit die Integratoranwendung die Anwesenheit der GP tom App erkennen und sich an deren Service binden kann, muss in der AndroidManifest.xml eine <queries>-Sektion ergänzt werden:

<manifest ...>   ...   <queries>     <package android:name="com.globalpayments.atom" />   </queries> </manifest>

Ohne diese Eintragung schlägt die Erkennung der installierten App fehl, und die App2App-Verbindung kommt nicht zustande.

Unterscheidung Test- und Produktionsumgebung

GP tom stellt getrennte Package-Namen für Entwicklung und Produktion bereit. Beim Service-Binding muss das passende Package angegeben werden – andernfalls bindet die Integratoranwendung an die falsche Umgebung oder gar nicht.

Praktische Empfehlung: Das Binding-Package in der eigenen App nicht hart codieren, sondern über Build-Varianten (Flavors) bzw. BuildConfig-Felder steuern. So ist sichergestellt, dass das Debug-Build automatisch gegen .dev und das Release-Build gegen die Produktion bindet. Ein versehentlicher Release-Build gegen die DEV-Umgebung – oder umgekehrt – wird damit ausgeschlossen.

Umgebung Zweck Package-Name zum Binden
Simulator / Test App Integration mit Simulator oder Test App com.globalpayments.atom.dev
Produktion Live-Betrieb mit echten Händlern com.globalpayments.atom

Service-Binding ab Android 14+

Ab Android 14 muss beim Aufruf von bindService() das Flag Context.BIND_ALLOW_ACTIVITY_STARTS gesetzt werden, damit der GP tom Service im Hintergrund-Kontext eine Activity starten darf (Zahlungs-UI). Ohne dieses Flag wird der Start der Zahlungsoberfläche von Android blockiert.

context.bindService(     intent,     serviceConnection,     Context.BIND_AUTO_CREATE or Context.BIND_ALLOW_ACTIVITY_STARTS )

Hintergrundinformationen siehe Android-Developer-Doku:
https://developer.android.com/guide/components/activities/background-starts

Originalquelle GP tom:
https://www.gptom.com/en/docs/api/app2app/nastaveni-v-android/

5. Schritt 3b – Testen

Für den Test der Integration stehen zwei Wege zur Verfügung, die sich je nach Reifegrad der Integration ergänzen:

5.1 Variante A – Simulator

Der Simulator emuliert die GP tom App und erlaubt es, alle Zertifizierungszustände ohne physische Testkarten durchzuspielen. Er wird kontinuierlich erweitert – vor jedem Testzyklus prüfen, ob die aktuellste Version installiert ist.

Schritt-für-Schritt: Simulator einrichten

  1. Simulator-APK herunterladen aus dem Download-Bereich:
    https://www.gptom.com/en/docs/api/uvod/ke-stazeni/
  2. Simulator auf dem Testgerät installieren, Zugangsdaten eingeben und beantragte Terminal-ID auswählen.
  3. Eigene Integration gegen den Simulator testen – die App2App-Aufrufe sind identisch zur produktiven App.

5.2 Simulation über Beträge

Der Simulator erlaubt es, Transaktionsergebnisse gezielt über den Betrag der Zahlungsaufforderung auszulösen. Dadurch lassen sich alle relevanten Erfolgs- und Fehlerpfade ohne echte Karten reproduzieren – ideal für automatisierte Integrationstests und für die strukturierte Vorbereitung auf die Zertifizierung.

Wird einer der folgenden Beträge an die App2App-API übergeben, antwortet der Simulator mit dem zugehörigen Ergebnis:

Betrag Simuliertes Ergebnis Erwartetes Verhalten der Integratoranwendung
1111 Kartenzahlung erfolgreich Erfolgreiches Transaktionsergebnis wird empfangen; Transaktion wird auf Integratorseite regulär abgeschlossen (Beleg, Bestätigung etc.).
1122 Kartenzahlung abgelehnt Negatives Transaktionsergebnis wird empfangen; die Ablehnung muss dem Bediener korrekt angezeigt und sauber weiterverarbeitet werden.
1123 Kartenzahlung fehlgeschlagen, Timeout während der Zahlung Es erfolgt keine reguläre Rückmeldung von GP tom; die Integratoranwendung muss den Timeout-Fall behandeln und ein definiertes Ergebnis darstellen.
1124 Kartenzahlung fehlgeschlagen, Exception während der Zahlung Simuliert ein technisches Fehlverhalten auf GP tom Seite; die Anwendung muss die Exception abfangen und dem Bediener eine kontrollierte Fehlermeldung anzeigen.

Weitere Fälle für die Betragssimulation (u.a. für DCC) finden Sie im Downloadbereich des GP tom Simulators unter folgendem Link:
https://www.gptom.com/en/download/gp-tom-simulator/

5.3 Variante B (optional) – Echte Test-App mit eigenen Zugangsdaten

Für den realitätsnahen Abschlusstest kann eine echte GP tom Testinstanz mit eigenen Zugangsdaten beantragt werden. Diese leitet während des Bezahlvorgangs auf ein Terminal weiter und durchläuft den vollständigen produktiven Transaktionspfad – allerdings im Testmodus.

Für die Simulation von erfolgreichen Zahlungen in der Testumgebung kann die folgende VISA App genutzt werden:

Wichtige Hinweise zu den Tests mit der VISA Wallet App:

  • Die App simuliert reale Karten, ohne echte Zahlungsströme auszulösen.
  • Nur mit dieser Karte sind erfolgreiche Autorisierungen möglich.
  • Eigene echte Karten werden abgelehnt.

Schritt-für-Schritt: Test-App beantragen

  1. Test Zugangsdaten beantragen – Anfrage über den Partner Manager stellen. Für die Anfrage werden ein Ansprechpartner, eine E-Mail-Adresse sowie eine Mobil-Nummer benötigt. Nach Setup erhalten Sie Zugangsdaten sowie eine Test Terminal-ID.
  2. Test-App herunterladen: https://www.commerz-globalpay.com/test-app-gp-tom
  3. Test-App auf Zielgerät installieren und mit übermittelten Zugangsdaten konfigurieren.
  4. Vollständige Testszenarien durchlaufen – idealerweise dieselben, die bei der Zertifizierung geprüft werden (siehe 6.2 Pflicht-Testszenarien, soweit möglich).

5.4 Empfohlene Teststrategie

Eine bewährte Vorgehensweise:

  1. Entwicklungsphase: Funktionale Tests gegen den Simulator – schnell, deckt alle definierten Zustände ab.
  2. Stabilisierungsphase: Wiederholung der Zertifizierungsszenarien gegen den Simulator, bis alle Szenarien fehlerfrei durchlaufen.
  3. Abnahmevorbereitung (optional): Test-App mit echtem Terminal beantragen, alle Zertifizierungsszenarien einmal end-to-end fahren (soweit möglich).
  4. Zertifizierungstermin buchen (siehe Schritt 4)
6. Schritt 4 – Zertifizierung und Abnahme

6.1 Ablauf

Wenn die Entwicklung abgeschlossen ist und die Tests stabil durchlaufen, kann die Zertifizierung gebucht werden. Der Ablauf:

  1. Termin vorschlagen – Anfrage per E-Mail mit Terminvorschlägen an das GP tom Team senden (Adresse: support@gptom.com). Alternativ ist es möglich, einen Termin per Jira-Ticket über folgenden Link anzufragen:
    https://www.gptom.com/en/docs/api/uvod/nez-zacnete/
  2. Bestätigung erhalten – Termin wird abgestimmt.
  3. Zertifizierungstests durchführen – Es gibt zwei Optionen:
    a. Testzugang zur eigenen Anwendung bereitstellen – als Teil der Zertifizierung wird das GP tom Team selbst Tests mit der Integratoranwendung durchführen. Hierzu wird ein Testzugang (App inkl. Zugangsdaten) benötigt.
    b. Alternativ können die Tests in einem gemeinsamen Online-Termin (Sprache: Englisch) durchgeführt werden.
  4. Ergebnismitteilung – Rückmeldung über bestandene oder offene Punkte.
  5. Nach erfolgreicher Zertifizierung – Veröffentlichung der Anwendung auf der GP tom Partnerseite, Vorstellung als unterstützender Partner.

Hinweise zum Abnahmeprozess finden Sie hier:
https://www.gptom.com/en/docs/api/uvod/nez-zacnete/

6.2 Pflicht-Testszenarien

Die folgenden Szenarien
https://www.gptom.com/en/docs/api/uvod/certification-test-cases/
werden bei der Zertifizierung systematisch geprüft. Es empfiehlt sich, diese Liste bereits in der internen QA als Akzeptanzkriterien zu verwenden. Hier eine Übersicht:

Nr. Szenario Erwartetes Verhalten
1 Prüfung auf installierte GP tom App Die Integratoranwendung prüft vor jedem Aufruf, ob GP tom auf dem Gerät installiert ist, und reagiert sinnvoll, falls nicht
2 Erfolgreiche Kartenzahlung inkl. PIN GP tom wird aufgerufen, Transaktion läuft durch, Integratoranwendung wird mit Erfolgsinformation zurückgerufen
3 Fehlgeschlagene Kartenzahlung Z. B. falsche PIN, unzureichendes Guthaben – Integratoranwendung wird zurückgerufen und zeigt die Ablehnungsinformation an
4 Timeout-Verhalten Verhalten der Anwendung bei Timeouts während der Transaktion ist definiert und stabil
5 Exception während der Zahlung Simulation einer Exception – Anwendung verhält sich kontrolliert (keine Abstürze, klare Information an den Bediener)
6 Stornierung der letzten Zahlung Cancellation-Aufruf für die zuletzt durchgeführte Transaktion funktioniert
7 Stornierung einer älteren Zahlung Cancellation-Aufruf für ältere Transaktionen funktioniert
8 Tagesabschluss Tagesabschluss wird sauber verarbeitet
9 Belegkonformität Der von der Integratoranwendung erzeugte Kundenbeleg enthält alle gesetzlich relevanten Daten, Daten vorhanden
10–16 Belegkonformität bei DCC Der von der Integratoranwendung erzeugte Kundenbeleg enthält alle gesetzlich relevanten Daten, insbesondere bei DCC.
17 Transaktion registrieren (Speicherung der transactionId) Die Integratoranwendung speichert die transactionId, die beim Aufruf von transactionRegisterV2 zurückgegeben wird.
18 Transaktionsanfrage senden Die Integratoranwendung löst die Zahlung über transactionRequestV2 aus.
19 Transaktionsstatus abfragen Die Integratoranwendung fragt den Status der Transaktion per stateRequest ab.
20 Transaktionsdetails abrufen Die Integratoranwendung ruft Details zu der Transaktion ab, wie: 1. Transaktionsergebnis (genehmigt / abgelehnt) sowie 2. Belegdaten

Empfehlung: Eine Tabelle mit diesen Szenarien plus Spalten für internes Testdatum, Ergebnis und Bemerkung als interne Test-Evidenz führen. Diese kann dem GP tom Team beim Zertifizierungstermin vorgelegt werden und beschleunigt die Abnahme erheblich.

7. Support-Kanäle im Detail

GP tom bietet mehrere reguläre Support-Kanäle. Die Wahl hängt vom Anliegen ab.

7.1 E-Mail-Support (support@gptom.com)

Wofür:

  • Anforderung von Terminal-ID (Simulator)
  • Terminvereinbarungen für Zertifizierung
  • Asynchrone Klärung technischer Detailfragen

So vorgehen:

  1. E-Mail an support@gptom.com
  2. Sprache: englisch
  3. Im Betreff Anliegen klar benennen (z. B. „Certification date: [Unternehmen]“)
  4. Im Text: Unternehmen, konkrete Frage oder Anliegen, ggf. Logfile-Auszüge oder Screenshots

7.2 Slack-Support (direkter Draht zu den Entwicklern)

Für Integratoren, die in der aktiven Entwicklungs- oder Stabilisierungsphase sind, bietet GP tom einen Slack-Zugang direkt zu den Entwicklern an. Damit lassen sich technische Detailfragen wesentlich schneller klären als per E-Mail.

Schritt-für-Schritt: Slack-Zugang anfordern

  1. Über die GP tom Website per Jira-Ticket Slack-Zugang anfragen – auf der Seite
    https://www.gptom.com/en/docs/api/uvod/nez-zacnete/
    über den Button “Request Access to Slack”.
  2. Einladungslink per E-Mail erhalten
  3. Einladung annehmen, Slack-Workspace beitreten.

7.3 Jira-Ticket

Ein Zertifizierungstermin sowie der Zugang zu Slack kann direkt über ein Jira-Ticket angefragt werden. Hierzu die entsprechenden Buttons auf der folgenden Website anklicken:
https://www.gptom.com/en/docs/api/uvod/nez-zacnete/.

7.4 Wann welcher Kanal?

Situation Empfohlener Kanal
Erstanfrage, Terminal-ID (Simulator) E-Mail
Zertifizierungstermin E-Mail oder Jira-Ticket
Konkrete Code-/API-Frage, Debugging Slack (sofern Zugang vorhanden)
Vertraulicher oder kommerzieller Inhalt Partner-Manager 
8. Häufige Fragen (FAQ)

Was kostet die Integration und Zertifizierung?

Der gesamte Integrationsprozess inklusive Zertifizierung ist kostenfrei.

Müssen wir Testkarten besorgen?

Nein. Der Simulator deckt alle Zertifizierungszustände ohne physische Karten ab. Lediglich für den Real-Terminal-Test mit der echten Test-App können Testkarten relevant werden – diese werden über die VISA App Visa Mobile CDET – Apps on Google Play bereitgestellt.

Wie lange dauert die Zertifizierung typischerweise?

Die reine Durchführung der Zertifizierungstests durch das GP tom Team ist überschaubar. Die Gesamtdauer hängt vom Integrationsreifegrad ab – gut vorbereitete Integratoren (alle Szenarien intern bereits durchgetestet) durchlaufen die Abnahme zügig.

Was passiert, wenn ein Zertifizierungsszenario fehlschlägt?

Das GP tom Team meldet die offenen Punkte zurück. Nach Behebung wird ein erneuter Test durchgeführt – entweder asynchron oder in einem Folgetermin.

Können wir vor der Zertifizierung live gehen?

Nein. Eine Veröffentlichung als Partner und der produktive Einsatz mit Echthändlern setzt die erfolgreiche Zertifizierung voraus.

Was tun, wenn auf dem Zielgerät kein NFC-Chip vorhanden ist?

Auf Android-Geräten ohne NFC-Chip kann GP tom nicht betrieben werden. Diese Anforderung sollte bei der Geräteauswahl auf Händlerseite frühzeitig kommuniziert werden.

Versionshinweise und Pflege dieses Dokuments

Dieser Leitfaden ist eine kuratierte deutschsprachige Zusammenfassung der offiziellen englischsprachigen GP tom Dokumentation. Bei Widersprüchen zwischen diesem Leitfaden und den in diesem Dokument verlinkten Originalquellen sind immer die Originalquellen maßgeblich.

Bei Aktualisierungen der Originalquellen sollte dieser Leitfaden zeitnah überprüft und angepasst werden – insbesondere die folgenden Abschnitte sind erfahrungsgemäß änderungsanfällig:

  • Generelle Voraussetzungen
  • Liste der Zertifizierungsszenarien
  • Download-Links und Adressen

Verantwortlich für dieses Dokument: Till Gramlich
Nächste planmäßige Review: