Para gestionar suscripciones con Pix Automático, separa la relación comercial de la autorización de pago y de cada cobro. El pagador concede la autorización mediante el flujo de su proveedor de servicios de pago; la empresa envía las instrucciones que permite ese permiso. La suscripción determina el acceso y las condiciones del servicio. El ingreso confirmado determina la liquidación del ciclo. Cancelar una de estas entidades no debe borrar ni alterar silenciosamente las demás.
Esta separación permite explicar al cliente por qué ha fallado una cuota mensual, si sigue habiendo un pago programado y qué ha interrumpido realmente la cancelación. También evita convertir una autorización válida en una garantía de saldo o un cobro no completado en la finalización automática de la relación comercial.
Las reglas citadas se verificaron el 22 de octubre de 2026. El modelo de datos y el caso de suscripción de esta guía son propuestas didácticas, sin correspondencia con clientes reales. La exposición del concepto no afirma que AZPay ofrezca Pix Automático: la modalidad y su contrato deben confirmarse en la documentación del servicio que se pretenda utilizar.
¿Pix Automático, Pix programado y la tarjeta recurrente resuelven el mismo problema?
Todos pueden formar parte de una relación periódica, pero tienen mecanismos distintos. Según las preguntas frecuentes del Banco Central sobre Pix Automático y Pix programado (se abre en una pestaña nueva ↗), en el programado el pagador programa pagos futuros; en el automático autoriza a una empresa, persona jurídica, a enviar cobros con importes y fechas acordados. No es correcto llamar Pix Automático a cualquier Pix que se repita.
En la tarjeta recurrente, una credencial almacenada y las reglas del ecosistema de tarjetas sustentan los cobros posteriores. La autorización de Pix Automático no es un token de tarjeta y no puede tratarse como tal. Tampoco basta con trasladar a Pix el cron que antes iniciaba los cobros con tarjeta.
La guía de pagos recurrentes y card-on-file explica la arquitectura comercial común a las suscripciones. Aquí nos centramos en la relación entre el permiso de Pix, las instrucciones, los pagos programados y los ingresos. Compartir el dominio de suscripciones resulta útil; borrar las diferencias entre métodos perjudica la operativa.
Para producto, la elección debe tener en cuenta qué entiende el cliente que está autorizando y cómo ejercerá sus controles. Para ingeniería, exige un adaptador que preserve el significado de los estados. Para finanzas, exige saber qué periodo se ha pagado, independientemente de cuántos mensajes o intentos hayan aparecido durante el proceso.
¿Quién autoriza y qué puede considerar confirmado la empresa?
La página del Banco Central sobre Pix Automático (se abre en una pestaña nueva ↗) describe la autorización previa del pagador y los parámetros de control, como el importe máximo y el uso de una línea de crédito. La entidad del pagador ejecuta los pagos conforme a la autorización. La empresa no debe convertir la selección de una opción en su propia pantalla en prueba de que la autorización bancaria se ha completado.
En la propuesta de integración de este artículo, registra primero la intención de alta. Después, sigue la solicitud de permiso a través del proveedor y confirma el resultado por un canal autenticado. El cliente puede abandonar el proceso, rechazar la propuesta o completar la acción en otro dispositivo. Una pantalla de retorno no sustituye la verificación en el servidor.
Guarda la referencia de la recurrencia externa, la suscripción correspondiente, los parámetros confirmados y la fecha en que se conoció la confirmación. Conserva también el historial de cambios. Si la solicitud comercial indicaba una frecuencia mensual y el registro confirmado presenta otro contexto, resuelve la discrepancia antes de habilitar el ciclo.
Una autorización no demuestra que se vaya a pagar cualquier cobro futuro. El saldo, los límites, la conformidad de la instrucción y las posibles cancelaciones siguen siendo relevantes. La interfaz puede informar de un alta confirmada y del próximo ciclo previsto sin presentarlo como dinero recibido. Este cuidado reduce las dudas de atención al cliente y evita un reconocimiento financiero prematuro.
¿Qué entidades debe representar una integración de suscripciones?
Un modelo conceptual puede contener suscripción, autorización externa, ciclo de facturación, instrucción, intento e ingreso. Los nombres son internos e ilustrativos, no endpoints de AZPay. La suscripción representa el servicio; la autorización registra el contexto permitido; el ciclo indica lo que se debe en ese periodo.
La instrucción materializa un cobro que tramitará el participante. El intento sigue la ejecución admitida por el flujo. El ingreso registra el Pix efectivamente confirmado. Este último debe conservar su identidad financiera, incluida la referencia externa adecuada, sin confundirse con el identificador del ciclo.
Una identidad estable del ciclo puede combinar la suscripción y el periodo de facturación. Debe sobrevivir a los reintentos de tu tarea, los cambios de estado y los cambios del canal de notificación. Si el mismo ciclo aparece en dos lotes de facturación, la aplicación debe reconocer que sigue tratándose de la misma obligación.
Contempla también una versión de las condiciones comerciales. El importe adeudado puede haberse calculado antes de un cambio de plan o de un abono. Conservar esa versión permite demostrar por qué se emitió una instrucción determinada. Recalcular el pasado utilizando solo el plan actual dificulta investigar cobros y tratar discrepancias con el cliente.
Los objetos Pix expuestos en la API Pix 2.10.0 (se abre en una pestaña nueva ↗) proporcionan referencias técnicas para recurrencias, cobros, intentos e ingresos. Un PSP puede ofrecer otra abstracción comercial. Valida su contrato en lugar de dar por hecho que todos los nombres y transiciones estarán disponibles de la misma forma.
¿Cómo preparar y seguir un ciclo de cobro?
Empieza por la elegibilidad comercial. ¿La suscripción permite facturar este periodo? ¿Hay algún abono que modifique el importe? ¿Existe una solicitud de cancelación aún no aplicada? ¿La autorización está confirmada y es compatible con la instrucción? Estas comprobaciones deben preceder al envío, no aparecer únicamente cuando alguien reclama por el cargo.
La orientación del BCB para la implementación, apartado 2.7 (se abre en una pestaña nueva ↗), establece como regla general el envío de instrucciones entre dos y diez días naturales antes de la liquidación prevista, con las excepciones y condiciones del artículo 5. El planificador comercial debe respetar ese contrato temporal y las interfaces que el participante ofrezca realmente.
Guardar la intención antes de la llamada externa permite recuperarse de una respuesta perdida. Asocia el comando con la identidad del ciclo y con el contenido enviado. Una nueva ejecución de la tarea debe encontrar la misma intención en lugar de generar otra cuota mensual solo porque el proceso anterior haya tardado.
Tras el envío, distingue entre instrucción aceptada, pago programado conocido y pago confirmado. El éxito de una etapa no garantiza el de la siguiente. Si la integración recibe un rechazo, registra el motivo y la etapa en la que se ha producido. Esto ayuda a distinguir una instrucción incompatible de un cobro que llegó al momento de ejecución, pero no se liquidó.
Cuando se reciba el ingreso, asígnalo al ciclo una sola vez y publica el evento comercial correspondiente de forma recuperable. El acceso al servicio debe seguir la política de producto, que puede prever un periodo de gracia o la finalización al terminar el periodo contratado. La arquitectura debe sostener esa política sin inventar reglas regulatorias para justificarla.
¿Qué hacer cuando no se completa el cobro?
Primero, identifica la situación comprobada. Una instrucción rechazada, la falta de saldo, un límite insuficiente, un error operativo y un resultado indeterminado requieren acciones distintas. No lo marques todo como rechazo definitivo ni intentes recuperar el pago creando un cobro paralelo sin evaluar el flujo que sigue en curso.
El artículo 7 de la IN BCB 513/2024 (se abre en una pestaña nueva ↗) explica el reintento intradía y los intentos posteriores. En los supuestos aplicables, hay al menos un intento adicional entre las 18:00 y las 21:00 del mismo día. Los intentos posteriores al vencimiento dependen de que estén previstos en la recurrencia: hasta tres fechas distintas dentro de siete días naturales, limitadas por el siguiente ciclo o el fin de la recurrencia, con el mismo importe original.
Esta regla no autoriza al comercio a repetir llamadas indiscriminadamente. El participante y el método coordinan parte de la ejecución. Tu sistema debe averiguar qué intentos existen ya, cuáles pueden producirse todavía y qué acción ordena realmente la empresa. Evita ejecutar a la vez un reintento propio y otro ya programado en el flujo contratado.
Si ofreces un medio alternativo para regularizar la cuota, asócialo a la misma obligación y gestiona los pagos concurrentes. Un ingreso alternativo no cancela por arte de magia una instrucción externa. Confirma las acciones necesarias y controla el excedente si se pagan ambas vías. Una recuperación comercial solo está completa cuando se han explicado sus efectos financieros.
Mientras el resultado sea indeterminado, restringe los comandos que puedan duplicar el pago. Consulta el recurso cuando sea posible, correlaciona los eventos y deriva la excepción con un responsable y una próxima acción. El mensaje al suscriptor debe reflejar esa incertidumbre, sin afirmar que el cliente se ha retrasado cuando la integración aún no ha podido verificar el resultado.
¿Cancelar la suscripción cancela la autorización y todos los cargos?
Son decisiones relacionadas que deben coordinarse. El Reglamento de Pix, artículo 11-Q (se abre en una pestaña nueva ↗), permite al pagador cancelar la autorización en cualquier momento y prevé la cancelación cuando el beneficiario solicita finalizar el permiso correspondiente. La cancelación comercial debe generar las acciones financieras pertinentes, con confirmación y tratamiento de las cuestiones pendientes.
En los artículos 8 y 9 de la IN BCB 513/2024 (se abre en una pestaña nueva ↗), el pagador puede solicitar la cancelación del pago programado hasta las 23:59 del día anterior; para solicitudes del PSP del beneficiario, el límite son las 22:00. La cancelación de la autorización afecta a los pagos programados futuros según el origen y la hora de la comunicación; existe una regla específica cuando la información del beneficiario llega entre las 22:00 y las 23:59. En esa franja tardía, la norma prevé cancelar los pagos programados para los días posteriores al día siguiente a la recepción de la información.
Por eso, no prometas que cualquier solicitud comercial de cancelación interrumpirá un cargo cuya ejecución es inminente. Registra la hora, confirma lo enviado al proveedor y verifica qué pagos programados se han cancelado realmente. Las horas corresponden a Brasilia, según las preguntas frecuentes para participantes. Los horarios regulatorios no eliminan la necesidad de conocer el procesamiento de tu propio sistema y el contrato operativo.
Las preguntas frecuentes del BCB para participantes, sección de cancelación (se abre en una pestaña nueva ↗), aclaran que cancelar un pago programado concreto no cancela toda la autorización. También existen particularidades de los reintentos que impiden tratar toda instrucción como un pago programado ordinario cancelable individualmente. La interfaz debe distinguir entre cancelar un cobro y finalizar el permiso para los siguientes.
Un pago ya realizado exige evaluar una devolución, no borrar el historial. La cancelación del servicio también puede dejar obligaciones comerciales anteriores en discusión. Conserva la distinción entre cobrar un saldo pendiente, finalizar una autorización y devolver un importe: una acción no debe utilizarse como atajo para resolver las demás sin pruebas.
Caso ficticio: cuota de R$ 79, fallo y cancelación antes del siguiente ciclo
Imagina una suscripción mensual de R$ 79, sin prorrateo, intereses ni abonos en el ejemplo. La autorización se confirmó y el primer ciclo se pagó. En el siguiente, el participante informa de que el cobro no se ha completado por insuficiencia de fondos. La suscripción puede continuar en el periodo de gracia definido comercialmente, mientras finanzas registra R$ 79 aún pendientes de ese ciclo.
La operación consulta los intentos y comprueba si existen ejecuciones futuras admitidas por el flujo. No crea otra cuota de R$ 79 para representar cada intento. Todos pertenecen a la misma obligación. El objetivo es recuperar R$ 79, no sumar los importes de tres instrucciones y concluir que el cliente debe ahora R$ 237.
Antes del ciclo posterior, el cliente solicita cancelar el servicio. El equipo registra la solicitud y su política de finalización del acceso, bloquea la generación de nuevos ciclos comerciales y tramita las acciones sobre el permiso y los pagos programados existentes. Después confirma los resultados externos. Las fechas de este escenario son relativas y no sustituyen los límites regulatorios descritos anteriormente.
Si se paga un intento del ciclo pendiente, el evento debe vincularse a ese periodo. No reactiva automáticamente la suscripción cancelada. Si el contrato comercial prevé devolver ese pago, la devolución tendrá identidad y confirmación propias. Si el importe sigue legítimamente destinado al periodo anterior, esa asignación debe comunicarse y ser trazable.
Al cerrar el proceso, soporte debe poder informar del estado del acceso, la autorización externa, los cobros abonados y cualquier importe en tratamiento. Una única etiqueta de cancelado no responde a estas preguntas. El caso demuestra por qué la suscripción y la infraestructura Pix deben comunicarse sin compartir indiscriminadamente el mismo estado.
¿Cómo gestionar los cambios de plan, importe y forma de pago?
Un cambio de plan exige comparar las nuevas condiciones con la autorización confirmada. No des por hecho que una subida de precio cabe en el límite permitido ni que un cambio comercial sustituye parámetros externos. Cuando el nuevo contexto exija otra acción del pagador, guíale por el proceso correspondiente y espera la confirmación antes de emitir instrucciones incompatibles.
Los abonos y el cobro proporcional pertenecen al cálculo comercial. Registra el desglose del cálculo y su periodo. Si ya se ha emitido la instrucción del ciclo, determina qué se puede modificar o cancelar todavía en el flujo disponible. Crear una instrucción adicional para compensar un error sin coordinar la original puede cobrar dos veces el mismo ajuste.
Al cambiar Pix por tarjeta u otro método, mantén la identidad del saldo pendiente y finaliza o sigue los comandos anteriores, según corresponda. El método nuevo no debe iniciar automáticamente un cobro mientras una ejecución anterior pueda producir un resultado. El historial debe mostrar qué ruta se utilizó para satisfacer la obligación y cómo se regularizó cualquier excedente.
¿Cómo mantienen los webhooks y la conciliación un historial coherente?
Cada mensaje debe tener un origen validado, identificación del recurso y procesamiento idempotente. Un evento recibido después puede describir una etapa anterior. Consulta las versiones o el estado externo cuando el orden de llegada no permita una transición segura. La guía de webhooks en pagos desarrolla este mecanismo.
Mantén la asociación entre autorización, ciclo y transacción recibida. Un cambio en la autorización no debe sobrescribir el ingreso del ciclo anterior; una devolución no debe borrar el Pix original. El modelo de cobros y devoluciones Pix ayuda a conservar estos límites.
La rutina de conciliación de pagos debe identificar ciclos pagados externamente y pendientes internamente, autorizaciones canceladas que siguen figurando como activas y devoluciones completadas que no aparecen en el control financiero. Corregir un evento perdido no debe repetir una entrega ni renovar el acceso por otro periodo.
Para cada discrepancia, registra el hecho observado, las fuentes consultadas, el ajuste aplicado y la prueba de cierre. Esto permite retomar una investigación sin depender de quien recibió la incidencia. También muestra si el problema se origina en el planificador, en el procesamiento de eventos o en el mapeo de los estados del participante.
¿Qué medir y probar antes de operar la recurrencia?
Mide el alta confirmada por separado del pago del primer ciclo. Después, sigue el éxito en el vencimiento, la recuperación por periodo, el tiempo de resolución de resultados indeterminados y las cancelaciones con acciones financieras pendientes. Define los denominadores: autorizaciones creadas, autorizaciones confirmadas, ciclos adeudados e intentos no son la misma población.
Prueba solicitudes de autorización abandonadas, rechazos, confirmaciones tardías y cancelaciones comunicadas externamente. Simula instrucciones rechazadas, límites insuficientes, respuestas perdidas y eventos fuera de orden. Incluye cambios de plan con el ciclo ya preparado, pagos alternativos concurrentes y cancelaciones cerca del límite aplicable. Comprueba los importes y los comandos, además del estado final mostrado en pantalla.
La aceptación operativa consiste en reconstruir una suscripción desde el alta hasta el último movimiento financiero, explicar quién autorizó cada etapa e impedir un nuevo ciclo cuando las condiciones ya no permitan facturar. Consulta la Dev Central de AZPay para evaluar el contrato de integración previsto. Confirmar las capacidades y la modalidad forma parte de esa evaluación, antes de hacer cualquier promesa al suscriptor.