La integración Azul le permite cobrar con tarjeta de crédito o débito a través de la Página de Pago de Azul (Servicios Digitales Popular). Usted genera un enlace de pago para una proforma de suscripción, el cliente entra a ese enlace, paga en el sitio seguro de Azul, y Axentra convierte la proforma en factura con e-CF cuando pasa la ventana de liquidación.
El cliente nunca digita su tarjeta en Axentra: los datos de la tarjeta se capturan en el sitio de Azul, no en el suyo ni en el nuestro. Por eso su empresa queda en el nivel más bajo de exigencia PCI (SAQ-A): nosotros no vemos, guardamos ni transmitimos números de tarjeta.
Se administra desde Configuración → Azul Pagos (permiso config.update).
Azul es un complemento. El módulo se habilita por Axentra para su empresa; no viene incluido en ningún plan por defecto. Si no lo ve en Configuración, escríbanos para activarlo.
MerchantID, AuthKey y CurrencyCode.Proforma -> Enlace de pago (/pay/<token>) -> Cliente paga en Azul
-> Azul redirige de vuelta con el resultado firmado
-> (aprobado) -> ventana de liquidación (24 h)
-> la proforma se convierte en factura + e-CF
La ventana de 24 horas es intencional. El pago se registra al instante, pero la factura fiscal se emite un día después, cuando el dinero está firme.
Vaya a Configuración → Azul Pagos y complete el bloque de credenciales:
| Campo | Qué es |
|---|---|
| Ambiente | Pruebas o Producción. Ver la sección de abajo. |
| MerchantID | El identificador de comercio que le dio Azul. |
| CurrencyCode | La moneda de cobro (ej. $ para DOP). |
| AuthKey | La llave secreta que autentica los resultados de pago. |
Notas importantes:
El ambiente es una propiedad del juego de credenciales, igual que en e-CF:
TEST_APPROVED y nunca se convierten en factura ni emiten e-CF. Úselo para probar el flujo completo sin cobrar dinero real ni generar comprobantes. La página de pago muestra un aviso de "MODO PRUEBA".Este candado es el equivalente al guardián de producción de e-CF: mientras esté en pruebas, ningún cobro genera documentos fiscales.
Además del enlace de pago sobre una proforma existente, Axentra ofrece un checkout público de autoservicio: un cliente que llega desde su sitio o desde su lista de precios puede suscribirse solo, llenar un formulario con sus datos (KYC) y pagar, sin que usted intervenga.
El flujo enlaza tres piezas: un plan público, un formulario de checkout y Azul.
En Suscripciones cree un plan con estas condiciones:
is_public). Solo los planes públicos aparecen en el checkout de autoservicio.Un plan que no cumpla las dos condiciones no se expone al público.
En Formularios web cree el formulario que recogerá los datos del cliente (razón social, RNC/cédula, nombre comercial, representante, correo, teléfono, etc.). Este es el formulario KYC.
En el editor del formulario, en la sección de checkout, vincúlelo al plan público y mapee los campos de rol:
Atribución de vendedores (opcional). Si usa enlaces de referido, agregue al formulario KYC un campo de tipo UTM (oculto) con la clave exacta utm_code. El campo es invisible para el cliente y viaja solo: cuando el visitante llegó por el enlace de un vendedor, la suscripción queda atribuida a ese vendedor desde el registro, antes del pago. La clave debe escribirse exactamente utm_code; un typo no da error pero deja las ventas sin atribuir (ver la advertencia y lista de verificación). Puede añadir también utm_source, utm_medium o utm_campaign para saber de qué campaña vino cada registro.
Cuando un formulario está vinculado a un plan público activo, en la lista de formularios verá:
El mismo candado aparece en el detalle del formulario, donde el botón Eliminar queda deshabilitado con una nota explicativa.
Cada formulario de checkout tiene su propio mensaje de éxito (hasta 2000 caracteres), que se muestra en la página de pago aprobado. Úselo para explicarle al cliente qué sigue: que su producto se está preparando, que recibirá credenciales por correo, tiempos de entrega, etc. Déjelo vacío para usar el mensaje genérico.
Cuando el pago se aprueba, los datos del formulario KYC se envían por correo al buzón de su empresa, para que su equipo procese el alta con la información que el cliente declaró.
En Configuración → Azul Pagos → Comisiones de referidos se define qué pasa cuando una suscripción atribuida a un vendedor recibe un pago:
Las comisiones registradas se revisan y aprueban en Ventas → Comisiones; el detalle del flujo está en Ventas.
Puede mostrar sus términos y condiciones en la página de pago, con aceptación obligatoria antes de cobrar.
En la página de pago, los términos se muestran en un recuadro con desplazamiento. El cliente debe desplazarse hasta el final y marcar "He leído y acepto los términos y condiciones" para que se habilite el botón de pago. El requisito es por diseño accesible: la casilla es obligatoria a nivel de navegador, de modo que un cliente sin JavaScript o con lector de pantalla tampoco queda bloqueado.
Los términos son por empresa: cada inquilino configura los suyos.
Como el único canal de resultado es la redirección del navegador, un cliente que cierra la pestaña justo después de pagar puede dejar un pago "en el aire". La pantalla de conciliación resuelve esos casos honestamente. Muestra:
PENDING) que nunca recibieron redirección.APPROVED sin CONVERTED): el peor estado, el dinero se movió pero no hay documento fiscal.Para cada caso puede:
recordAzulManualPayment), tras cotejar el resultado en el portal de Azul. Requiere una nota, queda en la bitácora de auditoría y solo funciona en producción. Corre el mismo camino de conversión que el flujo automático.Un intento tiene una vida de 24 horas; una redirección válida que llega tarde sobre un intento ya expirado pasa a revisión manual, nunca se convierte sola.
| Permiso | Qué permite |
|---|---|
config.update |
Configurar credenciales de Azul, términos y condiciones |
subscription.plan.read |
Ver los planes vinculados desde la lista de formularios |
forms.form.update |
Vincular/desvincular un formulario de checkout a un plan |
La configuración de Azul, incluidas las credenciales y los términos, vive bajo config.update. Por defecto ADMIN lo tiene.
Es el comportamiento normal en modo pruebas: los pagos de prueba se registran como TEST_APPROVED y nunca se convierten. En producción, la conversión ocurre tras la ventana de liquidación de 24 horas.
Espere a que pase la ventana de 24 horas. Si ya pasó y no se convirtió, revise la pantalla de conciliación: es probable que la redirección se haya perdido. Puede relanzar la conversión o registrar el pago manualmente tras cotejar en el portal de Azul.
Si el formulario tiene un candado, es porque es la página de cobro de un plan público activo. Despublique el plan primero (o desvincule el formulario) y luego podrá eliminarlo. La lista de formularios muestra a qué plan está vinculado.
Suele ser caché del navegador. Recargue con Ctrl+Shift+R. La página de pago no se cachea; si persiste, verifique que el enlace no haya expirado.
Hoy no. La Página de Pago requiere al cliente presente en cada cobro, incluso con tarjeta guardada. El cobro recurrente desatendido usa otra API de Azul (WebServices) y está en el plan a futuro.
En el formulario de checkout correspondiente: cada formulario tiene su propio mensaje de éxito. Para los términos y condiciones, en Configuración → Azul Pagos.