Flujo de pago
Importante: el flujo que aplica al canal está determinado por el modelo de integración configurado contractualmente en el dashboard de beTickets. Los cuatro modelos (A, B, C y D) se describen en detalle en integration-models.md.
Flujo A — Portal beTickets, cobro beTickets (portal_only)
El comprador accede directamente al portal con branding del canal. beTickets gestiona el checkout y el cobro vía Redsys. El canal no implementa nada técnicamente.
Comprador → portal.bticketing.com/{canal}/es/events
→ Selecciona asientos
→ Checkout portal beTickets
→ Redsys
→ Orden completada · entradas por emailFlujo B — Portal beTickets, cobro del canal (portal_external_payment)
El comprador navega en el portal de beTickets con branding del canal. Al pasar al pago, el portal redirige al checkout propio del canal (configurado en checkout_url). El canal cobra, y su servidor notifica a beTickets.
Comprador → portal.bticketing.com/{canal}/es/events
→ Selecciona asientos en el portal
→ Portal detecta integration_mode=portal_external_payment
→ Redirect a {checkout_url}?order_token={token}
→ Página de checkout del canal
→ Canal procesa cobro con su TPV
→ Servidor del canal → POST /confirm (con datos del comprador y pago)
→ beTickets: orden completada · entradas por emailConfiguración requerida
El campo checkout_url del canal debe apuntar a la página de checkout propia:
Dashboard → Canales → [canal] → Configuración → checkout_url
Ejemplo: https://mi-cine.com/pagarPágina de checkout del canal
La página recibe ?order_token= en la URL y debe:
- Consultar el resumen de la orden (endpoint público, sin auth):
GET /portal/{salesChannelSlug}/{lang}/orders/{orderToken}Mostrar el resumen al comprador y recoger sus datos.
Procesar el cobro con el TPV propio.
Notificar a beTickets (ver Confirmación de pago).
Flujo C — Widget, cobro beTickets (widget_betickets_payment)
El widget se embebe en el site del canal. Al pulsar "Ir al pago", el comprador es redirigido al portal de beTickets.
Widget en site del canal (selección + carrito)
→ Botón "Ir al pago" (integrado en el widget)
→ Portal beTickets ({portal_checkout_base_url}/{canal}/{lang}/checkout?order_token={token})
→ Redsys
→ Orden completada · entradas por emailIntegración
<div id="bt-widget"></div>
<script src="https://widget.bticketing.com/v1/widget.iife.js"></script>
<script>
BeTickets.init({
container: '#bt-widget',
channelSlug: 'mi-canal',
sessionId: 83,
apiKey: 'wk_xxxx',
});
// El widget detecta widget_betickets_payment desde /config
// y configura automáticamente el redirect al portal.
</script>Flujo D — Widget, cobro del canal (widget_external_payment)
El widget se embebe en el site del canal sin botón de checkout. El canal escucha onOrderUpdate, cobra con su TPV y notifica a beTickets.
Widget en site del canal (selección + carrito, sin botón checkout)
→ Canal escucha onOrderUpdate → habilita botón de pago propio
→ Canal procesa cobro con su TPV
→ Servidor del canal → POST /confirm (con datos del comprador y pago)
→ beTickets: orden completada · entradas por emailIntegración
Ver Widget Quickstart — Modelo D.
Confirmación de pago (Modelos B y D)
Cuando el canal ha cobrado, su servidor notifica el resultado a beTickets:
POST /sales-channel/v1/{salesChannelSlug}/{lang}/orders/{orderToken}/confirm
Authorization: Bearer {access_token}
Content-Type: application/json
{
"transaction_id": "ext_12345",
"amount": 125.50,
"payment_method": "card",
"name": "Ana",
"surname": "García",
"email": "ana@ejemplo.com",
"phone": "612345678"
}| Campo | Tipo | Requerido | Descripción |
|---|---|---|---|
transaction_id | string | Sí | Referencia de la pasarela del canal (para auditoría) |
amount | number | Sí | Importe cobrado. Debe coincidir con total_amount de la orden (±0.01 €) |
payment_method | string | No | card, transfer, cash, etc. |
name | string | Sí | Nombre del comprador |
surname | string | Sí | Apellidos del comprador |
email | string | Sí | Email del comprador (se usará para enviar las entradas) |
phone | string | No | Teléfono del comprador |
Server-to-server
Esta llamada siempre debe hacerse desde el servidor del canal, nunca desde el navegador del comprador. El Bearer token es un secreto del canal.
Respuesta en caso de éxito
{
"success": true,
"data": { "order_id": 123, "status": "completed" },
"message": "Pago confirmado correctamente"
}Qué ejecuta este endpoint
- Valida
amountvstotal_amountde la orden (tolerancia ±0.01 €). - Crea el
Customercon los datos del comprador (o actualiza si ya existe por email). - Transacción DB: orden →
completed, asientos →sold, items →confirmed. - Post-pago asíncrono: genera PDFs de tickets y los envía por email al comprador.
Idempotencia
Si la orden ya está completed, devuelve 200 sin reejecutar el proceso.
Errores posibles
| HTTP | Descripción |
|---|---|
401 | Bearer token inválido o expirado |
403 | El token no corresponde al salesChannelSlug o el modelo no permite confirm |
404 | Orden no encontrada |
422 | Importe no coincide, orden en estado inválido, o campo requerido faltante |
Pago en taquilla física
POST /portal/{salesChannelSlug}/{lang}/orders/{orderToken}/completeUso exclusivo de taquilla física (efectivo/tarjeta física). No aplica al canal web externo.