LupsOne — la llave de pago del usuario
Este BBP está centrado en un solo plan de trabajo, decidido el 3 y 4 de septiembre de 2026: convertir a Lups en la capa que gobierna el permiso de cobrar, sin tocar dinero ni guardar tarjetas. Todo lo anterior del proyecto vive en git y en 99-Archivo/lups-bbp-completo-20260904.html.
Qué es
La persona entrega un código, no una tarjeta. El comercio pide un token con límites y cobra.
Modelo
El comercio recauda directo con su propio código. Tarifa 2,9% con topes por plan.
Por qué sirve dos veces
Un mandato de suscripción y un Intent Mandate de AP2 son el mismo objeto.
Estado
Cero líneas de código escritas. Once decisiones abiertas, cuatro bloquean el diseño.
Reloj
Ley 21.719 exigible: consentimiento trazable y revocación propagada dejan de ser opcionales.
Contacto
Junngla SpA · Av. Providencia 1208, Santiago.
La regla que ordena todo el diseño
De dónde partimos, con números
La base es chica, y eso es una ventaja para probar y una limitación para proyectar. Conviene tenerla a la vista antes de leer cualquier plan.
| Dato | Valor | Qué implica |
|---|---|---|
| Comercios | 21 | 85% del volumen es uno solo (Simplee) |
| Volumen histórico procesado | $15.852.067 | El porcentaje no construye un negocio a esta escala |
| Comisión Lups acumulada | $322.914 | El producto no se autofinancia con la base actual |
| Suscriptores activos | 5 personas | Todas de Reponeme. Lo que se usa son solicitudes de pago, no suscripciones |
| Comercios con código propio | 3 de 21 | Los otros 18 hay que migrarlos; es condición del modelo |
| Cobro automático | 0 de 4 en Foodtag | Es el tramo 0: si no sabemos cobrarnos solos, no hay de dónde facturar |
Cómo leer este BBP
| Sección | Qué contiene |
|---|---|
| Bitácora | Pendientes por responsable, acuerdos inmutables y el registro de sesiones. Es la fuente de verdad de qué se decidió y cuándo |
| Desarrollos | El journey de punta a punta y los tres assets — Lups, LupsOne y Web — cada uno con su tablero de qué tenemos y qué no, más el backlog técnico transversal |
| LupsOne · El modelo | Qué es, qué problema resuelve, los tres lados y la tarifa |
| LupsOne · Diseño | Objetos, flujos, las cuatro superficies de front y qué existe hoy |
| LupsOne · Plan | Las fases, los cinco tramos y las decisiones L-01 a L-11 |
| Ley 21.719 | El marco que fija la fecha del 1º de diciembre |
03-Documentos/LupsOne/LupsOne-especificacion.md (v0.1, 574 líneas). Este BBP es el resumen navegable y la bitácora; la especificación es el detalle técnico.Diccionario
Lo que nombramos nosotros
| Término | Qué es |
|---|---|
| LupsOne | El producto: la llave de pago del usuario y todo lo que cuelga de ella. |
| Llave | El código público que la persona entrega al comercio. Es un identificador, no una credencial: sirve para pedir permiso, no para cobrar. Rotable y no derivada de datos personales. |
| Mandato | El permiso de un usuario para un comercio, con monto tope, frecuencia y vigencia obligatoria. Se revoca, no se borra. |
| Token de cobro | Lo que el comercio recibe y usa para cobrar. Opaco y acotado a ese comercio: el token de A no funciona en B. |
| Credencial por referencia | El puntero a un medio de pago que custodia un tercero (OneClick, PAC). Nunca guardamos el número de tarjeta. |
| Autorización de agente | Pieza separada del mandato: qué agente puede pedir en nombre del usuario, en qué comercios y hasta qué monto. |
| Evidencia | El registro append-only encadenado por hash de qué se autorizó y qué se intentó. Si se puede editar, no sirve como prueba. |
| Componente embebido | El SDK que se inserta en el checkout del comercio, donde el usuario crea su llave y confirma. No es una pantalla nuestra: vive en el sitio ajeno. |
| Consola del usuario | Donde la persona ve sus suscripciones, sus medios de pago, sus agentes y el botón de cancelar. |
| Consola del comercio | El backoffice del cliente que paga: sus mandatos, cobros, liquidaciones y tarifa. |
| Enrutamiento | Elegir el rail más conveniente para cada cobro. Cuando el mandato dice «que LupsOne elija», de ahí sale el margen. |
| LupsDunning | Motor de recuperación de pagos fallidos de la familia Lups. Fuera de foco desde el 4-sep-2026 (A-12); su capacidad vive dentro de Lups, sin marca propia. |
| Asset | Cada una de las tres piezas de software del proyecto: Lups (lo que ya opera), LupsOne (lo nuevo) y Web (lo que se sirve públicamente). |
| Journey | Las once etapas por las que pasa un cobro de punta a punta. Es la vista que manda; los assets explican dónde vive cada pieza. |
| Tramo | Unidad de construcción del plan, del 0 al 4. Cada tramo se vende solo. |
Códigos de identificación
Ninguno se recicla: cuando un ítem se cierra, su número no se reutiliza.
| Prefijo | Qué identifica |
|---|---|
| A-XX | Acuerdos y decisiones de negocio. Inmutables: uno nuevo reemplaza a otro citándolo. |
| P-XX | Pendientes por responsable, en la bitácora. |
| B-XX | Deuda técnica transversal, en el backlog. |
| L-XX | Decisiones de Francisco que bloquean diseño, negocio o legal. |
Términos del mercado que usamos
| Término | Qué es |
|---|---|
| AP2 | Agent Payments Protocol. El estándar de pagos agénticos que Google donó a la FIDO Alliance el 28-abr-2026, con Visa y Mastercard presidiendo el grupo de pagos. |
| Intent Mandate | En AP2, la credencial donde el usuario aprueba restricciones para que un agente actúe después. Equivale a nuestra autorización de agente. |
| Human Not Present | El modo de AP2 en que el agente ejecuta sin el usuario delante, dentro de límites aprobados antes. Es la forma exacta de un cobro recurrente autorizado. |
| KYA | Know Your Agent. Verificar la identidad, la autoridad y el comportamiento de un agente de IA, como el KYC lo hace con personas. |
| Web Bot Auth | Propuesta IETF liderada por Cloudflare para firmar peticiones HTTP y verificar agentes. Cloudflare, Anthropic y OpenAI ya en producción: es estándar de facto. |
| Rail | El camino por el que viaja un pago: crédito, débito, prepago, transferencia, PAC, y a futuro el SPI. |
| MDR | Merchant Discount Rate. Lo que el comercio paga al adquirente por procesar. Nuestra comisión es 2,9% menos el MDR del medio usado. |
| Tope | El máximo que Lups cobra por transacción según el plan. Cuando se activa, el ahorro del rail barato se lo lleva el comercio. |
| Churn involuntario | El suscriptor que se pierde porque su tarjeta venció o se bloqueó, sin que quisiera irse. Es el dolor que LupsOne ataca en la causa. |
| PAC | Mandato de cargo automático en cuenta bancaria. Lups lo opera hoy con BCI. |
| OneClick | La tokenización de tarjeta de Transbank. Es la base del modelo de credenciales por referencia. |
| SPI | Sistema de Pagos Instantáneos. Lo que el Banco Central impulsa en vez de replicar Pix; sus estándares de alias, QR y APIs salen a consulta este semestre. |
| SFA | Sistema de Finanzas Abiertas de la Ley Fintec. Entra en vigencia en julio de 2027, no 2026: la CMF extendió la implementación a 36 meses. |
Bitácora del proyecto
Fuente de verdad del proyecto: pendientes por responsable, acuerdos y registro de sesiones. Última actualización: 4 de septiembre de 2026 (hora de Chile continental).
Pendientes por responsable
| ID | Responsable | Pendiente | Prioridad | Estado |
|---|---|---|---|---|
| P-01 | Francisco — Junngla | Nombrar formalmente al Technical Lead y registrar su contacto en el equipo. | Media | Hecho |
| P-02 | Francisco — Junngla | Definir el modelo de monetización final de LupsDunning (¿% de recuperado, comisión fija, incluido en plan?). | Alta | Hecho |
| P-03 | Equipo legal — Junngla | Completar checklist Ley 21.719 (consentimiento, ARSOP, DPA, RAT, protocolo de brechas) antes de la vigencia plena del 01-dic-2026. | Alta | Pendiente |
| P-04 | Francisco — Junngla | Decidir integración con Mercado Pago (PAC/PAT Digital, comisión 2,59% + IVA) vs. seguir con Webpay / OneClick. | Media | Hecho |
| P-06 | Francisco — Junngla | Toma de control de Lups desde Claude: operar y administrar Lups directamente desde Claude. | Alta | Hecho |
| P-07 | Francisco — Junngla | Envío de botón de pago en tiempo real: generar y enviar el botón de pago en tiempo real. | Alta | Pendiente |
| P-05 | Producto — Junngla | Habilitar importación masiva de productos vía CSV y PAC (ambos anunciados como "próximamente" en el sitio). | Media | Pendiente |
Acuerdos y decisiones
Registro de las decisiones de negocio: cuándo se tomaron y quién las tomó. Cada acuerdo nuevo se agrega arriba. Los acuerdos son inmutables: uno nuevo reemplaza a otro citándolo.
| ID | Fecha | Acuerdo / decisión | Quién decidió |
|---|---|---|---|
| A-12 | 04-sep-2026 | LupsDunning sale del foco por ahora. La oferta se centra en Lups (gestiona) y LupsOne (acelera). La capacidad de reintentar con criterio se mantiene como función de Lups, sin marca propia ni promesa de porcentaje de recuperación. | Francisco |
| A-11 | 04-sep-2026 | El plan de trabajo se estructura en fases con dependencias: fundaciones, catastro, diseño y construcción por tramos. El catastro se hace con squad-onboard y va antes de SuperArqDev. | Francisco |
| A-10 | 03-sep-2026 | LupsOne no guarda números de tarjeta: guarda referencias tokenizadas de terceros (OneClick, PAC). Deja de ser un vault y pasa a ser un índice de credenciales ajenas. | Francisco |
| A-09 | 03-sep-2026 | Cambio de modelo: la persona tiene una llave LupsOne con sus medios de pago; entrega un código al comercio y este pide un token de cobro con límites. El mismo flujo sirve para el caso humano y el agéntico. | Francisco |
| A-08 | 03-sep-2026 | Modelo de tres lados: las billeteras aportan las personas, los adquirentes aportan los comercios y Junngla aporta la tecnología. No adquirimos ninguno de los dos lados. | Francisco |
| A-07 | 03-sep-2026 | La parrilla de productos debe ser diferenciada de la oferta chilena, con luces al futuro y poco replicable: SaaS, sin tocar dinero. | Francisco |
| A-06 | 03-sep-2026 | El comercio recauda directo con su propio código; Junngla no recauda. Se mantiene la tarifa de 2,9% con topes por plan. Reemplaza el modelo agregador vigente, en que 18 de 21 comercios cobran con el código mall de Junngla. | Francisco |
| A-05 | 13-jul-2026 | Toda cifra de pricing del BBP nace de estos acuerdos; las secciones la citan y no la redefinen (fuente única de verdad). | Francisco |
| A-04 | 2026 | Comisiones de medio de pago: Webpay 2% y pago con transferencia bancaria 1%. PAC "próximamente". | Francisco |
| A-03 | 2026 | Plan Pro: $990 + IVA por suscriptor/mes, con mínimo mensual de $500.000. Incluye dominio propio y soporte WhatsApp/teléfono. | Francisco |
| A-02 | 2026 | Plan Starter: $1.590 + IVA por suscriptor/mes, sin mínimo mensual. | Francisco |
| A-01 | 2026 | LupsDunning se incluye en todos los planes sin costo adicional, como diferenciador central. | Francisco |
Registro de entradas
Entrada 004 — Cambio de modelo: nace LupsOne
Sesiones de estrategia sobre dónde llevar Lups. Se partió leyendo dos informes de mercado — uno global de pagos e IA, otro de competencia y espacios disponibles del fintech chileno — y una investigación web propia sobre KYA (Know Your Agent). Los tres quedaron digeridos en Conocimiento/.
La primera propuesta que hice fue equivocada y Francisco la corrigió: yo recomendé posicionar a Lups como recaudador delegado, aprovechando que hoy 18 de 21 comercios cobran con el código mall de Junngla. La decisión fue la contraria y quedó como A-06: el comercio recauda directo y nosotros vendemos herramientas. Sobre esa base se construyó todo lo demás.
El modelo final es LupsOne: la persona tiene una llave con sus medios de pago, entrega un código al comercio, y el comercio pide un token de cobro con límites. El mismo flujo sirve cuando quien pide el token es un agente de IA. Quedó escrito en 03-Documentos/LupsOne/LupsOne-especificacion.md, 574 líneas con flujos, modelo de datos, API y decisiones pendientes.
Nadie está en este cruce. El mapeo completo de empresas que construyen identidad de agentes concluye «None identified» sobre cobro recurrente y sobre el lado del que cobra: todos trabajan en autenticación de checkout. Y AP2 v0.2 ya especificó «Human Not Present», que es la forma exacta de un cobro recurrente autorizado.
El informe chileno nombra a Junngla como candidato en dos de los siete espacios disponibles — orquestación multi-rail y el vacío post-RedPay — y constata que no existe ningún actor chileno construyendo infraestructura agéntica propia: los bancos son participantes de estándares ajenos, no diseñadores.
Corrección de fecha que cambia la urgencia: el Sistema de Finanzas Abiertas no arranca en julio de 2026 sino en julio de 2027. La CMF extendió la implementación de 24 a 36 meses tras una consulta con más de 400 comentarios.
Se registraron los acuerdos A-06 a A-11 y se abrieron las secciones LupsOne de este BBP. Quedan once decisiones L-01 a L-11 esperando respuesta, cuatro de las cuales bloquean el diseño.
El BBP quedó bajo git, con el estado publicado como primer commit. Es el aprendizaje directo del BBP de AgentRoom, que se pisó entre sesiones paralelas por no tener versionado y llegó a tener tres versiones divergentes al mismo tiempo. Además se recortó el BBP para que quede centrado solo en este plan; lo anterior vive en git y en 99-Archivo/lups-bbp-completo-20260904.html.
No se escribió una línea de código. Todo lo de esta entrada es diseño y decisión. El tramo 0 — que Lups logre cobrarse sola, hoy en 0 de 4 en Foodtag — sigue pendiente y es el cimiento de lo demás.
Entrada 003 — Caída del login por OTP y toma de control de la infraestructura
Una clienta reportó que no podía entrar. El diagnóstico mostró que el login por códigos de toda la plataforma llevaba tres días caído, desde la migración de Keycloak del 13 de agosto: el feature token-exchange quedó apagado, así que el código se validaba, se consumía, y recién después fallaba la emisión del token. El usuario veía "código incorrecto o vencido" y quedaba en un bucle. No lo detectó ningún monitor.
Al ir a persistir el arreglo apareció algo más grave: la base de identidad de Lups y FLUX —16 realms, 1.191 usuarios— vivía en el disco raíz de una instancia que el grupo de autoescalado repone sola sin restaurar nada. El próximo reemplazo la habría borrado, dejando un Keycloak que responde HTTP 200 con cero realms. Se migró a un volumen dedicado y se probó terminando la instancia a propósito: vuelve completa en unos 4 minutos, sola.
Se abrió la sección Backlog de este BBP con los 17 ítems de deuda técnica que quedaron en el tintero. Se levantó una alarma que revisa cada 5 minutos que los realms existan y que el servidor reconozca el grant de token-exchange — las dos fallas de esa noche devolvían HTTP 200, así que un monitor de disponibilidad las habría dado por buenas.
P-06 — Toma de control de Lups desde Claude Hecho
Entrada 002 — Cierre de pendientes y nuevos encargos
Se marcaron como Hechos los pendientes P-01 (nombramiento del Technical Lead), P-02 (modelo de monetización final de LupsDunning) y P-04 (definición de integración Mercado Pago vs. Webpay/OneClick).
Francisco levantó dos nuevos pendientes: P-06 (toma de control de Lups desde Claude, para operar y administrar la plataforma directamente) y P-07 (envío del botón de pago en tiempo real).
P-01, P-02 y P-04 Hecho
Entrada 001 — Creación del BBP de Lups
Se creó lups-bbp.html a partir del template estándar y se pobló con el contenido real del proyecto: producto (4 servicios + LupsDunning), operación (medios de pago, envíos, recuperación), pricing, marketing, marco legal y checklist Ley 21.719. Se aplicó el brand oficial de Lups (naranja #F58220, Inter, isotipo en el sidebar).
Se registraron los acuerdos A-01 a A-05 (LupsDunning incluido, pricing Starter/Pro, comisiones de medio de pago, fuente única de verdad). Próximos pasos abiertos: P-01 a P-05.
T-06 — BBP de Lups creado con estructura estándar y branding oficial Hecho
Backlog técnico
Lo que quedó en el tintero: cosas que detectamos y decidimos hacer después, con la razón por la que se pospusieron. A diferencia de los pendientes de la bitácora —que son encargos por responsable—, esto es deuda del sistema. Si algo de acá muerde, la explicación ya está escrita. Última actualización: 4 de septiembre de 2026.
Prioridad alta
| ID | Área | Qué queda pendiente | Por qué se pospuso |
|---|---|---|---|
| B-01 | Seguridad | Credencial por integración en los endpoints del widget. Hoy el header x-store es un identificador, no una credencial: cualquiera que conozca el UUID de una tienda puede consultar productos, carrito, suscripciones y auth. Y como todo el tráfico servidor-a-servidor se ve idéntico en los logs, no hay forma de distinguir quién llama. | Es un cambio de API: hay que coordinar con cada comercio integrado. No se improvisa. |
| B-02 | Continuidad | Sacar el despliegue del computador de una persona. El script que publica los frontends copia a rutas fijas de un laptop, y no hay CI/CD en ninguno de los nueve repos. El backend se publica a mano. | Requiere ventana de trabajo y transferencia de conocimiento, no solo escribir los workflows. |
| B-03 | Continuidad | Runbook de operación y despliegue escrito, y una segunda persona que ejecute un deploy completo de punta a punta sin ayuda. Esa es la prueba de que el conocimiento se transfirió. | Depende de B-02: no tiene sentido documentar un proceso que está por cambiar. |
| B-04 | Correo | Activar DKIM en SES y publicar SPF y DMARC en lups.cl. El dominio está verificado pero sin autenticar. | Hoy entrega bien, pero con las reglas de Gmail se degrada a spam — y todo el login depende de que el correo llegue. |
| B-05 | Seguridad | Verificar y rotar la credencial AWS con formato real commiteada en .env.sample del api-service, presente desde los primeros commits del repo. | El repo es privado, pero la llave está en toda la historia de git. |
Prioridad media
| ID | Área | Qué queda pendiente | Por qué se pospuso |
|---|---|---|---|
| B-06 | Login | El parámetro OTP_TIME no existe en producción, así que los códigos no expiran nunca. Y created_at se guarda en hora de Chile pero se lee en la zona del servidor, que corre en UTC. | Trampa: crear el parámetro sin arreglar antes la zona horaria deja a todos los usuarios fuera. Los dos cambios van en el mismo despliegue o en ninguno. |
| B-07 | Login | El código OTP se consume antes de que puedan fallar los pasos siguientes. Cualquier error posterior quema el código y deja al usuario en un bucle sin salida. | Es exactamente lo que convirtió la falla de agosto en tres días de bucle. Requiere reordenar la transacción. |
| B-08 | Login | El código se escribe en la cuenta antes de validar la tienda: un envío que falla igual deja un código huérfano. | Mismo cambio que B-07, conviene hacerlos juntos. |
| B-09 | Integración | Deprecar el calce por dominio (externalWebsite) como forma de identificar la tienda. Dejar el UUID como único mecanismo documentado y avisar a los comercios que hoy calzan por dominio. | Hay ocho tiendas con dominio configurado. Necesita fecha de corte y aviso previo. |
| B-10 | Integración | Los frontends no mapean los códigos de error de autenticación: cualquier 400 de /verify-code se ve igual. Publicar la tabla a los comercios que tienen frontend propio. | Por eso un fallo de emisión de token se mostró como "código incorrecto o vencido" y mandó el diagnóstico para el lado equivocado. |
| B-11 | Observabilidad | Los logs de la aplicación no llegan a CloudWatch: el grupo existe pero está vacío. Sí están en la instancia. | Hay con qué diagnosticar entrando por SSM; falta la cañería. |
| B-12 | Operación | Habilitar acceso a la base de datos por Client VPN o bastión. Hoy solo se llega ejecutando comandos dentro de la instancia. | Funciona, pero es incómodo y deja poco rastro de quién consultó qué. |
| B-13 | Identidad | Crear un administrador de Keycloak con kc.sh bootstrap-admin. Hoy la única forma de administrar es la cuenta de servicio de la aplicación. | El bootstrap admin nunca se creó porque la base se importó completa desde Tokeni, y por eso la clave guardada en SSM no sirve. |
| B-14 | Continuidad | Decidir qué hacer con el riesgo de zona única de Keycloak: base multi-zona, o procedimiento escrito y probado para restaurar el snapshot en otra zona. | Es una decisión de costo, no una tarea. Multi-zona suma gasto fijo. |
Higiene y proceso
| ID | Área | Qué queda pendiente | Por qué se pospuso |
|---|---|---|---|
| B-15 | Proceso | Definir quién es dueño de dar de baja la infraestructura de un cliente que migra o se va. | El sitio viejo de Tukan siguió meses corriendo en nuestra cuenta, sirviendo checkout de una tienda que ya no existe y ensuciando los logs. No falló por un bug: falló porque nadie tenía el encargo. |
| B-19 | Seguridad | El portal del proveedor no tiene usuarios. Se autentica con un providerToken: un UUID fijo por proveedor, sin vencimiento y sin persona detrás (auth-provider-token.middleware.ts). Cualquiera con ese enlace puede confirmar despachos y entregas de una tienda completa, y el sistema no distingue quién fue. | Se descubrió al preguntar quién marcó una orden como entregada: no hay respuesta posible porque no hay actor. Cambiarlo implica introducir cuentas por operador. |
| B-20 | Operación | Se puede declarar una entrega sin ninguna evidencia. En 13 de 28 órdenes el salto de "enviado" a "entregado" tomó menos de 5 minutos — varias en segundos, y en tandas. En la orden ORD005-000239 el picking terminó 90 segundos antes de declararla entregada en Colina, algo físicamente imposible. La clienta recibió un correo de "entregado" por una caja recién empacada. | El estado delivered no sirve como prueba de entrega: no hay foto, firma, número de seguimiento ni actor. Si un cliente reclama que no le llegó, no hay con qué contradecirlo. |
| B-21 | Datos | Limpiar la tabla de proveedores logísticos. De 25 en producción, ocho están marcados [PRUEBA], varios tienen correos de relleno (kadus@example.com) o teléfonos en "Sin valor", y tres apuntan a francisco@junngla.com.17-ago: se renombró el proveedor de Reponeme, que seguía llamándose "Tukan". Queda pendiente el resto. | Cinco de los ocho [PRUEBA] están referenciados por 41 ofertas de producto: borrarlos las deja huérfanas. El prefijo TUK no se cambió a propósito — genera los SKU de bultos y hay 36 órdenes despachadas con él. |
| B-18 | Baja de infra | Dar de baja la infraestructura de Tukan. Sigue viva en la cuenta recurennt: App Runner tucanloop-web (sirve www, dev y qa.tukan.cl, USD 6,37/mes), CloudFront EZ90KNH04JFWI con bucket S3 para el redirect del raíz, tres certificados ACM y la zona Route 53. Genera más de 1.000 errores diarios contra nuestra propia API.Secuencia: Reponeme entrega los valores de Railway → apuntamos www.tukan.cl ahí → verificamos que los 404 se detienen → eliminamos el App Runner y los subdominios dev y qa. El raíz y su CloudFront se quedan: sostienen la cadena de redirección. | Bloqueado esperando los valores de Railway de Reponeme. 17-ago: se eliminó el correo del dominio (MX, DMARC y DKIM de Mailchimp) — Francisco confirmó que nadie usa direcciones @tukan.cl. Se conservó el TXT de verificación de Google por si Reponeme necesita el cambio de dirección en Search Console. Pendiente aparte: revisar si queda una suscripción de Google Workspace cobrando — borrar el MX corta la entrega, no el contrato. |
| B-16 | Datos | Revisar las dos tiendas Simplee activas. La marcada "(test)" lleva 162 transacciones reales desde noviembre de 2025, con su propio código de comercio. | Puede ser intencional, pero una tienda que por nombre parece de prueba procesando pagos reales merece una mirada. |
| B-17 | Higiene | Limpiar el volumen raíz huérfano y los snapshots de la migración de Keycloak, y agregar update_default_version a la plantilla de lanzamiento. | Los respaldos se dejan a propósito hasta tener confianza en el cambio. Cuestan centavos. |
El journey de punta a punta
Las once etapas por las que pasa un cobro en el modelo LupsOne, con lo que hoy existe y lo que no. Es la vista que manda: los assets se leen después, y explican dónde vive cada pieza.
| # | Etapa | Estado | Qué hay y qué falta |
|---|---|---|---|
| 1 | Enrolamiento del comercio | Sin construir | Registro, aceptación de tarifa, asignación de plan y credenciales de API. Depende de L-05: si se exige código de comercio propio, hoy solo 3 de 21 califican. |
| 2 | Creación de la llave | Sin construir | Embebido en el checkout del comercio, sin desvío. Bloqueado por L-01 (formato) y L-03 (qué se pide al usuario). |
| 3 | Solicitud de mandato | Sin construir | El comercio presenta la llave y pide permiso. Devuelve solicitud pendiente, nunca un token directo. |
| 4 | Confirmación del usuario | Sin construir | El paso innegociable: sin él la llave sería una credencial. Bloqueado por L-02 (por dónde confirma). |
| 5 | Emisión del token | Sin construir | Opaco y acotado a un comercio. El mandato se evalúa en cada cobro, no solo al emitirlo. |
| 6 | Ejecución del cobro | Listo | Única etapa que ya corre. WebPay, OneClick y PAC operativos en la plataforma actual. |
| 7 | Reintento con criterio | Roto | Hoy se reintenta a ciegas. Foodtag: 0 de 4 cobros automáticos, insistiendo con la tarjeta ····2220 que ya había rechazado dos veces. Es el tramo 0 del plan. |
| 8 | Elección del medio | Sin construir | No hay enrutamiento: la tasa está fija al 3,57% en dos entidades. Es de donde sale el margen del modelo comercial. |
| 9 | Revocación | Sin construir | Un botón, efecto inmediato, sin veto del comercio. Es lo que la Ley 21.719 llama revocación propagada. |
| 10 | Cambio de medio de pago | Sin construir | Actualizar una vez y que ninguna suscripción se caiga. Es la funcionalidad que vende el producto al comercio. |
| 11 | Evidencia | Sin construir | Registro append-only encadenado por hash. Es lo que se presenta ante un contracargo, ante SERNAC y ante la Agencia. |
Asset · Lups
La plataforma que ya existe y opera hoy con 21 comercios. Es la base sobre la que se construye LupsOne, no algo a reemplazar. Trece repos recurennt-*, NestJS sobre MariaDB en Elastic Beanstalk.
Comercios
85% del volumen es uno solo
Volumen histórico
Comisión acumulada: $322.914
Suscriptores activos
Todos de Reponeme
| Pieza | Estado | Qué hay y qué falta |
|---|---|---|
| Cobro WebPay | Listo | Operativo. |
| Tokenización OneClick | Listo | Es la base del modelo de referencias de LupsOne: los tokens ya inscritos son las primeras credenciales. No partimos de cero, partimos de una migración. |
| PAC bancario (BCI) | Listo | Cada PAC vigente es un mandato que hay que representar en el modelo nuevo sin romperlo. |
| Solicitudes de pago | Listo | Es lo que los comercios realmente usan: Simplee mueve $12,7 millones con cero suscriptores. |
| Suscripciones recurrentes | A medias | Existe, pero la base completa son 5 personas. El producto se vende como plataforma de suscripciones y lo que opera es recaudación de facturas. |
| Planes y pricing en la base | A medias | Los tiers 2 a 5 se cargaron el 6-mar-2026, llevan seis meses visibles y no se ha migrado ni un comercio. Ver L-07. |
| Liquidación a comercios | A medias | 18 de 21 cobran con el código mall de Junngla, contra el acuerdo A-06. Quedan $8.125.757 por abonar; Reponeme nunca ha recibido un peso. |
| Login OTP | A medias | La caída de agosto se resolvió, pero siguen abiertos B-06, B-07 y B-08: los códigos no expiran nunca y se consumen antes de que puedan fallar los pasos siguientes. |
| Cobro automático | Roto | 0 de 4 en Foodtag. Los cuatro cobros logrados fueron manuales por WebPay. Tiene OneClick inscrito desde el 8-jun y nunca se usó. Es el tramo 0 del plan. |
| Reintento con criterio | No existe | Se reintenta lo mismo que ya falló. Fintoc publica que hacerlo bien mejora hasta 48% la recaudación. |
| Enrutamiento entre medios | No existe | 3,57% hardcodeado en payment-trace-webpay.entity.ts:33 y payment-trace-oneclick.entity.ts:27. No consulta el plan ni distingue medio de pago. |
| Modelo de comisiones 2026 | Sin desplegar | El correo del 17-ago prometió a 12 comercios la primera facturación con las tarifas nuevas al cierre de agosto. La rama feat/modelo-comisiones-2026 nunca se subió. |
| LupsDunning | Fuera de alcance | Sale del foco por A-12. La marca no se comunica y la promesa de «hasta 85% de recuperación» del brand kit no se usa: no hay evidencia que la respalde y choca con el 0 de 4 de Foodtag. El reintento con criterio se mantiene como función de Lups. |
| Consola del comercio | Por verificar | Alcance real por levantar en el catastro. Es la superficie que el comercio usa todos los días. |
Asset · LupsOne
El producto nuevo: la llave del usuario y todo lo que cuelga de ella. Nada de esto está construido. La especificación completa está en 03-Documentos/LupsOne/LupsOne-especificacion.md.
| Pieza | Estado | Qué es y de qué depende |
|---|---|---|
| Credenciales por referencia | Base existente | Lo único con cimiento: la tokenización OneClick de Lups. Falta el índice que las agrupa por usuario. Nunca guardamos el número de tarjeta. |
| La llave | Sin construir | Identificador público rotable, no derivado de datos personales, que no autoriza nada por sí solo. Bloqueado por L-01. |
| Mandato | Sin construir | El objeto central: usuario, un solo comercio, tope, frecuencia, vigencia obligatoria, revocación. Se escribe en formato AP2 desde el día uno. |
| Token de cobro | Sin construir | Opaco y acotado al comercio, como los Shared Payment Tokens de ACP. El del comercio A no sirve para el B. |
| Autorización de agente | Sin construir | Pieza separada del mandato. Sin ella, tener la llave no habilita a ningún agente. Equivale al Intent Mandate de AP2. |
| Evidencia append-only | Sin construir | Encadenada por hash. Si se puede editar, no sirve como prueba. Es la mitad del valor frente a la Ley 21.719. |
| Consola del usuario | Sin construir | Suscripciones, próximo cobro, medios de pago, agentes autorizados y el botón de cancelar. Web responsive, no app. Bloqueado por L-04. |
| Componente embebido | Sin construir | La pieza crítica. No es una pantalla, es un SDK que se inserta en el checkout ajeno. Si no es fluido, ningún comercio adopta y el producto no arranca. |
| API pública v1 | Sin construir | Nueve endpoints. Es infraestructura de terceros: no se rompe nunca una vez publicada. |
| Verificación de agente | Sin construir | Se consume Web Bot Auth y los directorios de Visa y Mastercard. Construir un directorio propio es pelear contra las redes y se pierde. |
| Enrutamiento por costo | Sin construir | «Que LupsOne elija». Es de donde sale el margen: el mismo 2,9% rinde más si el rail es más barato. |
Asset · Web
Todo lo que se sirve públicamente. Verificado en vivo el 4 de septiembre de 2026.
lups.cl responde 200 pero no tiene sitio propio — sirve la página de Junngla. Su <title> es «Cobranza automatizada y cobros recurrentes | Junngla» y su schema declara junngla.com como organización. El dominio es nuestro y está libre para construir.| Pieza | Estado | Qué hay y qué falta |
|---|---|---|
Dominio lups.cl | Listo | Es nuestro y resuelve. Aparece como contacto oficial (hola@lups.cl). |
| BBP | Listo | Este documento, en lups.junngla.com/bbp, desplegado por Vercel (lups-web) y versionado en git desde el 4-sep. |
| Precios públicos | A medias | El tarifario 2026 vive en junngla.com/lups#precio, no en un sitio de Lups. El FAQ se corrigió en es.json y en.json pero falta desplegar la web. |
| Sitio propio de Lups | Sin construir | Hoy es una sección dentro de junngla.com. Con el cambio de modelo necesita identidad propia. |
| Landing de LupsOne | Sin construir | Depende de L-08: si es white-label del comercio, esta pieza cambia de naturaleza o no existe. |
| Onboarding de comercio | Sin construir | Registro, aceptación de tarifa y entrega de credenciales, autoservicio. |
| Documentación para desarrolladores | Sin construir | Sin docs no hay integración. Es requisito de venta, no un extra. |
| Términos y privacidad | Sin construir | Con abogado y al estándar de la Ley 21.719, antes del 1º de diciembre. Ver L-09. |
| Autenticación de correo | Sin construir | B-04: falta DKIM en SES y publicar SPF y DMARC en lups.cl. Todo el login depende de que el correo llegue. |
| Consola del comercio (front) | Sin construir | La superficie de uso diario del cliente que paga. Alcance de lo actual por levantar en el catastro. |
LupsOne — la llave de pago del usuario
Cambio de modelo definido el 3 y 4 de septiembre de 2026. En vez de dejar la tarjeta en el checkout de cada comercio, la persona tiene una sola llave y entrega un código. El comercio pide un token con límites y cobra, sin ver nunca el medio de pago. Cuando quien pide el token es un agente de IA en lugar de un comercio, el flujo es idéntico.
Qué problema resuelve
| Para quién | Dolor actual | Qué cambia |
|---|---|---|
| Usuario | No sabe a cuántas cosas está suscrito ni cómo cancelarlas; cambiar de tarjeta obliga a reinscribirla en quince lugares | Un solo lugar donde ve todo, cancela con un botón y actualiza la tarjeta una vez |
| Comercio | Churn involuntario: la tarjeta vence y la suscripción se cae sin que el cliente quisiera irse | La credencial vive actualizada en un solo lugar; no hay nada que reintentar |
| Lups | La relación de pago es del comercio y somos un proveedor reemplazable | La relación es del usuario: el comercio puede cambiar de proveedor, el usuario no cambia de llave |
No es una idea rara: es el patrón dominante
Lo que LupsOne llama llave es lo que UPI llama dirección virtual, Pix llama chave y Bre-B llama llave. Son los sistemas de pago que más crecen del mundo — UPI mueve ~23.200 millones de transacciones al mes y Bre-B lleva 99 millones de llaves registradas en Colombia. Chile no tiene llaves, y nadie las ha aplicado a recurrencia, que es donde el dolor es peor.
Los tres lados
El modelo comercial no exige que Junngla adquiera usuarios ni comercios: cada socio llega con su cartera hecha.
| Quién | Qué pone | Qué recibe |
|---|---|---|
| Billeteras | Las personas y su credencial | LupsOne: emitir y gobernar mandatos |
| Adquirentes | Los comercios | Verificación del agente y del mandato al momento de cobrar |
| Junngla | El motor, el registro y la firma | La posición del medio |
Lo que nunca hacemos
Delimitado a propósito, porque define el perfil de riesgo y de cumplimiento: no tocamos dinero (va directo del cliente al comercio), no guardamos números de tarjeta (guardamos referencias tokenizadas ajenas), no somos token requestor de una red, no construimos un riel propio y no competimos en descubrimiento ni selección, donde están OpenAI y Google con su índice.
Modelo comercial
Vigente por acuerdo A-06: comisión = min(venta × (2,9% − MDR del medio), tope del plan). El markup no depende del plan; el plan solo fija el tope.
| Medio | MDR supuesto | Markup Lups |
|---|---|---|
| Crédito | 1,7% | 1,2% |
| Débito | 0,9% | 2,0% |
| Prepago | 0,6% | 2,3% |
| Plan | Tope por transacción |
|---|---|
| Activate | $18.000 |
| Spark | $15.000 |
| Scale | $10.000 |
| Pro | $6.000 |
| Enterprise | a conversar |
Por qué ahora
Tres relojes corriendo al mismo tiempo. La Ley 21.719 es exigible el 1 de diciembre de 2026: consentimiento trazable y revocación propagada dejan de ser opcionales, y casi ningún comercio mediano chileno los tiene. El estándar agentico se está cerrando: AP2 pasó a la FIDO Alliance el 28 de abril de 2026 con Visa y Mastercard presidiendo el grupo de pagos, y ya hubo pilotos en vivo en Chile (Santander con Visa; Mastercard con Falabella, Ripley y Security). Y el Banco Central pone en consulta pública los estándares de alias, QR y APIs este semestre.
Diseño y arquitectura
Resumen del documento maestro 03-Documentos/LupsOne/LupsOne-especificacion.md (v0.1, 3-sep-2026, 574 líneas), que es la fuente de verdad del diseño. Ahí están los campos completos, el SQL y los flujos paso a paso.
La decisión que saca el vault
LupsOne no guarda tarjetas: guarda referencias. El usuario inscribe su tarjeta en el formulario del proveedor, Transbank devuelve un token OneClick y nosotros guardamos ese token. El número de tarjeta nunca toca nuestros servidores. Dejamos de ser un vault y pasamos a ser un índice de credenciales ajenas, con una carga de cumplimiento muchísimo menor. Es lo que Lups ya hace hoy, escalado.
Objetos del dominio
| Objeto | Qué es | Regla dura |
|---|---|---|
| Llave | Identificador público del usuario | No se deriva de datos personales, es rotable y no autoriza nada por sí sola |
| Credencial | Referencia a un medio de pago ajeno (OneClick, PAC) | Nunca el PAN |
| Mandato | Permiso de un usuario para un comercio, con límites | Siempre un solo comercio; vigencia obligatoria; se revoca, no se borra; monto en centésimos enteros |
| Token | Lo que el comercio usa para cobrar | Opaco y acotado al comercio; el mandato se evalúa en cada cobro, no solo al emitirlo |
| Autorización de agente | Qué agente puede pedir en nombre del usuario | Pieza separada del mandato; sin ella la llave no habilita a ningún agente |
| Evidencia | Registro de qué se autorizó y qué se intentó | Append-only y encadenado por hash: si se puede editar, no sirve como prueba |
El paso innegociable
En el flujo humano, cuando el comercio presenta la llave, LupsOne no entrega un token: crea una solicitud pendiente y le pregunta al usuario en su idioma — «Reponeme quiere cobrarte hasta $19.900 al mes, hasta el 3 de septiembre de 2027». Recién con su confirmación se emite el mandato firmado. Ese paso es lo que separa el producto de un sistema donde conocer la llave basta para cobrar, y es además la evidencia de consentimiento que exige la 21.719.
En el flujo agéntico el orden es el mismo, con tres verificaciones antes de emitir: que la firma del agente sea válida y venga del dominio que declara, que el usuario haya autorizado a ese agente, y que lo pedido caiga dentro del alcance autorizado. Si cae dentro, se emite sin molestar al usuario — eso es «Human Not Present». Si se pasa del umbral, se escala al humano.
Las cuatro superficies de front
| Superficie | Para quién | Qué es |
|---|---|---|
| lups.cl | Mercado | Web pública; vende a comercios |
| Consola del comercio | Cliente que paga | Sus mandatos, cobros, liquidaciones y tarifa |
| Consola LupsOne | Usuario final | Suscripciones, medios de pago, agentes autorizados, botón de cancelar |
| Componente embebido | Se inserta en el checkout ajeno | Donde el usuario crea su llave y confirma el mandato |
Compatibilidad con AP2
Escribir el mandato en formato AP2 desde el primer día no cuesta más y evita reescribirlo entero después. El día que un agente que habla AP2 llegue a Chile, el traductor es una capa fina y no una refundación.
| AP2 | LupsOne |
|---|---|
| Intent Mandate — el usuario aprueba restricciones para que el agente actúe después | lupsone_agente_auth |
| Cart / Checkout Mandate | lupsone_mandato tipo oneshot |
| Payment Mandate | lupsone_mandato tipo recurrente + credencial |
| Human Not Present | Rama agéntica que no escala al usuario |
Qué existe hoy y qué falta
| Pieza | Estado |
|---|---|
| Conexión a WebPay, OneClick y PAC | Existe |
| Tokenización de tarjeta vía OneClick | Existe — es la base del modelo de referencias |
| Ejecución del cobro | Existe |
| Cobro automático que funcione | Roto — 0 de 4 en Foodtag |
| Decisión de reintento con criterio | No existe |
| Enrutamiento entre medios | No existe — la tasa está hardcodeada al 3,57% en dos entidades |
| Mandato como objeto, token acotado, llave | No existe |
| Consola del usuario y evidencia append-only | No existe |
| Verificación de identidad de agente | No existe |
| Comercios con código propio | 3 de 21 |
| CI/CD en los 13 repos | No existe |
Plan de trabajo
Estructura acordada el 4 de septiembre de 2026. Las fases tienen dependencias reales: saltarse el orden cuesta caro.
Fase 0 — Fundaciones (en paralelo, ya)
| Tarea | Estado |
|---|---|
| BBP de Lups con git desde el día uno, para que no se pise entre sesiones | Hecho |
| Responder las decisiones L-01 a L-11; cuatro bloquean el diseño | Pendiente |
| Seguir la consulta pública del Banco Central sobre alias, QR y APIs (2S-2026) | Pendiente |
Confirmar quién tiene lups.cl hoy (resuelve a IPs de AWS) | Pendiente |
Fase 1 — Catastro: saber qué tenemos
Se hace con /junngla-squad:squad-onboard sobre Lups, que levanta el as-is en cuatro frentes en paralelo — arquitectura, datos, entrega e infraestructura — y cierra con veredicto del CTO. Debe cubrir dos cosas que no son código: los tokens OneClick ya inscritos, que son las primeras credenciales de LupsOne (no partimos de cero, partimos de una migración), y los mandatos PAC vigentes, que hay que representar en el modelo nuevo sin romperlos.
Fase 2 — Diseño
Cerrar la especificación v1 con las respuestas a las L- y lo que devuelva el catastro. Diseño de las cuatro superficies de front, empezando por el componente embebido, que es el que decide la conversión.
Fase 3 — Construcción por tramos
Cada tramo con /junngla-squad:squad-plan, y cada uno se vende solo. Si el mundo agéntico tarda tres años, los tramos 0 a 3 igual generaron ingreso.
| Tramo | Qué | Criterio de éxito |
|---|---|---|
| 0 | Que Lups se cobre sola: cobro automático con decisión de reintento | Foodtag pasa de 0 de 4 a cobrarse solo |
| 1 | El mandato: objeto, firma, evidencia append-only, revocación | Vendible como consentimiento trazable para el 1-dic y defensa de contracargos |
| 2 | La llave y la consola del usuario, embebidas en el checkout | El producto empieza a llamarse LupsOne hacia afuera |
| 3 | El enrutamiento: «que LupsOne elija» con criterio de costo | El modelo comercial empieza a rendir |
| 4 | El agente: Web Bot Auth, autorización de agentes, Human Not Present | Se construye cuando 1 a 3 están en producción |
Transversales que no estaban en la lista
| Tema | Por qué entra |
|---|---|
| CI/CD en los 13 repos | Cero hoy, con bus factor 1. El squad de AgentRoom montó gate y branch protection en un día; es replicable |
| Keycloak | Punto único de falla ya demostrado: tres días de login caído. Meterle usuarios finales sin resolverlo multiplica el radio |
| Migración de 18 comercios a código propio | Es condición del modelo y depende de Transbank: son plazos de terceros, arranca temprano |
| Legal con abogado | Términos, privacidad, contrato de enrolamiento y el mandato como documento válido, contra el 1-dic |
| PCI | Confirmar con un QSA el nivel real bajo el modelo de referencias |
| Marca y dominios | L-08 define si es marca propia o white-label, y eso cambia el diseño de las cuatro superficies |
Decisiones pendientes de Francisco
IDs estables con prefijo L-, para no chocar con P- ni A-. No se reciclan: si una se cierra, su número no se reutiliza.
| ID | Decisión | Bloquea |
|---|---|---|
| L-01 | Formato de la llave, y si se espera la consulta del Banco Central antes de congelarlo | Diseño |
| L-02 | Por dónde confirma el usuario un mandato: componente embebido, push, SMS o correo | Diseño |
| L-03 | Qué se le pide al usuario para crear su llave (nivel de KYC) | Diseño |
| L-04 | Autenticación del usuario: Keycloak actual, instancia separada u otra cosa | Diseño |
| L-05 | ¿Se exige código de comercio propio para enrolarse? Hoy 18 de 21 no lo tienen | Negocio |
| L-06 | Cómo le cobramos al comercio si no descontamos del flujo | Negocio |
| L-07 | Redefinir el corte de los planes: mandatos activos en vez de suscriptores | Negocio |
| L-08 | ¿Marca propia LupsOne o white-label del comercio? | Negocio |
| L-09 | Política de retención: la tensión entre supresión y evidencia obligatoria | Legal |
| L-10 | Nivel de PCI real bajo el modelo de referencias — confirmar con un QSA | Legal |
| L-11 | Quién responde si un cobro sale mal dentro de un mandato válido | Legal |
Riesgos del modelo
| Riesgo | Lectura |
|---|---|
| Conversión | Un paso extra en el checkout cuesta ventas. Si el flujo embebido no es fluido, ningún comercio lo adopta. Es el riesgo que mata el producto |
| Confianza | Junngla no tiene marca de consumidor. Nadie deja su medio de pago con alguien que no conoce |
| Concentración | El 85% del volumen de Lups es un solo comercio. Si Simplee se va, la base de pruebas desaparece |
| RedPay | El precedente propio: la interoperabilidad técnica no basta sin adopción. La defensa acá es que LupsOne no necesita que nadie coordine — cada comercio que se enrola trae sus propios usuarios |
Ley 21.719 — Protección de datos personales
Vigencia plena: 1 de diciembre de 2026. Checklist de cumplimiento del proyecto (responsable general: P-03).
Mapa de datos que trata el proyecto
| Dato | Finalidad | Base de licitud | Sensible |
|---|---|---|---|
| Identidad del suscriptor (nombre, email, teléfono) | Gestión de la suscripción y comunicaciones | Contrato | No |
| Datos de tarjeta / medio de pago (tokenizados) | Cobro recurrente y recuperación | Contrato | No (dato financiero, alta protección) |
| Dirección de despacho | Envío de productos físicos | Contrato | No |
| Historial de pagos y comportamiento | Reintentos inteligentes (LupsDunning) y métricas | Interés legítimo / contrato | No |
Checklist de cumplimiento
| Ítem | Estado | Responsable |
|---|---|---|
| Consentimiento y avisos de privacidad | En curso | P-03 |
| Derechos del titular (ARSOP + bloqueo) | Pendiente | P-03 |
| DPA con proveedores / encargados (procesadores de pago, carriers) | Pendiente | P-03 |
| Registro de actividades de tratamiento (RAT) | Pendiente | P-03 |
| Protocolo de brechas | Pendiente | P-03 |