Tapaya
Zahlungsannahme vor OrtIntegrationsleitfadenCloud Accept APIBeta

Cloud Accept API

Beta

Starten Sie Zahlungen vor Ort auf einem gekoppelten Tapaya-Gerät über Ihr ECR- oder POS-Backend.

Mit der Cloud Accept API kann Ihre elektronische Registrierkasse (ECR) oder Ihr POS-Backend über die Cloud eine Zahlung auf einem Tapaya-Gerät starten. Ihr System kommuniziert nie direkt mit dem Gerät: Es sendet eine Zahlungsanfrage an Tapaya, Tapaya benachrichtigt das gekoppelte Gerät, und das Gerät zeigt dem Kunden den Zahlungsbildschirm. Den Fortschritt erhalten Sie als Webhooks, oder Sie fragen ihn regelmäßig ab (Polling).

Art der Gerätekopplung wählen

Jedes Gerät, an das Sie Zahlungen senden, benötigt eine externalDeviceId: den Namen, unter dem Ihr System es kennt, zum Beispiel till-01. Sie können sie auf eine von zwei Arten zuweisen:

Bevor Sie beginnen

  1. Holen Sie sich Ihr Server Secret Token auf der Seite API Keys. Weiter unten tauschen Sie es gegen ein auf den Händler beschränktes Zugriffstoken ein (siehe Authentifizierung der Platform API).
  2. Registrieren Sie den Händler und bewahren Sie sein merchantToken auf. Siehe Neuen Händler registrieren.
  3. Bereiten Sie jedes Gerät vor, indem Sie die Tapaya-App für diesen Händler anmelden, damit es gekoppelt werden und Anfragen empfangen kann.

Ein Token, ein Händler

Jeder Aufruf der Cloud Accept API ist auf genau einen Händler beschränkt. Wenn Sie mehrere Händler bedienen, tauschen Sie für jeden ein eigenes Zugriffstoken ein.

Gerät koppeln

Die Kopplung weist einem Tapaya-Gerät eine externalDeviceId zu, sodass Sie es beim Auflisten der Geräte finden und beim Starten einer Zahlung gezielt ansprechen können.

Zuweisung aus Ihrer App

Ihre Anwendung ruft auf dem Gerät eine Funktion des Accept SDK auf, die ihm seine externalDeviceId zuweist. Verwenden Sie in jedem Aufruf der Cloud Accept API für dieses Gerät dieselbe Kennung.

QR-Code scannen

Der Händler öffnet den Kopplungsvorgang in der Tapaya Platform, die einen QR-Code für die zuzuweisende externalDeviceId anzeigt. Der Händler scannt ihn mit der Tapaya-Händler-App auf dem Zielgerät, und die App schließt die Kopplung ab.

Zugriffstoken eintauschen

Tauschen Sie Ihr Server Secret Token und das merchantToken des Händlers mit POST /ecr/auth gegen ein Zugriffstoken ein. merchantToken wird nur hier gesendet; alle späteren Aufrufe senden nur Authorization: Bearer <accessToken>.

curl -X 'POST' 'https://api.tapaya.com/ecr/auth' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer REPLACE_ME' \
-d '{
        "merchantToken": "unique_merchant_id_from_your_db"
    }'
200 OK
{
    "accessToken": "...",
    "tokenType": "Bearer",
    "expiresAt": "2026-01-13T16:30:59Z"
}
CodeBeschreibung
401Ungültiges oder abgelaufenes API-Token.
403Zugriff auf den Händler nicht erlaubt.

Erneuern Sie das Token vor expiresAt. Rufen Sie POST /ecr/auth/refresh mit dem aktuellen, noch gültigen accessToken im Header Authorization auf. Der Endpoint gibt denselben Body mit einem neuen Token zurück; speichern Sie es und verwenden Sie ab dann nur noch dieses.

curl -X 'POST' 'https://api.tapaya.com/ecr/auth/refresh' \
-H 'Authorization: Bearer ACCESS_TOKEN'
CodeBeschreibung
401Das Zugriffstoken ist ungültig, abgelaufen oder widerrufen. Tauschen Sie mit POST /ecr/auth ein neues ein.
403Sie haben keinen Zugriff mehr auf den Händler. Es wird kein neues Token ausgestellt.

Einsatzbereites Gerät finden

Listen Sie die Geräte des Händlers mit GET /ecr/devices auf. Mit ?connected=true lassen Sie nicht verbundene Geräte weg; ein einzelnes Gerät rufen Sie mit GET /ecr/devices/{externalDeviceId} ab.

curl 'https://api.tapaya.com/ecr/devices/till-01' \
-H 'Authorization: Bearer ACCESS_TOKEN'
200 OK
{
    "externalDeviceId": "till-01",
    "name": "Front counter",
    "connected": true,
    "availability": "ready",
    "lastSeenAt": "2026-01-13T16:30:59Z",
    "updatedAt": "2026-01-13T16:30:59Z"
}

Senden Sie Zahlungen nur an ein Gerät, dessen availability den Wert ready hat. Die Liste ist eine Momentaufnahme: Die Verfügbarkeit wird beim Absenden erneut geprüft, daher kann auch ein Gerät mit ready eine Anfrage ablehnen. Siehe Geräteverfügbarkeit.

Zahlungsanfrage senden

Senden Sie den Betrag mit POST /ecr/payment-requests an ein Gerät. Tapaya speichert die Anfrage und benachrichtigt das Gerät, das den Zahlungsbildschirm anzeigt.

curl -X 'POST' 'https://api.tapaya.com/ecr/payment-requests' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer ACCESS_TOKEN' \
-H 'Idempotency-Key: order-1042-attempt-1' \
-d '{
        "externalDeviceId": "till-01",
        "amount": 12500,
        "tipAmount": 500,
        "currency": "CZK"
    }'

Parameter:

FeldTypErforderlichBeschreibung
externalDeviceIdstring✓Das gekoppelte Gerät, das die Zahlung anzeigen soll.
amountinteger✓Betrag in der kleinsten Einheit der Währung (12500 entspricht 125,00 Kč).
tipAmountintegerTrinkgeld in der kleinsten Einheit der Währung.
currencystring✓ISO-4217-Währungscode.
paymentTokenstringEine bestehende Zahlung, an die die Anfrage angehängt werden soll.
202 Accepted
{
    "requestId": "...",
    "status": "pending",
    "paymentToken": null,
    "expiresAt": "2026-01-13T16:30:59Z"
}

202 ist kein Zahlungsergebnis

202 Accepted bedeutet, dass Tapaya die Anfrage gespeichert hat. Es bedeutet weder, dass das Gerät sie gesehen hat, noch, dass der Kunde bezahlt hat. Alles, was später fehlschlägt, erreicht Sie als Statusänderung.

Sichern Sie Wiederholungsversuche ab. Der Header Idempotency-Key ist erforderlich. Wird ein Schlüssel mit demselben Body erneut verwendet, wird die ursprüngliche Anfrage zurückgegeben, statt eine zweite Zahlung zu starten; wird er mit einem anderen Body erneut verwendet, wird 409 idempotency_conflict zurückgegeben. Binden Sie den Schlüssel an den Verkauf und den Versuch, wie bei order-1042-attempt-1.

Ergebnis verfolgen

Verfolgen Sie die Anfrage durch ihre Status mit Webhooks, oder fragen Sie regelmäßig GET /ecr/payment-requests/{requestId} ab. Sobald sie payment_created erreicht, enthält die Antwort das paymentToken, und Events vom Typ payment.updated melden den Fortschritt der Zahlung selbst.

Um Webhooks zu empfangen, registrieren Sie Ihren HTTPS-Endpoint mit POST /ecr/webhook-subscriptions oder legen Sie die Callback-URL und die Event-Typen für den Händler in der Tapaya Platform fest.

curl -X 'POST' 'https://api.tapaya.com/ecr/webhook-subscriptions' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer ACCESS_TOKEN' \
-d '{
        "url": "https://integrator.example.com/webhooks/tapaya",
        "events": ["payment_request.updated", "payment.updated"]
    }'
201 Created
{
    "subscriptionId": "...",
    "url": "https://integrator.example.com/webhooks/tapaya",
    "events": ["payment_request.updated", "payment.updated"],
    "signingSecret": "..."
}

Signing secret speichern

signingSecret wird nur beim Erstellen des Abonnements zurückgegeben. Speichern Sie es sicher; Sie benötigen es, um die Signatur eingehender Webhooks zu prüfen.

Ein Abonnement gehört dem Integrator und dem Händler, nicht einem Zugriffstoken, und bleibt daher bei der Erneuerung des Tokens bestehen. Beantworten Sie jedes Event mit einem 2xx, sobald Sie es angenommen haben.

Vor dem Abschluss des Verkaufs prüfen

Webhooks sind Benachrichtigungen, kein Zahlungsnachweis, und ein Webhook kann verspätet oder gar nicht ankommen. Schließen Sie einen Verkauf nie allein aufgrund eines Webhooks ab:

  • Wenn ein Webhook ankommt, bestätigen Sie das endgültige Ergebnis über die API, zum Beispiel mit Zahlungsdetails abrufen.
  • Wenn kein Webhook ankommt (innerhalb eines zu Ihrem Bezahlvorgang passenden Timeouts, spätestens jedoch bis zum expiresAt der Anfrage), rufen Sie GET /ecr/payment-requests/{requestId} auf, um ihren aktuellen Status abzufragen, und bestätigen Sie die Zahlung dann wie oben beschrieben über die API.

Referenz

Endpoints

MethodeEndpointBeschreibung
POST/ecr/authTauscht Ihr API-Token und ein merchantToken gegen ein Zugriffstoken ein.
POST/ecr/auth/refreshErneuert ein noch gültiges Zugriffstoken.
GET/ecr/devicesListet die Geräte des Händlers auf. Optionaler Filter connected=true.
GET/ecr/devices/{externalDeviceId}Gibt ein Gerät und seine aktuelle Verfügbarkeit zurück.
POST/ecr/payment-requestsSpeichert eine Zahlungsanfrage und benachrichtigt das Gerät. Erfordert Idempotency-Key.
GET/ecr/payment-requests/{requestId}Gibt den Status der Anfrage, einen etwaigen Ablehnungsgrund und das paymentToken zurück.
POST/ecr/webhook-subscriptionsRegistriert eine HTTPS-URL und Event-Typen. Gibt das signing secret (Signaturschlüssel) nur einmal zurück.
GET/ecr/webhook-subscriptionsListet Ihre Abonnements für den Händler auf, ohne signing secrets.
DELETE/ecr/webhook-subscriptions/{subscriptionId}Entfernt ein Abonnement.

Geräteverfügbarkeit

Beide Geräte-Endpoints geben externalDeviceId, name, connected, availability, lastSeenAt und updatedAt zurück.

WertBeschreibung
readyVerbunden und in der Lage, eine Anfrage zu empfangen und anzuzeigen.
busyVerarbeitet gerade eine Zahlung oder hat eine aktive Anfrage.
unavailableNicht verbunden, ohne gültige Session oder nicht in der Lage, den Zahlungsbildschirm anzuzeigen.

Status der Anfrage

StatusBeschreibung
pendingGespeichert; wartet darauf, dass das Gerät sie annimmt.
acknowledgedDas Gerät hat sie empfangen; die Zahlung existiert möglicherweise noch nicht.
payment_createdEine Zahlung und ihr paymentToken existieren. Verfolgen Sie den weiteren Fortschritt anhand der Zahlung.
rejectedDas Gerät oder Tapaya hat die Anfrage abgelehnt.

Fehler

CodeGrundBeschreibung
403 / 404Objekt nicht verfügbarIhnen fehlt die Berechtigung, oder das Objekt existiert nicht.
409device_busyDas Gerät hat bereits eine aktive Anfrage oder Zahlung.
409device_unavailableDas Gerät ist verbunden, aber nicht bereit.
409idempotency_conflictDer Schlüssel wurde bereits mit einem anderen Body verwendet.
503device_offlineDas Gerät ist nicht verbunden.

Validierungsfehler bei Betrag und Währung folgen denselben Konventionen wie der Rest der Platform API.

Webhook-Events

EventGesendet, wennInhalt von data
device.connectedEin Gerät eine neue Live-Verbindung aufbaut.externalDeviceId, connected, availability, lastSeenAt
device.disconnectedDie Verbindung geschlossen wird oder bei der Verbindungsprüfung (Liveness-Check) ein Timeout auftritt.externalDeviceId, connected, availability, lastSeenAt
device.availability_changedDie Verfügbarkeit zwischen ready, busy und unavailable wechselt.externalDeviceId, availability, optional reason
payment_request.updatedDie Anfrage wird gespeichert, bestätigt oder zurückgewiesen, läuft ab oder erhält eine Zahlung.requestId, externalDeviceId, status, paymentToken, reference, reason, expiresAt
payment.updatedSich der Status der Zahlung ändert.paymentToken, requestId, externalDeviceId, status, reference, amount, currency, optional receiptUrl

Jedes Event kommt als HTTP-POST mit derselben Hülle (Envelope) an:

{
    "eventId": "...",
    "type": "payment_request.updated",
    "occurredAt": "2026-01-13T16:30:59Z",
    "data": {
        "requestId": "...",
        "externalDeviceId": "till-01",
        "status": "acknowledged",
        "paymentToken": null,
        "reference": "ORDER-1042",
        "reason": null,
        "expiresAt": "2026-01-13T16:30:59Z"
    }
}
Fehlt Ihnen etwas auf dieser Seite?Wünschen Sie sich eine Funktion. Wir hängen diese Seite an, damit das Team den Kontext sieht.