Skip to content

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 email

Flujo 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 email

Configuració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/pagar

Página de checkout del canal

La página recibe ?order_token= en la URL y debe:

  1. Consultar el resumen de la orden (endpoint público, sin auth):
http
GET /portal/{salesChannelSlug}/{lang}/orders/{orderToken}
  1. Mostrar el resumen al comprador y recoger sus datos.

  2. Procesar el cobro con el TPV propio.

  3. 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 email

Integración

html
<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 email

Integració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:

http
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"
}
CampoTipoRequeridoDescripción
transaction_idstringReferencia de la pasarela del canal (para auditoría)
amountnumberImporte cobrado. Debe coincidir con total_amount de la orden (±0.01 €)
payment_methodstringNocard, transfer, cash, etc.
namestringNombre del comprador
surnamestringApellidos del comprador
emailstringEmail del comprador (se usará para enviar las entradas)
phonestringNoTelé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

json
{
  "success": true,
  "data": { "order_id": 123, "status": "completed" },
  "message": "Pago confirmado correctamente"
}

Qué ejecuta este endpoint

  1. Valida amount vs total_amount de la orden (tolerancia ±0.01 €).
  2. Crea el Customer con los datos del comprador (o actualiza si ya existe por email).
  3. Transacción DB: orden → completed, asientos → sold, items → confirmed.
  4. 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

HTTPDescripción
401Bearer token inválido o expirado
403El token no corresponde al salesChannelSlug o el modelo no permite confirm
404Orden no encontrada
422Importe no coincide, orden en estado inválido, o campo requerido faltante

Pago en taquilla física

http
POST /portal/{salesChannelSlug}/{lang}/orders/{orderToken}/complete

Uso exclusivo de taquilla física (efectivo/tarjeta física). No aplica al canal web externo.

beTickets — Plataforma de ticketing