Was ist der Paygate Payment Tester?

Der Paygate Payment Tester unterstützt Entwickler und technische Teams dabei, Paygate-Integrationen direkt im Browser vorzubereiten und nachzuvollziehen.

Zahlungsrequests erstellen Parameter für Hosted Payment Page, Kreditkartenformular und Pay By Link konfigurieren.

Verschlüsselung prüfen MAC, Klartextparameter, Blowfish-Payload, Länge und finale Request-URL transparent kontrollieren.

Responses analysieren Paygate-Callbacks entschlüsseln und Request- sowie Response-Verläufe lokal nachvollziehen.

Keine Installation und kein eigener Server erforderlich: Die Verarbeitung erfolgt lokal im Browser. Einstellungen und lokale Verlaufsdaten werden dabei – je nach Funktion – über localStorage und IndexedDB im jeweiligen Browser gespeichert.

Hinweis: Diese Seite verarbeitet die Konfiguration lokal im Browser; beim Ausführen wird der Request jedoch an das Paygate übergeben. Eingetragene Rücksprung- und Benachrichtigungs-URLs – insbesondere URLNotify – werden Bestandteil des Requests und können durch das Paygate beziehungsweise serverseitig aufgerufen werden. Verwenden Sie ausschließlich vertrauenswürdige, von Ihnen kontrollierte HTTPS-Ziele und übermitteln Sie darüber keine unnötigen vertraulichen Daten. Die Verwendung externer URLs erfolgt auf eigene Verantwortung. Prüfen Sie daher vor jedem Test sorgfältig die eingetragenen Endpunkte, deren Zugriffsrechte und Protokollierung sowie die dorthin übertragenen Daten. Im Testmodus bitte nur kleine Beträge (0,11–2,00 EUR) verwenden, da Kreditkartenauthorisierungen auch im Test real sind.

Sicherheitshinweis zu Ihren Credentials

Die Eingabe von produktiven API-Credentials in webbasierte Tools birgt grundsätzlich ein Restrisiko. Obwohl dieser Tester ausschließlich im Browser ausgeführt wird und keine Daten an externe Server übermittelt, liegt die Verantwortung für den sicheren Umgang mit Ihren Zugangsdaten bei Ihnen.

Empfehlung: Betreiben Sie den Tester in einer von Ihnen kontrollierten Umgebung – idealerweise auf einem eigenen, zugriffsgeschützten Webserver über HTTPS. Alternativ können Sie die index.html direkt lokal im Browser öffnen. Beachten Sie dabei, dass im Request verwendete Rücksprung- und Benachrichtigungs-URLs für den jeweiligen Aufrufer erreichbar sein müssen. Vermeiden Sie eine ungeschützte öffentliche Bereitstellung.

Aktuellen Entwicklungsstand herunterladen Direkt aus dem main-Branch: enthält immer die neuesten Änderungen, auch vor dem nächsten Release.

Stabile Releases anzeigen Getaggte Versionen mit Release Notes; ideal, wenn Sie einen nachvollziehbaren Stand verwenden möchten.

App-Bereiche

Direkt einsteigen

Die wichtigsten App-Bereiche auf einen Blick.

Workflow Payment Workflow Credentials, Zahlungsdaten, Preview und Ausführung vorbereiten. Request Request konfigurieren Classic- und REST-Parameter für Zahlungen oder Statusabfragen zusammenstellen. Preview Vorschau & Ausführen Payload, GET-URL, JSON, Testkarten und Ausführungsoptionen prüfen. Log Request-Log Die zuletzt erzeugten Requests lokal wiederfinden und nachvollziehen. ClassicREST Response-Analyse Classic-Callbacks entschlüsseln und REST-JSON lesbar auswerten. ClassicREST Response-Log Classic- und REST-Rückmeldungen gemeinsam lokal prüfen. Debug Werkzeuge HMAC-SHA256, Base64 und Computop-Testtool-Links schnell öffnen. Guide Hilfe Integration, Bedienung, Dokumentation, Testdaten und Datenschutz nachlesen. Beta v3.6.8 Changelog Änderungen, Release-Historie und neue Funktionen verfolgen.

Schritt 1 — Konfiguration ▼

Aktives Credential-Profil Kein Profil aktiv –

Credentials können direkt verwendet oder als neues Profil gespeichert werden.

Classic- und REST-Credentials werden AES-GCM verschlüsselt im Browser-LocalStorage gespeichert. Der lokale Schutz ersetzt keinen Passwortmanager.

Schnittstelle

Merchant ID *

Für Classic erforderlichMerchant ID, Blowfish- und HMAC-Passwort werden für MAC-Berechnung und Verschlüsselung benötigt.

Classic-Credentialsfür Data / Len / MAC

Blowfish / AES Passwort * (für Data-Verschlüsselung)

HMAC Passwort * (für MAC-Berechnung)

Demo-Vorschau ohne Credentials Fehlende Classic-Credentials werden nur für die lokale Berechnung durch Demo-Werte ersetzt. Die erzeugte URL kann nicht ausgeführt werden.

Credentials gesperrt Die gespeicherten Profile sind mit deinem Master-Passwort geschützt. Entsperre Schritt 1, um Zugangsdaten zu laden oder zu bearbeiten.

Warum zusätzlich verschlüsselt? Browser-Speicher ist lokal, aber nicht automatisch geheim: Wer Zugriff auf dein Browser-Profil, Backups, Sync-Daten oder den Rechner hat, könnte gespeicherte Werte auslesen. Das Master-Passwort legt deshalb eine zweite Schutzschicht über die Credentials.

Schritt 2 — Request konfigurieren ▼

Classic-Verschlüsselung

Classic-Verschlüsselung: Blowfish ECB ist der Standardmodus. AES-CBC kann durch den Computop Helpdesk für eine MID aktiviert werden und nutzt 16, 24 oder 32 Byte lange Schlüssel. Blowfish-Doku AES-Doku Computop FAQ

Use Case

Integrationsoptionen

Betrag *

EUR

Währung

Sprache

Transaction ID (auto-generiert)

Referenznummer (optional)

Bestellbeschreibung (OrderDesc)

Zahlarten (PayTypes)

Template (optional, unverschlüsselt)

Kundendaten mitsenden Optional für 3-D Secure, Risiko- und Stammdaten-Tests. Der Generator füllt nur synthetische Testdaten ein.

Kunde

Anrede

Vorname *

Nachname *

Geburtsdatum (YYYY-MM-DD)

Kundennummer

E-Mail

Telefon-Ländercode

Telefonnummer

Rechnungsadresse

Straße

Hausnummer

PLZ

Stadt

Land

Lieferadresse entspricht Rechnungsadresse

Artikeldaten mitsenden Optionale Artikeldaten für unterstützte Zahlarten. ArticleList wird als Base64-kodiertes JSON übertragen. Classic: ArticleList (Base64-JSON)

Template-CustomFields mitsenden Optionale, unverschlüsselte CustomField1–9 für unterstützende Hosted-Payment-Page-Templates. Classic HPP: CustomField1 … CustomField9 (Query-String)

URLSuccess * (nach erfolgreicher Zahlung)

URLFailure * (nach fehlgeschlagener Zahlung)

URLNotify * (serverseitige Zahlungsbenachrichtigung)

URLBack (Abbrechen-Button, unverschlüsselt)

Dieses Tool als Callback-Empfänger aktivieren (setzt URLSuccess, URLFailure, URLNotify & URLBack auf diese Seite — kein externer Dienst nötig)

Externe Demo-Option: httpbingo.org nur mit synthetischen Testdaten verwenden. URLSuccess, URLFailure und URLBack sind im Browser sichtbar; URLNotify wird nur extern empfangen und ist in dieser App nicht sichtbar.

Schritt 3 — Vorschau & Ausführen ▼

Hinweis: Noch keine Vorschau generiert. Klicke in Schritt 2 auf „Vorschau generieren", um die Request-Daten und die ausführbare Ausgabe hier anzuzeigen.

Vorschau nicht mehr aktuell. In Schritt 2 wurden Daten geändert. Aktualisiere die Vorschau, bevor du die Payment Page öffnest.

Wie wird die GET-URL erzeugt?

MAC-Berechnung HMAC-Passwort

Mit dem HMAC-Passwort wird per HMAC-SHA256 eine digitale Signatur über den String *TransID*MerchantID*Amount*Currency berechnet. Das führende * steht für die leere PayID einer neuen Transaktion. Der MAC wird als Parameter in den Payload aufgenommen und stellt die Integrität der Anfrage sicher — das Paygate lehnt Anfragen mit falschem oder fehlendem MAC sofort ab.

Payload-Verschlüsselung Blowfish / AES Passwort

Alle Zahlungsparameter (inkl. des MAC) werden als Klartextstring im Format Key=Value&Key=Value… zusammengesetzt. Dieser String wird mit dem Blowfish-Passwort per Blowfish ECB verschlüsselt und anschließend hexadezimal kodiert. Das Ergebnis bildet den Data-Parameter. Die Länge des ursprünglichen Klartexts wird separat als Len übergeben, da Blowfish auf ein Vielfaches von 8 Byte auffüllt.

URL-Zusammensetzung

Die finale GET-URL setzt sich aus drei unverschlüsselten Pflichtparametern zusammen, die direkt an die Paygate-Endpoint-URL angehängt werden:

https://www.computop-paygate.com/paymentPage.aspx?MerchantID=IhreMID&Len=142&Data=a3f09c…

MerchantID — Händlerkennung (Klartext) Len — Länge des unverschlüsselten Payloads in Bytes Data — Blowfish-ECB- oder AES-CBC-verschlüsselter, hex-kodierter Payload

Klartext-Payload vor Blowfish-Verschlüsselung

–

Data-Parameter nach Verschlüsselung

–

Unverschlüsselte URL-Parameter (Query-String)

–

Vollständige GET-URL (Paygate)

–

Testkarten

Testkarten: Ablaufdatum und CVC können frei gewählt werden. Non-3DS-Karten gelten ohne 3-D Secure; 3-D-Secure-Karten benötigen Testmodus und 3DS-Konfiguration. Für Challenge-Szenarien lautet das OTP 1234. Quelle: Paygate-Dokumentation.

Testkartennummern (Non-3DS)

Marke	Kartennummer	Ergebnis

Testkartennummern (3-D Secure 2.x)

Marke	Kartennummer	Szenario

Öffnet das Paygate in einem neuen Tab

Request-Log ▼

Response-Analyse ▼

Hinweis: Füge die vollständige Callback-URL des Paygate ein (URLSuccess / URLFailure / URLNotify). MerchantID, Len und Data werden automatisch extrahiert und mit dem Blowfish-Passwort aus Schritt 1 entschlüsselt.

Callback-URL (URLSuccess / URLFailure / URLNotify)

Oder manuell

Data (Hex)

Len

Response-Log ▼

HMAC-SHA256

MAC-Validator

Prüft, ob ein MAC korrekt berechnet wurde. Die App bildet den HMAC-SHA256 über PayID*TransID*MerchantID*Amount*Currency — auf Wunsch mit Vergleich gegen den MAC aus deinem Request.

PayID (bei Erst-Requests leer)

TransID

Merchant ID

Amount (kleinste Einheit, z. B. 123 = 1,23 EUR)

Currency

HMAC Passwort

Erwarteter MAC (optional, zum Vergleich)

Base64

Base64-Encoder / -Decoder

Wandelt JSON-Parameter wie credentialOnFile oder browserInfo in Base64 um — mit fertigen Vorlagen für CIT- und MIT-Zahlungen. Dekodieren funktioniert genauso, wenn du einen Base64-Wert aus einem Request lesen möchtest.

Vorlage

Klartext (JSON)

Base64

Parametername (für „Als Parameter kopieren“)

Computop

Testtool & Dokumentation

Beide Werkzeuge orientieren sich am offiziellen Paygate-Test von Computop — hier findest du das Original und die zugehörige Anleitung.

Paygate-TestOffizielles Computop-Testtool im Browser öffnen DokumentationAnleitung zum Testtool im Computop Developer-Portal

Was ist der Paygate Payment Tester?

Direkt einsteigen

Payment Workflow

Request-Log

Response-Analyse

Response-Log

Changelog

Werkzeuge

MAC-Validator

Base64-Encoder / -Decoder

Testtool & Dokumentation

Hilfe & Dokumentation