Platform API
Umgebungen, Authentifizierung und welche Bereiche der Tapaya Platform API Ihre Integration benötigt.
Mit der Tapaya Platform API verwalten Sie Händler, Zahlungen und Organisationseinstellungen von Ihrem Server aus. Welche Endpoints Sie benötigen, hängt davon ab, wie Ihre App Zahlungen annimmt; nicht jeder Integrator braucht jeden Bereich.
Swagger documentationTapaya Integrator APIEvery endpoint, request field, and enum value, with a console to try requests.Open the API reference
Enums sind numerisch
Felder wie businessTypeId, countryId, currencyId, documentType und refundReasonId sind allesamt numerische
Enums. Die möglichen Werte für jedes dieser Felder sind in der
Swagger-Dokumentation aufgeführt, nicht in diesem Leitfaden.
Welche Bereiche für Sie gelten
| Ihre Integration | Händler-Authentifizierung | Händler-Onboarding | Reporting und Zahlungen |
|---|---|---|---|
| Accept SDK (in Ihre App eingebettet) | 🟢 Erforderlich | 🟡 Optional | 🟡 Optional |
| Nur die App Tapaya Terminal (Intent/Deeplink, ohne SDK) | ⚪ Nicht nötig | 🟡 Optional | 🟡 Optional |
| Nur Reporting / Backoffice | ⚪ Nicht nötig | ⚪ Nicht nötig | 🟢 Erforderlich |
- Händler-Authentifizierung: Das SDK authentifiziert sich als Händler mit einem Login-Token, das Ihr Backend anfordert. Für Integrationen mit Tapaya Terminal nicht nötig: Der Händler meldet sich direkt in der App Tapaya Terminal an, daher gibt es keine SDK-Session, die Ihr Backend authentifizieren müsste.
- Händler-Onboarding: optional für jede Zahlungsintegration, vor Ort oder online. Ein Händler durchläuft das Onboarding einmal, und dieses Onboarding gilt für beide Kanäle. Das Onboarding erfolgt über die Tapaya Platform UI, eine gehostete Einladung oder die API, je nachdem, wer die Daten des Händlers erheben soll.
- Reporting und Zahlungen: optional für beide Zahlungsintegrationen, wenn Sie eigene Dashboards erstellen; erforderlich (und für sich allein ausreichend), wenn Sie ausschließlich Reporting-Daten abrufen und keine eigene Zahlungsintegration haben.
Alle Zeilen erfordern dennoch eine Authentifizierung mit einem Server Secret Token.
Den Secret key für Checkout verwenden
Online-Checkout akzeptiert denselben Secret key von der
Seite API Keys, der hier Server Secret Token heißt.
Checkout erfordert Authorization: Bearer <secret-key> und ordnet die Organisation einem Händler zu.
Die Anforderungen an die Händlerzuordnung finden Sie unter Checkout-Authentifizierung.
Umgebungen
Die Tapaya Platform API unterstützt die folgenden Umgebungen:
- Produktion: Gehostet unter
https://api.tapaya.com. Diese Umgebung verwendet echte Konten, und es werden echte Gelder bewegt. Verwenden Sie die Produktionsumgebung nicht zum Testen. - Sandbox: Gehostet unter
https://api.sandbox.tapaya.com. In dieser Umgebung können Sie Ihre Integration testen, ohne dass echte Gelder bewegt werden. Mehr zum Testen erfahren Sie in unserem Leitfaden zu Tests und Sandbox.
Authentifizierung
Anfragen an die Platform API verwenden Ihr Server Secret Token, das auf der Seite API Keys als Secret key bezeichnet ist. Übergeben Sie es unverändert im Header Authorization Ihrer HTTP-Anfragen.
Authorization: REPLACE_MEUm Ihre Plattform gegenüber der API zu authentifizieren, müssen Sie auf der Seite API Keys einen Secret key erzeugen, hier als Server Secret Token bezeichnet, und REPLACE_ME oben damit ersetzen.
Sicherheitswarnung
Ihr Server Secret Token verfügt über weitreichende Berechtigungen. Geben Sie es niemals in clientseitigem Code (mobilen Apps, Web-Browsern) preis. Es darf ausschließlich von Ihren sicheren Backend-Servern aus verwendet werden.
Wenn ein Token kompromittiert wurde, widerrufen Sie es auf der Seite API Keys; der Widerruf wird sofort wirksam und kann nicht rückgängig gemacht werden. Erzeugen Sie je nach Bedarf vor oder nach dem Widerruf ein Ersatz-Token; eine Aktion zum direkten „Rotieren“ gibt es nicht, aktualisieren Sie daher Ihre Backend-Konfiguration mit dem neuen Token, sobald es erstellt ist.
Keine Einschränkung von Schlüsseln
Jedes Server Secret Token hat dieselben organisationsweiten Berechtigungen; Tokens lassen sich derzeit nicht auf bestimmte Endpoints oder Händler beschränken. Behandeln Sie jedes Token so, als gewähre es vollen API-Zugriff für Ihre Organisation.
Der Server ist nur über das HTTPS-Protokoll erreichbar, wobei auf Infrastrukturebene TLS 1.2 oder höher erzwungen wird. Es gilt eine Ratenbegrenzung (100 Anfragen pro Minute und IP-Adresse); Anfragen, die den Server überlasten, liefern den Fehler 429 Too Many Requests.