BCRA A 8488: PSP, QR y cobranza con registro
La Comunicación A 8488 actualiza reglas para PSP, QR, adquirentes y cobranzas. Qué dato guardar, quién lo valida y cómo probar pagos sin planillas.
BCRA A 8488/2026 actualizó el texto ordenado de Proveedores de Servicios de Pago y puso en la misma mesa a bancos, PSP, QR, adquirentes, agregadores y cobranzas extrabancarias. Para una entidad que cobra cuotas por transferencia, el cambio duele en el registro: cada operación debe decir quién la inicia, quién la procesa, qué cuenta la recibe y qué evidencia queda. Esta nota explica el flujo técnico antes de tocar producción.
Qué cambió en el registro de pagos
La Comunicación A 8488, publicada en el Boletín Oficial el 7 de octubre, alcanza a doce tipos de actores: entidades financieras, redes de cajeros, redes de transferencias, administradores de esquemas, PSP, iniciadores, aceptadores, administradores QR, adquirentes, agregadores y empresas de cobranza. La cifra corrige una costumbre: el cobro ya no termina en el comprobante que recibe tesorería. La norma incorpora hojas del texto ordenado de PSP en función de la Comunicación A 8472. Ese texto ya admitía que agencias complementarias de servicios financieros inscriptas como cobranzas extrabancarias puedan subcontratar personas humanas o jurídicas para servicios delegados, con conformidad previa de la entidad financiera y sin subcontratación sucesiva. El antagonista operativo es la planilla de cobranzas que dice "pagó por QR" y no guarda actor, cuenta, identificador ni responsable. Un lector pegado al mostrador resuelve la atención, pero no explica quién inició la operación ni qué participante quedó obligado a responder si el pago se cae. El dato técnico acompaña la exigencia. En la encuesta Stack Overflow 2025, SQL aparece entre las tecnologías más usadas por quienes responden sobre bases de datos. Para una cámara empresaria de Cuyo, eso convierte el cobro en una tabla revisable: operación, canal, usuario, estado, conciliación y adjunto.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. 1. Administración carga socio, CUIT, concepto, vencimiento y medio de pago permitido. 2. El sistema genera o recibe la orden: QR, transferencia, cobranza extrabancaria o link informado por el proveedor. 3. El PSP o adquirente procesa la instrucción y entrega identificador, cuenta receptora, estado y fecha. 4. PostgreSQL guarda operación, usuario, monto, canal, estado, referencia externa y auditoría. 5. Los permisos separan carga de cuota, conciliación, anulación y lectura de reportes. 6. El backup copia base, comprobantes y reportes; la restauración abre una muestra de pagos y compara totales. La función de cada pieza debe quedar escrita. PostgreSQL guarda registros estructurados, usuarios, estados y auditoría. El almacenamiento S3 conserva comprobantes, constancias y archivos de liquidación como objetos con metadatos. Metabase lee consultas aprobadas y muestra cuotas cobradas, pendientes, rechazadas y reversadas. El monitoreo avisa si la conciliación diaria no corre o si una API devuelve errores. El texto ordenado de PSP describe actores y funciones. La tarea interna consiste en traducir esa lista a permisos: quién crea una cuota, quién registra una excepción, quién cambia una cuenta, quién exporta un reporte y quién cierra el día.
Qué se instala o configura primero
El primer entregable verificable es una matriz de cobranzas. Debe tener concepto, canal, PSP, cuenta receptora, identificador, estado, usuario, fecha de conciliación y archivo asociado. Una pila chica usa PostgreSQL 17, una API de conciliación, almacenamiento S3 compatible, tablero en Metabase, roles por área y respaldo diario probado. Con dólar oficial vendedor informado por DolarAPI, una implementación inicial de USD 320 a USD 680 equivale a ARS $492.800 a ARS $1.047.200. Ese costo cubre modelo, carga de casos reales, tablero y restauración; no cubre asesoría regulatoria ni comisiones del proveedor de pagos. UMSA puede empezar con cien pagos recientes: cuotas por QR, transferencias manuales, reversos y cobranzas por tercero. El primer corte útil muestra si cada registro tiene responsable, referencia externa, cuenta receptora y salida exportable para tesorería.
Dónde se rompe y cómo probarlo
El primer riesgo es aceptar pagos sin referencia única. La señal aparece cuando dos cuotas se imputan con el mismo comprobante. La prueba carga diez pagos de canales distintos y exige identificador externo único. El segundo riesgo es mezclar permisos de carga y anulación. La señal aparece cuando el mismo usuario crea una cuota, la marca pagada y borra la excepción. La prueba usa perfiles de administración, tesorería y gerencia, y confirma rechazos. El tercer riesgo es depender del archivo que manda el proveedor. La señal aparece cuando el tablero no puede reconstruir un pago si falta el CSV. La prueba restaura base y adjuntos, abre cinco operaciones y compara estado contra comprobante. El cuarto riesgo es cerrar el día sin alerta. La señal aparece cuando una API falló y nadie revisó pendientes. La prueba corta el servicio en ambiente de ensayo y confirma aviso, reintento y reporte de operaciones sin conciliación. El cobro ordenado deja una pregunta simple para cada cuota: quién la inició, qué sistema la movió y qué evidencia queda si alguien la discute.
