# Webhooks
# Überblick
Webhooks sind Benachrichtigungen über Ereignisse im System. Wenn ein bestimmtes
Ereignis eintritt, sendet Xsolla eine HTTP-Anfrage mitsamt den Ereignisdaten an
Ihre Anwendung. In der Regel handelt es sich dabei um eine POST-Anfrage im JSON-
Format.
Ereignisbeispiele:
- Nutzer interagiert mit einem Artikelkatalog
- Bestellung wird bezahlt oder storniert
Wenn ein bestimmtes Ereignis eintritt, benachrichtigt Xsolla Ihr System per
Webhook. Infolgedessen können Sie Aktionen einleiten, wie zum Beispiel:
- das Guthaben eines Nutzers aufladen
- eine Zahlung erstatten
- dem Nutzerkonto neue Artikel gewähren oder Artikel aus dem Nutzerkonto entfernen
- ein Abonnement aktivieren
- einen Nutzer bei Betrugsverdacht sperren
Beispielhafter Webhook-Ablauf bei der Zahlungsabwicklung:

Hinweis
Je nach verwendeter Lösung und Art der Integration können die Webhooks und die Interaktionsabfolge vom angegebenen Beispiel abweichen.
Videoanleitung für die Xsolla-Webhook-Integration:
Webhooks-Einstellungen beim Arbeiten mit Xsolla-Produkten und ‑Lösungen:
| Produkt/Lösung |
Erforderlich/Optional |
Wozu die Webhooks verwendet werden |
| Payments |
Erforderlich |
- Benutzervalidierung.
- Transaktionsdetails im Falle einer erfolgreichen Zahlung oder Zahlungserstattung erhalten
- gekaufte Artikel einem Nutzer gewähren und im Falle einer Stornierung der Bestellung die Artikel entfernen
|
| In-Game Store |
Erforderlich |
- Benutzervalidierung.
- Transaktionsdetails im Falle einer erfolgreichen Zahlung oder Zahlungserstattung erhalten
- gekaufte Artikel einem Nutzer gewähren und im Falle einer Stornierung der Bestellung die Artikel entfernen
|
| Game Sales |
Optional |
Für den Verkauf von Spielschlüsseln sind keine Benutzervalidierung und keine Gewährung von Artikeln erforderlich. Dennoch können Sie Webhooks nutzen, wenn Sie Informationen über Ereignisse erhalten möchten, z. B., wenn eine Bestellung bezahlt oder storniert wird. Wenn Sie sich für Webhooks entscheiden, ist es wichtig, alle eingehenden erforderlichen Webhooks zu verarbeiten.
|
| Subscriptions |
Optional |
Zum Abrufen von Informationen über den Abschluss, die Aktualisierung oder die Kündigung eines Abonnements. Alternativ können Sie die Informationen auch über die API anfordern.
|
| Web Shop |
Erforderlich |
- Benutzervalidierung.
- Transaktionsdetails im Falle einer erfolgreichen Zahlung oder Zahlungserstattung erhalten
- gekaufte Artikel einem Nutzer gewähren und im Falle einer Stornierung der Bestellung die Artikel entfernen
- Für die Benutzerauthentifizierung, wenn Sie Benutzer über deren ID authentifizieren. Alternativ dazu können Sie Benutzer über Xsolla Login authentifizieren.
|
| Digital Distribution Hub |
Erforderlich |
- Benutzervalidierung.
- Transaktions-ID aufseiten von Xsolla mit der Transaktions-ID in Ihrem System verknüpfen
- zusätzliche Transaktionsparameter in der Bestellung übermitteln
- gekaufte Artikel einem Nutzer gewähren und im Falle einer Stornierung der Bestellung die Artikel entfernen
Ausführliche Informationen zum Einrichten von Webhooks für den Digital Distribution Hub finden Sie in der Dokumentation.
|
| Login |
Optional |
Empfang von Ereignisinformationen:
- Benutzerregistrierung/-autorisierung
- Bestätigung der E-Mail-Adresse des Benutzers
- Verknüpfung eines Social-Media-Kontos des Benuters
Ausführliche Informationen zur Einrichtung von Webhooks finden Sie in der -Login-Dokumentation.
|
# Liste der erforderlichen Webhooks
Wenn Sie Produkte und Lösungen verwenden, die Webhooks erfordern, müssen Sie
die Webhooks in Ihrem Kundenportal aktivieren, testen und deren Verarbeitung
einrichten. Wenn bestimmte Ereignisse eintreten, werden die Webhooks der
Reihe nach gesendet. Wenn Sie also einen der Webhooks nicht verarbeiten, werden
die nachfolgenden Webhooks nicht gesendet. Die Liste der erforderlichen
Webhooks finden Sie unten.
## In-Game Store und Payments
Für den Kauf und die Rückgabe von Artikeln auf der Website hat Xsolla zwei
Webhook-Sendeoptionen eingerichtet: Informationen über Zahlungs- und
Transaktionsdaten sowie Informationen über gekaufte Artikeln können entweder
separat oder zusammengefasst in einem Webhook gesendet werden.
Empfang von Informationen in kombinierten Webhooks:
Wenn Sie sich nach dem 22. Januar 2025 im Kundenportal registriert haben, werden
alle Informationen in den Webhooks Erfolgreiche Bezahlung der Bestellung (`order_paid`) und Stornierung der Bestellung
(`order_canceled`) übermittelt. In diesem Fall müssen Sie die Webhooks Zahlung (`payment`) und Erstattung (`refund`) nicht verarbeiten.
Empfang von Informationen in separaten Webhooks:
Wenn Sie sich am oder vor dem 22. Januar 2025 im Kundenportal registriert haben,
empfangen Sie die folgenden Webhooks:
- Zahlung (`payment`) und Erstattung (`refund`) mit Informationen
über die Zahlungsdaten und Transaktionsdetails.
- Erfolgreiche
Bezahlung der Bestellung (`order_paid`) und Stornierung der Bestellung (`order_canceled`)
mit Informationen über die gekauften Artikel.
Sie müssen alle eingehenden Webhooks verarbeiten. Wenn Sie auf die neue Option
(Empfang kombinierter Webhooks) umsteigen möchten, wenden Sie sich an Ihren
Customer Success Manager oder senden Sie eine E-Mail an csm@xsolla.com.
Damit In-Game Store und die Zahlungsverwaltung uneingeschränkt funktionieren,
muss die Verarbeitung der wichtigsten Webhooks implementiert sein.
Beim Empfang kombinierter Webhooks:
| Webhook-Name und ‑Typ |
Beschreibung |
Benutzervalidierung > Benutzervalidierung (user_validation) |
Wird in verschiedenen Phasen des Zahlungsvorgangs gesendet, um sicherzustellen, dass der Nutzer im Spiel registriert ist. |
Spieldienste > kombinierte Webhooks > Erfolgreiche Bezahlung der Bestellung (order_paid) |
Enthält Zahlungsdaten, Transaktionsdetails und Informationen über gekaufte Artikel. Verwenden Sie die Daten aus dem Webhook, um dem Nutzer Artikel zu gewähren. |
Spieldienste > kombinierte Webhooks > Stornierung der Bestellung (order_canceled) |
Enthält Daten der stornierten Zahlung, Transaktionsdetails und Informationen über die gekauften Artikel. Verwenden Sie die Daten aus dem Webhook, um die gekauften Artikel zu entfernen. |
Beim Empfang separater Webhooks:
| Webhook-Name und ‑Typ |
Beschreibung |
Benutzervalidierung > Benutzervalidierung (user_validation) |
Wird in verschiedenen Phasen des Zahlungsvorgangs gesendet, um sicherzustellen, dass der Nutzer im Spiel registriert ist. |
Zahlungen > Zahlung (payment) |
Enthält Zahlungsdaten und Transaktionsdetails. |
Spieldienste > separate Webhooks > Erfolgreiche Bezahlung der Bestellung (order_paid) |
Enthält Informationen über gekaufte Artikel. Verwenden Sie die Daten aus dem Webhook, um dem Nutzer Artikel hinzuzufügen. |
Zahlungen > Erstattung (refund) |
Enthält Zahlungsdaten und Transaktionsdetails. |
Spieldienste > separate Webhooks > Stornierung der Bestellung (order_canceled) |
Enthält Informationen über die gekauften Artikel und die ID der stornierten Transaktion. Verwenden Sie die Daten aus dem Webhook, um die gekauften Artikel zu entfernen. |
Falls die Artikelkatalogpersonalisierung aufseiten Ihrer Anwendung
implementiert ist, müssen Sie den Webhook Katalogpersonalisierung aufseiten des
Partners einrichten.
## Subscriptions
Um Abo-Modelle automatisch zu verwalten, muss die Verarbeitung der wichtigsten
Webhooks implementiert sein:
- Benutzervalidierung
(`user_validation`) – wird in verschiedenen Phasen des Bezahlvorgangs gesendet,
um sicherzustellen, dass der Nutzer im Spiel registriert ist.
- Zahlung (`payment`) – wird gesendet,
wenn eine Bestellung bezahlt wird, und enthält Zahlungsdaten sowie
Transaktionsdetails.
- Abgeschlossenes
Abonnement (`create_subscription`) – wird gesendet, wenn ein Webhook vom
Typ Zahlung erfolgreich verarbeitet
wurde oder der Nutzer ein Probeabo abgeschlossen hat. Der Webhook enthält
Details über das abgeschlossene Abonnement und die Nutzerdaten. Verwenden Sie
die Webhook-Daten, um das Abonnement für den Nutzer zu aktivieren.
- Aktualisiertes
Abonnement (`update_subscription`) – wird gesendet, wenn ein Abonnement
verlängert oder geändert und Webhook vom Typ Zahlung
erfolgreich verarbeitet wurde. Der Webhook enthält Details über das
abgeschlossene Abonnement und die Nutzerdaten. Verwenden Sie die Webhook-Daten,
um das Abonnement des Nutzers zu verlängern oder die Abonnementparameter zu
ändern.
- Erstattung (`refund`) – wird gesendet,
wenn eine Bestellung storniert wird und enthält die Daten der stornierten
Zahlung sowie Transaktionsdetails.
- Gekündigtes Abonnement
(`cancel_subscription`) – wird gesendet, wenn ein Webhook vom Typ Erstattung erfolgreich verarbeitet oder
das Abonnement aus einem anderen Grund gekündigt wurde. Der Webhook enthält
Informationen über das Abonnement und die Nutzerdaten. Verwenden Sie die
Webhook-Daten, um die vom Nutzer abgeschlossenen Abonnements zu kündigen.
# Webhooks im Kundenportal einrichten
## Allgemeine Einstellungen
So aktivieren Sie den Empfang von Webhooks:
1. Navigieren Sie im Kundenportal-Projekt zu Projekteinstellu
ngen > Webhooks.
2. Geben Sie im Feld Webhook-Server die URL Ihres Servers an, auf dem Sie
Webhooks im Format `https://example.com` empfangen möchten. Sie können auch
eine URL aus einem Tool, mit dem sich Webhooks testen lassen, angeben.
Hinweis:
Für die Datenübertragung wird das HTTPS-Protokoll verwendet; das HTTP-Protokoll wird nicht unterstützt.
3. Standardmäßig wird ein geheimer Schlüssel zum Signieren von Projekt-Webhooks
generiert. Wenn Sie einen neuen geheimen Schlüssel generieren möchten, klicken
Sie auf das Aktualisieren-Symbol.
4. Klicken Sie auf Webhooks aktiveren.

Hinweis
Webhooks können Sie auch über eine beliebige zweckbestimmte Website (z. B. webhook.site) oder Plattform (z. B. ngrok) testen.
Hinweis
Sie können Webhooks nicht gleichzeitig an verschiedene URLs senden. Im Kundenportal können Sie jedoch zunächst eine URL zum Testen angeben und diese dann durch die echte URL ersetzen.
So deaktivieren Sie den Empfang von Webhooks:
1. Navigieren Sie im Kundenportal-Projekt zu Projekteinstellu
ngen > Webhooks.
2. Klicken Sie auf Webhooks deaktivieren.
## Erweiterte Einstellungen
Für die Webhooks im Abschnitt Payments und Store sind erweiterte
Einstellungen verfügbar. Diese werden automatisch unter dem Block Allgemeine Einstellungen angezeigt, nachdem Sie auf die
Schaltfläche Webhooks abrufen geklickt haben.
Hinweis
Wenn die erweiterten Einstellungen nicht angezeigt werden, müssen Sie zuerst den Webhook-Empfang in den allgemeinen Einstellungen aktivieren und dann zur Registerkarte Testen > Payments und Store wechseln.
Hier können Sie den Empfang zusätzlicher Informationen in Webhooks einrichten.
Dazu müssen Sie die entsprechenden Schalter aktivieren. In jeder
Berechtigungszeile werden die Webhooks angezeigt, die von der Änderung der
Einstellungen betroffen sind.
| Schalter |
Beschreibung |
| Infos über das gespeicherte Zahlungskonto anzeigen |
Informationen über die gespeicherte Zahlungsmethode werden in dem benutzerdefinierten Objekt payment_account übermittelt. |
| Infos über Transaktionen anzeigen, die mit gespeicherten Zahlungsmethoden getätigt wurden |
Informationen werden in den folgenden benutzerdefinierten Parametern des Webhooks übermittelt. saved_payment_method:0 – die gespeicherte Zahlungsmethode wurde nicht verwendet1 – die Zahlungsmethode wurde während des aktuellen Bezahlvorgangs gespeichert2 – die zuvor gespeicherte Zahlungsmethode wird verwendet
payment_type:1 – Einmalzahlung2 – wiederkehrende Zahlung
|
| Bestellobjekt dem Webhook hinzufügen |
Die Informationen über die Bestellung werden im order-Objekt des Zahlung-Webhooks übermittelt. |
| Nur notwendige Nutzerparameter ohne vertrauliche Daten senden |
Im Webhook werden nur die folgenden Nutzerinformationen übermittelt: |
| Individuelle Parameter senden |
Informationen über individuelle Tokenparameter werden in dem Webhook übermittelt. |
| BLZ und Endziffern von Karten anzeigen |
Im Webhook werden nur die folgenden Informationen über die Bankkartennummer übermittelt: - die ersten sechs Ziffern im Parameter
card_bin - die letzten vier Ziffern im Parameter
card_suffix
|
| Kartenmarke anzeigen |
Die Marke der Karte, mit der die Zahlung getätigt wurde. Zum Beispiel: Mastercard oder Visa. |

# Webhooks im Kundenportal testen
Webhooks zu testen, hilft dabei, sicherzustellen, dass das Projekt sowohl bei
Ihnen als auch aufseiten von Xsolla korrekt eingerichtet ist.
Sind die Webhooks erfolgreich eingerichtet, wird unterhalb des
Einrichtungsbereichs ein Bereich zum Testen von Webhooks angezeigt.

Der Testbereich im Kundenportal variiert je nach dem, welche Webhook-
Empfangsoption ausgewählt sind.
Beim Empfang kombinierter Webhooks:
Beim Empfang separater Webhooks:
Hinweis
Wird im Testbereich eine Fehlermeldung angezeigt, wonach der Test nicht erfolgreich war, sollten Sie in den Einstellungen Ihres Webhook-Listener prüfen, wie dieser auf Webhooks antwortet. Die Gründe für den fehlgeschlagenen Test sind in den Testergebnissen ersichtlich.
Beispiel:
Sie haben eine spezielle Website (z. B. webhook.site) zum Testen verwendet.
Im Abschnitt Test: Antwort auf eine ungültige Signatur wird ein Fehler angezeigt.
Das liegt daran, dass Xsolla einen Webhook mit falscher Signatur gesendet hat und nun erwartet, dass Ihr Handler mit dem HTTP-Statuscode 4xx und dem Fehlercode INVALID_SIGNATURE antwortet.
webhook.site antwortet allen Webhooks mit dem HTTP-Statuscode 200, selbst solchen Webhooks mit ungültiger Signatur. Weil der HTTP-Statuscode 4xx nicht wie erwartet empfangen wurde, ist das Testergebnis fehlerhaft.

Im Folgenden ist der Testvorgang für das Szenario mit kombinierten Webhooks
beschrieben.
## Payments und Store
Auf der Registerkarte Payments und Store können Sie die folgenden
Webhooks testen:
- Benutzervalidierung
(`user_validation`)
- Erfolgreiche Bezahlung
der Bestellung (`order_paid`)
- Stornierung der Bestellung
(`order_canceled`)
So testen Sie die Webhooks:
1. Wechseln Sie im Webhooks-Testbereich zur Registerkarte Payments und
Store.
2. Wählen Sie im Drop-down-Menü einen Artikeltyp aus. Ist der ausgewählte
Artikeltyp im Kundenportal nicht eingerichtet, klicken Sie auf:
* Verknüpfen, sofern das entsprechende Modul noch nicht verknüpft ist,
* Konfigurieren, sofern das Modul bereits verknüpft, aber die Einrichtung
noch nicht abgeschlossen ist.
Durch Klick auf die Schaltfläche werden Sie
zum entsprechenden Abschnitt im Kundenportal weitergeleitet. Nachdem Sie den
Artikel angelegt haben, sollten Sie zum Webhook-Testbereich zurückkehren und
mit dem nächsten Schritt fortfahren.
3. Füllen Sie die Pflichtfelder aus: - Wählen Sie die SKU des
Artikels aus der der Drop-down-Liste aus, und legen Sie die Menge fest. Sie
können mehrere Artikel desselben Typs wählen, indem Sie auf + klicken
und einen weiteren Artikel in der neuen Zeile hinzufügen.
- Benutzer-
ID – Zum Testen können Sie eine beliebige Kombination aus Buchstaben und
Ziffern angeben.
- Public-User-ID – ID, die dem Nutzer bekannt
ist, z. B. E-Mail-Adresse oder Nickname. Dieses Feld wird angezeigt, sofern die
Public-User-ID in Ihrem Projekt unter Pay Station > Einstellungen
aktiviert ist.
- Geben Sie einen beliebigen Wert in das Feld Xsolla-
Bestell-ID ein.
- Xsolla-Rechnungs-ID – Transaktions-ID
aufseiten von Xsolla. Zum Testen können Sie eine beliebige Ziffernfolge
angeben.
- Rechnungs-ID – Transaktions-ID aufseiten Ihres Spiels.
Zum Testen können Sie eine beliebige Kombination aus Buchstaben und Ziffern
angeben. Dieser Parameter ist für eine erfolgreiche Zahlung nicht erforderlich.
Allerdings können Sie die Transaktions-ID aufseiten Ihres Spiels mit der
Transaktions-ID aufseiten von Xsolla verknüpfen, indem Sie den Parameter
übermitteln.
- Betrag – Zahlungsbetrag. Zum Testen können Sie
eine beliebige Ziffernfolge angeben.
- Währung – Wählen Sie eine
Währung aus der Drop-down-Liste aus.
4. Klicken Sie auf Webhooks testen.
Die Webhooks Benutzervalidierung, Erfolgreiche Bezahlung der Bestellung und Stornierung der Bestellung
werden zusammen mit den angegebenen Daten an die festgelegte URL gesendet. Die
Testergebnisse der einzelnen Webhook-Typen werden unter der Schaltfläche
Webhooks testen angezeigt.
Wenn in Ihrem Projekt die Public-User-ID aktiviert ist, werden ebenso die
Ergebnisse einer Benutzerprüfung angezeigt.
Für jeden Webhook müssen Sie die Verarbeitung beider Szenarien, also
erfolgreich und fehlerbehaftet, konfigurieren.

## Subscriptions
Auf der Registerkarte Subscriptions können Sie die folgenden Webhooks
testen:
- Benutzervalidierung
(`user_validation`)
- Zahlung (`payment`)
Hinweis
Im Kundenportal können Sie nur die grundlegenden Webhooks vom Typ "Benutzervalidierung" und "Zahlung" testen. Wie Sie andere Webhook-Typen testen, erfahren Sie unter:
Hinweis
Damit Sie Webhooks testen können, müssen Sie unter Kundenportal > Subscriptions > Abo-Modelle mindestens eine Abo-Modell erstellt haben.
So testen Sie die Webhooks: - Wechseln Sie im Testbereich zur
Registerkarte Subscriptions.
- Füllen Sie die Pflichtfelder aus:
- Benutzer-ID – Zum Testen können Sie eine beliebige
Kombination aus Buchstaben und Ziffern angeben.
- Xsolla-Rechnungs-
ID – Transaktions-ID aufseiten von Xsolla. Zum Testen können Sie eine
beliebige Ziffernfolge angeben.
- Public- User-ID – ID, die einem
Nutzer bekannt ist, z. B. E-Mail-Adresse oder Nickname. Dieses Feld wird
angezeigt, sofern die Public-User-ID in Ihrem Projekt unter Pay Station >
Einstellungen > Sonstige Einstellungen aktiviert ist.
- Währung – Wählen Sie eine Währung aus der Drop-down-Liste aus.
- ID des Abo-Modells – Abo-Modell. Wählen Sie ein Abo-Modell aus der
Drop-down-Liste.
- Abo-Produkt – Wählen Sie ein Produkt aus der
Drop-down-Liste (optional).
- Betrag – Zahlungsbetrag. Zum Testen
können Sie eine beliebige Ziffernfolge angeben.
- Rechnungs-ID –
Transaktions-ID aufseiten Ihres Spiels. Zum Testen können Sie eine beliebige
Kombination aus Buchstaben und Ziffern angeben. Dieser Parameter ist nicht
erforderlich, um die Zahlung erfolgreich zu verarbeiten. Allerdings können Sie
die Transaktions-ID aufseiten Ihres Spiels mit der Transaktions-ID aufseiten
von Xsolla verknüpfen, indem Sie den Parameter übermitteln.
- Probezeitraum. Wenn Sie den Absc
hluss eines Abonnements ohne Probezeitraum oder die Verlängerung eines Abonnements testen möchten, geben Sie den Wert
0 an.
- Klicken Sie auf Webhooks
testen.
Unter der angegebenen URL erhalten Sie Webhooks mit ausgefüllten Daten. Die
Testergebnisse jedes Webhooks, sowohl für ein erfolgreiches Szenario als auch
für ein Fehlerszenario, werden unter der Schaltfläche Webhooks testen
angezeigt.
# Webhook-Listener
Ein Webhook-Listener ist ein Programmcode, der es ermöglicht, eingehende
Webhooks unter einer bestimmten URL-Adresse zu empfangen, eine Signatur zu generieren und dem Xsolla-Webhook-Server zu antworten.
Implementieren Sie anwendungsseitig den Empfang von Webhooks von den folgenden
IP-Adressen:
- `185.30.20.0/24`
- `185.30.21.0/24`
- `185.30.22.0/24`
- `185.30.23.0/24`
- `34.102.38.178`
- `34.94.43.207`
- `35.236.73.234`
- `34.94.69.44`
- `34.102.22.197`
Wenn Sie das Produkt Login integriert haben, müssen
zusätzlich implementieren, dass Webhooks von den folgenden IP-Adressen
verarbeitet werden:
- `34.94.0.85`
- `34.94.14.95`
- `34.94.25.33`
- `34.94.115.185`
- `34.94.154.26`
- `34.94.173.132`
- `34.102.48.30`
- `35.235.99.248`
- `35.236.32.131`
- `35.236.35.100`
- `35.236.117.164`
Einschränkungen:
- In der Datenbank Ihrer Anwendung dürfen nicht mehrere erfolgreiche
Transaktionen mit derselben ID vorhanden sein.
- Wenn der Webhook-Listener einen Webhook mit einer ID empfängt, die bereits in
der Datenbank vorhanden ist, muss das Ergebnis der zuvor verarbeiteten
Transaktion zurückgeben werden. Es wird davon abgeraten, dem Nutzer einen
gekauften Artikel zweimal zu gewähren und doppelte Datensätze in der Datenbank
anzulegen.
## Signatur generieren
Um eine sichere Datenübertragung zu gewährleisten, müssen Sie verifizieren, ob
der Webhook tatsächlich vom Xsolla-Server gesendet und während der Übertragung
nicht manipuliert wurde. Generieren Sie dazu Ihre eigene Signatur basierend auf
der Payload des Anfragerumpfs und vergleichen Sie diese mit der Signatur im
`authorization`-Header der eingehenden Anfrage. Wenn die Signaturen
übereinstimmen, ist der Webhook authentisch und kann gefahrlos verarbeitet
werden.
Verifizierungsablauf:
1. Rufen Sie die Signatur aus dem `authorization`-Header der eingehenden Webhook-
Anfrage ab. Das Header-Format ist wie folgt: `Signature `.
2. Rufen Sie den Webhook-Anfragerumpf im JSON-Format ab. Hinweis
Verwenden Sie die JSON-Payload
genau so, wie Sie sie erhalten haben. Die Payload darf nicht geparst oder neu
codiert werden, da dies die Formatierung verändert, woraufhin die
Signaturüberprüfung fehlschlägt.
3. Generieren Sie Ihre eigene Signatur für den Abgleich:
- Verknüpfen Sie die JSON-Payload mit dem geheimen Schlüssel Ihres Projekts,
indem Sie den Schlüssel an das Ende des Strings anhängen.
- Wenden Sie
die kryptografische Hash-Funktion SHA-1 auf den resultierenden String an. Als
Ergebnis erhalten Sie einen hexadezimalen String aus Kleinbuchstaben.
4. Vergleichen Sie die generierte Signatur mit der Signatur im
`authorization`-Header. Wenn beide übereinstimmen, ist der Webhook authentisch.
Nachfolgend finden Sie Beispiele für die Implementierung der
Signaturgenerierung für die folgenden Sprachen: C#, C++, Go, PHP und Node.js.
### Beispielhafter Webhook (HTTP):
```http
POST /your_uri HTTP/1.1
host: your.host
accept: application/json
content-type: application/json
content-length: 165
authorization: Signature 52eac2713985e212351610d008e7e14fae46f902
{
"notification_type":"user_validation",
"user":{
"ip":"127.0.0.1",
"phone":"18777976552",
"email":"email@example.com",
"id":1234567,
"name":"Xsolla User",
"country":"US"
}
}
```
### Beispielhafter Webhook (curl):
```bash
curl -v 'https://your.hostname/your/uri' \
-X POST \
-H 'authorization: Signature 52eac2713985e212351610d008e7e14fae46f902' \
-d '{
"notification_type":
"user_validation",
"user":
{
"ip": "127.0.0.1",
"phone": "18777976552",
"email": "email@example.com",
"id": 1234567,
"name": "Xsolla User",
"country": "US"
}
}'
```
### Implementierung der Signaturgenerierung in C# (Allgemeines Beispiel):
Hinweis
Dieses Code-Beispiel ist kompatibel mit .NET Framework 4.0 und höher sowie mit .NET Core und anderen modernen .NET-Versionen. Die Signaturüberprüfung verwendet einen Vergleich mit konstanter Zeit mithilfe der ConstantTimeEquals-Methode zur Verhinderung von Timing-Angriffen.
```csharp
using System;
using System.Security.Cryptography;
using System.Text;
public static class XsollaWebhookSignature
{
public static string ComputeSha1(string jsonBody, string secretKey)
{
// Concatenation of the JSON from the request body and the project's secret key
string dataToSign = jsonBody + secretKey;
using (SHA1 sha1 = SHA1.Create())
{
byte[] hashBytes = sha1.ComputeHash(Encoding.UTF8.GetBytes(dataToSign));
// Convert hash bytes to lowercase hexadecimal string
var hexString = new StringBuilder(hashBytes.Length * 2);
foreach (byte b in hashBytes)
{
hexString.Append(b.ToString("x2"));
}
return hexString.ToString();
}
}
public static bool VerifySignature(string jsonBody, string secretKey, string receivedSignature)
{
string computedSignature = ComputeSha1(jsonBody, secretKey);
string receivedSignatureLower = receivedSignature.ToLower();
// Use constant-time comparison to prevent timing attacks
return ConstantTimeEquals(computedSignature, receivedSignatureLower);
}
private static bool ConstantTimeEquals(string a, string b)
{
if (a.Length != b.Length)
{
return false;
}
int result = 0;
for (int i = 0; i < a.Length; i++)
{
result |= a[i] ^ b[i];
}
return result == 0;
}
}
```
### Implementierung der Signaturgenerierung in C# (.NET 5.0 und höher):
Hinweis
Um die Convert.ToHexString-Methode nutzen zu können, brauchen Sie .NET 5.0 oder höher.
Über .NET 7.0 oder höher verfügen, können Sie anstelle von
ConstantTimeEquals auch die
CryptographicOperations.FixedTimeEquals-Methode verwenden.
```csharp
// For .NET 5.0 and later, you can use the more concise Convert.ToHexString method:
using System;
using System.Security.Cryptography;
using System.Text;
public static class XsollaWebhookSignature
{
public static string ComputeSha1(string jsonBody, string secretKey)
{
string dataToSign = jsonBody + secretKey;
using var sha1 = SHA1.Create();
byte[] hashBytes = sha1.ComputeHash(Encoding.UTF8.GetBytes(dataToSign));
return Convert.ToHexString(hashBytes).ToLower();
}
public static bool VerifySignature(string jsonBody, string secretKey, string receivedSignature)
{
string computedSignature = ComputeSha1(jsonBody, secretKey);
string receivedSignatureLower = receivedSignature.ToLower();
// Use constant-time comparison to prevent timing attacks
return ConstantTimeEquals(computedSignature, receivedSignatureLower);
}
private static bool ConstantTimeEquals(string a, string b)
{
if (a.Length != b.Length)
{
return false;
}
int result = 0;
for (int i = 0; i < a.Length; i++)
{
result |= a[i] ^ b[i];
}
return result == 0;
}
}
```
### Implementierung der Signaturgenerierung in C# (.NET 7.0 und höher):
Hinweis
Wenn Sie über .NET 7.0 oder höher verfügen, könne Sie die CryptographicOperations.FixedTimeEquals-Methode verwenden.
```csharp
// For .NET 7.0+, you can use the built-in CryptographicOperations.FixedTimeEquals:
using System.Security.Cryptography;
public static bool VerifySignature(string jsonBody, string secretKey, string receivedSignature)
{
string computedSignature = ComputeSha1(jsonBody, secretKey);
byte[] computedBytes = Encoding.UTF8.GetBytes(computedSignature);
byte[] receivedBytes = Encoding.UTF8.GetBytes(receivedSignature.ToLower());
return CryptographicOperations.FixedTimeEquals(computedBytes, receivedBytes);
}
```
### Implementierung der Signaturgenerierung in C++ (Beispiel):
```c++
#include
#include
#include
#include
class XsollaWebhookSignature {
public:
static std::string computeSha1(const std::string& jsonBody, const std::string& secretKey) {
// Concatenation of the JSON from the request body and the project's secret key
std::string dataToSign = jsonBody + secretKey;
unsigned char digest[SHA_DIGEST_LENGTH];
// Create SHA1 hash
SHA1(reinterpret_cast(dataToSign.c_str()),
dataToSign.length(), digest);
// Convert to lowercase hexadecimal string
std::ostringstream hexStream;
hexStream << std::hex << std::setfill('0');
for (int i = 0; i < SHA_DIGEST_LENGTH; ++i) {
hexStream << std::setw(2) << static_cast(digest[i]);
}
return hexStream.str();
}
static bool verifySignature(const std::string& jsonBody, const std::string& secretKey, const std::string& receivedSignature) {
std::string computedSignature = computeSha1(jsonBody, secretKey);
// Timing-safe comparison
if (computedSignature.length() != receivedSignature.length()) {
return false;
}
volatile unsigned char result = 0;
for (size_t i = 0; i < computedSignature.length(); ++i) {
result |= (computedSignature[i] ^ receivedSignature[i]);
}
return result == 0;
}
};
```
### Implementierung der Signaturgenerierung in Go (Beispiel):
```go
package main
import (
"crypto/sha1"
"crypto/subtle"
"encoding/hex"
"strings"
)
type XsollaWebhookSignature struct{}
func (x *XsollaWebhookSignature) ComputeSha1(jsonBody, secretKey string) string {
// Concatenation of the JSON from the request body and the project's secret key
dataToSign := jsonBody + secretKey
// Create SHA1 hash
h := sha1.New()
h.Write([]byte(dataToSign))
signature := h.Sum(nil)
// Convert to lowercase hexadecimal string
return strings.ToLower(hex.EncodeToString(signature))
}
func (x *XsollaWebhookSignature) VerifySignature(jsonBody, secretKey, receivedSignature string) bool {
computedSignature := x.ComputeSha1(jsonBody, secretKey)
receivedSignatureLower := strings.ToLower(receivedSignature)
// Use constant time comparison to prevent timing attacks
return subtle.ConstantTimeCompare([]byte(computedSignature), []byte(receivedSignatureLower)) == 1
}
```
### Implementierung der Signaturgenerierung in PHP (Beispiel):
```php
```
### Implementierung der Signaturgenerierung in Node.js (Beispiel):
```js
const crypto = require('crypto');
class XsollaWebhookSignature {
// IMPORTANT: jsonBody must be the raw JSON string exactly as received from Xsolla
static computeSha1(jsonBody, secretKey) {
// Concatenation of the JSON from the request body and the project's secret key
const dataToSign = jsonBody + secretKey;
// Create SHA1 hash
const hash = crypto.createHash('sha1');
hash.update(dataToSign, 'utf8');
// Convert to lowercase hexadecimal string
return hash.digest('hex').toLowerCase();
}
static verifySignature(jsonBody, secretKey, receivedSignature) {
const computedSignature = this.computeSha1(jsonBody, secretKey);
const cleanReceivedSignature = receivedSignature.toLowerCase();
// Check if signatures have the same length before using timingSafeEqual
if (computedSignature.length !== cleanReceivedSignature.length) {
return false;
}
try {
return crypto.timingSafeEqual(
Buffer.from(computedSignature, 'hex'),
Buffer.from(cleanReceivedSignature, 'hex')
);
} catch (error) {
// Return false if there's any error (e.g., invalid hex characters)
return false;
}
}
}
```
## Dem Webhook antworten
Ihr Server muss wie folgt antworten, um den Empfang eines Webhooks zu
bestätigen:
* mit dem HTTP-Statuscode 200, 201 oder 204 ohne Nachrichtenrumpf im Falle einer
positiven Antwort
* mit dem HTTP-Statuscode 400 samt Problembeschreibung, sofern der
angegebene Benutzer nicht gefunden oder eine ungültige Signatur übermittelt
wurde. Ihr Webhook-Handler kann ebenso mit dem HTTP-Stautscode 5xx antworten,
wenn Ihr Server vorübergehend Probleme hat.
Wenn der Xsolla-Server keine Antwort auf die Webhooks Erfolgreiche Bezahlung der
Bestellung und Stornierung
der Bestellung empfangen hat oder aber eine Antwort mit dem HTTP-Statuscode
5xx, werden die Webhooks gemäß dem folgenden Zeitplan erneut gesendet:
* zwei Versuche im Abstand von 5 Minuten
* sieben Versuche im Abstand von jeweils 15 Minuten
* zehn Versuche im Abstand von jeweils 60 Minuten
Innerhalb von 12 Stunden nach dem ersten Versuch werden maximal 20 Versuche
unternommen, Webhooks zu senden.
Die Logik für das erneute Senden der Webhooks Zahlung und Erstattung ist auf der jeweiligen Webhook-
Seite beschrieben.
Hinweis
Die Zahlung wird dem Nutzer auch dann erstattet, wenn alle folgenden Bedingungen erfüllt sind:
- Xsolla hat die Erstattung veranlasst.
- Als Antwort auf einen Webhook wurde ein Statuscode
4xx zurückgegeben, oder es wurde nach allen weiteren Zustellversuchen keine Antwort empfangen, oder es wurde der Statuscode 5xx zurückgegeben.
Wenn der Xsolla-Server keine Antwort auf den Webhook Benutzervalidierung empfangen
hat oder aber eine Antwort mit dem HTTP-Statuscode 400 oder 5xx, wird der
Webhook Benutzervalidierung
nicht erneut gesendet. Stattdessen wird dem Nutzer eine Fehlermeldung angezeigt
und die Webhooks Zahlung und Erfolgreiche Bezahlung der
Bestellung werden nicht gesendet.
# Fehler
Fehlercodes für den HTTP-Code 400:
| Code |
Nachricht |
| INVALID_USER |
Ungültiger Benutzer |
| INVALID_PARAMETER |
Ungültiger Parameter |
| INVALID_SIGNATURE |
Unzulässige Signatur |
| INCORRECT_AMOUNT |
Ungültiger Betrag |
| INCORRECT_INVOICE |
Ungültige Rechnung |
```
HTTP/1.1 400 Bad Request
{
"error":{
"code":"INVALID_USER",
"message":"Invalid user"
}
}
```
# Liste der Webhooks
Hinweis
Der Benachrichtigungstyp wird im Parameter notification_type gesendet.
| Webhook |
Benachrichtigungstyp |
Beschreibung |
| Benutzervalidierung |
user_validation |
Wird versendet, um zu prüfen, ob ein Benutzer im Spiel existiert. |
| Benutzersuche |
user_search |
Wird versendet, um Benutzerinformationen anhand der öffentlichen Benutzer-ID abzurufen. |
| Zahlung |
payment |
Wird versendet, wenn ein Benutzer eine Zahlung abschließt. |
| Erstattung |
refund |
Wird versendet, falls eine Zahlung aus einem beliebigen Grund storniert werden muss. |
| Teilerstattung |
partial_refund |
Wird versendet, falls eine Zahlung aus einem beliebigen Grund teilweise storniert werden muss. |
| Abgelehnte Zahlung |
ps_declined |
Wird versendet, wenn eine Zahlung vom Zahlungssystem abgelehnt wird. |
| Abgelehnte Transaktion (AFS) |
afs_reject |
Wird versendet, wenn eine Transaktion während einer AFS-Prüfung abgelehnt wird. |
| Aktualisierte AFS-Blockliste |
afs_black_list |
Wird bei Aktualisierung der AFS-Blockliste versendet. |
| Abgeschlossenes Abonnement |
create_subscription |
Wird versendet, wenn ein Benutzer ein Abonnement abschließt. |
| Aktualisiertes Abonnement |
update_subscription |
Wird versendet, wenn ein Abonnement erneuert oder geändert wird. |
| Storniertes Abonnement |
cancel_subscription |
Wird versendet, wenn ein Abonnement gekündigt wird. |
| Automatisch endendes Abonnement |
non_renewal_subscription |
Wird versendet, wenn der Status auf "Automatisch endend" gesetzt wird. |
| Zahlungskonto hinzufügen |
payment_account_add |
Wird versendet, wenn ein Benutzer ein Zahlungskonto hinzufügt oder speichert. |
| Zahlungskonto entfernen |
payment_account_remove |
Wird versendet, wenn ein Benutzer das Zahlungskonto aus den gespeicherten Konten entfernt. |
| Benutzervalidierung im Web Shop |
- |
Wird von einer Web Shop-Seite gesendet, um zu prüfen, ob ein Benutzer im Spiel vorhanden ist. |
| Katalogpersonalisierung aufseiten des Partners |
partner_side_catalog |
Wird gesendet, wenn ein Benutzer mit dem Shop interagiert. |
| Erfolgreiche Bezahlung der Bestellung |
order_paid |
Wird gesendet, wenn eine Bestellung bezahlt wurde. |
| Stornierung der Bestellung |
order_canceled |
Wird gesendet, wenn eine Bestellung storniert wird. |
| Streitfall |
dispute |
Wird gesendet, wenn ein neuer Streiftall eröffnet wird. |
Version: 1.0
## Servers
```
https://api.xsolla.com/merchant/v2
```
## Download OpenAPI description
[Webhooks](https://developers.xsolla.com/_bundle/@l10n/de/webhooks/index.yaml)
## Benutzervalidierung
### Benutzersuche
- [POST user-search](https://developers.xsolla.com/de/webhooks/user-validation/user-search.md): Public User ID ist ein Parameter, der den Benutzer eindeutig identifiziert und ihm bekannt ist, im Gegensatz zur User ID (Public User ID kann eine E-Mail-Adresse, ein Anzeigename usw. sein). Xsolla sendet einen Webhook vom Typ user_search, wenn ein Kauf außerhalb des Spieleshops getätigt wird (z. B. an einem Automaten).
### Benutzervalidierung
- [POST user-validation](https://developers.xsolla.com/de/webhooks/user-validation/user-validation.md): Xsolla sendet einen Webhook vom Typ user_validation an die Webhook-URL, um zu
überprüfen, ob ein Benutzer im Spiel registriert ist. Die Anfrage wird im
Rahmen des Bezahlvorgangs mehrfach gesendet:
* wenn ein Benutzer eine Zahlungsmethode im Zahlungsportal auswählt
* wenn ein Benutzer Daten in die Zahlungsmaske eingibt, z. B. Bankkartendaten
oder die Postleitzahl bei Zahlung über PayPal
* wenn ein Benutzer auf Jetzt bezahlen klickt, um mit der Zahlung fortzufahren
* wenn der Bezahlvorgang abgeschlossen ist und der Transaktionsstatus sich in
done ändert
Die Anfrage wird beim Bezahlen gesendet, ganz gleich, welche Zahlungsmethode
zum Einsatz kommt.
Wenn Sie die Webhook-URL im Kundenportal speichern, können Sie Berechtigungen
erteilen, detaillierte Informationen in Webhooks zu empfangen. Aktivieren Sie
dazu im Kundenportal unter Projekteins
tellungen > Webhooks > Erweiterte Einstellungen die entsprechenden
Schalter.
Hinweis
Wenn Sie sich am oder vor dem 22. Januar 2025 im Kundenportal registriert haben, finden Sie die Schalter unter Projekteinstellungen > Webhooks > Testen > Payments > Erweiterte Einstellungen.
Schalter
Beschreibung
Nur notwendige Nutzerparameter ohne vertrauliche Daten senden
Im Webhook werden nur die folgenden Nutzerinformationen übermittelt:IDLand
Individuelle Parameter senden
Informationen über individuelle Tokenparameter werden in dem Webhook übermittelt.
### Benutzervalidierung im Web Shop
- [POST user-validation-in-webshop](https://developers.xsolla.com/de/webhooks/user-validation/user-validation-in-webshop.md): Xsolla sendet einen Webhook von einer Webshop-Seite, um zu prüfen, ob ein Benutzer im Spiel vorhanden ist. Der Webhook wird von der folgenden IP-Adresse gesendet: 34.102.38.178.
Hinweis
Der Webhook dient lediglich der Benutzervalidierung im Webshop. Wie man Webhooks im Site Builder konfiguriert, erfahren Sie in dieser Anleitung.
## Payments
### Zahlungskonto hinzufügen
- [POST add-payment-account](https://developers.xsolla.com/de/webhooks/payments/add-payment-account.md): Xsolla sendet eine Webhook vom Typ payment_account_add an die Webhook-URL, wenn ein Benutzer bei einem Ingame-Kauf ein Zahlungskonto hinzufügt oder speichert. Wenden Sie sich an Ihren Customer Success Manager oder senden Sie eine E-Mail an csm@xsolla.com, wenn Sie diesen Webhook erhalten möchten.
### Teilerstattung
- [POST partial-refund](https://developers.xsolla.com/de/webhooks/payments/partial-refund.md): Wird ein Betrag teilweise erstattet, sendet Xsolla die Details der stornierten
Transaktion in einem Webhook vom Typ partial_refund an die Webhook-URL.
Weitere Informationen zu Teilerstattungen finden Sie in dieser Anleitung.
Wenn Sie die Webhook-URL im Kundenportal speichern, können Sie Berechtigungen
erteilen, detaillierte Informationen in Webhooks zu empfangen. Aktivieren Sie
dazu im Kundenportal unter Projekteins
tellungen > Webhooks > Erweiterte Einstellungen den folgenden
Schalter.
Hinweis
Wenn Sie sich am oder vor dem 22. Januar 2025 im Kundenportal registriert haben, finden Sie die Schalter unter Projekteinstellungen > Webhooks > Testen > Payments > Erweiterte Einstellungen.
Schalter
Beschreibung
Infos über Transaktionen anzeigen, die mit gespeicherten Zahlungsmethoden getätigt wurden
Informationen werden in den folgenden benutzerdefinierten Parametern des Webhooks übermittelt.saved_payment_method:0 – die gespeicherte Zahlungsmethode wurde nicht verwendet1 – die Zahlungsmethode wurde während des aktuellen Bezahlvorgangs gespeichert2 – die zuvor gespeicherte Zahlungsmethode wird verwendetpayment_type:1 – Einmalzahlung2 – wiederkehrende Zahlung
Codes zur Rückerstattung:
Code
Grund
Beschreibung
1
Cancellation by the user request / the game request
Aus dem Kundenportal heraus eingeleitete Stornierung.
3
Integration error
Integrationsprobleme zwischen Xsolla und dem Spiel.Empfehlung: Benutzer nicht auf Sperrliste setzen.
5
Test payment
Testweise getätigte Transaktion gefolgt von Stornierung.Empfehlung: Benutzer nicht auf Sperrliste setzen.
7
Fraud notification from PS
Zahlung wurde vom Zahlungssystem abgelehnt. Potenzieller Betrug durch Zahlungssystem entdeckt. Empfehlung: Benutzer auf Sperrliste setzen.
9
Cancellation by the user request
Der Benutzer war aus irgendeinem Grund nicht zufrieden mit dem Spiel oder dem Einkauf.Empfehlung: Benutzer nicht auf Sperrliste setzen.
10
Cancellation by the game request
Das Spiel hat die Stornierung angefordert.Empfehlung: Benutzer nicht auf Sperrliste setzen.
### Zahlung
- [POST payment](https://developers.xsolla.com/de/webhooks/payments/payment.md): Wenn ein Nutzer eine Zahlung abschließt, sendet Xsolla die Zahlungsdetails in
einem Webhook vom Typ payment an die Webhook-URL.
Die erwarteten Antwortcodes sind im Abschnitt Responses beschrieben, Sie
können jedoch auch andere Antwortcodes verwenden:
Antwortcode
Beschreibung
200, 201, 204
Eine erfolgreiche Antwort.
4xx
Ein Fehler ist aufgetreten. Beispielsweise wurde der angegebene Nutzer nicht gefunden oder eine ungültige Signatur wurde übermittelt.
5xx
Ein temporärer Serverfehler. Bei einer solchen Antwort versucht Xsolla automatisch, den Webhook erneut zu senden. Dabei verlängert sich das Intervall zwischen den Versuchen schrittweise, bis Ihr Listener den Empfang bestätigt. Es werden maximal 12 Versuche innerhalb eines Zeitraums von 48 Stunden unternommen.
Wenn Sie die Webhook-URL im Kundenporta
l speichern, können Sie auch den Empfang zusätzlicher Informationen in
Webhooks einrichten.
Hinweis
Wenn Sie sich am oder vor dem 22. Januar 2025 im Kundenportal registriert haben, finden Sie die Schalter in Ihre Projekt unter Einstellungen > Webhooks > Testen > Payments > Erweiterte Einstellungen.
Schalter
Beschreibung
Infos über das gespeicherte Zahlungskonto anzeigen
Informationen über die gespeicherte Zahlungsmethode werden in dem benutzerdefinierten Objekt payment_account übermittelt.
Infos über Transaktionen anzeigen, die mit gespeicherten Zahlungsmethoden getätigt wurden
Informationen werden in den folgenden benutzerdefinierten Parametern des Webhooks übermittelt.saved_payment_method:0 – die gespeicherte Zahlungsmethode wurde nicht verwendet1 – die Zahlungsmethode wurde während des aktuellen Bezahlvorgangs gespeichert2 – die zuvor gespeicherte Zahlungsmethode wird verwendetpayment_type:1 – Einmalzahlung2 – wiederkehrende Zahlung
Bestellobjekt dem Webhook hinzufügen
Die Informationen über die Bestellung werden im order-Objekt des Zahlung-Webhooks übermittelt.
Nur notwendige Nutzerparameter ohne vertrauliche Daten senden
Im Webhook werden nur die folgenden Nutzerinformationen übermittelt:IDLand
BLZ und Endziffern von Karten anzeigen
Im Webhook werden nur die folgenden Informationen über die Bankkartennummer übermittelt:die ersten sechs Ziffern im Parameter card_bindie letzten vier Ziffern im Parameter card_suffix
Kartenmarke anzeigen
Die Marke der Karte, mit der die Zahlung getätigt wurde. Zum Beispiel: Mastercard oder Visa.
Hinweis
Die in einem Webhook versendeten Felder hängen von Folgendem ab:den erweiterten Einstellungen im Kundenportalden bei Xsolla konfigurierten benutzerdefinierten EinstellungenBei Fragen wenden Sie sich bitte an Ihren Customer Success Manager oder senden Sie eine E-Mail an csm@xsolla.com.
### Abgelehnte Zahlung
- [POST payment-declined](https://developers.xsolla.com/de/webhooks/payments/payment-declined.md): Wenn eine Transaktion von einem Zahlungssystem abgelehnt wird, sendet Xsolla
die Transaktionsdetails in einem Webhook vom Typ ps_declined an die von Ihnen
festgelegte Webhook-URL. Der Webhook wird während der Autorisierung- oder
Zahlungsabwicklung gesendet. In diesem Fall wird der Webhook
payment\ order_paid nicht gesendet.
Typische Gründe für von Zahlungssystemen abgelehnte Zahlungen:
* Die Kartenautorisierung ist fehlgeschlagen (z. B. konnte das Zahlungssystem den
Autorisierungsvorgang aufgrund eines technischen Fehlers oder einer
ausbleibenden Antwort der Bank nicht abschließen) oder wurde abgelehnt (z. B.
hat die Bank geantwortet, die Transaktion jedoch aufgrund unzureichender
Deckung oder ungültiger Kartendaten abgelehnt).
* Die "3-D Secure"-Prüfung ist fehlgeschlagen, wurde nicht abgeschlossen oder es
kam zu einem Timeout, weil der Nutzer nicht rechtzeitig bestätigt hat.
* Der Zahlungsabwickler oder die abrechnende Bank (Acquirer) ist vorübergehend
nicht verfügbar oder antwortet aufgrund eines nicht behebbaren Fehlers (z. B.
einem geschlossenen Konto oder einer ungültigen Kartennummer) mit einer
endgültigen Ablehnung. Ein erneuter Versuch ohne Behebung des zugrunde
liegenden Problems führt nicht zu einer erfolgreichen Transaktion.
Nicht zu verwechseln mit:
* Ablehnung durch Betrugsbekämpfungssysteme; diese werden über den Webhook
afs_reject gemeldet.
* Erstattungen oder Teilerstattungen nach einer erfolgreichen Zahlung; diese
werden über die Webhooks
refund und
partial_refund gemeldet.
Hinweis
Wenden Sie sich an Ihren Customer Success Manager oder senden Sie eine E-Mail an csm@xsolla.com, wenn Sie den Webhook ps_declined erhalten möchten.
### Erstattung
- [POST refund](https://developers.xsolla.com/de/webhooks/payments/refund.md): Wenn eine Zahlung storniert wird, sendet Xsolla die Details der stornierten
Transaktion in einem Webhook vom Typ refund an die Webhook-URL.
Ob und wie weitere Zustellversuche unternommen werden, hängt davon ab, wer die
Erstattung veranlasst hat:
* Wenn Sie die Erstattung veranlasst haben, wird der Webhook nicht erneut
gesendet. Die Zahlung wird dem Nutzer unabhängig von der Antwort auf einen
Webhook erstattet.
* Wenn die Erstattung von einem Dritten veranlasst wurde (beispielsweise einem
Zahlungssystem oder dem Xsolla-Kundensupport) und als Antwort auf einen Webhook
der Statuscode "5xx" zurückgegeben wurde, wird der Webhook in immer längeren
Intervallen erneut gesendet. Innerhalb von 48 Stunden nach dem ersten Versuch
werden maximal 12 weitere Zustellversuche unternommen.
Detaillierte Informationen zum Erstattungsvorgang finden Sie in der
entsprechenden Anleitung.
Hinweis
Die Zahlung wird dem Nutzer auch dann erstattet, wenn alle folgenden Bedingungen erfüllt sind:Xsolla hat die Erstattung veranlasst.Als Antwort auf einen Webhook wurde ein Statuscode 4xx zurückgegeben, oder es wurde nach allen weiteren Zustellversuchen keine Antwort empfangen, oder es wurde der Statuscode 5xx zurückgegeben.
Wenn Sie die Webhook-URL im Kundenporta
l speichern, können Sie auch den Empfang zusätzlicher Informationen in
Webhooks einrichten.
Hinweis
Wenn Sie sich am oder vor dem 22. Januar 2025 im Kundenportal registriert haben, finden Sie die Schalter in Ihre Projekt unter Einstellungen > Webhooks > Testen > Payments > Erweiterte Einstellungen.
Schalter
Beschreibung
Infos über Transaktionen anzeigen, die mit gespeicherten Zahlungsmethoden getätigt wurden
Informationen werden in den folgenden benutzerdefinierten Parametern des Webhooks übermittelt.saved_payment_method:0 – die gespeicherte Zahlungsmethode wurde nicht verwendet1 – die Zahlungsmethode wurde während des aktuellen Bezahlvorgangs gespeichert2 – die zuvor gespeicherte Zahlungsmethode wird verwendetpayment_type:1 – Einmalzahlung2 – wiederkehrende Zahlung
Codes zur Rückerstattung:
Code
Grund
Beschreibung
1
Cancellation by the user request / the game request
Aus dem Kundenportal heraus eingeleitete Stornierung.
2
Chargeback
Rückbuchung der Transaktion angefordert.
3
Integration error
Integrationsprobleme zwischen Xsolla und dem Spiel.Empfehlung: Benutzer nicht auf Sperrliste setzen.
4
Potential fraud
Betrugsverdacht.Empfehlung: Benutzer auf Sperrliste setzen.
5
Test payment
Testweise getätigte Transaktion gefolgt von Stornierung.Empfehlung: Benutzer nicht auf Sperrliste setzen.
6
User invoice expired
Rechnung überfällig (wird bei Postpaid-Zahlungsweise genutzt).
7
Fraud notification from PS
Zahlung wurde vom Zahlungssystem abgelehnt. Potenzieller Betrug durch Zahlungssystem entdeckt. Empfehlung: Benutzer auf Sperrliste setzen.
8
Cancellation by the PS request
Zahlungssystem hat Stornierung angefordert.Empfehlung: Benutzer nicht auf Sperrliste setzen.
9
Cancellation by the user request
Der Benutzer war aus irgendeinem Grund nicht zufrieden mit dem Spiel oder dem Einkauf.Empfehlung: Benutzer nicht auf Sperrliste setzen.
10
Cancellation by the game request
Das Spiel hat die Stornierung angefordert.Empfehlung: Benutzer nicht auf Sperrliste setzen.
11
Account holder called to report fraud
Der Kontoinhaber gibt an, dass die Transaktion nicht von ihm getätigt wurde.
12
Friendly fraud
Es wurde ein "Friendly Fraud" gemeldet.
13
Duplicate
Duplizierte Transaktion für dieselbe Rechnung.
### Zahlungskonto entfernen
- [POST remove-payment-account](https://developers.xsolla.com/de/webhooks/payments/remove-payment-account.md): Wenn ein Benutzer ein Zahlungskonto aus den gespeicherten Konten entfernt, sendet Xsolla einen Webhook vom Typ payment_account_remove an die Webhook-URL. Wenden Sie sich an Ihren Customer Success Manager oder senden Sie eine E-Mail an csm@xsolla.com, wenn Sie diesen Webhook erhalten möchten.
## Kombinierte Webhooks
### Stornierung der Bestellung (mit Zahlungs- und Transaktionsdetails)
- [POST order-cancellation](https://developers.xsolla.com/de/webhooks/combined-webhooks/order-cancellation.md): Xsolla sendet den Webhook order_canceled an die angegebene URL,
wenn die Zahlung vom Nutzer, Partner oder automatisch storniert wurde. Der
Webhook enthält Informationen über zurückgesandte Artikel, Zahlungsdaten und
Details zur stornierten Bestellung.
Der Webhook wird nicht gesendet, wenn die Zahlung nicht erfolgreich war, zum
Beispiel:
* das Zahlungsportal geöffnet wurde, aber der Nutzer die Bestellung nicht bezahlt
hat
* das Zahlungsportal geöffnet wurde, aber während der Zahlung Fehler auftraten
Die empfohlene Verarbeitungszeit für Webhooks beträgt maximal drei Sekunden.
### Erfolgreiche Bezahlung der Bestellung (mit Zahlungs- und Transaktionsdetails)
- [POST successful-order-payment](https://developers.xsolla.com/de/webhooks/combined-webhooks/successful-order-payment.md): Xsolla sendet den Webhook order_paid an die angegebene URL, wenn
der Nutzer die Bestellung erfolgreich bezahlt hat.
Der Webhook order_paid enthält Informationen zu den gekauften
Artikeln, Zahlungsdaten und Transaktionsdetails.
Der Webhook order_paid wird nicht gesendet, wenn die Zahlung nicht
erfolgreich war, zum Beispiel:
* die Zahlungsmaske geöffnet wurde, aber der Benutzer die Bestellung nicht
bezahlt hat
* die Zahlungsmaske geöffnet wurde, aber während der Zahlung Fehler auftraten
Es wird empfohlen, den Webhook order_paid in weniger als drei
Sekunden zu verarbeiten.
Hinweis
Die in einem Webhook versendeten Felder hängen von den folgenden Einstellungen ab:den im Kundenportal unter Projekteinstellungen > Webhooks > Erweiterte Einstellungen konfigurierten Einstellungenden bei Xsolla konfigurierten EinstellungenBei Fragen wenden Sie sich bitte an Ihren Customer Success Manager oder senden Sie eine E-Mail an csm@xsolla.com.
Die erwarteten Antworten sind im Abschnitt Antworten beschrieben. Sie
können andere Antwortcodes verwenden. Abhängig vom Antwortcode und je nachdem,
ob die automatische Zahlungserstattung aktiviert ist oder nicht, sieht die
Webhook-Verarbeitungslogik aufseiten von Xsolla wie folgt aus:
Antwortcode
Automatische Zahlungserstattung ist deaktiviert (standardmäßig)
Automatische Zahlungserstattung ist aktiviert
400, 401, 402, 403, 404, 409, 422, 415
Keine Aktionen
Benutzer erhält automatische eine Erstattung
200, 201, 204
Keine Aktionen
Keine Aktionen
Anderer Code oder keine Antwort auf Webhook
Mehrere Webhooks werden innerhalb eines bestimmten Zeitintervalls gesendet: Zwei Versuche im Abstand von 5 Minuten, sieben Versuche im Abstand von jeweils 15 Minuten, zehn Versuche im Abstand von jeweils 60 Minuten.
Mehrere Webhooks werden innerhalb eines bestimmten Zeitintervalls gesendet: Zwei Versuche im Abstand von 5 Minuten, sieben Versuche im Abstand von jeweils 15 Minuten, zehn Versuche im Abstand von jeweils 60 Minuten. Wurden alle Webhooks gesendet, ohne eine erfolgreiche Antwort erhalten zu haben, wird dem Benutzer automatisch eine Erstattung ausgestellt.
Wenden Sie sich an Ihre Customer Success Manager oder senden Sie eine E-Mail an
csm@xsolla.com, um die automatische Erstattungsfunktion zu verknüpfen.
## Separate Webhooks
### Stornierung der Bestellung (ohne Zahlungs- und Transaktionsdetails)
- [POST order-cancellation-separate](https://developers.xsolla.com/de/webhooks/separate-webhooks/order-cancellation-separate.md): Xsolla sendet den Webhook order_canceled an die angegebene URL,
wenn die Zahlung vom Nutzer, Partner oder automatisch storniert wurde. Der
Webhook enthält Informationen über zurückgesandte Artikel und Details zur
stornierten Bestellung.
Der Webhook wird nicht gesendet, wenn die Zahlung nicht erfolgreich war, zum
Beispiel:
* das Zahlungsportal geöffnet wurde, aber der Nutzer die Bestellung nicht bezahlt
hat
* das Zahlungsportal geöffnet wurde, aber während der Zahlung Fehler auftraten
Die empfohlene Verarbeitungszeit für Webhooks beträgt maximal drei Sekunden.
### Erfolgreiche Bezahlung der Bestellung (ohne Zahlungs- und Transaktionsdetails)
- [POST successful-order-payment-separate](https://developers.xsolla.com/de/webhooks/separate-webhooks/successful-order-payment-separate.md): Xsolla sendet den Webhook order_paid an die angegebene URL, wenn
die folgenden Bedingungen erfüllt sind:
1. Der Benutzer hat die Bestellung erfolgreich bezahlt.
2. Xsolla hat eine Antwort über die erfolgreiche Verarbeitung des Webhooks
Zahlung erhalten.
Der Webhook order_paid enthält Informationen zu den gekauften
Artikeln und Transaktionsdetails.
Der Webhook order_paid wird nicht gesendet, wenn:
* die Zahlung nicht erfolgreich war, zum Beispiel:
* die Zahlungsmaske geöffnet wurde, aber der Benutzer die Bestellung nicht
bezahlt hat
* die Zahlungsmaske geöffnet wurde, aber während der Zahlung Fehler auftraten
* die Antwort über die erfolgreiche Verarbeitung des Webhooks
Zahlung nicht eingegangen ist.
Es wird empfohlen, den Webhook order_paid in weniger als drei
Sekunden zu verarbeiten.
Die erwarteten Antworten sind im Abschnitt Antworten beschrieben. Sie
können andere Antwortcodes verwenden. Abhängig vom Antwortcode und je nachdem,
ob die automatische Zahlungserstattung aktiviert ist oder nicht, sieht die
Webhook-Verarbeitungslogik aufseiten von Xsolla wie folgt aus:
Antwortcode
Automatische Zahlungserstattung ist deaktiviert (standardmäßig)
Automatische Zahlungserstattung ist aktiviert
400, 401, 402, 403, 404, 409, 422, 415
Keine Aktionen
Benutzer erhält automatische eine Erstattung
200, 201, 204
Keine Aktionen
Keine Aktionen
Anderer Code oder keine Antwort auf Webhook
Mehrere Webhooks werden innerhalb eines bestimmten Zeitintervalls gesendet: Zwei Versuche im Abstand von 5 Minuten, sieben Versuche im Abstand von jeweils 15 Minuten, zehn Versuche im Abstand von jeweils 60 Minuten.
Mehrere Webhooks werden innerhalb eines bestimmten Zeitintervalls gesendet: Zwei Versuche im Abstand von 5 Minuten, sieben Versuche im Abstand von jeweils 15 Minuten, zehn Versuche im Abstand von jeweils 60 Minuten. Wurden alle Webhooks gesendet, ohne eine erfolgreiche Antwort erhalten zu haben, wird dem Benutzer automatisch eine Erstattung ausgestellt.
Wenden Sie sich an Ihre Customer Success Manager oder senden Sie eine E-Mail an
csm@xsolla.com, um die automatische Erstattungsfunktion zu verknüpfen.
## Personalisierungs-Webhook
### Katalogpersonalisierung aufseiten des Partners
- [POST personalized-partner-catalog](https://developers.xsolla.com/de/webhooks/personalization/personalized-partner-catalog.md): Xsolla sendet den Webhook partner_side_catalog mitsamt der
Benutzer- und Projektparameter an die Webhook-URL, wenn ein Benutzer mit dem
Shop interagiert.
Geben Sie eine Liste der item_id oder der SKUs der für den
Benutzer erhältlichen Artikel zurück. In diesem Fall können Sie auch die
Information einfügen, dass ein bestimmter Benutzer eine bestimmte Menge eines
bestimmten Produkts kaufen kann. Mit dieser Funktion können Sie die Anzahl und
Art der Produkte steuern, die der Benutzer in den Warenkorb legen und kaufen
kann.
Es wird empfohlen, den Webhook partner_side_catalog in weniger als
drei Sekunden zu verarbeiten.
## Anti-fraud
### Anti-fraud-Sperrliste aktualisieren
- [POST afs-rejected-blocklist](https://developers.xsolla.com/de/webhooks/anti-fraud/afs-rejected-blocklist.md): Wenn die Sperrliste des Anti-fraud-Systems aktualisiert wird (z. B. ein Parameter wird hinzugefügt oder entfernt), sendet Xsolla einen Webhook vom Typ afs_black_list an die Webhook-URL. Parameter werden automatisch aufseiten von Xsolla oder auf Anfrage hinzugefügt. Parameter zu entfernen, ist nur auf Anfrage möglich. Wenden Sie sich an Ihren Customer Success Manager oder senden Sie eine E-Mail an csm@xsolla.com, wenn Sie diesen Webhook erhalten möchten.
### Anti-fraud-System lehnt Transaktion ab
- [POST afs-rejected-transaction](https://developers.xsolla.com/de/webhooks/anti-fraud/afs-rejected-transaction.md): Wird eine Transaktion während einer Prüfung vom Anti-fraud-System abgelehnt,
sendet Xsolla die Transaktionsdetails in einem Webhook vom Typ afs_reject an
die Webhook-URL. Wenden Sie sich an Ihren Customer Success Manager oder senden
Sie eine E-Mail an csm@xsolla.com, wenn Sie
diesen Webhook erhalten möchten.
Wenn Sie die Webhook-URL im Kundenportal speichern, können Sie Berechtigungen
erteilen, detaillierte Informationen in Webhooks zu empfangen. Aktivieren Sie
dazu im Kundenportal unter Projekteins
tellungen > Webhooks > Erweiterte Einstellungen den folgenden
Schalter.
Hinweis
Wenn Sie sich am oder vor dem 22. Januar 2025 im Kundenportal registriert haben, finden Sie die Schalter unter Projekteinstellungen > Webhooks > Testen > Payments > Erweiterte Einstellungen.
Schalter
Beschreibung
Infos über Transaktionen anzeigen, die mit gespeicherten Zahlungsmethoden getätigt wurden
Informationen werden in den folgenden benutzerdefinierten Parametern des Webhooks übermittelt.saved_payment_method:0 – die gespeicherte Zahlungsmethode wurde nicht verwendet1 – die Zahlungsmethode wurde während des aktuellen Bezahlvorgangs gespeichert2 – die zuvor gespeicherte Zahlungsmethode wird verwendetpayment_type:1 – Einmalzahlung2 – wiederkehrende Zahlung
### Streitfall
- [POST dispute](https://developers.xsolla.com/de/webhooks/anti-fraud/dispute.md): Wenn ein neuer Streitfall eröffnet wird oder sich der Status eines Streitfalls ändert, sendet Xsolla einen Webhook vom Typ dispute an die Webhook-URL. Wenden Sie sich an Ihren Customer Success Manager oder senden Sie eine E-Mail an csm@xsolla.com, wenn Sie diesen Webhook erhalten möchten.
## Subscriptions
### Gekündigtes Abonnement
- [POST canceled-subscription](https://developers.xsolla.com/de/webhooks/subscriptions/canceled-subscription.md): Wird ein Abonnement gekündigt, sendet Xsolla einen Webhook vom Typ cancel_subscription an die Webhook-URL.
### Abgeschlossenes Abonnement
- [POST created-subscription](https://developers.xsolla.com/de/webhooks/subscriptions/created-subscription.md): Wenn ein Benutzer ein Abonnement abschließt, sendet Xsolla einen Webhook vom Typ create_subscription an die Webhook-URL.
### Automatisch endendes Abo
- [POST nonrenewing-subscription](https://developers.xsolla.com/de/webhooks/subscriptions/nonrenewing-subscription.md): Wird für ein Abonnement der Status "Automatisch endend" festgelegt, sendet Xsolla einen Webhook vom Typ non_renewal_subscription an die Webhook-URL. Wenden Sie sich an Ihren Customer Success Manager oder senden Sie eine E-Mail an csm@xsolla.com, wenn Sie diesen Webhook erhalten möchten.
### Aktualisiertes Abonnement
- [POST updated-subscription](https://developers.xsolla.com/de/webhooks/subscriptions/updated-subscription.md): Bei jeder Abonnementverlängerung, oder wenn bestimmte Abonnementparameter (plan_id, date_next_charge) geändert werden, sendet Xsolla einen Webhook vom Typ update_subscription an die Webhook-URL.