# Webhooks
# Descripción general
Los webhooks son notificaciones sobre eventos que se producen en el sistema.
Cuando ocurre un evento específico, Xsolla envía una solicitud HTTP, en la cual
se transmiten los datos del evento, a su aplicación. Generalmente, se trata de
una solicitud POST en formato JSON.
Ejemplos de eventos:
- interacción del usuario con un catálogo de artículos
- pago o cancelación de un pedido
Cuando se produce un evento definido, Xsolla lo notifica a su sistema mediante
un webhook. En consecuencia, puede realizar acciones como:
- reponer el saldo del usuario
- efectuar una devolución de pago
- abonar o cargar nuevos artículos en la cuenta de usuario
- empezar a proveer una suscripción
- bloquear a un usuario si hay una sospecha de fraude
Ejemplo de un flujo de trabajo de webhook de procesamiento de pagos:

Nota
Dependiendo de la solución utilizada y del tipo de integración, el conjunto de webhooks y la secuencia de interacciones pueden ser distintos a los del ejemplo proporcionado.
Videoguía para la integración de webhooks con Xsolla:
Configuración de Webhooks para trabajar con productos y soluciones de Xsolla:
| Producto/Solución |
Obligatorio/Opcional |
¿Para qué se utilizan los webhooks? |
| Payments |
Obligatorio |
- Validación del usuario.
- Recibir información sobre los datos de la transacción en caso de pago aceptado o devolución del pago.
- Abonar a un usuario los artículos comprados y cargar en su cuenta los artículos si se cancela el pedido.
|
| In-Game Store |
Obligatorio |
- Validación del usuario.
- Recibir información sobre los datos de la transacción en caso de pago aceptado o devolución del pago.
- Abonar a un usuario los artículos comprados y cargar en su cuenta los artículos si se cancela el pedido.
|
| Game Sales |
Opcional |
Para vender claves del juego, la validación del usuario y el abono de los artículos no son necesarios. Puede conectar los webhooks si desea recibir información sobre eventos, como el pago o la cancelación de pedidos. Si conecta webhooks, es esencial procesar todos los webhooks requeridos entrantes.
|
| Suscripciones |
Opcional |
Recibir información sobre la creación, actualización o cancelación de una suscripción. También puede solicitar información mediante la API.
|
| Web Shop |
Obligatorio |
- Validación del usuario.
- Recibir información sobre los datos de la transacción en caso de pago aceptado o devolución del pago.
- Abonar a un usuario los artículos comprados y cargar en su cuenta los artículos si se cancela el pedido.
- Autenticación de usuario, si usa la autenticación mediante ID de usuario. Como alternativa, puede utilizar autenticación de usuario mediante Xsolla Login.
|
| Digital Distribution Hub |
Obligatorio |
- Validación del usuario.
- Vincular el ID de transacción en el lado de Xsolla con el ID de transacción en su sistema.
- Transferir parámetros de transacción adicionales en el pedido.
- Abonar al usuario los artículos comprados y cargar en su cuenta los artículos si se cancela el pedido.
Consulte la documentación para obtener información detallada sobre cómo establecer webhooks para el Digital Distribution Hub.
|
| Login |
Opcional |
Recibir información sobre un evento:
- registro/autorización del usuario
- Confirmación de la dirección de correo electrónico del usuario
- vincular la cuenta de redes sociales de un usuario
Consulte la documentación de Login para obtener información detallada sobre cómo establecer webhooks.
|
# Lista de webhooks requeridos
Si utiliza productos y soluciones que requieren trabajar con webhooks, active
y pruebe los webhooks en su Cuenta del editor y establezca su
procesamiento. Cuando se producen eventos específicos, los webhooks se
envían secuencialmente. Por lo tanto, si no procesa uno de los webhooks, no se
enviarán los posteriores. La lista de webhooks requeridos se muestra a
continuación.
## In-Game Store y Payments
Se han configurado 2 opciones de envío de webhook por parte de Xsolla al
comprar y devolver artículos en el sitio: la información con los datos de pago
y transacción, y la información sobre los artículos comprados pueden enviarse
por separado o pueden combinarse en un solo webhook.
Recibir información en webhooks combinados:
Si se registró en Cuenta del editor
después del 22 de enero de 2025, recibirá toda la información en los webhooks
Successful payment for
order (`order_paid`) y Order cancellation (`order_canceled`). En este caso, no es
necesario procesar los webhooks Payment (`payment`) y Refund (`refund`).
Recibir información en webhooks separados:
Si se registró en Cuenta del editor
el 22 de enero de 2025 o antes, recibirá los siguientes webhooks:
- Pago (`payment`) y Reembolso (`refund`) con información
sobre los datos de pago y los detalles de la transacción.
- Successful
payment for order (`order_paid`) y Order cancellation (`order_canceled`) con
información sobre los artículos comprados.
Debe procesar todos los webhooks entrantes. Para cambiar a la nueva opción con
la recepción de webhooks combinados, contacte con sus gestores de éxito del
cliente o escriba a csm@xsolla.com.
Para el funcionamiento completo de la tienda del juego y la gestión de pagos,
es necesario implementar el procesamiento de los principales webhooks.
Si recibe webhooks combinados:
| Nombre y tipo de webhook |
Descripción |
Validación del usuario > Validación del usuario (user_validation) |
Se envía en diferentes etapas del proceso de pago para garantizar que el usuario está registrado en el juego. |
> Webhooks combinados > de Game services Successful payment for order (order_paid) |
Contiene datos de pago, detalles de la transacción e información sobre los artículos comprados. Utilice los datos del webhook para añadir artículos al usuario. |
Servicios de juego > Webhooks combinados > Cancelación del pedido (order_canceled) |
Contiene datos del pago cancelado, detalles de la transacción e información sobre los artículos comprados. Utilice los datos del webhook para eliminar los artículos comprados. |
Si recibe webhooks por separado:
| Nombre y tipo de webhook |
Descripción |
Validación del usuario > Validación del usuario (user_validation) |
Se envía en diferentes etapas del proceso de pago para garantizar que el usuario está registrado en el juego. |
Pagos > Pago (payment) |
Contiene los datos del pago y los detalles de la transacción. |
> Webhooks separados >de Game services Successful payment for order (order_paid) |
Contiene información sobre los artículos comprados. Utilice los datos del webhook para añadir artículos al usuario. |
Pagos > Reembolso (refund) |
Contiene los datos del pago y los detalles de la transacción. |
Servicios de juego > Webhooks separados > Cancelación del pedido (order_canceled) |
Contiene información sobre los artículos comprados y el ID de la transacción cancelada. Utilice los datos del webhook para eliminar los artículos comprados. |
Si la personalización
del catálogo de artículos se implementa en el lado de su aplicación, establezca
el procesamiento del webhook Personalización del catálogo en el lado del socio.
## Suscripciones
Para gestionar automáticamente los planes de suscripción, es necesario
implementar el procesamiento de los principales webhooks:
- Validación del usuario
(`user_validation`): se envía en diferentes etapas del proceso de pago para
garantizar que el usuario esté registrado en el juego.
- Pago (`payment`): se envía cuando se
paga un pedido y contiene los datos del pago y los detalles de la transacción.
- Suscripción creada
(`create_subscription`): se envía cuando se ha procesado correctamente un
webhook de Pago o el usuario ha
adquirido una suscripción con un periodo de prueba. Contiene los detalles de la
suscripción adquirida y los datos del usuario. Use los datos del webhook para
agregar una suscripción al usuario.
- Suscripción actualizada
(`update_subscription`): se envía cuando se renueva o modifica una suscripción,
cuando se ha procesado correctamente un webhook de Pago.
Contiene los detalles de la suscripción adquirida y los datos del usuario. Use
los datos del webhook para ampliar la suscripción del usuario o cambiar los
parámetros de la suscripción.
- Reembolso (`refund`): se envía cuando
se cancela un pedido y contiene los datos del pago cancelado y los detalles de
la transacción.
- Suscripción cancelada
(`cancel_subscription`): se envía cuando se ha procesado correctamente un
webhook de Reembolso o se ha cancelado
la suscripción por otro motivo. Contiene información sobre la suscripción y los
datos del usuario. Use los datos del webhook para sustraer al usuario las
suscripciones adquiridas.
# Establecer webhooks en Cuenta del editor
## Configuración general
Para habilitar la recepción de webhooks:
1. En el proyecto en la Cuenta del editor vaya a Project
Settings > Webhooks.
2. En el campo Webhook server, especifique la URL de su servidor en el que
desea recibir webhooks en el formato `https://example.com`. También puede
especificar la URL que encuentre en una herramienta para probar webhooks.
Atención
El protocolo HTTPS se utiliza para transferir datos; el protocolo HTTP no es compatible.
3. Por defecto, se genera una clave secreta para firmar los webhooks del proyecto.
Si desea generar una nueva clave secreta, haga clic en el icono de
actualización.
4. Haga clic en Enable webhooks.

Tenga en cuenta
Para probar los webhooks, puede seleccionar cualquier sitio web específico, como webhook.site, o una plataforma, como ngrok.
Atención
No puede enviar simultáneamente webhooks a diferentes URL. Lo que sí puede hacer en la Cuenta del editor es especificar primero una URL de prueba y luego sustituirla por la real.
Para deshabilitar la recepción de webhooks:
1. En el proyecto en la Cuenta del editor vaya a Project
Settings > Webhooks.
2. Haga clic en Disable webhooks.
## Configuración avanzada
Para los webhooks de la sección Payments and Store, hay opciones de
configuración avanzada disponibles. Aparecerán automáticamente en el bloque General settings después de hacer clic en el botón Get
webhooks.
Nota
Si no se muestra la configuración avanzada, asegúrese de que la recepción de webhooks está conectada en la configuración general y de que se encuentra en la pestaña Testing > Payments and Store.
En esta sección puede configurar la recepción de información adicional en
webhooks. Para ello, active la opción. La línea de cada permiso indica los
webhooks que se verán afectados al cambiar la configuración.
| Conmutador |
Descripción |
| Mostrar información sobre la cuenta de pago guardada |
La información sobre el método de pago guardado se transmite en el objeto personalizado payment_account. |
| Mostrar información sobre las transacciones mediante los métodos de pago guardados |
La información se transmite en los siguientes parámetros personalizados del webhook: saved_payment_method:0: no se utilizó el método de pago guardado1: el método de pago se guardó al realizar el pago actual2: se utiliza el método de pago guardado previamente
payment_type:1: pago único2: pago periódico
|
| Añadir objeto del pedido al webhook |
La información sobre el pedido se transmite en el objeto order del webhook Pago. |
| Enviar solamente los parámetros de usuario necesarios sin datos confidenciales |
Solamente la siguiente información sobre el usuario se transmite en el webhook: |
| Enviar parámetros personalizados |
La información sobre los parámetros de token personalizados se transmite en el webhook. |
| Mostrar número de BIC y sufijo de la tarjeta |
La siguiente información sobre el número de tarjeta bancaria se transmite en el webhook: - los 6 primeros dígitos del parámetro
card_bin - los 4 últimos dígitos del
card_suffix
|
| Mostrar marca de tarjeta |
La marca de la tarjeta empleada para realizar el pago. Por ejemplo, Mastercard o Visa. |

# Probar webhooks en Cuenta del editor
Probar los webhooks ayuda a asegurar la correcta configuración del proyecto
tanto en su lado como en el lado de Xsolla.
Si los webhooks están establecidos correctamente, aparecerá una sección de
prueba de webhooks bajo la sección de configuración de webhooks.

La sección de pruebas de la Cuenta del editor varía en función de la opción de
recepción del webhook.
Si recibe webhooks combinados:
Si recibe webhooks por separado:
Tenga en cuenta
Si aparece un aviso de que la prueba no se ha superado en la sección de pruebas, verifique la configuración de la respuesta del webhook en su agente de escucha del webhook. Los motivos de los errores en la prueba se indican en los resultados de la prueba.
Ejemplo:
Cuando utiliza el sitio especializado webhook.site para la prueba.
Aparece un error en la sección Testing response to invalid signature.
Esto ocurre porque Xsolla envía un webhook con una firma incorrecta y espera que su controlador responda con un código HTTP 4xx que especifique el código de error INVALID_SIGNATURE.
webhook.site envía un código HTTP 200 en respuesta a todos los webhooks, incluyendo un webhook con una firma incorrecta. No se puede obtener el código HTTP 4xx esperado, por lo que aparece un error en el resultado de la prueba.

A continuación se describe el proceso de pruebas para el escenario con webhooks
combinados.
## Payments and Store
En la pestaña Payments and Store, puede probar los siguientes webhooks:
- Validación del usuario
(`user_validation`)
- Successful payment for
order (`order_paid`)
- Cancelación del pedido
(`order_canceled`)
Para realizar la prueba:
1. En la sección de pruebas de webhooks, vaya a la pestaña Payments and
Store.
2. En el menú desplegable, seleccione el tipo de artículo. Si el artículo del tipo
seleccionado no está establecido en Cuenta del editor, haga clic en:
* Connect: si el módulo con artículos de este tipo no está conectado.
* Configure: si conectó el módulo anteriormente, pero no ha finalizado la
configuración
Cuando haga clic en el botón, se le redirigirá a la sección
de Cuenta del editor correspondiente al tipo de artículo seleccionado. Cuando
haya creado el artículo, vuelva a la sección de pruebas de webhooks y proceda
al siguiente paso.
3. Rellene los campos necesarios: - Seleccione el SKU de los
artículos en la lista desplegable e indique la cantidad. Puede elegir varios
artículos del mismo tipo haciendo clic en + y añadiéndolos en una nueva
línea.
- User ID: al realizar la prueba, puede utilizar cualquier
combinación de letras y dígitos.
- Public user ID: ID conocido
por un usuario, por ejemplo, un correo electrónico o un apodo. Este campo se
muestra si el ID de usuario público está habilitado en su proyecto en Pay
Station > Settings.
- Introduzca cualquier valor en el campo
Xsolla Order ID.
- Xsolla Invoice ID: ID de transacción en
el lado de Xsolla. Al realizar la prueba, puede usar cualquier valor
numérico.
- Invoice ID: ID de transacción del lado de su juego.
Al realizar la prueba, puede utilizar cualquier combinación de letras y
dígitos. No es un parámetro requerido para pagar correctamente, pero puede
transmitirlo para enlazar el ID de transacción de su lado con el ID de
transacción del lado de Xsolla.
- Amount: cantidad del pago. Al
realizar la prueba, puede utilizar cualquier valor numérico.
- Currency: seleccione una moneda de la lista desplegable.
4. Haga clic en Test webhooks.
Los webhooks User
validation, Successful payment for order y Order cancellation con los datos especificados se envían a la
URL facilitada. Los resultados de la prueba de cada tipo de webhook se muestran
debajo del botón Test webhooks.
Si el ID de usuario público está activado en su proyecto, también verá los
resultados de una comprobación de búsqueda de usuarios.
Para cada webhook, tiene que establecer el procesamiento de ambos escenarios:
uno, satisfactorio, y el otro, fallido.

## Suscripciones
En la pestaña Subscriptions puede probar los siguientes webhooks:
- Validación del usuario
(`user_validation`)
- Pago (`payment`)
Nota
En la Cuenta del editor, solo es posible probar los webhooks básicos de Validación del usuario y Pago. Para probar otros tipos de webhooks, vaya a:
Nota
Para probar los webhooks, debe tener al menos un plan de suscripción creado en la sección Cuenta del editor > Subscriptions > Subscription Plans.
Para realizar pruebas: - En la sección de pruebas, vaya a la pestaña
Subscriptions.
- Rellene los campos necesarios:
- User ID: al realizar la prueba, puede usar cualquier combinación de
letras y dígitos.
- Xsolla Invoice ID: ID de transacción en el
lado de Xsolla. Cuando realice pruebas, puede usar cualquier valor
numérico.
- Public user ID: ID conocido por un usuario, p. ej.,
un correo electrónico o un alias. Este campo se muestra si el ID público de
usuario está habilitado en su proyecto en la sección Pay Station > Settings
> Additional settings.
- Currency: seleccione una moneda de la
lista desplegable.
- Plan ID: un plan de suscripción. Elija un
plan de la lista desplegable.
- Subscription product: elija un
producto de la lista desplegable (opcional).
- Amount: importe
del pago. Al realizar pruebas, puede usar cualquier valor numérico.
- Invoice ID: ID de transacción en el lado del juego. Cuando realice
pruebas, puede usar cualquier combinación de letras y dígitos. No es un
parámetro obligatorio para que el pago sea aceptado, pero puede transmitirlo
para vincular el ID de transacción de su lado con el ID de transacción del lado
de Xsolla.
- Periodo de prueba. Para probar la comp
ra de una suscripción sin periodo de prueba o para probar la renovación de una suscripción, especifique el valor
0.
- Haga clic en Test webhooks.
En la URL especificada, recibirá webhooks con datos rellenados. Los resultados
de las pruebas de cada webhook, tanto para un escenario con satisfactorio como
para un escenario fallido, se muestran bajo el botón Test webhooks.
# Agente de escucha de webhooks
El agente de escucha es un código de programa que permite recibir webhooks
entrantes en una dirección URL especificada, generar una firma y enviar una respuesta al servidor de
webhooks de Xsolla.
En el lado de su aplicación, implemente la recepción de webhooks desde las
siguientes direcciones IP:
- `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`
Si ha integrado el producto Login, añada webhooks de
procesamiento desde las siguientes direcciones IP:
- `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`
Limitaciones:
- En la base de datos de su aplicación no debería haber varias transacciones
aceptadas con el mismo ID.
- Si el agente de escucha de webhooks recibió un webhook con un ID que ya existe
en la base de datos, deberá devolver el resultado del procesamiento anterior de
esta transacción. No se recomienda acreditar al usuario una compra duplicada ni
crear registros duplicados en la base de datos.
## Generación de firma
Para garantizar una transmisión de datos segura, debe comprobar que el webhook
se ha enviado desde el servidor de Xsolla y que no ha sido manipulado durante
el tránsito. Para ello, genere su propia firma basada en la carga útil del
cuerpo de la solicitud y compárela con la firma proporcionada en el encabezado
`authorization` de la solicitud entrante. Si las firmas coinciden, significa
que el webhook es auténtico y seguro de procesar.
Pasos de verificación:
1. Obtenga la firma del encabezado `authorization` de la solicitud de webhook
entrante. El formato del encabezado es `Signature `.
2. Obtenga el cuerpo de la solicitud del webhook en formato JSON. Atención
Utilice la carga JSON tal y
como la recibió. No analice ni recodifique la carga útil, ya que modificaría el
formato y provocaría un error en la verificación de la firma.
3. Genere su propia firma para comparar: - Concatene la carga JSON
con la clave secreta de su proyecto al añadir la clave al final de la
cadena.
- Aplique la función hash criptográfica SHA-1 a la cadena
obtenida. El resultado será una cadena hexadecimal en minúsculas.
4. Compare su firma generada con la del encabezado `authorization`. Si coinciden,
significa que el webhook es auténtico.
A continuación encontrará ejemplos de implementación de generación de firmas
para los siguientes lenguajes: C#, C++, Go, PHP y Node.js.
### Ejemplo de 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"
}
}
```
### Ejemplo de 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"
}
}'
```
### Ejemplo C# de implementación de generación de firmas (muestra general):
Nota
Este ejemplo de código es compatible con .NET Framework 4.0 y versiones posteriores, así como con .NET Core y otras versiones modernas de .NET. La verificación de firmas utiliza la comparación en tiempo constante a través del método ConstantTimeEquals para ayudar a prevenir ataques de temporización.
```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;
}
}
```
### Ejemplo C# de implementación de generación de firmas (.NET 5.0 y posteriores):
Nota
Para utilizar el método Convert.ToHexString, necesita .NET 5.0 y posterior.
Si tiene .NET 7.0 y posterior, también puede utilizar el método
CryptographicOperations.FixedTimeEquals en lugar de
ConstantTimeEquals.
```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;
}
}
```
### Ejemplo C# de implementación de generación de firmas (.NET 7.0 y posteriores):
Nota
Si dispone de .NET 7.0 y versiones posteriores, puede utilizar el método CryptographicOperations.FixedTimeEquals.
```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);
}
```
### Ejemplo C++ de implementación de generación de firmas:
```c++
#include
#include
#include
#include
class XsollaWebhookSignature {
public:
static std::string computeSha1(const std::string& jsonBody, const std::string& secretKey) {
// Concatenation of the JSON from the request body and the project's secret key
std::string dataToSign = jsonBody + secretKey;
unsigned char digest[SHA_DIGEST_LENGTH];
// Create SHA1 hash
SHA1(reinterpret_cast(dataToSign.c_str()),
dataToSign.length(), digest);
// Convert to lowercase hexadecimal string
std::ostringstream hexStream;
hexStream << std::hex << std::setfill('0');
for (int i = 0; i < SHA_DIGEST_LENGTH; ++i) {
hexStream << std::setw(2) << static_cast(digest[i]);
}
return hexStream.str();
}
static bool verifySignature(const std::string& jsonBody, const std::string& secretKey, const std::string& receivedSignature) {
std::string computedSignature = computeSha1(jsonBody, secretKey);
// Timing-safe comparison
if (computedSignature.length() != receivedSignature.length()) {
return false;
}
volatile unsigned char result = 0;
for (size_t i = 0; i < computedSignature.length(); ++i) {
result |= (computedSignature[i] ^ receivedSignature[i]);
}
return result == 0;
}
};
```
### Ejemplo Go de implementación de generación de firmas:
```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
}
```
### Ejemplo PHP de implementación de generación de firmas:
```php
```
### Ejemplo Node.js de implementación de generación de firmas:
```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;
}
}
}
```
## Enviar respuestas al webhook
Para confirmar la recepción del webhook, su servidor debe devolver:
* Código HTTP "200", "201" o "204" en el caso de una respuesta satisfactoria.
* Código HTTP "400" con la descripción del problema si no se
encontró el usuario especificado o se transmitió una firma no válida. Su gestor
de webhooks también puede devolver un código HTTP "5xx" si hay problemas
temporales en su servidor.
Si el servidor de Xsolla no ha recibido respuesta a los webhooks Successful payment for
order y Order
cancellation o ha recibido una respuesta con un código `5xx`, los webhooks
se reenvían de la siguiente manera:
* 2 intentos con un intervalo de 5 minutos
* 7 intentos con un intervalo de 15 minutos
* 10 intentos con un intervalo de 60 minutos
Se realiza un máximo de 20 intentos de envío de webhooks en un plazo de 12
horas desde el primer intento.
La lógica de reintento para los webhooks de pago y reembolso se describe en la página del
webhook correspondiente.
Aviso
El pago se reembolsará al usuario si se cumplen las siguientes condiciones:
- El reembolso lo inició Xsolla.
- En respuesta a un webhook, se devolvió un código de estado
4xx, o no se recibió ninguna respuesta tras todos los intentos, o se devolvió un código de estado 5xx.
Si el servidor de Xsolla no ha recibido respuesta al webhook User validation o ha recibido
una respuesta con un código `400` o `5xx`, el webhook User validation no se reenvía.
En este caso, el usuario ve un error y los webhooks Payment y Successful payment for order no se envían.
# Errores
Códigos de error para el código HTTP 400:
| Código |
Mensaje |
| INVALID_USER |
Usuario no válido |
| INVALID_PARAMETER |
Parámetro no válido |
| INVALID_SIGNATURE |
Firma no válida |
| INCORRECT_AMOUNT |
Importe incorrecto |
| INCORRECT_INVOICE |
Factura incorrecta |
```
HTTP/1.1 400 Bad Request
{
"error":{
"code":"INVALID_USER",
"message":"Invalid user"
}
}
```
# Lista de webhooks
Observación
El tipo de notificación se envía en el parámetro notification_type.
Version: 1.0
## Servers
```
https://api.xsolla.com/merchant/v2
```
## Download OpenAPI description
[Webhooks](https://developers.xsolla.com/_bundle/@l10n/es/webhooks/index.yaml)
## Validación del usuario
### Búsqueda del usuario
- [POST user-search](https://developers.xsolla.com/es/webhooks/user-validation/user-search.md): Public User ID es un parámetro que identifica al usuario de forma exclusiva y que este conoce, a diferencia de User ID (Public User ID puede ser correo electrónico, nombre de usuario, etc). Xsolla envía un webhook con el tipo user_search cuando se realiza una compra fuera de la tienda de juegos (p. ej., a través de quioscos de efectivo/cajeros automáticos).
### Validación del usuario
- [POST user-validation](https://developers.xsolla.com/es/webhooks/user-validation/user-validation.md): Xsolla envía un webhook con el tipo user_validation a la dirección URL del
webhook para verificar que un usuario esté registrado en el juego. La solicitud
se envía varias veces como parte del proceso de pago:
* cuando un usuario elige un método de pago en la interfaz de pago
* cuando un usuario introduce datos en el formulario de pago, p. ej., los datos
de la tarjeta bancaria o el código postal al pagar a través de PayPal
* cuando un usuario hace clic en Pagar ahora para proceder al pago
* cuando finalice el proceso de pago y el estado de la transacción cambie a done
La solicitud se envía al pagar con cualquier método de pago.
Al guardar la URL del webhook en Cuenta del editor, puede dar permisos para
recibir información detallada en los webhooks. Para ello, active las opciones
correspondientes en Cuenta del editor en Project
settings > Webhooks > Advanced settings.
Nota
Si se registró en Cuenta del editor el 22 de enero de 2025 o antes, encontrará las opciones en Project settings > Webhooks > Testing > Payments > Advanced settings.
Conmutador
Descripción
Enviar solamente los parámetros de usuario necesarios sin datos confidenciales
Solamente la siguiente información sobre el usuario se transmite en el webhook:IDpaís
Enviar parámetros personalizados
La información sobre los parámetros de token personalizados se transmite en el webhook.
### Validación de usuarios en Web Shop
- [POST user-validation-in-webshop](https://developers.xsolla.com/es/webhooks/user-validation/user-validation-in-webshop.md): Xsolla envía un webhook desde un sitio de Web Shop para comprobar si un usuario existe en el juego. El webhook se envió desde la siguiente dirección IP: "34.102.38.178".
ObservaciónEl webhook se utiliza solamente para la
validación de usuarios en Web Shop. Consulte estas instrucciones para obtener más información sobre cómo configurar este webhook en Site Builder.
## Payments
### Añadir cuenta de pago
- [POST add-payment-account](https://developers.xsolla.com/es/webhooks/payments/add-payment-account.md): Xsolla envía un webhook con el tipo de payment_account_add a la URL del webhook cada vez que un usuario añade una cuenta de pago o guarda una cuenta de pago al comprar algo dentro del juego. Para recibir este webhook, contacte con su gestor del éxito del cliente o envíe un correo electrónico a csm@xsolla.com.
### Reembolso parcial
- [POST partial-refund](https://developers.xsolla.com/es/webhooks/payments/partial-refund.md): Cuando se realiza un reembolso parcial, Xsolla envía los detalles de la
transacción cancelada en un webhook con el tipo de partial_refund a la URL
del webhook. Obtenga más información sobre el proceso de reembolso parcial en
estas instrucciones.
Al guardar la URL del webhook en Cuenta del editor, puede dar permisos para
recibir información detallada en los webhooks. Para ello, active la siguiente
opción en Cuenta del editor en Project
settings > Webhooks > Advanced settings.
Nota
Si se registró en Cuenta del editor el 22 de enero de 2025 o antes, encontrará las opciones en Project settings > Webhooks > Testing > Payments > Advanced settings.
Conmutador
Descripción
Mostrar información sobre las transacciones mediante los métodos de pago guardados
La información se transmite en los siguientes parámetros personalizados del webhook:saved_payment_method:0: no se utilizó el método de pago guardado1: el método de pago se guardó al realizar el pago actual2: se utiliza el método de pago guardado previamentepayment_type:1: pago único2: pago periódico
Códigos de reembolso:
Código
Motivo
Descripción
1
Cancelación por solicitud del usuario/solicitud del juego
Cancelación iniciada desde Cuenta del editor.
3
Integration error (Error de integración)
Problemas con la integración entre Xsolla y el juego.Recomendación: no añada el usuario a la lista de bloqueo.
5
Test payment (Pago de prueba)
Transacción de prueba seguida de cancelación.Recomendación: no añada el usuario a la lista de bloqueo.
7
Fraud notification from PS (Notificación de fraude de PS)
Pago rechazado por el sistema de pago. Fraude potencial detectado por PS.Recomendación: añada el usuario a la lista de bloqueo.
9
Cancellation by the user request (Cancelación solicitada por el usuario)
El usuario no quedó satisfecho con el juego o con la compra por cualquier motivo.Recomendación: no añada el usuario a la lista de bloqueo.
10
Cancellation by the game request
Cancelación solicitada por el juego.Recomendación: no añada el usuario a la lista de bloqueo.
### Pago
- [POST payment](https://developers.xsolla.com/es/webhooks/payments/payment.md): Cuando un usuario finaliza el proceso de pago, Xsolla envía los datos del pago
en un webhook con el tipo payment a la URL del webhook.
Los códigos de respuesta esperados se describen en la sección Responses,
pero también puede usar otros códigos de respuesta:
Código de respuesta
Descripción
200, 201, 204
Una respuesta correcta.
4xx
Se ha producido un error. Por ejemplo, si no se ha encontrado el usuario especificado o se ha transmitido una firma que no es válida.
5xx
Un error temporal del servidor. Cuando se recibe esta respuesta, Xsolla automáticamente volverá a intentar enviar el webhook, aumentando progresivamente el intervalo entre intentos hasta que su agente de escucha confirme la recepción. El número máximo de reintentos es de 12 en un periodo de 48 horas.
Cuando guarde la URL del webhook en Cuenta del
editor, también podrá configurar la recepción de información adicional en
webhooks.
Nota
Si se registró en Cuenta del editor el 22 de enero de 2025 o antes, encontrará las opciones en su proyecto en Settings > Webhooks > Testing > Payments > Advanced settings.
Conmutador
Descripción
Mostrar información sobre la cuenta de pago guardada
La información sobre el método de pago guardado se transmite en el objeto personalizado payment_account.
Mostrar información sobre las transacciones mediante los métodos de pago guardados
La información se transmite en los siguientes parámetros personalizados del webhook:saved_payment_method:0: no se utilizó el método de pago guardado1: el método de pago se guardó al realizar el pago actual2: se utiliza el método de pago guardado previamentepayment_type:1: pago único2: pago periódico
Añadir objeto del pedido al webhook
La información sobre el pedido se transmite en el objeto order del webhook Pago.
Enviar solamente los parámetros de usuario necesarios sin datos confidenciales
Solamente la siguiente información sobre el usuario se transmite en el webhook:IDpaís
Mostrar número de BIC y sufijo de la tarjeta
La siguiente información sobre el número de tarjeta bancaria se transmite en el webhook:los 6 primeros dígitos del parámetro card_binlos 4 últimos dígitos del card_suffix
Mostrar marca de tarjeta
La marca de la tarjeta empleada para realizar el pago. Por ejemplo, Mastercard o Visa.
Aviso
Los campos que se envían en un webhook dependen de:los parámetros establecidos en la configuración avanzada de Cuenta del editorla configuración personalizada establecida en el lado de XsollaSi tiene alguna pregunta, contacte con su gestor del éxito del cliente o envíe un correo electrónico a csm@xsolla.com.
### Pago rechazado
- [POST payment-declined](https://developers.xsolla.com/es/webhooks/payments/payment-declined.md): Si una transacción es rechazada por un sistema de pago, Xsolla envía los
detalles de la transacción en un webhook del tipo ps_declined a la URL
configurada de su webhook. El webhook se envía durante la fase de autorización
o de procesamiento del pago. En este caso, el webhook
payment\ order_paid no se envía.
Razones habituales del rechazo por parte de los sistemas de pago:
* Se produjo un error en la autorización de la tarjeta (por ejemplo, el sistema
de pago no pudo finalizar el proceso de autorización debido a un error técnico
o a la falta de respuesta del banco) o la transacción fue rechazada (por
ejemplo, el banco respondió pero denegó la transacción por fondos insuficientes
o porque los datos de la tarjeta no eran válidos).
* Se produjo un error en la verificación 3-D Secure, no se ha realizado o se
agotó el tiempo de confirmación del usuario.
* El procesador o el banco adquirente no está disponible temporalmente o devuelve
un rechazo definitivo debido a un error irreversible, como una cuenta cerrada o
un número de tarjeta no válido. Volver a intentarlo sin solucionar el problema
de fondo no resultará en una transacción satisfactoria.
No debe confundirse con:
* Rechazos por el sistema antifraude, que se notifican mediante el webhook
afs_reject.
* Reembolsos y reembolsos parciales tras un pago realizado con éxito, que se
notifican mediante los webhooks
refund y
partial_refund.
Observación
Para recibir el webhook ps_declined, contacte con su gestor de éxito del cliente o envíe un correo electrónico a csm@xsolla.com.
### Reembolso
- [POST refund](https://developers.xsolla.com/es/webhooks/payments/refund.md): Cuando se cancela un pago, Xsolla envía los detalles de la transacción
cancelada en un webhook con el tipo refund a la URL del webhook.
El mecanismo de reintento del webhook depende de quién haya iniciado el
reembolso:
* Si el reembolso se inició desde su lado, el webhook no se volverá a enviar. El
pago se reembolsará al usuario independientemente de la respuesta al webhook.
* Si el reembolso lo inició un tercero (por ejemplo, un sistema de pagos o el
equipo de atención al cliente de Xsolla) y, en respuesta a un webhook, se
devolvió un código de estado 5xx, el webhook se reenvía a intervalos cada vez
mayores. El número máximo de reintentos es de 12 en un plazo de 48 horas desde
el primer intento.
Para obtener información detallada sobre el proceso de reembolso, consulte las
instrucciones.
Aviso
El pago se reembolsará al usuario si se cumplen las siguientes condiciones:El reembolso lo inició Xsolla.En respuesta a un webhook, se devolvió un código de estado 4xx, o no se recibió ninguna respuesta tras todos los intentos, o se devolvió un código de estado 5xx.
Cuando guarde la URL del webhook en Cuenta del
editor, también podrá configurar la recepción de información adicional en
webhooks.
Nota
Si se registró en Cuenta del editor el 22 de enero de 2025 o antes, encontrará las opciones en su proyecto en Settings > Webhooks > Testing > Payments > Advanced settings.
Conmutador
Descripción
Mostrar información sobre las transacciones mediante los métodos de pago guardados
La información se transmite en los siguientes parámetros personalizados del webhook:saved_payment_method:0: no se utilizó el método de pago guardado1: el método de pago se guardó al realizar el pago actual2: se utiliza el método de pago guardado previamentepayment_type:1: pago único2: pago periódico
Códigos de reembolso:
Código
Motivo
Descripción
1
Cancelación por solicitud del usuario/solicitud del juego
Cancelación iniciada desde Cuenta del editor.
2
Chargeback (Contracargo)
Contracargo de transacción solicitado.
3
Integration error (Error de integración)
Problemas con la integración entre Xsolla y el juego.Recomendación: no añada el usuario a la lista de bloqueo.
4
Potential fraud (Fraude potencial)
Sospecha de fraude.Recomendación: no añada el usuario a la lista de bloqueo.
5
Test payment (Pago de prueba)
Transacción de prueba seguida de cancelación.Recomendación: no añada el usuario a la lista de bloqueo.
6
User invoice expired (Factura de usuario expirada)
Factura vencida (se usa para el modelo de pospago).
7
Fraud notification from PS (Notificación de fraude de PS)
Pago rechazado por el sistema de pago. Fraude potencial detectado por PS.Recomendación: añada el usuario a la lista de bloqueo.
8
Cancellation by the PS request (Cancelación solicitada por PS)
Cancelación solicitada por el sistema de pago.Recomendación: no añada el usuario a la lista de bloqueo.
9
Cancellation by the user request (Cancelación solicitada por el usuario)
El usuario no quedó satisfecho con el juego o con la compra por cualquier motivo.Recomendación: no añada el usuario a la lista de bloqueo.
10
Cancellation by the game request
Cancelación solicitada por el juego.Recomendación: no añada el usuario a la lista de bloqueo.
11
Account holder called to report fraud
El titular de la cuenta declara que no realizó la transacción.
12
Friendly fraud
Fraude amistoso comunicado.
13
Duplicate
Transacción duplicada para la misma factura.
### Eliminar cuenta de pago
- [POST remove-payment-account](https://developers.xsolla.com/es/webhooks/payments/remove-payment-account.md): Cuando un usuario elimina la cuenta de pago de las cuentas guardadas, Xsolla envía un webhook con el tipo payment_account_remove a la URL del webhook. Para recibir este webhook, contacte con su gestor del éxito del cliente o envíe un correo electrónico a csm@xsolla.com.
## Webhooks combinados
### Cancelación del pedido (con los detalles del pago y la transacción)
- [POST order-cancellation](https://developers.xsolla.com/es/webhooks/combined-webhooks/order-cancellation.md): Xsolla envía el webhook order_canceled a la URL especificada
cuando el pago es cancelado por el usuario, socio o de forma automática. El
webhook contiene información sobre los artículos devueltos, los datos de pago y
los detalles del pedido cancelado.
El webhook no se envía si el pago no se realiza correctamente, por ejemplo:
* se abrió la interfaz de pago, pero el usuario no pagó el pedido
* se abrió la interfaz de pago, pero hubo errores durante el pago
El tiempo de procesamiento recomendado del webhook es de menos de 3 segundos.
### Pago del pedido realizado correctamente (con detalles del pago y de la transacción)
- [POST successful-order-payment](https://developers.xsolla.com/es/webhooks/combined-webhooks/successful-order-payment.md): Xsolla envía el webhook order_paid a la URL especificada cuando el
usuario paga el pedido.
El webhook order_paid contiene información sobre los artículos
comprados, los datos de pago y los detalles de la transacción.
El webhook order_paid no se envía si el pago no se realiza
correctamente, por ejemplo:
* se abrió el formulario de pago, pero el usuario no pagó el pedido
* se abrió el formulario de pago, pero hubo errores durante el pago
Se recomienda que el tiempo de procesamiento del webhook
order_paid sea inferior a 3 segundos.
Aviso
Los campos que se envían en un webhook dependen de los siguientes parámetros de configuración:los que haya establecido en Cuenta del editor en Project settings > Webhooks > Advanced settings los establecidos en el lado de XsollaSi tiene alguna duda, contacte con su gestor del éxito del cliente o envíe un correo electrónico a csm@xsolla.com.
Las respuestas esperadas se describen en la sección Responses. Puede
utilizar otros códigos de respuesta. Dependiendo del código de respuesta y de
la conexión de la función de reembolso automático de pagos, la lógica de
procesamiento del webhook por parte de Xsolla es la siguiente:
Código de respuesta
El reembolso automático de pagos está desactivado (por defecto)
El reembolso automático de pagos está activado
400, 401, 402, 403, 404, 409, 422, 415
Ninguna acción
Reembolso automático al usuario
200, 201, 204
Ninguna acción
Ninguna acción
Diferente código o ninguna respuesta al webhook
Se envían varios webhooks en un intervalo de tiempo especificado: 2 intentos con un intervalo de 5 minutos, 7 intentos con un intervalo de 15 minutos, 10 intentos con un intervalo de 60 minutos.
Se envían varios webhooks en un intervalo especificado: 2 intentos con un intervalo de 5 minutos, 7 intentos con un intervalo de 15 minutos, 10 intentos con un intervalo de 60 minutos. Si se envían todos los webhooks pero no se recibe una respuesta satisfactoria, se emite un reembolso automático al usuario.
Para conectar la función de reembolso automático, contacte con sus gestores de
éxito del cliente o escriba a csm@xsolla.com.
## Webhooks independientes
### Cancelación del pedido (sin los detalles del pago y la transacción)
- [POST order-cancellation-separate](https://developers.xsolla.com/es/webhooks/separate-webhooks/order-cancellation-separate.md): Xsolla envía el webhook order_canceled a la URL especificada
cuando el pago ha sido cancelado por el usuario, el socio o automáticamente. El
webhook contiene información sobre los artículos devueltos y los detalles del
pedido cancelado.
El webhook no se envía si el pago no se ha realizado correctamente, por ejemplo:
* se abrió la interfaz de pago, pero el usuario no pagó el pedido
* se abrió la interfaz de pago, pero hubo errores durante el pago
El tiempo de procesamiento recomendado del webhook es de menos de 3 segundos.
### Pago del pedido realizado correctamente (sin los detalles del pago ni de la transacción)
- [POST successful-order-payment-separate](https://developers.xsolla.com/es/webhooks/separate-webhooks/successful-order-payment-separate.md): Xsolla envía el webhook order_paid a la URL especificada cuando se
cumplen las siguientes condiciones:
1. El usuario pagó correctamente el pedido.
2. Xsolla recibió una respuesta sobre el procesamiento correcto del webhook
payment.
El webhook order_paid contiene información sobre los artículos
comprados y los datos de la transacción.
El webhook order_paid no se envía si:
* El pago no se realizó correctamente, por ejemplo:
* se abrió el formulario de pago, pero el usuario no pagó el pedido
* se abrió el formulario de pago, pero hubo errores durante el pago
* No se ha recibido la respuesta sobre el procesamiento correcto del webhook
payment.
Se recomienda que el tiempo de procesamiento del webhook
order_paid sea inferior a 3 segundos.
Las respuestas esperadas se describen en la sección Responses. Puede
utilizar otros códigos de respuesta. Dependiendo del código de respuesta y de
la conexión de la función de reembolso automático de pagos, la lógica de
procesamiento del webhook por parte de Xsolla es la siguiente:
Código de respuesta
El reembolso automático de pagos está desactivado (por defecto)
El reembolso automático de pagos está activado
400, 401, 402, 403, 404, 409, 422, 415
Ninguna acción
Reembolso automático al usuario
200, 201, 204
Ninguna acción
Ninguna acción
Diferente código o ninguna respuesta al webhook
Se envían varios webhooks en un intervalo de tiempo especificado: 2 intentos con un intervalo de 5 minutos, 7 intentos con un intervalo de 15 minutos, 10 intentos con un intervalo de 60 minutos.
Se envían varios webhooks en un intervalo especificado: 2 intentos con un intervalo de 5 minutos, 7 intentos con un intervalo de 15 minutos, 10 intentos con un intervalo de 60 minutos. Si se envían todos los webhooks pero no se recibe una respuesta satisfactoria, se emite un reembolso automático al usuario.
Para conectar la función de reembolso automático, contacte con sus gestores de
éxito del cliente o escriba a csm@xsolla.com.
## Webhook de personalización
### Personalización del catálogo en el lado del socio
- [POST personalized-partner-catalog](https://developers.xsolla.com/es/webhooks/personalization/personalized-partner-catalog.md): Xsolla enviará un webhook partner_side_catalog que contenga los
parámetros del usuario y del proyecto a la URL del webhook cuando un usuario
interactúe con la tienda.
Devuelve una lista de item_id o de SKU (códigos) de artículo que
están disponibles para el usuario como respuesta. En este caso, también puede
incluir información de que un usuario concreto puede comprar un determinado
producto un número especificado de veces. Esta función le permite controlar el
número y el tipo de productos que el usuario puede añadir a la cesta y comprar.
Se recomienda que el tiempo de procesamiento del webhook
partner_side_catalog sea inferior a 3 segundos.
## Anti-fraud
### Actualización de la lista de bloqueo antifraude
- [POST afs-rejected-blocklist](https://developers.xsolla.com/es/webhooks/anti-fraud/afs-rejected-blocklist.md): Cuando se actualiza la lista de bloqueo del sistema antifraude (agregar o eliminar un parámetro), Xsolla envía un webhook con el tipo de afs_black_list a la URL del webhook. La adición del parámetro se realiza automáticamente en el lado de Xsolla o previa solicitud. La eliminación de un parámetro solo puede realizarse previa solicitud. Para recibir este webhook, contacte con su gestor del éxito del cliente o envíe un correo electrónico a csm@xsolla.com.
### Transacción rechazada por el sistema Anti-fraud
- [POST afs-rejected-transaction](https://developers.xsolla.com/es/webhooks/anti-fraud/afs-rejected-transaction.md): Cuando se rechaza una transacción durante una comprobación del sistema
Antifraude, Xsolla envía los detalles de la transacción en el webhook con el
tipo de afs_reject a la URL del webhook. Para recibir este webhook, contacte
con su gestor del éxito del cliente o envíe un correo electrónico a csm@xsolla.com.
Al guardar la URL del webhook en Cuenta del editor, puede dar permisos para
recibir información detallada en los webhooks. Para ello, active la siguiente
opción en Cuenta del editor en Project
settings > Webhooks > Advanced settings.
Nota
Si se registró en Cuenta del editor el 22 de enero de 2025 o antes, encontrará las opciones en Project settings > Webhooks > Testing > Payments > Advanced settings.
Conmutador
Descripción
Mostrar información sobre las transacciones mediante los métodos de pago guardados
La información se transmite en los siguientes parámetros personalizados del webhook:saved_payment_method:0: no se utilizó el método de pago guardado1: el método de pago se guardó al realizar el pago actual2: se utiliza el método de pago guardado previamentepayment_type:1: pago único2: pago periódico
### Disputa
- [POST dispute](https://developers.xsolla.com/es/webhooks/anti-fraud/dispute.md): Cuando se abre una nueva disputa o una disputa cambia de estado, Xsolla envía un webhook con el tipo dispute a la URL del webhook. Para recibir este webhook, contacte con su gestor de éxito del cliente o envíe un correo electrónico a csm@xsolla.com.
## Suscripciones
### Suscripción cancelada
- [POST canceled-subscription](https://developers.xsolla.com/es/webhooks/subscriptions/canceled-subscription.md): Cuando se cancela una suscripción, Xsolla envía un webhook con el tipo de cancel_subscription a la URL del webhook.
### Suscripción creada
- [POST created-subscription](https://developers.xsolla.com/es/webhooks/subscriptions/created-subscription.md): Cuando un usuario crea una suscripción, Xsolla envía un webhook con el tipo de create_subscription a la URL del webhook.
### Suscripción con renovación suspendida
- [POST nonrenewing-subscription](https://developers.xsolla.com/es/webhooks/subscriptions/nonrenewing-subscription.md): Cuando el estado de una suscripción se establece como "con renovación suspendida", Xsolla envía un webhook con el tipo non_renewal_subscription a la URL del webhook. Para recibir este webhook, contacte con su gestor del éxito del cliente o envíe un correo electrónico a csm@xsolla.com.
### Suscripción actualizada
- [POST updated-subscription](https://developers.xsolla.com/es/webhooks/subscriptions/updated-subscription.md): Si algunos parámetros de la suscripción (plan_id, date_next_charge) fueran modificados, y en el caso de cada renovación de suscripción, Xsolla envía un webhook con el tipo update_subscription a la URL del webhook.