Método de Pago JConf Dominicana

[ecabrerar]

En las últimas 3 ediciones de JConf Dominicana hemos utilizado EventBrite para la gestión de ventas de las boletas para dicho evento. Eventbrite nos permite configurar la venta de boletas de forma rápida, pero existen costos por el uso de la plataforma que no podemos sostener a largo plazo, por lo que nos vemos en la necesidad de buscar una alternativa para gestionar la venta de boletas.

Más información aquí:
https://docs.google.com/document/d/1zZaMEuP-fnTJaTjSXMS6Fpjba1oZIMced89sS6cDMq8/edit?usp=sharing

[ecabrerar]

@zerh la idea es la siguiente:

• Investigar cuales opciones locales (nombre, precio, proceso para registrarnos) de venta de boletas
• Como podemos utilizar alguna de la pasarelas de pagos para montar una plataforma propia basada en pretix

[zerh]

Estuve investigando las opciones para reemplazar Eventbrite y básicamente tenemos dos caminos: usar una plataforma local ya hecha o montarnos nuestro propio servidor.

Opción A: Servicios Locales

Si nos vamos por servicios locales, Tix.do es la opción que mejor se ve.

• Costo: 4.9% + RD$25 por boleta (al organizador).
• Ventajas: Facturan localmente y el proceso es autoservicio.
• Comparativa: Otras opciones como Uepa son más burocráticas y caras para lo que necesitamos.

---

Opción B: Plataforma Propia

Si decidimos armar nuestra propia plataforma, podemos desarrollar una simple que podríamos madurar poco a poco o también tenemos a Alf.io (además de Pretix), que es Open Source y nació para gestionar a Devoxx.

El Stack (Alf.io):

• Spring Boot 3
• Java 17/21
• PostgreSQL

Ventajas:

• Si hay que meter mano al código, ya sea para una integración custom o cualquier cosa, todo el equipo domina el stack. A diferencia de Pretix (Python).
• Branding personalizado.

Integración de Pagos (CardNET o AZUL)

En el caso de Alf.io

1. Alf.io usa un patrón Strategy. Crear un conector para CardNET o Azul es simplemente implementar una interfaz Java (PaymentGateway) y consumir su API REST.
2. Lo Burocrático: Para que CardNET nos dé credenciales de producción, necesitamos RNC activo, cuenta comercial y firmar contratos. El software propio no nos salva del papeleo bancario.

En el caso de Pretix
Es exactamente igual, habría que desarrollar un plugin en Python para integrar con CardNET o Azul.

Requisitos Comerciales y Legales

CardNET exige lo siguiente:

• Entidad Legal: (Somos una ONG).
• RNC Activo.
• Cuenta Bancaria Comercial: Una cuenta a nombre de la entidad en un banco afiliado (que prácticamente son todos) para recibir los pagos.
• Sitio Web: El sitio debe tener visibles las "Políticas de Devolución/Cancelación", "Términos y Condiciones" y datos de contacto.
• Certificación PCI: Dependiendo del modelo de integración, debemos llenar un cuestionario de auto-evaluación (SAQ A o SAQ D).

Importante: El proceso de afiliación suele tomar entre 2 y 4 semanas.

Azul exige lo siguiente:

• Entidad Legal: (ONG o SRL) Debidamente registrada.
• RNC Activo: Situación fiscal al día.
• Cuenta Bancaria: A diferencia de CardNET (que es multirubros), Azul requiere obligatoriamente una Cuenta en Banco Popular Dominicano para la liquidación de los fondos (si no la tienen, deben abrirla).
• Sitio Web: Debe estar "Live" y tener visibles las Políticas de Devolución, Privacidad, Términos de Servicio y datos de contacto de la ONG.
• Certificación PCI:
  • Si usamos Hosted Payment Page (Redirección): Llenar formulario SAQ A.
  • Si usamos API Directa: Llenar formulario SAQ D (Auditoría compleja).

Importante: El tiempo de aprobación es similar (2 a 4 semanas) e incluye una revisión técnica del sitio web para validar que el carrito de compras y las políticas sean funcionales.

---

2. Modelos de Integración Disponibles

A. Hosted Payment Page (Redirección) - Recomendado

El usuario es redirigido a una página segura de CardNET (o AZUL) para poner su tarjeta.

• PCI Scope: Bajo (SAQ A). Nosotros nunca tocamos el número de tarjeta.
• Pros: Fácil de aprobar, menor riesgo de seguridad.
• Contras: El usuario "sale" de nuestra web momentáneamente.

B. API Directa / Server-to-Server

El usuario pone la tarjeta en nuestro formulario y nuestro backend la envía a CardNET.

• PCI Scope: Alto (SAQ D). Requiere auditorías de seguridad más estrictas.
• Pros: UX totalmente integrada, el usuario nunca ve que usaste CardNET.
• Contras: Requiere SSL/TLS avanzado y manejo estricto de datos.

[ecabrerar]

@zerh gracias por la investigación.
Cuando disponga de tiempo, favor investigar sobre estos servicios que ofrece portaldom https://portaldom.do/servicios/soluciones-digitales/

Hay otra plataforma que se llama https://ticketmax.org que pudieramos revisar también