PayPhone Proxy: pensar fuera de la caja

PAYPHONE // STORE_ID // PENSAR_FUERA_DE_LA_CAJA

No estaba buscando construir un gateway de pagos. Solo quería seguir construyendo.

Con los agentes de desarrollo, muchas ideas que antes se quedaban en mi cabeza ahora pueden convertirse en proyectos funcionales. Ninguno de ellos ha sido exitoso todavía, al menos no en el sentido comercial. Eso no me quita las ganas de seguir probando. Si aparece una idea, quiero poder abrirla, construirla y descubrir después si tenía futuro.

El problema es que PayPhone Developer me permitía crear como máximo tres aplicaciones.

No necesitaba más aplicaciones porque ya tuviera ventas

Necesitaba más espacio porque mi forma de trabajar es convertir ideas en experimentos reales.

En mi ecosistema hay proyectos de naturaleza completamente distinta:

• PachaPixel, dedicado a la preservación digital del patrimonio arqueológico ecuatoriano mediante drones, fotogrametría y modelos 3D.[7]
• nexOS, un sistema operativo comercial para MiPyMEs ecuatorianas que conecta facturación, CRM, canales de comunicación, pagos y automatización.[8]
• Lineage2.tuxevil.com, un servidor competitivo de Lineage 2 centrado en PvP, sin grind y sin pay-to-win.[9]
• LeadPulse, una plataforma de inteligencia comercial y prospección B2B en Ecuador.[10]
• PawPaw, una plataforma de identidad persistente para mascotas, todavía en pruebas.
• Juzgado de lo Absurdo, un juego multiusuario para WhatsApp que convierte conflictos cotidianos en juicios interactivos de comedia, también en pruebas.

Cuatro proyectos están desplegados e integrados en ambientes productivos, aunque todavía esperan sus primeras transacciones. Los otros dos siguen en pruebas. No estaba administrando seis negocios maduros. Estaba intentando no cerrar el abanico de oportunidades antes de saber qué proyecto podía encontrar su lugar.

PayPhone, dentro de todo, me pareció una plataforma práctica. En pocos minutos podía tener una cuenta lista para cobrar desde mis aplicaciones. Deuna, por su lado, se presenta como una plataforma para conectar múltiples proveedores, herramientas antifraude y métodos de pago mediante una sola integración.[11] Mi experiencia actual ha sido distinta: llevaba aproximadamente dos semanas intentando conseguir acceso a sus APIs sin tener todavía una respuesta. No uso esa experiencia para decir que una plataforma sea universalmente mejor que la otra. Es simplemente la diferencia entre una integración que pude empezar rápido y otra que todavía estaba esperando.

El límite llegó antes que el mercado

Contacté a PayPhone para pedir más aplicaciones. Seguí el procedimiento, expliqué que tenía distintos proyectos personales, entregué los dominios y envié la documentación que me solicitaron.

La respuesta fue negativa: todavía no tenía historial transaccional suficiente para justificar el aumento. Este punto forma parte de mi experiencia con la cuenta y no de la documentación pública de PayPhone.

La respuesta tenía lógica desde el punto de vista del proveedor. Yo estaba pidiendo capacidad adicional para proyectos que todavía no habían demostrado volumen. Pero también dejaba una contradicción práctica: justamente porque estoy construyendo y probando proyectos nuevos, todavía no puedo demostrar el historial que justificaría poder construirlos.

No necesitaba una solución para escalar millones de pagos. Necesitaba una solución para no quedarme limitado a tres experimentos.

Cambiar el eje: aplicación, token y tienda

Mientras revisaba cómo funcionaba PayPhone, entendí que el token de la aplicación no era la única dimensión importante.

El token sigue siendo crítico: es la credencial con la que el servidor habla con PayPhone y no debe repartirse entre proyectos ni exponerse al navegador. Pero, en la experiencia visible para el comprador, el StoreID tenía un peso distinto. El nombre de la tienda y la imagen que PayPhone mostraba antes de pagar cambiaban según el StoreID seleccionado.

Ahí apareció la idea: una aplicación de pruebas y una aplicación de producción podían centralizar el flujo de varios proyectos propios, mientras cada proyecto se distinguía por su tienda.

Yo ya tenía seis StoreID y, hasta ahora, no había encontrado un límite equivalente. Eso es una observación de mis pruebas, no una afirmación de que PayPhone permita una cantidad ilimitada de tiendas. Lo importante era que cada identificador mostraba la identidad correcta frente al usuario final.

Empecé a implementar el proxy en ese mismo momento. La verificación visual de los nombres e imágenes llegó después, como confirmación de que la dirección era correcta.

No evadí el límite de PayPhone

Conviene decirlo claramente: payphone-proxy no crea aplicaciones adicionales, no inventa permisos y no intenta saltarse las reglas de PayPhone.

Uso las aplicaciones que ya tengo, los StoreID autorizados y el flujo oficial de PayPhone Button. La documentación distingue las aplicaciones WEB usadas para Button de las aplicaciones API utilizadas por otros productos, y no asumí que una credencial WEB habilitara automáticamente todo el catálogo.[4][5][6]

El proxy tampoco reemplaza PayPhone. Es una capa alrededor del proveedor. Cambié la arquitectura de mis proyectos, no las capacidades de la plataforma.

Una API propia para no repetir la integración

La configuración de proyectos y tiendas es pequeña: vive en variables de entorno. La parte útil está en la lógica interna.

Los proyectos consumidores llaman a una API propia. El proxy autentica al proyecto, selecciona el alias de tienda, prepara el pago ante PayPhone y devuelve una URL de checkout. El checkout central se sirve desde el dominio WEB registrado. Después PayPhone retorna al proxy, el proxy confirma la transacción y valida que los identificadores, el importe, la moneda y la tienda correspondan con la operación original.[2][3]

El proyecto nació implementando primero esa API propia. No quería que cada aplicación conociera el token de PayPhone ni que cada una tuviera su propia versión del flujo de preparación, checkout, retorno y confirmación.

El resultado no es una dependencia plug-and-play. Cada proyecto necesitó adaptación para hablar con la nueva API. Pero tampoco fue una migración complicada: quitar credenciales directas, reemplazar el cliente de PayPhone por el cliente del proxy y verificar el flujo.

La arquitectura real de mis proyectos

La separación quedó así:

Proyecto	Estado	Integración
PachaPixel	Producción, esperando primeras transacciones	payphone-proxy común
Lineage2.tuxevil.com	Producción, esperando primeras transacciones	payphone-proxy común
LeadPulse	Producción, esperando primeras transacciones	payphone-proxy común
nexOS	Producción, esperando primeras transacciones	Proxy propio para tokens de sus tenants
PawPaw	Pruebas	Todavía no publicado como integración productiva
Juzgado de lo Absurdo	Pruebas	Todavía no publicado como integración productiva

nexOS es la excepción importante. No lo trato como un consumidor más de payphone-proxy, porque cada tenant puede manejar sus propios tokens y credenciales de PayPhone. Para mantener esa independencia utilicé la tercera aplicación disponible en mi panel de Developer y conservé un proxy propio.

Eso también define el alcance real del proyecto. payphone-proxy no intenta ser un gateway universal ni resolver pagos para comercios ajenos. Resuelve un caso concreto: varios proyectos personales que cobran para el mismo comercio y pueden separarse mediante sus tiendas configuradas.

El beneficio inmediato: dejar de copiar secretos

La ventaja práctica apareció antes de cualquier transacción real.

Dejé de copiar y pegar tokens de PayPhone en cada proyecto. Las credenciales quedaron centralizadas. La lógica de pagos, idempotencia, checkout, callback y estados quedó en un solo lugar. El navegador nunca recibe el token del proveedor y los proyectos sólo conocen su propia clave interna.[2][3]

Los tres consumidores comunes ya están desplegados en producción. Todavía esperan sus primeras transacciones, así que no voy a inventar métricas de ventas ni presentar esto como un sistema probado a escala. Lo que sí puedo decir es que la integración está montada, los ambientes están separados y las pruebas del flujo funcionaron dentro del caso que necesitaba.

Hasta ahora tampoco he encontrado una limitación funcional de payphone-proxy para ese caso de uso. Eso no convierte al proyecto en universal. Significa que, dentro de mis necesidades actuales, la solución está haciendo exactamente lo que esperaba.

Por qué lo abrí

Cada vez me acerco más a la filosofía open source.

No veo una ventaja competitiva secreta en este proxy. Tampoco me parece una pieza tan difícil de replicar. Si alguien necesita resolver lo mismo, prefiero compartir una implementación que ya funciona antes que observar cómo cada persona construye su propio clon desde cero.

Además, yo mismo tengo montones de forks de proyectos ajenos. Buena parte de lo que construimos existe porque alguien decidió publicar una herramienta en lugar de guardarla. Abrir payphone-proxy es devolver un poco de esa misma lógica.

Lo construí para resolver mi problema. Lo mantengo y decido su rumbo. Pero si a alguien más le sirve, puede usarlo, abrir un issue o proponer un pull request.

El repositorio está publicado bajo la licencia MIT y documenta el flujo, la configuración, la seguridad y las limitaciones conocidas del diseño.[1][2]

Pensar fuera de la caja

PayPhone me puso un límite de tres aplicaciones. No pude ampliarlo porque todavía no tenía historial transaccional. La salida no fue insistir indefinidamente ni buscar una forma de engañar al proveedor.

La salida fue mirar el problema desde otro ángulo.

No necesitaba una aplicación nueva por cada idea. Necesitaba una capa común para los proyectos que compartían comercio, y una forma de distinguirlos sin repartir secretos. El StoreID ya existía. La API propia y el proxy fueron la estructura que faltaba alrededor.

No es magia. No es una arquitectura revolucionaria. Es una solución sencilla que apareció cuando dejé de aceptar que el límite de aplicaciones tenía que convertirse también en el límite de mis proyectos.

La curiosidad también necesita infraestructura. Y cuando una solución personal puede ayudar a alguien más, no veo mucho sentido en esconderla.

Sources

[1] https://github.com/tuxevil/payphone-proxy — tuxevil/payphone-proxy [2] https://raw.githubusercontent.com/tuxevil/payphone-proxy/main/README.md — PayPhone Proxy README [3] https://raw.githubusercontent.com/tuxevil/payphone-proxy/main/docs/api.md — PayPhone Proxy HTTP API [4] https://raw.githubusercontent.com/tuxevil/payphone-proxy/main/docs/payphone-official-research.md — investigación oficial de PayPhone incluida en el proyecto [5] https://docs.payphone.app/configuracion-de-ambiente-y-credenciales — PayPhone configuration and credentials [6] https://docs.payphone.app/boton-de-pago — PayPhone Button [7] https://pachapixel.ec — PachaPixel [8] https://nexos.ec — nexOS [9] https://lineage2.tuxevil.com — Lineage 2 Battle Tournament [10] https://leadpulse.tuxevil.com — LeadPulse [11] https://deuna.com — DEUNA