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:
Cuando se produce un evento definido, Xsolla lo notifica a su sistema mediante un webhook. En consecuencia, puede realizar acciones como:
Ejemplo de un flujo de trabajo de webhook de procesamiento de pagos:
Webhook de procesamiento de pagos
Configuración de webhooks cuando se trabaja con productos y soluciones de Xsolla:
Producto/Solución | Obligatorio/Opcional | ¿Para qué se utilizan los webhooks? |
---|---|---|
Pagos | Obligatorio |
|
In-Game Store | Obligatorio |
|
Buy Button | 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 | Para 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 | Opcional | Para la 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 | Opcional |
Puede obtener más información en las instrucciones de para establecer webhooks para Digital Distribution Hub. |
Si utiliza productos y soluciones que requieren webhooks, habilite 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 tanto, si no procesa uno de los webhooks, no se enviarán los posteriores. La lista de webhooks requeridos se muestra a continuación.
Para que una tienda dentro del juego funcione plenamente, hay que implementar el procesamiento de los principales webhooks:
user_validation
): se envía en diferentes etapas del proceso de pago para
garantizar que el usuario esté registrado en el juego.payment
): se envía cuando se
paga un pedido y contiene los datos del pago y los detalles de la transacción.order_paid
): se envía cuando se procesó correctamente un webhook
Pago y contiene información sobre los
artículos comprados y el ID de la transacción. Usa los datos del webhook para
agregar artículos al usuario.refund
): se envía cuando
se cancela un pedido y contiene los datos del pago cancelado y los detalles de
la transacción.order_canceled
): se envía cuando se ha procesado correctamente un webhook Reembolso y contiene información sobre
los artículos comprados y el ID de la transacción cancelada. Use 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.
Tenga en cuenta
Para recibir pagos reales, solo tiene que implementar el procesamiento de los webhooks Pago, Pago del pedido realizado correctamente y Validación de usuario, así como firmar el acuerdo de licencia.
Para gestionar automáticamente los planes de suscripción, es necesario implementar el procesamiento de los principales webhooks:
user_validation
): se envía en diferentes etapas del proceso de pago para
garantizar que el usuario esté registrado en el juego.payment
): se envía cuando se
paga un pedido y contiene los datos del pago y los detalles de la transacción.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.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.refund
): se envía cuando
se cancela un pedido y contiene los datos del pago cancelado y los detalles de
la transacción.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.Para habilitar la recepción de 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:
Probar los webhooks ayuda a asegurar la correcta configuración del proyecto tanto en su lado como en el lado de Xsolla.
Puede probar la recepción de los siguientes webhooks:
Nombre del webhook | Tipo de webhook |
---|---|
Validación de usuario | user_validation |
Pago | payment |
Cancelación del pedido | order_canceled |
Pago del pedido realizado correctamente | order_paid |
Si los webhooks están establecidos correctamente, aparecerá una sección de prueba de webhooks bajo la sección de configuración de webhooks.
Sección de pruebas de Webhooks
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.
En la pestaña Store, puede probar los siguientes webhooks:
order_paid
)order_canceled
)Para realizar la prueba:
Los webhooks Pago del pedido realizado correctamente y Cancelación del pedido que contienen 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.
En la pestaña Payments puede probar los siguientes webhooks:
user_validation
)payment
)Para realizar la prueba:
En la URL especificada, recibirá webhooks con los datos rellenados. Los resultados de las pruebas de cada webhook, tanto para un escenario satisfactorio como para un escenario fallido, se muestran bajo el botón Test webhooks. Si el ID público de usuario está habilitada en su proyecto, también podrá ver los resultados de una comprobación de búsqueda de usuario.
Para cada webhook, tiene que establecer el procesamiento de ambos escenarios: uno, satisfactorio, y el otro, fallido.
Cuando guarde la URL en el campo Webhook server, podrá ver la sección Advanced settings donde podrá conceder permisos para recibir información detallada en los webhooks. Para ello, establezca los respectivos selectores en la posición On. En la línea de cada permiso, puede ver la lista de webhooks afectados por la configuración.
Selector | 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:
|
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:
|
Mostrar marca de tarjeta | La marca de la tarjeta empleada para realizar el pago. Por ejemplo, Mastercard o Visa. |
En la pestaña Subscriptions puede probar los siguientes webhooks:
user_validation
)payment
)Tenga en cuenta
En Cuenta del editor, solamente puede probar los webhooks básicos de Validación de usuario y Pago. Para probar otros tipos de webhooks, vaya a:
Tenga en cuenta
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:
0
.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.
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.
Nota
Puede utilizar la biblioteca de SDK para PHP de Pay Station, que contiene clases predefinidas para procesar webhooks.
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.23.0/24
, 34.102.38.178
, 34.94.43.207
, 35.236.73.234
,
34.94.69.44
, 34.102.22.197
.
Limitaciones:
Cuando reciba un webhook, debe garantizar la seguridad de la transmisión de los datos. Para ello, se debe generar una firma a partir de los datos del webhook y verificar que coincide con la firma enviada en el encabezado de la solicitud HTTP. Para generar una firma:
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"
}
}
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"
}
}'
Para confirmar la recepción del webhook, su servidor debe devolver:
Si no se recibió una respuesta para los webhooks Pago del pedido realizado correctamente y Cancelación del pedido o si se recibió una respuesta con un código "5xx", los webhooks se reenvían de acuerdo con la siguiente programación:
Se efectúan un máximo de 20 intentos de envío de webhooks en un periodo de 12 horas desde el primer intento. Si para el webhook Pago o el webhook Reembolso no se ha recibido una respuesta o si se ha recibido una respuesta con un código "5xx", los webhooks también se reenvían con un intervalo de tiempo mayor. Se realiza un máximo de 12 intentos en el plazo de 12 horas.
Atención
Si la devolución del pago fue iniciado por Xsolla y llegó una respuesta con un código HTTP "5xx" como respuesta al webhook Reembolso, el pago seguirá siendo reembolsado.
Si no se recibió una respuesta para el webhook Validación de usuario o se ha recibido una respuesta con un código "400" o "5xx", el webhook Validación de usuario no se reenvía. En este caso, se muestra un error al usuario y no se envían los webhooks Pago y Pago del pedido realizado correctamente.
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"
}
}
Observación
El tipo de notificación se envía en el parámetro notification_type
.
Webhook | Tipo de notificación | Descripción |
---|---|---|
Validación de usuario | user_validation |
Se envía para comprobar si un usuario existe en el juego. |
Búsqueda de usuario | user_search |
Se envía para obtener información de usuario basada en el ID público del usuario. |
Pago | payment |
Se envía cuando un usuario realiza un pago. |
Reembolso | refund |
Se envía cuando un pago debe cancelarse por cualquier motivo. |
Reembolso parcial | partial_refund |
Se envía cuando un pago debe cancelarse parcialmente por cualquier motivo. |
Transacción de AFS rechazada | afs_reject |
Se envía cuando se rechaza una transacción durante una comprobación de AFS. |
Lista de bloqueo de AFS rechazada | afs_black_list |
Se envía cuando se actualiza la lista de bloqueo de AFS. |
Suscripción creada | create_subscription |
Se envía cuando un usuario crea una suscripción. |
Suscripción actualizada | update_subscription |
Se envía cuando se renueva o modifica una suscripción. |
Suscripción cancelada | cancel_subscription |
Se envía cuando se cancela una suscripción. |
Suscripción con renovación suspendida | non_renewal_subscription |
Se envía cuando el estado es de renovación suspendida. |
Añadir cuenta de pago | payment_account_add |
Se envía cuando un usuario añade o guarda una cuenta de pago. |
Eliminar cuenta de pago | payment_account_remove |
Se envía cuando un usuario elimina la cuenta de pago de las cuentas guardadas. |
Validación de usuarios en Web Shop | - |
Se envía desde un sitio de Web Shop para comprobar si un usuario existe en el juego. |
Personalización del catálogo en el lado del socio | partner_side_catalog |
Se envía cuando un usuario interactúa con la tienda. |
Pago del pedido realizado correctamente | order_paid |
Se envía cuando se paga un pedido. |
Cancelación del pedido | order_canceled |
Se envía cuando se cancela un pedido. |
Disputa | dispute |
Se envía cuando se abre una nueva disputa. |