# Webhooks

# Überblick {% #overview %}

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.

<strong>Ereignisbeispiele:</strong>
- 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

<b>Beispielhafter Webhook-Ablauf bei der Zahlungsabwicklung:</b>

![Webhook für die 
Zahlungsabwicklung](https://cdn.xsolla.net/developers/current/images/api_docs/webhooks-general.svg)

<div class="note">
<p><strong>Hinweis</strong></p><p>Je nach verwendeter Lösung und Art der Integration können die Webhooks und die Interaktionsabfolge vom angegebenen Beispiel abweichen.</p>
</div>

<b>Videoanleitung für die Xsolla-Webhook-Integration:</b>

<div style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; border-radius: 15px; overflow: hidden;">
  <iframe src="https://player.vimeo.com/video/1034591338" style="position: absolute; top:0; left: 0; width: 100%; height: 100%; border:0; border-radius: 15px;" allowfullscreen></iframe>
</div>


<b>Webhooks-Einstellungen beim Arbeiten mit Xsolla-Produkten und ‑Lösungen:</b>

<table>
<thead>
    <tr>
        <th>Produkt/Lösung</th>
        <th>Erforderlich/Optional</th>
        <th>Wozu die Webhooks verwendet werden</th>
    </tr>
</thead>
<tbody>
    <tr>
        <td>Payments</td>
        <td>Erforderlich</td>
        <td>
          <ul>
            <li>Benutzervalidierung.</li>
            <li>Transaktionsdetails im Falle einer erfolgreichen Zahlung oder Zahlungserstattung erhalten</li>
            <li>gekaufte Artikel einem Nutzer gewähren und im Falle einer Stornierung der Bestellung die Artikel entfernen</li>
          </ul>
        </td>
    </tr>
    <tr>
        <td>Store</td>
        <td>Erforderlich</td>
        <td>
          <ul>
            <li>Benutzervalidierung.</li>
            <li>Transaktionsdetails im Falle einer erfolgreichen Zahlung oder Zahlungserstattung erhalten</li>
            <li>gekaufte Artikel einem Nutzer gewähren und im Falle einer Stornierung der Bestellung die Artikel entfernen</li>
          </ul>
        </td>
    </tr>
    <tr>
        <td>Game Sales</td>
        <td>Optional</td>
        <td>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.<br />Wenn Sie sich für Webhooks entscheiden, ist es wichtig, alle eingehenden <a href="/de/webhooks/overview/#section/List-of-required-webhooks">erforderlichen Webhooks</a> zu verarbeiten.
</td>
    </tr>
    <tr>
        <td>Subscriptions</td>
        <td>Optional</td>
        <td>Zum Abrufen von Informationen über den Abschluss, die Aktualisierung oder die Kündigung eines Abonnements. Alternativ können Sie die <a href="/doc/subscriptions/integration-guide/get-subscription-information/#guides_subscriptions_get_subscription_information_set_up_via_api">Informationen auch über die API anfordern</a>.
</td>
    </tr>
    <tr>
        <td>Web Shop</td>
        <td>Erforderlich</td>
        <td>
          <ul>
            <li>Benutzervalidierung.</li>
            <li>Transaktionsdetails im Falle einer erfolgreichen Zahlung oder Zahlungserstattung erhalten</li>
            <li>gekaufte Artikel einem Nutzer gewähren und im Falle einer Stornierung der Bestellung die Artikel entfernen</li>
            <li>Für die Benutzerauthentifizierung, wenn Sie Benutzer über deren ID authentifizieren. Alternativ dazu können Sie <a href="/solutions/web-shop/authentication-and-analytics/set-up-authentication/#web_shop_guide_shop_with_auth_set_up_auth_xsolla_login_how_to_get_it">Benutzer über Xsolla Login authentifizieren</a>.</li>
          </ul>
        </td>
    </tr>
    <tr>
        <td>Digital Distribution Hub</td>
        <td>Erforderlich</td>
        <td>
          <ul>
            <li>Benutzervalidierung.</li>
            <li>Transaktions-ID aufseiten von Xsolla mit der Transaktions-ID in Ihrem System verknüpfen</li>
            <li>zusätzliche Transaktionsparameter in der Bestellung übermitteln</li>
            <li>gekaufte Artikel einem Nutzer gewähren und im Falle einer Stornierung der Bestellung die Artikel entfernen</li>
          </ul>
          <p>Ausführliche Informationen zum Einrichten von Webhooks für den Digital Distribution Hub finden Sie in der <a href="/solutions/ddh/#integration_guide_ddh_webhook">Dokumentation</a>.</p>
        </td>
    </tr>
    <tr>
        <td>Login</td>
        <td>Optional</td>
        <td>
          <p>Empfang von Ereignisinformationen:</p>
          <ul>
            <li>Benutzerregistrierung/-autorisierung</li>
            <li>Bestätigung der E-Mail-Adresse des Benutzers</li>
            <li>Verknüpfung eines Social-Media-Kontos des Benuters</li>
          </ul>
          <p>Ausführliche Informationen zur Einrichtung von Webhooks finden Sie in der <a href="/api/login/operation/add-webhook-for-event/">-Login-Dokumentation</a>.</p>
        </td>
    </tr>
</tbody>
</table>

# Liste der erforderlichen Webhooks {% #list-of-required-webhooks %}
Wenn Sie Produkte und Lösungen verwenden, die Webhooks erfordern, müssen Sie 
die <a href="/webhooks/overview/#section/Set-up-webhooks-in-Publisher-
Account">Webhooks in Ihrem Kundenportal aktivieren, testen</a> und <a 
href="/webhooks/overview/#section/Webhook-listener">deren Verarbeitung 
einrichten</a>. 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.

## Store und Payments {% #store-and-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.

<b>Empfang von Informationen in kombinierten Webhooks:</b>

Wenn Sie sich nach dem 22. Januar 2025 im <a 
href="https://publisher.xsolla.com/">Kundenportal</a> registriert haben, werden 
alle Informationen in den Webhooks <a href="/webhooks/operation/successful-
order-payment">Erfolgreiche Bezahlung der Bestellung</a> (`order_paid`) und <a 
href="/webhooks/operation/order-cancellation">Stornierung der Bestellung</a> 
(`order_canceled`) übermittelt. In diesem Fall müssen Sie die Webhooks <a 
href="/webhooks/operation/payment">Zahlung</a> (`payment`) und <a 
href="/webhooks/operation/refund">Erstattung</a> (`refund`) nicht verarbeiten.

<b>Empfang von Informationen in separaten Webhooks:</b>

Wenn Sie sich am oder vor dem 22. Januar 2025 im <a 
href="https://publisher.xsolla.com/">Kundenportal</a> registriert haben, 
empfangen Sie die folgenden Webhooks:
- <a href="/webhooks/operation/payment">Zahlung</a> (`payment`) und <a 
  href="/webhooks/operation/refund">Erstattung</a> (`refund`) mit Informationen 
  über die Zahlungsdaten und   Transaktionsdetails.
- <a href="/webhooks/operation/successful-order-payment-separate">Erfolgreiche 
  Bezahlung der Bestellung</a> (`order_paid`) und <a href="/webhooks/operation
  /order-cancellation-separate">Stornierung der Bestellung</a> (`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 <a 
href="mailto:csm@xsolla.com">csm@xsolla.com</a>.

Damit In-Game Store und die Zahlungsverwaltung uneingeschränkt funktionieren, 
muss die Verarbeitung der wichtigsten Webhooks implementiert sein.

<b>Beim Empfang kombinierter Webhooks:</b>

<table>
<thead>
    <tr>
        <th>Webhook-Name und ‑Typ</th>
        <th>Beschreibung</th>
    </tr>
</thead>
<tbody>
    <tr>
        <td>Benutzervalidierung &gt; <a href="/webhooks/operation/user-validation/">Benutzervalidierung</a> (<code>user_validation</code>)</td>
        <td>Wird in verschiedenen Phasen des Zahlungsvorgangs gesendet, um sicherzustellen, dass der Nutzer im Spiel registriert ist.</td>
    </tr>
    <tr>
        <td>Spieldienste &gt; kombinierte Webhooks &gt; <a href="/webhooks/operation/successful-order-payment">Erfolgreiche Bezahlung der Bestellung</a> (<code>order_paid</code>)</td>
        <td>Enthält Zahlungsdaten, Transaktionsdetails und Informationen über gekaufte Artikel. Verwenden Sie die Daten aus dem Webhook, um dem Nutzer Artikel zu gewähren.</td>
    </tr>
    <tr>
        <td>Spieldienste &gt; kombinierte Webhooks &gt; <a href="/webhooks/operation/order-cancellation">Stornierung der Bestellung</a> (<code>order_canceled</code>)</td>
        <td>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.</td>
    </tr>
</tbody>
</table>


<b>Beim Empfang separater Webhooks:</b>

<table>
<thead>
    <tr>
        <th>Webhook-Name und ‑Typ</th>
        <th>Beschreibung</th>
    </tr>
</thead>
<tbody>
    <tr>
        <td>Benutzervalidierung &gt; <a href="/webhooks/operation/user-validation/">Benutzervalidierung</a> (<code>user_validation</code>)</td>
        <td>Wird in verschiedenen Phasen des Zahlungsvorgangs gesendet, um sicherzustellen, dass der Nutzer im Spiel registriert ist.</td>
    </tr>
    <tr>
        <td>Zahlungen &gt; <a href="/webhooks/operation/payment">Zahlung</a> (<code>payment</code>)</td>
        <td>Enthält Zahlungsdaten und Transaktionsdetails.</td>
    </tr>
    <tr>
        <td>Spieldienste &gt; separate Webhooks &gt; <a href="/webhooks/operation/successful-order-payment-separate">Erfolgreiche Bezahlung der Bestellung</a> (<code>order_paid</code>)</td>
        <td>Enthält Informationen über gekaufte Artikel. Verwenden Sie die Daten aus dem Webhook, um dem Nutzer Artikel hinzuzufügen.</td>
    </tr>
    <tr>
        <td>Zahlungen &gt; <a href="/webhooks/operation/refund">Erstattung</a> (<code>refund</code>)</td>
        <td>Enthält Zahlungsdaten und Transaktionsdetails.</td>
    </tr>
    <tr>
        <td>Spieldienste &gt; separate Webhooks &gt; <a href="/webhooks/operation/order-cancellation-separate">Stornierung der Bestellung</a> (<code>order_canceled</code>)</td>
        <td>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.</td>
    </tr>
</tbody>
</table>

Falls die Artikelkatalog<a href="/doc/in-game-
store/features/personalization">personalisierung</a> aufseiten Ihrer Anwendung 
implementiert ist, müssen Sie den Webhook <a href="/webhooks/operation
/personalized-partner-catalog">Katalogpersonalisierung aufseiten des 
Partners</a> einrichten.

<div class="note">
<p><strong>Hinweis</strong></p>
<p>Um echte Zahlungen entgegennehmen zu können, müssen Sie lediglich <a href="/doc/in-game-store/integration-guide/sign-licensing-agreement/">die Lizenzvereinbarung unterzeichnen</a> und die Verarbeitung der folgenden Webhooks implementieren:</p>
<p><ul><li><a href="/webhooks/operation/payment">Zahlung</a>, <a href="/webhooks/operation/successful-order-payment-separate">Erfolgreiche Bezahlung der Bestellung</a> und <a href="/webhooks/operation/user-validation/">Benutzervalidierung</a>, sofern Sie separate Webhooks empfangen</li><li><a href="/webhooks/operation/successful-order-payment">Erfolgreiche Bezahlung der Bestellung</a> und <a href="/webhooks/operation/user-validation/">Benutzervalidierung</a>, sofern Sie kombinierte Webhooks empfangen</li></ul></p>
</div>

## Subscriptions {% #required-webhooks-subscriptions %}
Um Abo-Modelle automatisch zu verwalten, muss die Verarbeitung der wichtigsten 
Webhooks implementiert sein:
- <a href="/webhooks/operation/user-validation/">Benutzervalidierung</a> 
  (`user_validation`) – wird in verschiedenen Phasen des Bezahlvorgangs gesendet, 
  um sicherzustellen, dass der Nutzer im Spiel registriert ist.
- <a href="/webhooks/operation/payment">Zahlung</a> (`payment`) – wird gesendet, 
  wenn eine Bestellung bezahlt wird, und enthält Zahlungsdaten sowie 
  Transaktionsdetails.
- <a href="/webhooks/operation/created-subscription/">Abgeschlossenes 
  Abonnement</a> (`create_subscription`) – wird gesendet, wenn ein Webhook vom 
  Typ <a href="/webhooks/operation/payment">Zahlung</a> 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.
- <a href="/webhooks/operation/updated-subscription/">Aktualisiertes 
  Abonnement</a> (`update_subscription`) – wird gesendet, wenn ein Abonnement 
  verlängert oder geändert und Webhook vom Typ <a 
  href="https://developers.xsolla.com/de/webhooks/operation/payment">Zahlung</a> 
  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.
- <a href="/webhooks/operation/refund">Erstattung</a> (`refund`) – wird gesendet, 
  wenn eine Bestellung storniert wird und enthält die Daten der stornierten 
  Zahlung sowie Transaktionsdetails.
- <a href="/webhooks/operation/canceled-subscription/">Gekündigtes Abonnement</a> 
  (`cancel_subscription`) – wird gesendet, wenn ein Webhook vom Typ <a 
  href="/webhooks/operation/refund">Erstattung</a> 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 {% #set-up-webhooks-in-publisher-account %}

## Allgemeine Einstellungen {% #general-settings %}

So aktivieren Sie den Empfang von Webhooks:
1. Navigieren Sie im Kundenportal-Projekt zum Menüpunkt <a 
   href="https://publisher.xsolla.com/0/projects/0/edit/webhooks/">Projekteinstellu
   ngen &gt; Webhooks</a>.
2. Geben Sie im Feld <b>Webhook-Server</b> 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.

<div class="notice">
<p><strong>Hinweis:</strong></p>
<p> Für die Datenübertragung wird das HTTPS-Protokoll verwendet; das HTTP-Protokoll wird nicht unterstützt.</p>
</div>

<p></p>

3. Generieren Sie einen geheimen Schlüssel:

<ol><ol type="a">
<li>Klicken Sie im Abschnitt <strong>Secret keys</strong> auf <strong>Add key</strong>.</li>
<li>Daraufhin öffnet sich ein Modalfenster. Vergeben Sie dort einen Namen für den Schlüssel, anhand dessen Sie ihn in der allgemeinen Liste identifizieren können.</li>
<li>Klicken Sie auf <strong>Create key</strong>.</li>
<li>Klicken Sie auf <strong>Copy secret</strong>, und speichern Sie den erstellten Schlüssel an einem sicheren Ort in Ihrem System.</li>
<li>Klicken Sie auf <strong>Done</strong>.</li>
<li>Bestätigen Sie, dass Sie den Schlüssel gespeichert haben, und klicken Sie auf <strong>Ok, close</strong>.</li>
</ol></ol>

![Schlüssel 
hinzufügen](https://cdn.xsolla.net/developers/current/images/api_docs/webhooks/add-key.svg)

<div class="notice">
<p><strong>Hinweis</strong></p>
<p>Empfehlungen:<ul>
<li><strong>Speichern Sie den generierten geheimen Schlüssel an einem sicheren Ort in Ihrem System</strong>. Der Schlüssel wird im Kundenportal nur einmal angezeigt, nämlich dann, wenn er erstellt wird.</li>
<li>Geben Sie Ihren geheimen Schlüssel an niemanden weiter.</li>
<li>Der geheime Schlüssel muss auf Ihrem Server gespeichert sein, keinesfalls in Binärdateien oder im Frontend.</li></ul>
</p>
</div>

4. Klicken Sie auf **Webhooks aktivieren**.

<div class="note">
<p><strong>Hinweis</strong></p>
<p>Webhooks können Sie auch über eine beliebige zweckbestimmte Website (z. B. <a href="https://webhook.site/#!/">webhook.site</a>) oder Plattform (z. B. <a href="https://ngrok.com/">ngrok</a>) testen.</p>
</div>

<p></p>

<div class="notice">
    <p><strong>Hinweis</strong></p>
    <p>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.</p>
</div>

So deaktivieren Sie den Empfang von Webhooks:
1. Navigieren Sie im Kundenportal-Projekt zum Menüpunkt <a 
   href="https://publisher.xsolla.com/0/projects/0/edit/webhooks/">Projekteinstellu
   ngen &gt; Webhooks</a>.
2. Klicken Sie auf <b>Webhooks deaktivieren</b>.

## Geheimen Schlüsseln austauschen {% #secret-key-rotation %}

Es empfiehlt sich, den geheimen Schlüssel regelmäßig auszutauschen, weil dies 
die Sicherheit Ihrer Integration erhöht. Sie können in Ihrem Projekt bis zu 
fünf geheime Schlüssel erstellen und zwischen ihnen wechseln. Gehen Sie dazu 
wie folgt vor:

1. Klicken Sie unter <a 
   href="https://publisher.xsolla.com/0/projects/0/edit/webhooks/">Projekteinstellu
   ngen &gt; Webhooks</a> auf **Add key**.

![Schlüssel 
hinzufügen](https://cdn.xsolla.net/developers/current/images/api_docs/webhooks/add-new-key.svg)

2. Daraufhin öffnet sich ein Modalfenster. Vergeben Sie dort einen Namen für den 
   Schlüssel, anhand dessen Sie ihn in der allgemeinen Liste identifizieren können.
3. Klicken Sie auf **Create key**.
4. Klicken Sie auf **Copy secret**, und speichern Sie den erstellten Schlüssel an 
   einem sicheren Ort in Ihrem System.
5. Klicken Sie auf **Done**.
6. Bestätigen Sie, dass Sie den Schlüssel gespeichert haben, und klicken Sie auf 
   **Ok, close**.

<div class="notice">
<p><strong>Hinweis</strong></p>
<p>Empfehlungen:<ul>
<li><strong>Speichern Sie den generierten geheimen Schlüssel an einem sicheren Ort in Ihrem System</strong>. Der Schlüssel wird im Kundenportal nur einmal angezeigt, nämlich dann, wenn er erstellt wird.</li>
<li>Geben Sie Ihren geheimen Schlüssel an niemanden weiter.</li>
<li>Der geheime Schlüssel muss auf Ihrem Server gespeichert sein, keinesfalls in Binärdateien oder im Frontend.</li></ul>
</p>
</div>

Pro Projekt kann nur ein geheimer Schlüssel aktiv sein. Wenn Sie den Schlüssel 
ändern möchten, klicken Sie in der Zeile eines anderen Schlüssels auf **Set as 
active**, und bestätigen Sie die Aktion. Wir empfehlen Ihnen, den deaktiviertem 
Schlüssel zu löschen, sobald die Umstellung auf den neuen Schlüssel erfolgreich 
war.

![Aktiven Schlüssel 
ändern](https://cdn.xsolla.net/developers/current/images/api_docs/webhooks/activate-key.svg)

## Erweiterte Einstellungen {% #advanced-settings %}

Für die Webhooks im Abschnitt <a href="/webhooks/overview/#section/Test-
webhooks-in-Publisher-Account/Store">Payments und Store</a> sind erweiterte 
Einstellungen verfügbar. Diese werden automatisch unter dem Block <a 
href="/webhooks/overview/#section/Set-up-webhooks-in-Publisher-Account/General-
settings">Allgemeine Einstellungen</a> angezeigt, nachdem Sie auf die 
Schaltfläche <b>Webhooks abrufen</b> geklickt haben.

<div class="note">
<p><strong>Hinweis</strong></p>
<p>Wenn die erweiterten Einstellungen nicht angezeigt werden, müssen Sie zuerst den Webhook-Empfang in den allgemeinen Einstellungen aktivieren und dann zur Registerkarte <b>Testen &gt; Payments und Store</b> wechseln.</p>
</div>

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.

<table>
<thead>
    <tr>
        <th>Schalter</th>
        <th>Beschreibung</th>
    </tr>
</thead>
<tbody>
    <tr>
        <td>Infos über das gespeicherte Zahlungskonto anzeigen (wird nur angezeigt, wenn Sie sich am oder vor dem 22. Januar 2025 im Kundenportal registriert haben und Webhooks separat empfangen).</td>
        <td>Informationen über die gespeicherte Zahlungsmethode werden in dem benutzerdefinierten Objekt <code>payment_account</code> übermittelt.</td>
    </tr>
    <tr>
        <td>Infos über Transaktionen anzeigen, die mit gespeicherten Zahlungsmethoden getätigt wurden.</td>
        <td><p>Informationen werden in den folgenden benutzerdefinierten Parametern des Webhooks übermittelt.</p><ul><li><code>saved_payment_method</code>:<ul><li><code>0</code> – die gespeicherte Zahlungsmethode wurde nicht verwendet</li><li><code>1</code> – die Zahlungsmethode wurde während des aktuellen Bezahlvorgangs gespeichert</li><li><code>2</code> – die zuvor gespeicherte Zahlungsmethode wird verwendet</li></ul></li><li><code>payment_type</code>:<ul><li><code>1</code> – Einmalzahlung</li><li><code>2</code> – wiederkehrende Zahlung</li></ul></li></ul></td>
    </tr>
    <tr>
        <td><code>order</code>-Objekt dem Webhook hinzufügen (wird nur angezeigt, wenn Sie sich am oder vor dem 22. Januar 2025 im Kundenportal registriert haben und Webhooks separat empfangen)</td>
        <td>Die Informationen über die Bestellung werden im <code>order</code>-Objekt des <a href="/webhooks/operation/payment/">Zahlung</a>-Webhooks übermittelt.</td>
    </tr>
    <tr>
        <td>Nur notwendige Nutzerparameter ohne vertrauliche Daten senden.</td>
        <td><p>Im Webhook werden nur die folgenden Nutzerinformationen übermittelt:</p><ul><li>ID</li><li>Land</li></ul></td>
    </tr>
    <tr>
        <td>Individuelle Parameter senden.</td>
        <td>Informationen über <a href="/api/pay-station/operation/create-token/">individuelle Tokenparameter</a> werden in dem Webhook übermittelt.</td>
    </tr>
    <tr>
        <td>BLZ und Endziffern von Karten anzeigen.</td>
        <td><p>Im Webhook werden nur die folgenden Informationen über die Bankkartennummer übermittelt:</p><ul><li>die ersten sechs Ziffern im Parameter <code>card_bin</code></li><li>die letzten vier Ziffern im Parameter <code>card_suffix</code></li></ul></td>
    </tr>
    <tr>
        <td>Kartenmarke anzeigen.</td>
        <td>Die Marke der Karte, mit der die Zahlung getätigt wurde. Zum Beispiel: Mastercard oder Visa.</td>
    </tr>
    <tr>
        <td>Infos über den Erstattungsgrund anzeigen</td>
        <td>Ausführliche Informationen zu den Gründen der Erstattung.</td>
    </tr>
    <tr>
        <td>Länder-Quellensteuer und Nutzerakquisitionsgebühr anzeigen</td>
        <td>Die Objekte <code>payment_details.​country_wht</code> und <code>payment_details.​user_acquisition_fee</code> werden im Webhook übermittelt. Der Schalter ist standardmäßig aktiviert.</td>
    </tr>
    <tr>
        <td>3DS-Infos senden</td>
        <td>Das Objekt <code>cards</code> mit den Daten für die "3-D Secure"-Prüfung wird im Webhook übermittelt.</td>
    </tr>
</tbody>
</table>

![Erweiterte 
Einstellungen](https://cdn.xsolla.net/developers/current/images/api_docs/webhooks/advanced-settings.png)

# Webhooks im Kundenportal testen {% #test-webhooks-in-publisher-account %}

Webhooks zu testen, hilft dabei, sicherzustellen, dass das Projekt sowohl bei 
Ihnen als auch aufseiten von Xsolla korrekt eingerichtet ist.

Sind die Webhooks erfolgreich <a href="/webhooks/overview/#section/Set-up-
webhooks-in-Publisher-Account">eingerichtet</a>, wird unterhalb des 
Einrichtungsbereichs ein Bereich zum Testen von Webhooks angezeigt.

![Webhook-
Testbereich](https://cdn.xsolla.net/developers/current/images/api_docs/webhooks/testing-section.svg)

Der Testbereich im Kundenportal variiert je nach dem, welche Webhook-
Empfangsoption ausgewählt sind.

Wenn Sie sich nach dem 22. Januar 2025 im Kundenportal registriert haben, 
empfangen Sie Webhooks in kombinierter Form:

<table>
<thead>
    <tr>
        <th>Registerkartenname für Webhook-Tests</th>
        <th>Webhook-Name und ‑Typ</th>
    </tr>
</thead>
<tbody>
    <tr>
        <td><b>Payments und Store</b></td>
        <td>Benutzervalidierung &gt; <a href="/webhooks/operation/user-validation/">Benutzervalidierung</a> (<code>user_validation</code>)</td>
    </tr>
    <tr>
        <td></td>
        <td>Spieldienste &gt; kombinierte Webhooks &gt; <a href="/webhooks/operation/successful-order-payment">Erfolgreiche Bezahlung der Bestellung</a> (<code>order_paid</code>)</td>
    </tr>
    <tr>
        <td></td>
        <td>Spieldienste &gt; kombinierte Webhooks &gt; <a href="/webhooks/operation/order-cancellation">Stornierung der Bestellung</a> (<code>order_canceled</code>)</td>
    </tr>
    <tr>
        <td><b>Subscriptions</b></td>
        <td>Benutzervalidierung &gt; <a href="/webhooks/operation/user-validation/">Benutzervalidierung</a> (<code>user_validation</code>)</td>
    </tr>
    <tr>
        <td></td>
        <td>Zahlungen &gt; <a href="/webhooks/operation/payment">Zahlung</a> (<code>payment</code>)</td>
    </tr>
</tbody>
</table>


Wenn Sie sich am oder vor dem 22. Januar 2025 für das Kundenportal registriert 
haben, empfangen Sie Webhooks separat:

<table>
<thead>
    <tr>
        <th>Registerkartenname für Webhook-Tests</th>
        <th>Webhook-Name und ‑Typ</th>
    </tr>
</thead>
<tbody>
    <tr>
        <td><b>Store</b></td>
        <td>Spieldienste &gt; separate Webhooks &gt; <a href="/webhooks/operation/successful-order-payment-separate">Erfolgreiche Bezahlung der Bestellung</a> (<code>order_paid</code>)</td>
    </tr>
    <tr>
        <td></td>
        <td>Spieldienste &gt; separate Webhooks &gt; <a href="/webhooks/operation/order-cancellation-separate">Stornierung der Bestellung</a> (<code>order_canceled</code>)</td>
    </tr>
    <tr>
        <td><b>Payments</b></td>
        <td>Benutzervalidierung &gt; <a href="/webhooks/operation/user-validation/">Benutzervalidierung</a> (<code>user_validation</code>)</td>
    </tr>
    <tr>
        <td></td>
        <td>Zahlungen &gt; <a href="/webhooks/operation/payment">Zahlung</a> (<code>payment</code>)</td>
    </tr>
    <tr>
        <td><b>Subscriptions</b></td>
        <td>Benutzervalidierung &gt; <a href="/webhooks/operation/user-validation/">Benutzervalidierung</a> (<code>user_validation</code>)</td>
    </tr>
    <tr>
        <td></td>
        <td>Zahlungen &gt; <a href="/webhooks/operation/payment">Zahlung</a> (<code>payment</code>)</td>
    </tr>
</tbody>
</table>

<div class="note">
<p><strong>Hinweis</strong></p>
<p>Wird im Testbereich eine Fehlermeldung angezeigt, wonach der Test nicht erfolgreich war, sollten Sie in den Einstellungen Ihres <a href="/webhooks/overview/#section/Webhook-listener">Webhook-Listener</a> prüfen, wie dieser auf Webhooks antwortet. Die Gründe für den fehlgeschlagenen Test sind in den Testergebnissen ersichtlich.</p>
<p><b>Beispiel:</b></p>
<p>Sie haben eine spezielle Website (z. B. <a href="https://webhook.site/#!/">webhook.site</a>) zum Testen verwendet.</p>
<p>Im Abschnitt <b>Test: Antwort auf eine ungültige Signatur</b> wird ein Fehler angezeigt.</p>
<p>Das liegt daran, dass Xsolla einen Webhook mit falscher Signatur gesendet hat und nun erwartet, dass Ihr Handler mit dem HTTP-Statuscode <code>4xx</code> und dem Fehlercode <code>INVALID_SIGNATURE</code> antwortet.</p>
<p><a href="https://webhook.site/#!/">webhook.site</a> antwortet allen Webhooks mit dem HTTP-Statuscode <code>200</code>, selbst solchen Webhooks mit ungültiger Signatur. Weil der HTTP-Statuscode <code>4xx</code> nicht wie erwartet empfangen wurde, ist das Testergebnis fehlerhaft.</p>
</div>

Im Folgenden ist der Testvorgang für das Szenario mit kombinierten Webhooks 
beschrieben.

## Payments und Store {% #payments-and-store %}

Auf der Registerkarte <b>Payments und Store</b> können Sie die folgenden 
Webhooks testen:
- <a href="/webhooks/operation/user-validation/">Benutzervalidierung</a> 
  (`user_validation`)
- <a href="/webhooks/operation/successful-order-payment">Erfolgreiche Bezahlung 
  der Bestellung</a> (`order_paid`)
- <a href="/webhooks/operation/order-cancellation">Stornierung der Bestellung</a> 
  (`order_canceled`)

So testen Sie die Webhooks:
1. Wechseln Sie im Webhooks-Testbereich zur Registerkarte <b>Payments und 
   Store</b>.
2. Wählen Sie in der Drop-down-Liste den Artikeltyp aus. Falls Sie diesen 
   Artikeltyp noch nicht im Kundenportal eingerichtet haben, klicken Sie auf die 
   entsprechende Schaltfläche, um den Artikel zu konfigurieren. Kehren Sie nach 
   dem Erstellen des Artikel zum Webhook-Testbereich zurück, und fahren Sie mit 
   dem nächsten Schritt fort.
3. Füllen Sie die Pflichtfelder aus:
   * **Benutzer-ID** – Zum Testen können Sie eine beliebige Kombination aus 
     Buchstaben und Ziffern eingeben.
   * Geben Sie einen beliebigen Wert im Feld **Xsolla-Bestell-ID** ein.
   * **Xsolla-Rechnungs-ID** – Transaktions-ID aufseiten von Xsolla. Zum Testen 
     können Sie einen beliebigen numerischen Wert eingeben.
   * **Rechnungs-ID** – Transaktions-ID aufseiten Ihres Spiels. Zum Testen können 
     Sie eine beliebige Kombination aus Buchstaben und Ziffern eingeben. Dieser 
     Parameter ist für eine erfolgreiche Zahlung nicht zwingend erforderlich, Sie 
     können ihn jedoch übermitteln, um die Transaktions-ID in Ihrem System mit der 
     Transaktions-ID aufseiten von Xsolla zu verknüpfen.
   * **Betrag** – Zahlungsbetrag. Zum Testen können Sie einen beliebigen numerischen 
     Wert eingeben.
   * **Währung** – Wählen Sie eine Währung aus der Drop-down-Liste 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.
4. Klicken Sie auf **Webhooks testen**.

Die Webhooks <a href="/webhooks/operation/user-
validation/">Benutzervalidierung</a>, <a href="/webhooks/operation/successful-
order-payment">Erfolgreiche Bezahlung der Bestellung</a> und <a 
href="/webhooks/operation/order-cancellation">Stornierung der Bestellung</a> 
werden zusammen mit den angegebenen Daten an die festgelegte URL gesendet. Die 
Testergebnisse der einzelnen Webhook-Typen werden unter der Schaltfläche 
<b>Webhooks testen</b> angezeigt.

Wenn das Kontrollkästchen <b>Öffentliche Benutzer-ID verwenden</b> unter <a 
href="https://publisher.xsolla.com/0/projects/0/edit/advanced">Projekteinstellun
gen > Integrationseinstellungen</a> aktiviert ist, wird der Webhook <a 
href="/webhooks/user-validation/user-search">Benutzersuche</a> ebenfalls an die 
URL Ihres Webhookservers gesendet und das Testergebnis angezeigt.

Für jeden Webhook müssen Sie die Verarbeitung beider Szenarien, also 
erfolgreich und fehlerbehaftet, konfigurieren.

![Payments-
Testbereich](https://cdn.xsolla.net/developers/current/images/api_docs/webhooks/testing-results.svg)

## Subscriptions {% #test-webhooks-subscriptions %}

<div class="note">
<p><strong>Hinweis</strong></p>
<p>Um Webhooks zu testen, sollten Sie mindestens ein <a href="/sell-subscriptions/integration-guide/set-up-plan/">Abo-Modell</a> im Kundenportal unter dem Menüpunkt <a href="https://publisher.xsolla.com/0/projects/0/subscriptions/plans">Artikelkatalog &gt; Abonnements</a> erstellt haben.</p>
</div>

Auf der Registerkarte <b>Subscriptions</b> können Sie die folgenden Webhooks 
testen:
- <a href="/webhooks/operation/user-validation/">Benutzervalidierung</a> 
  (`user_validation`)
- <a href="/webhooks/operation/payment">Zahlung</a> (`payment`)

<div class="note">
<p><strong>Hinweis</strong></p>
<p>Ausführliche Informationen zum Testen anderer Abonnementverwaltungsszenarien finden Sie im <a href="/sell-subscriptions/integration-guide/set-up-plan/#guides_subscriptions_set_up_plan_testing_purchase">Integrationsleitfaden</a>.</p>
</div>

So testen Sie die Webhooks:

1. 1. Wechseln Sie im Testbereich zur Registerkarte **Subscriptions**.
2. Füllen Sie die Pflichtfelder aus:
   * **Benutzer-ID** – Zum Testen können Sie eine beliebige Kombination aus 
     Buchstaben und Ziffern eingeben.
   * **Xsolla-Rechnungs-ID** – Transaktions-ID aufseiten von Xsolla. Zum Testen 
     können Sie einen beliebigen numerischen Wert eingeben.
   * **Öffentliche Benutzer-ID** – ID, die einem Nutzer bekannt ist, z. B. E-Mail-
     Adresse oder Nickname. Dieses Feld wird angezeigt, wenn Sie das 
     Kontrollkästchen **Öffentliche Benutzer-ID verwenden** in Ihrem Projekt unter 
     [Projekteinstellungen > 
     Integrationseinstellungen](https://publisher.xsolla.com/0/projects/0/edit/advanced) aktiviert haben.
   * **Betrag** – Zahlungsbetrag. Zum Testen können Sie einen beliebigen numerischen 
     Wert eingeben.
   * **Währung** – Wählen Sie eine Währung aus der Drop-down-Liste aus.
   * **Abo-Modell-ID** – ein Abo-Modell. Wählen Sie ein Modell aus der Drop-down-
     Liste.
   * **Abonnementprodukt** — Wählen Sie ein Produkt aus der Drop-down-Liste 
     (optional). Die Liste wird angezeigt, sofern [Produkte](/de/sell-subscriptions/integration-guide/get-started/#guides_subscriptions_glossary_product) in Ihrem 
     Projekt eingerichtet sind.
   * **Rechnungs-ID** – Transaktions-ID aufseiten Ihres Spiels. Zum Testen können 
     Sie eine beliebige Kombination aus Buchstaben und Ziffern eingeben. Dieser 
     Parameter ist für eine erfolgreiche Zahlung nicht zwingend erforderlich, Sie 
     können ihn jedoch übermitteln, um die Transaktions-ID in Ihrem System mit der 
     Transaktions-ID aufseiten von Xsolla zu verknüpfen.
   * **Testzeitraum**. Geben Sie den Wert `0` an, um den [Kauf eines Abonnements 
     ohne Testzeitraum](/de/sell-subscriptions/integration-guide/get-subscription-information/#guides_subscriptions_get_subscription_set_up_webhooks_sandbox) 
     oder die [Verlängerung eines Abonnements](/de/sell-subscriptions/integration-guide/get-subscription-information/#guides_subscriptions_get_subscription_set_up_webhooks_test_renewal)
      zu testen.
3. Klicken Sie auf **Testen**.

Unter der angegebenen URL empfangen Sie Webhooks mit ausgefüllten Daten. Die 
Testergebnisse jedes Webhooks, sowohl für ein erfolgreiches als auch für ein 
fehlerhaftes Szenario, werden unter der <b>Testen</b>-Schaltfläche angezeigt.

# Webhook-Listener {% #webhook-listener %}

Ein Webhook-Listener ist ein Programmcode, der es ermöglicht, eingehende 
Webhooks unter einer bestimmten URL-Adresse zu empfangen, <a 
href="/webhooks/overview/#section/Webhook-listener/Generation-of-
signature">eine Signatur zu generieren</a> und dem Xsolla-Webhook-Server zu <a 
href="/webhooks/overview/#section/Webhook-listener/Sending-responses-to-
webhook">antworten</a>.

<div class="note">
<p><strong>Hinweis</strong></p>
<p>Sie können die <a href="https://developers.xsolla.com/de/sdk/php/">Pay Station PHP SDK-Bibliothek</a> verwenden, die vorgefertigte Klassen für die Verarbeitung von Webhooks enthält.</p>
</div>

<!-- IMPORTANT! Changing the list of IP addresses should be coordinated with the administrators. Request for Director of Infrastructure and IT approval in the ticket for changing the IP address list. -->

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 <a href="/doc/login/">Login</a> 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 {% #generation-of-signature %}

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 <signature_value>`.
2. Rufen Sie den Webhook-Anfragerumpf im JSON-Format ab. <div 
   class="notice"><p><strong>Hinweis</strong></p><p>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.</p></div><p></p>

3. Generieren Sie Ihre eigene Signatur für den Abgleich: <ol type="a"> 
   <li>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.</li> <li>Wenden Sie 
   die kryptografische Hash-Funktion SHA-1 auf den resultierenden String an. Als 
   Ergebnis erhalten Sie einen hexadezimalen String aus Kleinbuchstaben.</li> </ol>
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): {% #example-of-a-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): {% #example-of-a-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): {% #csharp-signature-generation-general-sample %}

<div class="note">
<p><strong>Hinweis</strong></p>
<p>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 <code>ConstantTimeEquals</code>-Methode zur Verhinderung von Timing-Angriffen.</p>
</div>

```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): {% #csharp-signature-generation-net-5-0-and-later %}

<div class="note">
<p><strong>Hinweis</strong></p>
<p>Um die <code>Convert.ToHexString</code>-Methode nutzen zu können, brauchen Sie .NET 5.0 oder höher.<p></p>Über .NET 7.0 oder höher verfügen, können Sie anstelle von <code>ConstantTimeEquals</code> auch die <code>CryptographicOperations.FixedTimeEquals</code>-Methode verwenden.</p>
</div>

```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): {% #csharp-signature-generation-net-7-0-and-later %}

<div class="note">
<p><strong>Hinweis</strong></p>
<p> Wenn Sie über .NET 7.0 oder höher verfügen, könne Sie die <code>CryptographicOperations.FixedTimeEquals</code>-Methode verwenden.</p>
</div>

```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): {% #cpp-signature-generation %}

```c++
#include <string>
#include <sstream>
#include <iomanip>
#include <openssl/sha.h>
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<const unsigned char*>(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<unsigned int>(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-signature-generation %}

```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-signature-generation %}

```php
<?php
class XsollaWebhookSignature
{
    /**
     * Compute SHA1 signature from webhook JSON body and secret key
     *
     * @param string $jsonBody The raw JSON body from webhook
     * @param string $secretKey The project's secret key
     * @return string The lowercase SHA1 signature
     */
    public static function computeSha1(string $jsonBody, string $secretKey): string
    {
        // Concatenation of the JSON from the request body and the project's secret key
        $dataToSign = $jsonBody . $secretKey;
        // Generate SHA1 signature
        $signature = sha1($dataToSign);
        return strtolower($signature);
    }
    /**
     * Verify webhook signature using timing-safe comparison
     *
     * @param string $jsonBody The raw JSON body from webhook
     * @param string $secretKey The project's secret key  
     * @param string $receivedSignature The signature from authorization header
     * @return bool True if signature is valid, false otherwise
     */
    public static function verifySignature(string $jsonBody, string $secretKey, string $receivedSignature): bool
    {
        $computedSignature = self::computeSha1($jsonBody, $secretKey);
        // Use hash_equals for timing-safe comparison
        return hash_equals($computedSignature, strtolower($receivedSignature));
    }
}
?>
```

### Implementierung der Signaturgenerierung in Node.js (Beispiel): {% #nodejs-signature-generation %}

```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 {% #sending-responses-to-webhook %}

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 <a 
  href="/webhooks/overview/#section/Fehler">Problembeschreibung</a>, 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 <a 
href="/webhooks/operation/successful-order-payment">Erfolgreiche Bezahlung der 
Bestellung</a> und <a href="/webhooks/operation/order-cancellation">Stornierung 
der Bestellung</a> 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 <a 
href="/webhooks/operation/payment">Zahlung</a> und <a 
href="/webhooks/operation/refund">Erstattung</a> ist auf der jeweiligen Webhook-
Seite beschrieben.

<div class="notice">
<p><strong>Hinweis</strong></p>
<p>Die Zahlung wird dem Nutzer auch dann erstattet, wenn alle folgenden Bedingungen erfüllt sind:<ul><li>Xsolla hat die Erstattung veranlasst.</li><li>Als Antwort auf einen Webhook wurde ein Statuscode <code>4xx</code> zurückgegeben, oder es wurde nach allen weiteren Zustellversuchen keine Antwort empfangen, oder es wurde der Statuscode <code>5xx</code> zurückgegeben.</li></ul></p>
</div>

Wenn der Xsolla-Server keine Antwort auf den Webhook <a 
href="/webhooks/operation/user-validation/">Benutzervalidierung</a> empfangen 
hat oder aber eine Antwort mit dem HTTP-Statuscode 400 oder 5xx, wird der 
Webhook <a href="/webhooks/operation/user-validation/">Benutzervalidierung</a> 
nicht erneut gesendet. Stattdessen wird dem Nutzer eine Fehlermeldung angezeigt 
und die Webhooks <a href="/webhooks/operation/payment">Zahlung</a> und <a 
href="/webhooks/operation/successful-order-payment">Erfolgreiche Bezahlung der 
Bestellung</a> werden nicht gesendet.

# Fehler {% #errors %}

Fehlercodes für den HTTP-Code 400:

<table>
<thead>
    <tr>
        <th>Code</th>
        <th>Nachricht</th>
    </tr>
</thead>
<tbody>
    <tr>
        <td>INVALID_USER</td>
        <td>Ungültiger Benutzer</td>
    </tr>
    <tr>
        <td>INVALID_PARAMETER</td>
        <td>Ungültiger Parameter</td>
    </tr>
    <tr>
        <td>INVALID_SIGNATURE</td>
        <td>Unzulässige Signatur</td>
    </tr>
    <tr>
        <td>INCORRECT_AMOUNT</td>
        <td>Ungültiger Betrag</td>
    </tr>
    <tr>
        <td>INCORRECT_INVOICE</td>
        <td>Ungültige Rechnung</td>
    </tr>
</tbody>
</table>

```
HTTP/1.1 400 Bad Request
{
    "error":{
        "code":"INVALID_USER",
        "message":"Invalid user"
    }
}
```

# Best Practices {% #best-practices %}

## Sicherheit {% #security %}

Richtlinien:

* Verwenden Sie ausschließlich HTTPS mit einem gültigen Zertifikat.
* Vergleichen Sie die Signatur stets mit dem Rohtext des Anfragerumpfs – die 
  Daten dürfen nicht geparst oder neu kodiert werden.
* Übermitteln Sie keine sensiblen Daten in URLs und vermeiden Sie es, technische 
  Details in Fehlermeldungen offenzulegen.
* Der Webhook-Endpunkt muss von der [CSRF](https://en.wikipedia.org/wiki/Cross-site_request_forgery)-Middleware ausgenommen sein – eingehende Anfragen von 
  Xsolla enthalten kein CSRF-Token und werden bei fehlender Ausnahme abgelehnt.
* Weiße Liste für [Xsolla-IP-Adressen](/de/webhooks/section/webhook-listener).


## Webhook-Handler-Architektur {% #webhook-handler-architecture %}

Richtlinien:

1. Akzeptieren Sie die `POST`-Anfrage mit dem Rumpf und den Headern unverändert, 
   **ohne Änderungen**.
2. [Überprüfen Sie die Webhook-Signatur](/de/webhooks/section/webhook-listener/generation-of-signature) und antworten Sie mit dem entsprechenden Statuscode:
   * `4xx` – wenn die Signaturen nicht übereinstimmen;
   * `2xx` – im Erfolgsfall. Wir empfehlen, **vor** der Ausführung der eigentlichen 
     Geschäftslogik mit dem Statuscode`204 No Content` zu antworten. `200 OK` ist 
     als Antwort ebenfalls zulässig.
3. Leiten Sie die Payload zur weiteren Verarbeitung an einen asynchronen Job oder 
   eine Warteschlange weiter.
4. Implementieren Sie 
   [Idempotenz](https://en.wikipedia.org/wiki/Idempotence#Computer_science_meaning)
   . Ihr System muss in der Lage sein, [denselben Webhook mehr als einmal zu 
   empfangen](/de/webhooks/section/webhook-listener/sending-responses-to-webhook).

**Ablauf (Beispiel):**

```http
HTTP POST /webhooks/xsolla
  read raw_body, headers
  if !verify_signature(raw_body, headers['authorization']):
     return 400 {"error":{"code":"INVALID_SIGNATURE","message":"Invalid signature"}}
  enqueue(raw_body)
  return 204  # or 200
```

## Idempotenz und Duplikate {% #idempotency-and-duplicates %}

Richtlinien:

* Verwenden Sie die Transaktions-ID und/oder die [externe ID](/de/dev-resources/faq/payments/#faq_payments_q_new_transaction_external_id) sowie die 
  Bestell-ID als Idempotenzschlüssel.
* Speichern Sie die verarbeiteten IDs, und geben Sie das vorherige Ergebnis 
  zurück, falls ein Duplikat empfangen wird.
* Vermeiden Sie die erneute Vergabe von Artikeln, doppelte Datenbankeinträge und 
  doppelte Abbuchungen.
* Beachten Sie, dass bei aufeinanderfolgenden Zustellungen ein Fehler bei einem 
  früheren Ereignis die Verarbeitung aller nachfolgenden Ereignisse blockiert.

## Systemresilienz {% #system-resilience %}

Richtlinien:

* Verwenden Sie Warteschlangen und asynchrone Verarbeitung für 
  ressourcenintensive Vorgänge wie API-Aufrufe von Drittanbietern, Abrechnungen 
  und die Artikelvergabe.
* Legen Sie Timeouts für den Webhook-Handler fest (1–3 Sekunden). Bei 
  vorübergehenden Ausfällen können Sie sich auf den [Xsolla-
  Wiederholungsmechanismus](/de/webhooks/section/webhook-listener/sending-responses-to-webhook) verlassen.
* Implementieren Sie keine Wiederholungsversuche im Webhook-Handler – Xsolla 
  kümmert sich um die erneute Zustellung.
* Protokollieren Sie Zeitstempel und Verarbeitungsstatus der Webhook-Zustellung; 
  richten Sie Warnmeldungen für Spitzenauslastungen bei `5xx`-Fehlern und 
  erneuten Zustellungen ein.
* Leiten Sie Korrelations-IDs aus dem Webhook an Ihre Protokolle und Ihr 
  Überwachungssystem (Application Performance Monitoring, APM) weiter.
* Richten Sie Fehlerprotokollierung und ‑überwachung ein. Verschieben Sie Jobs 
  bei nicht behebbaren Fehlern in eine Warteschlange für unzustellbare 
  Nachrichten (Dead Letter Queue, DLQ). Entwickeln Sie ein sicheres Tool zur 
  erneuten Ausführung von Ereignissen, das durch einen Idempotenzmechanismus 
  geschützt ist.

## Implementationsbeispiele {% #implementation-examples %}

**Erfolgreicher Kauf – Artikel beim ersten Versuch zugeteilt:**

![Kauf](https://cdn.xsolla.net/developers/current/images/api_docs/webhook-schemes/purchase-v2.svg)

**Doppelt zugeteilt (Partner-Timeout beim ersten Versuch):**

![Timeout](https://cdn.xsolla.net/developers/current/images/api_docs/webhook-schemes/timeout-v2.svg)

**Erstattung:**

![Erstattung](https://cdn.xsolla.net/developers/current/images/api_docs/webhook-schemes/refund-v2.svg)

**Ausfall beim Partner**:

![Ausfall beim 
Partner](https://cdn.xsolla.net/developers/current/images/api_docs/webhook-schemes/server-error.svg)

# FAQ {% #faqs %}

## Muss ich für ein Webhook-Protokoll HTTPS verwenden? {% #do-i-need-to-use-https-for-a-webhook-protocol %}

Ja.

## Kann ich Zahlungs-Webhooks unter mehreren URLs empfangen? {% #can-i-receive-payment-webhooks-at-several-urls %}

Nein. Zahlungs-Webhooks verwenden das Server-zu-Server-Protokoll und werden an 
eine einzige URL gesendet, die in den [Projekteinstellungen](/de/webhooks/section/set-up-webhooks-in-publisher-account) angegeben ist. Wenn Sie 
Benachrichtigungen in Ihrem Spiel, auf Ihrer Website oder in Ihrer App erhalten 
möchten, richten Sie auf Ihrem Server den Versand von Webhooks ein, um Daten 
zwischen Xsolla und Ihrem Spiel auszutauschen. Sie können Webhooks auch über 
die Entwicklerkonsole testen.

<div class="note">
<p><strong>Hinweis</strong></p>
<p>Wenn Sie die Integration lokal testen, erreichen `POST`-Anfragen von Xsolla keine URLs wie <code>http://localhost:3000/my-webhook-endpoint</code>. Nutzen Sie Dienste wie <a href="https://ngrok.com/">ngrok</a>, mit denen Sie einen Tunnel für den externen Zugriff einrichten können, sodass Sie Anfragen von Xsolla lokal empfangen können. Weitere Informationen hierzu finden Sie beispielsweise in der <a href="https://ngrok.com/docs/guides/share-localhost/webhooks#test-webhooks-locally">ngrok-Dokumentation</a>.</p>
</div>

## Warum wurde die Xsolla-Benachrichtigung nicht an die Webhook-URL gesendet? {% #why-was-xsolla-notification-not-sent-to-the-webhook-url %}

Stellen Sie sicher, dass Ihr Webhook-Server die HTTP-Anfragetypen `POST` und 
`GET` unterstützt.

## Wie vermeide ich doppelte Transaktions-IDs bei der Verarbeitung? {% #how-do-i-prevent-duplicate-transaction-ids-during-processing %}

Verwenden Sie die externe ID – hierbei handelt es sich um die Transaktions-ID 
in Ihrem Spiel, die der Bestellung in Ihrem System zugewiesen wurde. Aufseiten 
von Xsolla ist die externe ID mit der Transaktions-ID verknüpft, wodurch Xsolla 
doppelte Zahlungen für dieselbe Transaktion verhindern kann. Weitere 
Informationen zur Konfiguration finden Sie in unserer [Dokumentation](/de/dev-resources/faq/payments/#faq_payments_q_new_transaction_external_id).

## Gibt es Best Practices für die Arbeit mit Webhooks? {% #are-there-any-best-practices-for-working-with-webhooks %}

Empfehlungen:

* unmittelbar nach der Signaturprüfung mit`204` oder `200` antworten
* Webhook-Signatur gegen den unveränderten Anfragerumpf abgleichen
* Idempotenz für alle Vorgänge implementieren
* alle Ereignisse protokollieren und Fehlerüberwachung einrichten
* keine sensiblen Daten in URLs übermitteln und keine technischen Details in 
  Fehlermeldungen offenlegen

Ausführliche Informationen finden Sie im Abschnitt [Best 
Practices](/de/webhooks/section/best-practices).

# Checkliste für die Webhook-Integration {% #webhook-integration-checklist %}

Damit Webhooks ordnungsgemäß funktionieren, müssen vor der Inbetriebnahme die 
folgenden Voraussetzungen erfüllt sein:

* HTTPS wird genutzt.
* Die Webhook-[Signaturprüfung](/de/webhooks/section/webhook-listener/generation-of-signature) erfolgt gegen den unveränderten Rohtext des Anfragerumpfs.
* Sobald die Signatur bestätigt ist, wird mit dem Statuscode `204/200` geantwort.
* Idempotenz ist für alle Vorgänge implementiert.
* Fehlerprotokollierung und ‑überwachung sind konfiguriert.
* Sensible Daten werden nicht in URLs übermittelt, und technische Details werden 
  in Fehlermeldungen nicht offengelegt.
* Versuche, einen Webhook erneut zu senden, werden gemäß der [Xsolla-
  Wiederholungslogik](/de/webhooks/section/webhook-listener/sending-responses-to-webhook) unterstützt.
* Die gesamte Integration ist dokumentiert.

# Liste der Webhooks {% #webhooks-list %}

<div class="note">
<p><strong>Hinweis</strong></p>
<p>Der Benachrichtigungstyp wird im Parameter <code>notification_type</code> gesendet.</p>
</div>

<table>
<thead>
    <tr>
        <th>Webhook</th>
        <th>Benachrichtigungstyp</th>
        <th>Beschreibung</th>
    </tr>
</thead>
<tbody>
    <tr>
        <td><a href="/webhooks/operation/user-validation/">Benutzervalidierung</a></td>
        <td><code>user_validation</code></td>
        <td>Wird versendet, um zu prüfen, ob ein Benutzer im Spiel existiert.</td>
    </tr>
    <tr>
        <td><a href="/webhooks/operation/user-search/">Benutzersuche</a></td>
        <td><code>user_search</code></td>
        <td>Wird versendet, um Benutzerinformationen anhand der öffentlichen Benutzer-ID abzurufen.</td>
    </tr>
    <tr>
        <td><a href="/webhooks/operation/payment/">Zahlung</a></td>
        <td><code>payment</code></td>
        <td>Wird versendet, wenn ein Benutzer eine Zahlung abschließt.</td>
    </tr>
    <tr>
        <td><a href="/webhooks/operation/refund/">Erstattung</a></td>
        <td><code>refund</code></td>
        <td>Wird versendet, falls eine Zahlung aus einem beliebigen Grund storniert werden muss.</td>
    </tr>
    <tr>
        <td><a href="/webhooks/operation/partial-refund/">Teilerstattung</a></td>
        <td><code>partial_refund</code></td>
        <td>Wird versendet, falls eine Zahlung aus einem beliebigen Grund teilweise storniert werden muss.</td>
    </tr>
    <tr>
        <td><a href="/webhooks/operation/payment-declined/">Abgelehnte Zahlung</a></td>
        <td><code>ps_declined</code></td>
        <td>Wird versendet, wenn eine Zahlung vom Zahlungssystem abgelehnt wird.</td>
    </tr>
    <tr>
        <td><a href="https://developers.xsolla.com/de/webhooks/operation/afs-rejected-transaction/">Abgelehnte Transaktion (AFS)</a></td>
        <td><code>afs_reject</code></td>
        <td>Wird versendet, wenn eine Transaktion während einer AFS-Prüfung abgelehnt wird.</td>
    </tr>
    <tr>
      <td><a href="https://developers.xsolla.com/de/webhooks/operation/afs-rejected-blocklist/">Aktualisierte AFS-Blockliste</a></td>
      <td><code>afs_black_list</code></td>
      <td>Wird bei Aktualisierung der AFS-Blockliste versendet.</td>
    </tr>
    <tr>
      <td><a href="https://developers.xsolla.com/de/webhooks/operation/created-subscription/">Abgeschlossenes Abonnement</a></td>
      <td><code>create_subscription</code></td>
      <td>Wird versendet, wenn ein Benutzer ein Abonnement abschließt.</td>
    </tr>
    <tr>
      <td><a href="https://developers.xsolla.com/de/webhooks/operation/updated-subscription/">Aktualisiertes Abonnement</a></td>
      <td><code>update_subscription</code></td>
      <td>Wird versendet, wenn ein Abonnement erneuert oder geändert wird.</td>
    </tr>
    <tr>
      <td><a href="https://developers.xsolla.com/de/webhooks/operation/canceled-subscription/">Storniertes Abonnement</a></td>
      <td><code>cancel_subscription</code></td>
      <td>Wird versendet, wenn ein Abonnement gekündigt wird.</td>
    </tr>
    <tr>
      <td><a href="https://developers.xsolla.com/de/webhooks/operation/nonrenewing-subscription/">Automatisch endendes Abonnement</a></td>
      <td><code>non_renewal_subscription</code></td>
      <td>Wird versendet, wenn der Status auf "Automatisch endend" gesetzt wird.</td>
    </tr>
    <tr>
      <td><a href="https://developers.xsolla.com/de/webhooks/operation/add-payment-account/">Zahlungskonto hinzufügen</a></td>
      <td><code>payment_account_add</code></td>
      <td>Wird versendet, wenn ein Benutzer ein Zahlungskonto hinzufügt oder speichert.</td>
    </tr>
    <tr>
      <td><a href="https://developers.xsolla.com/de/webhooks/operation/remove-payment-account/">Zahlungskonto entfernen</a></td>
      <td><code>payment_account_remove</code></td>
      <td>Wird versendet, wenn ein Benutzer das Zahlungskonto aus den gespeicherten Konten entfernt.</td>
    </tr>
    <tr>
      <td><a href="https://developers.xsolla.com/de/webhooks/operation/user-validation-in-webshop">Benutzervalidierung im Web Shop</a></td>
      <td><code>-</code></td>
      <td>Wird von einer Web Shop-Seite gesendet, um zu prüfen, ob ein Benutzer im Spiel vorhanden ist.</td>
    </tr>
    <tr>
      <td><a href="https://developers.xsolla.com/de/webhooks/operation/personalized-partner-catalog">Katalogpersonalisierung aufseiten des Partners</a></td>
      <td><code>partner_side_catalog</code></td>
      <td>Wird gesendet, wenn ein Benutzer mit dem Shop interagiert.</td>
    </tr>
    <tr>
      <td><a href="https://developers.xsolla.com/de/webhooks/operation/successful-order-payment">Erfolgreiche Bezahlung der Bestellung</a></td>
      <td><code>order_paid</code></td>
      <td>Wird gesendet, wenn eine Bestellung bezahlt wurde.</td>
    </tr>
    <tr>
      <td><a href="https://developers.xsolla.com/de/webhooks/operation/order-cancellation">Stornierung der Bestellung</a></td>
      <td><code>order_canceled</code></td>
      <td>Wird gesendet, wenn eine Bestellung storniert wird.</td>
    </tr>
    <tr>
      <td><a href="https://developers.xsolla.com/de/webhooks/operation/dispute">Streitfall</a></td>
      <td><code>dispute</code></td>
      <td>Wird gesendet, wenn ein neuer Streiftall eröffnet wird.</td>
    </tr>
</tbody>
</table>


Version: 1.0

## Servers

```
https://api.xsolla.com/merchant/v2
```

## Download OpenAPI description

[Webhooks](https://xsolla.redocly.app/_bundle/@l10n/de/webhooks/index.yaml)

## Benutzervalidierung

### Benutzersuche

 - [POST user-search](https://xsolla.redocly.app/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://xsolla.redocly.app/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 &gt; Webhooks &gt; 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 &gt; Webhooks &gt; Testen &gt; Payments &gt; 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://xsolla.redocly.app/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://xsolla.redocly.app/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://xsolla.redocly.app/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 &gt; Webhooks &gt; 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 &gt; Webhooks &gt; Testen &gt; Payments &gt; 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
        Die Zahlung wurde abgelehnt, da das Zahlungssystem einen möglichen Betrugsversuch festgestellt hat.Empfehlung: Setzen Sie den Nutzer auf die Sperrliste.
    
    
        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://xsolla.redocly.app/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 &gt; Webhooks &gt; Testen &gt; Payments &gt; 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.
    
    
        Länder-Quellensteuer und Nutzerakquisitionsgebühr anzeigen
        Die Objekte payment_details.​country_wht und payment_details.​user_acquisition_fee werden im Webhook übermittelt. Der Schalter ist standardmäßig aktiviert.
    
    
        3DS-Infos senden
        Das Objekt cards mit den Daten für die "3-D Secure"-Prüfung wird im Webhook übermittelt.
    




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://xsolla.redocly.app/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://xsolla.redocly.app/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 &gt; Webhooks &gt; Testen &gt; Payments &gt; 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
    
    
        Infos über den Erstattungsgrund anzeigen
        Ausführliche Informationen zu den Gründen der Erstattung.
    



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 – AFS reject
        Die Transaktion wurde abgelehnt, da Xsollas Betrugsbekämpfungssystem einen möglichen Betrugsversuch erkannt hat.
    
    
        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
        Die Zahlung wurde abgelehnt, da das Zahlungssystem einen möglichen Betrugsversuch festgestellt hat.Empfehlung: Setzen Sie den Nutzer auf die Sperrliste.
    
    
        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, die Transaktion nicht getätigt zu haben.Empfehlung: Setzen Sie den Nutzer auf die Sperrliste.
    
    
        12
        Potential fraud – friendly fraud
        Der rechtmäßige Karteninhaber hat die Transaktion beanstandet.
    
    
        13
        Duplicate
        Duplizierte Transaktion für dieselbe Rechnung.
    
    
        21
        Potential fraud – BIN attack
        Gestohlene Karten, die aus einer BIN oder mehreren BINs generiert wurden. Ein wichtiger Indikator sind zahlreiche Versuche innerhalb eines kurzen Zeitfensters, die sich auf denselben BIN-Bereich erstrecken, häufig mit durchlaufend generierten Kartennummern.
    
    
        22
        Potential fraud – monetization fraud
        Gestohlene Karte, die zum Kauf handelbarer Artikel mit der Absicht des Weiterverkaufs verwendet wird.
    
    
        23
        Potential fraud – low-scale card fraud
        Gestohlene Karten, die aus einer BIN oder mehreren BINs generiert wurden. Nicht so weit verbreitet und koordiniert wie der BIN-Angriff (Erstattungscode 21).
    
    
        24
        Potential fraud – regional price abuse
        Missbrauch im Zusammenhang mit länderspezifischen Preisen oder dem Weiterverkauf von Schlüsseln. Nutzer nutzten regionale Preisunterschiede aus (in der Regel durch falsche Angaben zum Standort oder zur Zahlungsmethode), um Artikel kostengünstig zu erwerben und sie anschließend in Märkten mit höheren Preisen weiterzuverkaufen.
    
    
        25
        Potential fraud – partner or PS exploit
        Diebstahl von Zugangsdaten und Kontoübernahme – Missbrauch eines Kontos oder einer Integration aufseiten des Partners oder des Zahlungssystems anstelle eines unmittelbaren Kartenmissbrauchs.
    
    
        26
        Potential fraud – not definable
        Es liegt ein bestätigter Betrugsfall vor, jedoch reichen die Beweise nicht aus, um die genaue Art des Angriffs zu bestimmen.
    
    
        27
        Fraud notification from PS – linked transactions
        Die Transaktion selbst wurde im Betrugsbericht des Zahlungssystems nicht näher beschrieben, steht jedoch (beispielsweise über eine gemeinsam genutzte Karte oder ein gemeinsam genutztes Gerät) in Zusammenhang mit Transaktionen, die aufgrund von Betrugsverdacht erstattet wurden.

### Zahlungskonto entfernen

 - [POST remove-payment-account](https://xsolla.redocly.app/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://xsolla.redocly.app/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://xsolla.redocly.app/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 &gt; Webhooks &gt; 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://xsolla.redocly.app/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://xsolla.redocly.app/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://xsolla.redocly.app/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.


Hinweis
Beachten Sie bei der Verarbeitung des Webhooks die folgenden Einschränkungen:Der Webhook muss innerhalb von drei Sekunden verarbeitet werden. Dauert die Verarbeitung länger, geben die API-Aufrufe Liste virtueller Gegenstände abrufen, Zahlungstoken erstellen und Bestellung anlegen einen Fehler zurück.Die Webhook-Antwort darf höchstens 64 kB groß sein. Antworten, die diese Obergrenze überschreiten, werden nicht verarbeitet – der Nutzer sieht einen leeren Katalog und kann keine Artikel kaufen. Um die maximal zulässige Antwortgröße zu ändern, wenden Sie sich bitte an Ihren Customer Success Manager oder senden Sie eine E-Mail an csm@xsolla.com.

## Anti-fraud

### Anti-fraud-Sperrliste aktualisieren

 - [POST afs-rejected-blocklist](https://xsolla.redocly.app/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://xsolla.redocly.app/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 &gt; Webhooks &gt; 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 &gt; Webhooks &gt; Testen &gt; Payments &gt; 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://xsolla.redocly.app/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://xsolla.redocly.app/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://xsolla.redocly.app/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://xsolla.redocly.app/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://xsolla.redocly.app/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.