Para una persona que compra una entrada, el recorrido parece una secuencia simple: elegir, pagar y recibir una confirmación. Para el organizador intervienen varios estados, sistemas y decisiones de soporte. Diseñar ese flujo antes de construirlo ayuda a evitar que una pantalla de regreso se confunda con un pago confirmado.

Presenta lo necesario antes de pagar

Indica evento, fecha, lugar, tipo de entrada, cantidad y condiciones aplicables. Explica los datos que se solicitarán y ofrece un canal para resolver dudas. Si el precio final puede incluir cargos, muéstralos de acuerdo con las condiciones y obligaciones que correspondan; revisa el texto con la persona responsable del evento.

Diseña el formulario para que sus etiquetas sean visibles y los errores indiquen cómo corregirlos. Antes de pedir muchos datos, pregunta si cada uno es necesario para la compra, el acceso o la atención posterior.

Modela estados, no solo pantallas

Un pedido puede crearse antes de que el pago termine. En la documentación de Wompi, por ejemplo, una transacción recién creada está pendiente y después puede quedar aprobada, rechazada o con otro resultado. Los nombres y mecanismos exactos dependen del proveedor elegido y deben revisarse en su documentación actual.

La pantalla de regreso o el cierre de la ventana no son evidencia suficiente de aprobación. Define cómo consulta el sistema el estado autorizado del proveedor, qué muestra mientras espera y cómo evita emitir dos veces si recibe información repetida. Antes de emitir, verifica en el servidor la autenticidad del evento según el proveedor y confirma que la transacción aprobada corresponda al pedido, su referencia, importe y moneda esperados. Registra qué operación ya fue procesada para evitar entradas duplicadas cuando se repita una notificación. Las credenciales y validaciones sensibles deben quedar en el servidor correspondiente.

Emisión y recuperación para el asistente

Una vez se cumplen las condiciones acordadas para emitir, decide qué recibe la persona, dónde consulta su compra y cómo puede pedir ayuda. El mensaje debe distinguir una entrada emitida de un pago todavía en revisión. No prometas entrega inmediata si el proveedor o la operación pueden requerir espera.

Ejemplo hipotético: una asistente paga y cierra la página antes de volver al sitio. El sistema registra el estado confirmado por el proveedor y el canal de soporte puede encontrar la compra usando una referencia apropiada. Si aún no hay confirmación, el equipo informa que está pendiente en lugar de emitir o negar una entrada sin comprobar.

Ensaya las excepciones

  • Pago aprobado y confirmación recibida normalmente.
  • Pago pendiente durante más tiempo del esperado.
  • Rechazo o error que permita intentar de nuevo sin duplicar pedidos.
  • Notificación repetida y cierre prematuro del navegador.
  • Necesidad de reenviar información o atender una devolución conforme a lo acordado.

Ejecuta estas pruebas en el entorno que indique el proveedor y mantén separadas las credenciales y transacciones reales. Esta guía describe decisiones de diseño; no garantiza que un proveedor o una base concreta incluya cada función.

Acuerda quién responde en cada etapa

El proveedor de pagos y el organizador pueden tener responsabilidades distintas. Antes de lanzar, documenta quién revisa una transacción, quién puede corregir un pedido y cómo contacta el asistente a la persona adecuada. No envíes información sensible por canales no previstos para ese propósito.

Prueba los mensajes que recibirá una persona cuando el estado todavía no sea definitivo. Deben explicar qué se sabe y qué puede hacer después, sin asegurar que el cobro fue exitoso o fallido cuando todavía no hay un resultado confirmado.

Fuentes consultadas

Exploremos tu plataforma de eventos

Cuéntanos cómo quieres que una persona compre, reciba y use su entrada.

Hablemos de tu evento