MerchantMerchantMerchantSu banco y FINORA, en alianza. Lista para operar.
La frase de apertura: «Hoy ustedes cobran con un solo banco. Lo que traemos es que cada tarjeta encuentre el suyo, que el cliente pague como quiera, y que ninguna venta dependa de un único camino.»
Doce láminas, quince minutos. Todo el detalle está en estas notas, para las preguntas. FINORA es un producto de DC GEEKS.
Cobra en la tienda, orquesta los medios y habla con su banco.
En una frase: «FINORA Merchant es la plataforma que cobra en la tienda. Acepta el pago por el medio que el cliente traiga, decide por dónde sale, concilia el día y prepara la liquidación. Ustedes ponen el banco; nosotros ponemos todo lo demás.»
Lo que NO es, y conviene decirlo: FINORA no mueve fondos. Calcula e instruye, y el banco abona. En Venezuela la adquirencia está reservada a las instituciones bancarias (Resolución SUDEBAN 049.20, artículo 3.13); operamos bajo patrocinio, en la figura de compañía administradora del artículo 3.2, que requiere autorización de SUDEBAN y del BCV.
El banco simulado: hoy el otro extremo de la cadena es un simulador nuestro que se comporta como un banco de verdad —responde, rechaza, demora y calla—. La cadena completa funciona de punta a punta contra él.
Si preguntan por el resto de la suite: Merchant es una pieza de una plataforma bancaria mayor, con FINORA Core (contable), Trust, Invest y el Payment Hub ISO 20022 detrás.
El mensaje: «No es un programa. Es una plataforma con piezas ya implementadas y en operación en el entorno de demostración, cada una con su oficio, y todas gobernadas desde el mismo sitio.»
Dígalo usted antes de que lo pregunten. Los treinta casos vienen con contrapeso: veintiún casos quedaron sin evidencia porque dependen de un banco real. Están rotulados así en el informe, no escondidos.
Sobre el chip, la frase exacta: «el terminal lee el chip y su firma viaja en el mensaje». Nunca «EMV certificado»: el nivel 3 lo firma el adquirente, no nosotros.
Y lo que no tenemos: la certificación de seguridad de tarjetas (PCI) no está iniciada y no hay prueba de carga — por eso no damos ninguna cifra de capacidad ni de transacciones por segundo.
Si preguntan por certificaciones: estas cifras son pruebas internas y precertificación propia, no certificaciones de marca ni de seguridad. La certificación con el banco se hace con su autorizador y su laboratorio, como paso siguiente.
Son rieles del catálogo, no intenciones. El orquestador los trata a todos igual: cada uno deja su intento, cada intento aprobado suma a la misma venta. Una compra puede repartirse entre varios y conciliarse en un solo corte.
Quién decide qué se acepta: cada riel se habilita o se apaga por comercio y por terminal, con monto mínimo y máximo propios. La caja de una sucursal puede aceptar pago móvil y la de otra no, sin desplegar nada.
El matiz honesto —uso interno, no se proyecta: hoy registran tráfico tres rieles: tarjeta, pago móvil y transferencia, contra el banco simulado. Débito y crédito inmediato están implementados pero todavía no habilitados: les falta su ruta al autorizador y encenderlos en el comercio. QR y cripto están en la hoja de ruta: existen como riel del catálogo, pero no hay generación ni lectura de QR en ninguna aplicación, ni integración con custodio de criptoactivos.
Narre el recorrido paso a paso con la tecla N o el botón «Siguiente». Cada flecha lleva su mensaje real.
La regla que no se negocia: el banco se elige antes de enviar el cobro. Una compra que ya salió a un banco no se reenvía nunca a otro: si el primero calla, se le manda un reverso y se rechaza la venta. Es lo que impide que un cliente quede cobrado dos veces.
Idempotencia: repetir la misma petición devuelve el mismo cobro, nunca dos.
El PAN no se ve: el número completo de la tarjeta no aparece en ninguna pantalla ni registro; se guarda enmascarado, seis dígitos al principio y cuatro al final.
Todo deja rastro: cada mensaje al banco queda en un registro que no se puede reescribir — a qué banco fue, por qué regla, cuánto tardó y qué respondió. Es evidencia, no una traza de depuración.
La frase: «El ciclo de compensación y liquidación es del negocio de tarjetas. Es el que obliga a esperar al día siguiente, y es el único que lo hace. Todo lo que cobren por un riel bancario ya está en la cuenta cuando el cliente sale de la tienda.»
Para una farmacia eso es capital de trabajo que no hay que financiar. Ese es el argumento, no el detalle técnico.
Si un técnico del banco pide la prueba: el ciclo lo alimenta un único servicio, que selecciona exclusivamente transacciones adquirentes aprobadas, capturadas en un lote cerrado y por marca de tarjeta, y emite los registros de compensación (Mastercard IPM 1240/200, Visa BASE II TC05). Ningún cobro por pago móvil, transferencia, débito o crédito inmediato produce un registro de compensación, así que ninguno entra en la corrida de liquidación T+n.
Precisión que no conviene perder: no diga «el dinero llega al instante» a secas. Es cierto por riel y confirmado en línea; el efectivo lo confirma el cajero y la tarjeta sigue siendo T+1.
La cadena nocturna de la tarjeta, si la piden: a las 23:05 se cierra el lote; de madrugada se compensa, se descuenta la comisión y sale el archivo de abono —quien lo genera no lo aprueba, hacen falta dos pares de ojos—; a las 06:00 se coteja lo calculado contra lo abonado.
Las cuentas: el comercio registra las que quiera y marca cuál cobra; solo una verificada recibe liquidaciones. El catálogo trae las instituciones venezolanas con su código oficial de cuatro dígitos: 27 bancos y el BCV.
Pendiente, dígalo: la corrida de liquidación de tarjeta se probó en el entorno de demostración; todavía no ha corrido ninguna con dinero real.
Sin jerga: «Los primeros dígitos del número de una tarjeta identifican al banco que la emitió. Es un estándar internacional, no un invento nuestro. La plataforma los consulta y decide a cuál enviar el cobro, antes de salir.»
Y se gobierna por reglas: además del emisor, la regla puede mirar el monto, la moneda, la sucursal o el terminal. Una regla se prueba en un simulador antes de activarla: nadie descubre el efecto de un cambio con una venta real.
La regla que no se negocia: el banco se elige antes de enviar el cobro. Una compra que ya salió a un banco no se reenvía nunca a otro: si el primero calla, se le manda un reverso y se rechaza la venta. Es lo que impide que un cliente quede cobrado dos veces. Y repetir la misma petición devuelve el mismo cobro, nunca dos.
Los rangos son del banco: la tabla que aparece en pantalla va rotulada «ejemplo». Los rangos reales los distribuye el banco miembro a su operador por contrato.
Uso interno —no se proyecta: hay dos caminos técnicos hacia un banco, el riel de tarjetas por ISO 8583 desde el Aurora Switch y el riel interbancario por ISO 20022 desde el Payment Hub. Son interfaces separadas a propósito.
El mensaje: «Dar de alta un banco no es un proyecto de software. Es una pantalla: se importa la plantilla del banco, se prueba en el simulador y se activa. Sin desplegar, sin reiniciar y sin parar la tienda.»
Qué crea la plantilla, en concreto: el nodo del banco con su transporte, sus rutas por BIN con prioridad, su dialecto de mensaje, el mapeo de campo a campo, la política de stand-in y la cola de reenvío. Todo por API y desde la consola.
Lo que ya está desplegado: alta, edición y baja de nodos; puerto de entrada propio por banco con apertura y cierre en caliente; dialecto de entrada por puerto; monitor en vivo por SSE y journal por nodo.
Los dos amarres que quedan —dígalos si preguntan: (1) el material del certificado TLS del puerto de entrada vive en propiedades, así que cambiarlo exige desplegar; (2) no existe todavía la pantalla para crear un dialecto desde cero, que hoy se carga por SQL. Ninguno de los dos bloquea encender un banco con un dialecto ya conocido.
Y un riesgo operativo vigente que preferimos declarar: hoy hay un comodín que manda al banco simulado cualquier tarjeta sin ruta. Con dos bancos vivos eso mandaría tarjetas de uno al otro. Cerrarlo son dos días y medio, y es lo primero de la lista.
Por qué importa: «Una farmacia sin billetes de vuelto pierde la venta o regala el redondeo. Aquí el vuelto se calcula y se envía por pago móvil al teléfono que dicta el cliente.»
Los controles, con su letra pequeña:
La devolución es otra cosa, y ahí sí hay dos pares de ojos: cuando se devuelve un producto, el dinero vuelve por el mismo riel y al mismo pagador con el que se cobró. Por encima del tope del comercio la autoriza gerencia, y nunca la misma persona que la pidió.
El estado exacto, y dígalo así si preguntan: el motor está construido y probado en el servidor —cálculo del importe, los tres controles, el asiento contable y los avisos—. Lo que está en desarrollo es la experiencia en la caja: hoy el cajero no tiene la pantalla para dar vuelto por pago móvil, solo el vuelto en efectivo. Todavía no se ha ejecutado ninguno con dinero real.
Uso interno —no se proyecta: el servicio del servidor es RefundRailService.vuelto y está completo. Falta la pantalla en merchant/finora-caja, el prellenado del importe y la llamada a la API; y, para que salga a un teléfono real, las credenciales del banco. No es «ni una línea de código más»: son tres eslabones de siete.
La frase: «Operar con varios bancos sin saber cómo está cada uno es operar a ciegas. La plataforma mide cada enlace de forma continua y avisa antes de que lo note la tienda.»
Los tiempos son medidos, no inventados: 884 ms es la media real del enlace que opera hoy en el entorno de demostración, y 249 ms la de la autorización que se resuelve en local, sin salir a ningún banco. Solo uno de los dos es un enlace bancario. Las tres filas ilustran las tres situaciones —normal, lento y caído— y por eso van rotuladas ejemplo.
Las dos pantallas: FINORA Pulse es el tablero de sala —ventas del día, aprobación, importes, reparto por destino—, implementado y en operación en el entorno de demostración. FINORA Torre vigila la flota del comercio —terminal fuera de línea, caja sin ventas, rechazos altos, ventas en duda, lote abierto tarde—, también implementada.
Lo que ya se mide: cada mensaje queda registrado con su banco de destino, su tiempo y su resultado, y se emiten en vivo doce tipos de suceso del enlace: se cayó, volvió, respondió el latido, cuánto tardó.
El estado vivo de los enlaces ya está encendido en Pulse: la configuración está puesta y el switch responde con el estado de cada nodo. Y lo que falta: la parrilla de alertas está escrita y sin encender, y el reparto por banco solo tiene sentido cuando haya un segundo banco real.
La frase: «Su app no se reescribe. Le sumamos el cobro con una llamada: FINORA lee la tarjeta, habla con el banco y le devuelve el resultado.»
Tres vías, según lo que ya tengan: el SDK de Android cuando el cobro ocurre en el mismo teléfono o datáfono (su app abre FINORA Pago y recibe el resultado); el cobro en la nube cuando su sistema crea la orden y un datáfono asignado la cobra; y el pago web para lo que se vende en línea.
Seguridad: solo cobran las apps autorizadas por el comercio —se verifica la firma del paquete en el equipo y otra vez en el servidor—. La app del integrador nunca recibe el número de la tarjeta.
Idempotencia: si la app repite la orden con la misma referencia, recibe el mismo cobro, no uno nuevo. Las anulaciones también van por el SDK.
Si su app está hecha en Flutter (el caso de la app del mensajero): el cobro es un Intent explícito de Android con startActivityForResult. Desde Flutter se llama con un canal nativo (MethodChannel) en la actividad principal de Android, que puede usar la librería del SDK tal cual. No hay que reescribir la app ni cambiar sus pantallas. Un plugin de Flutter publicado por FINORA está en la hoja de ruta; hoy el puente lo escribe el integrador, con nuestro acompañamiento.
Solo Android: el cobro con lector corre en Android. En iOS la vía es el cobro en la nube hacia un datáfono asignado.
Estado honesto: el SDK está en beta y probado con un lector real; la documentación está en el portal para desarrolladores.
El cierre, en voz alta: «La plataforma está construida y probada. Entra en servicio en cuanto se habilita la conexión, y desde ese momento la cadena cobra por todos los medios con el respaldo de su banco.»
Qué gana la cadena —dígalo con estas cuatro:
Cómo arranca, los cuatro pasos:
Lo que decide el comercio, y conviene dejar acordado: qué cuenta recibe las liquidaciones, qué rieles habilita por sucursal y por terminal, el tope de vuelto por operación y el tope de devolución sin autorización de gerencia.
Uso interno —no se proyecta: para encender un banco nuevo hacen falta su especificación de autorizador, un punto de conexión de pruebas, las llaves de cifrado, la tabla de rangos y el formato del archivo de liquidación. Nada de eso se le pide al banco delante de su cliente.
Trece láminas. ← → navegan, N avanza el recorrido del diagrama, S abre las notas, P exporta a PDF.