Registro de cambios

Cuando la confirmación de pago no puede abrir un pago en el token y la red que eligió el cliente, ahora devuelve un único 503: payment_method_unavailable. Sustituye a no_available_address, address_lease_failed, bridge_unavailable y collection_disabled.

La situación era la misma en los tres casos: ese token en esa red no puede aceptar un pago ahora mismo, y reintentar o elegir otro suele funcionar. Lo que los tres nombres añadían encima era una descripción de nuestra propia maquinaria, enviada al navegador de un comprador en tu página de pago. Los mensajes hacían lo mismo; ahora son idénticos sea cual sea la causa.

No se bifurca nada: no había ningún caso en el que los tres antiguos te llevaran a hacer cosas distintas. Los motivos se siguen registrando de nuestro lado, que es donde le sirven al soporte.

Si tu integración se bifurca según alguna de las tres cadenas antiguas, cámbiala ahora. Ya no se emiten y no hay periodo de transición en el que lleguen las dos. El enlace type del sobre de error sigue al nombre nuevo, así que un enlace guardado a un ancla antigua no abrirá nada.

La lista completa está en Códigos de error.

El 503 que devuelve un retiro cuando la red de destino no puede pagar ahora es withdrawal_network_unavailable. Antes era hot_wallet_insufficient_liquidity.

Cuándo aparece no cambia: mismo endpoint, mismo 503, misma situación — este token no se puede liquidar en esta red ahora mismo, y con otra red o más tarde suele salir. Lo que cambia son el nombre y el mensaje, que describían nuestro lado del pago en vez del tuyo.

Si tu integración se bifurca según la cadena antigua, cámbiala ya. El código antiguo ya no se emite y no hay periodo de transición en el que se envíen los dos. El enlace type del sobre de error sigue al nombre nuevo, así que un enlace guardado al ancla anterior no resolverá.

La lista completa está en Códigos de error.

Los importes del panel se muestran ya recortados a una longitud que se abarca de un vistazo, con la cifra completa a un cursor por encima. Una columna de saldos vuelve a estar alineada, en vez de terminar con un número de decimales distinto en cada fila.

Cuántos decimales se enseñan se decide token por token, y no en la dirección que parece: una stablecoin anclada al dólar se lee entera con dos, mientras que XAUT, respaldado en oro, pide seis. Cuanto más vale una unidad, más decimales hacen falta para que el último siga pesando lo mismo. En el libro mayor no se redondea nada — la forma corta es presentación, y debajo sigue estando la cifra entera.

Pagar a un destinatario y pagar a muchos de una vez eran dos pantallas distintas del panel. Ahora es el mismo diálogo: eliges un pago suelto o una tanda, lo repasas todo sin cambiar de sitio y envías. Aprobar las direcciones de esa tanda ocurre ahí dentro, y no de una en una.

Un pago que ya salió se repite desde el historial de retiros. La transferencia de todos los meses al mismo proveedor deja de pasar por teclear otra vez una dirección que ya usaste y que ya tenías aprobada.

Dos detalles que se notan enseguida: el historial muestra la etiqueta del destinatario, y cuántos destinatarios admite todavía la tanda aparece junto a la etiqueta del campo, antes de enviar. El diálogo descuenta del límite de la cuenta los pagos que ya van en camino, así que el número que ves en pantalla es el que te queda — no el que descubres luego en un rechazo.

Los canales de pago, sus webhooks y el flujo de depósitos entran en los ocho clientes oficiales: .NET, Go, Java, PHP, Python, Ruby, Rust y TypeScript. La firma, los reintentos y los errores tipados quedan del lado del SDK, y cada README trae el flujo entero en lugar de una lista de métodos.

El lector del flujo se comporta igual en los ocho, y esa es la propiedad que conviene decir en voz alta: mientras conserve su cursor, no puede saltarse un pago liquidado. Reanuda donde lo dejaste y cada depósito aparece exactamente una vez, le pase lo que le pase al proceso por el camino.

La lista de tokens de un canal ya no son símbolos sueltos. Cada entrada viene con su minimum_deposit: la transferencia más pequeña que esa ruta abona. El mínimo es del token y de la red a la vez, nunca de uno de los dos por separado: el mismo símbolo trae un suelo distinto en cada ruta en la que vive.

Enséñalo junto a la dirección, y tómalo de la respuesta que estás renderizando en ese momento: la cifra se calcula en cada lectura y no se fija en el código. Lo que llega por debajo del mínimo no se abona ni vuelve solo.

Un cambio emparejado: el proyecto acepta ya símbolos de token en lugar de parejas de red y símbolo. Activar una red deja de obligarte a aprobar otra vez, dentro de ella, todos los tokens que ya aceptabas.

Crear un proyecto trae ahora una pregunta que antes eran tres interruptores sueltos: por dónde cobra. Cinco respuestas posibles. Tu backend llama a la API; el cobro ocurre dentro de un bot de Telegram; un plugin lleva la tienda; la persona en caja cobra en el Terminal; o el Low-Code SDK cobra dentro de tu propia página.

Lo que respondas decide lo que el proyecto te enseña después. En uno de bot, el inicio rápido termina dentro de Telegram; en uno de plugin desaparece el fragmento incrustable que nunca ibas a pegar en ningún sitio.

La respuesta no se edita más adelante, y esa es toda la regla: un proyecto que necesita otra vía es otro proyecto. El terminal POS estrena además dirección: /pos responde con un 308 hacia /terminal.

Tu cliente copia una dirección hoy y la reutiliza el resto del año. Eso es un canal de pago: una identidad de depósito permanente, abierta para un solo pagador, con una dirección propia y duradera en cada red admitida. No lleva importe, no vence y no termina en ningún estado. Lo que entre por cualquiera de esas direcciones se anota como depósito y suma a tu saldo.

El canal se abre contra tu external_id, el identificador que ese cliente ya tiene en tu base de datos. Proyecto más id externo es la clave de idempotencia, sin nada más que generar ni que guardar: llama a crear cuantas veces quieras y la repetición te devuelve el canal que ya existe en vez de abrir un segundo. Bloquearlo corta la entrada de depósitos y no borra nada.

Los depósitos se leen aparte, en un flujo que solo trae pagos confirmados, del más antiguo al más nuevo, detrás de un cursor que nunca retrocede. Mientras el lector conserve su posición, no se le escapa ningún pago liquidado: cada uno aparece exactamente una vez. Una página vacía no es el final del flujo — el cursor avanza igual aunque no traiga nada, así que quien se detiene ahí se detiene antes de tiempo. El sandbox simula depósitos para probarlo antes de tener el primero de verdad.

Empieza por Crear un canal.

Si lees esto en español, ya no hace falta saltar al inglés. Entran hoy el español y el alemán, y no solo en las páginas de marketing: la página de pago que ve tu cliente, el panel, los correos, los avisos del bot de Telegram y los plugins de tienda hablan los dos.

El cliente elige el idioma en la propia página de pago. Aterrizar en el que no le toca no obliga a reiniciar el cobro ni a emitir otra factura.

El turco y el chino simplificado llevaban en producción desde el 20 de julio. Con estos dos últimos, el producto entero funciona en seis idiomas: español, alemán, inglés, ruso, turco y chino simplificado.

Un proyecto ya se puede marcar como bot de Telegram. En ese proyecto la factura no devuelve la dirección de una página alojada: devuelve un enlace que abre el bot de Paymos, y la conversación es donde el cliente elige qué token envía y por qué red.

A partir de ahí el bot enseña lo mismo que enseñaría una página. El código QR generado, la dirección con su botón de copiar y el tiempo que queda para pagar, sin empujar a nadie al navegador ni pedirle que se cree una cuenta.

Los cambios de estado caen en ese mismo chat. Quien pagó y cerró la aplicación se encuentra el desenlace de la factura donde ya estaba hablando contigo.

Actívalo en Pago en Telegram.

Recomienda un comercio y llévate parte de la comisión de procesamiento de Paymos que genere. Cuatro niveles van del 20 % al 40 %, con saltos en 5 y en 20 comercios activos; el nivel más alto se concede bajo solicitud y no por umbral.

La parte se abona en cada factura que liquide el comercio recomendado, en el momento en que liquida: ni al mes, ni en un calendario de pagos, ni cuando se supere algún mínimo. No hay tope de volumen ni tope de comisión total. Un cambio de nivel se aplica a toda la cartera, no solo a los comercios recomendados a partir de entonces.

La comisión sale de la comisión de Paymos en vez de sumarse encima, así que lo que paga un comercio recomendado es lo que paga cualquier comercio.

Tu enlace y tu nivel actual están en Programa de socios.

La página de analítica responde a tres preguntas: cuánto entró, qué parte de las facturas se pagó y cuánto tardaron los pagadores en pagarlas.

La conversión se calcula solo sobre una cohorte madura: las facturas cuyo desenlace ya se puede observar. Una factura creada hace veinte minutos no ha fracasado, y contarla como impagada hundiría la tasa sin motivo y haría que cada hora recién empezada pareciera un incidente.

El tiempo hasta el pago es una distribución, no una media: de 0 a 5 minutos, de 5 a 10, de 10 a 15, de 15 a 20, y 20 o más. El volumen se desglosa por token, por red y por proyecto: los cinco primeros de cada uno, no la lista entera. La actividad de facturas se agrupa por día de la semana y por hora, en la zona horaria que elijas.

Ábrela en Analítica.

Las acciones privilegiadas se registran con el actor, la acción, el objetivo, el resultado y la hora. Las del comercio y las del operador, en un mismo registro.

Cada entrada nombra la acción de forma explícita —merchant.add_whitelisted_address, operator.engage_freeze— y guarda una foto de quién era el actor en ese momento, con su rol incluido. Un ascenso el mes que viene no reescribe lo que hizo un Observador en marzo.

Los datos sensibles se ocultan al escribir, no al leer. Los secretos, los tokens, los hashes y las firmas se quitan antes de guardar el registro, así que el registro de auditoría no puede convertirse más adelante en el sitio por el que se filtre una credencial.

Lo que ve un comercio es el historial de su propia cuenta, con la actividad de inicio de sesión, el dispositivo y la IP incluidos. El registro completo de la plataforma sigue siendo solo para operadores: contiene acciones de otros comercios, y no hay ninguna forma segura de enseñarlo.

Los eventos de cuenta y de dinero llegan ya al comercio por dos canales. Cada aviso existe como correo y como mensaje de Telegram, a partir del mismo evento, así que conectar Telegram añade una vía de entrega sin silenciar el buzón.

El movimiento de dinero está cubierto —un retiro creado, un retiro completado— junto con los cambios en el equipo, las entregas de webhook que se dieron por vencidas y el bloque de seguridad: el 2FA activado o desactivado, una passkey añadida o eliminada, un método de acceso vinculado, una dirección de la lista blanca añadida o revocada, un secreto de API rotado, una credencial anulada.

Las categorías rutinarias las apagas tú. Las de seguridad no, y no hay ningún ajuste que las esconda: que te avisen de que ha cambiado tu dirección de retiro compensa de sobra un correo que no querías, mucho más que al revés. El SMS no es un canal aquí.

Todos los endpoints que fallan responden con la misma forma: Problem Details de RFC 9457, servido como application/problem+json.

El campo por el que ramificar es code, una cadena estable cuyo significado no cambia una vez publicado. title y detail están escritos para personas y pueden reformularse, ampliarse o traducirse de una versión a otra, así que una integración que interpreta detail es una integración que se rompe con una corrección de estilo. Los errores de validación de un solo campo llevan field; cuando fallan varios campos a la vez, en su lugar viaja un array errors[] con el desglose campo a campo.

type enlaza directamente con la fila de la documentación de ese código exacto, lo que convierte una cadena desconocida dentro de un log en un solo clic. La lista completa está en /docs/errors/codes.

external_order_id es la clave de idempotencia. Mándalo al crear una factura y una llamada repetida devuelve la que ya existe en lugar de crear una segunda.

No hay ninguna cabecera Idempotency-Key que generar y guardar, porque el identificador que ya tienes —el número de pedido, el id del carrito, la referencia del retiro— es el que importa. Una factura nueva responde 201 Created; la repetición del mismo identificador responde 200 OK con la factura original. Los retiros funcionan igual, y ahí es donde esta propiedad se gana el sueldo: una llamada de pago reintentada devuelve el primer retiro en vez de mandar los fondos dos veces.

La unicidad tiene alcance por proyecto en las facturas y por comercio en los retiros. Que se agote el tiempo de espera de la red en tu lado pasa a ser algo que se reintenta, no algo que se investiga.

Cada credencial de API lleva su propia lista blanca: hasta 50 entradas, IPv4 o IPv6, direcciones sueltas o rangos CIDR. Una lista vacía significa que la credencial no está restringida por IP.

En una clave Payout el caso vacío no dura. Una credencial Payout recién generada permanece inactiva mientras no se añada al menos una dirección, así que una clave robada el mismo día en que se creó no tiene desde dónde llamar. Las claves Payment no llevan comprobación de IP: crean facturas, no mueven dinero.

Editar una lista blanca es una operación de autenticación reforzada y queda en el registro de auditoría con la lista completa tal y como quedó, no solo con lo que cambió. Ensanchar el cortafuegos que hay delante de una credencial que mueve dinero debería dejar constancia de quién lo ensanchó.

Las credenciales vienen en dos tipos. Una clave Payment (pk_) crea facturas y lee su estado; una clave Payout (rk_) crea y cancela retiros y lee saldos.

La comprobación del alcance es central, no ruta por ruta. El nivel de acceso se deduce del tipo de clave en cada petición, así que una clave Payment que se cuele en un paquete de cliente no puede mover fondos apunte a donde apunte: la petición se rechaza antes de que la vea un manejador, en vez de depender de que una ruta se acordara de comprobarlo.

Los secretos de API llevan el prefijo sk_, y los de firma de webhooks, whsec_. El entorno va también en el prefijo, lo que convierte pk_live_… y pk_test_… en dos cosas visiblemente distintas dentro de un archivo de configuración, y no en dos cadenas parecidas que alguien tenga que mirar con lupa.

Gestiónalas en Desarrolladores → Claves de API.

El TOTP se puede activar en cualquier cuenta: un código de seis dígitos de una aplicación de autenticación, que cambia cada treinta segundos.

El inicio de sesión es la mitad pequeña. La grande es la autenticación reforzada: una lista corta de operaciones que exigen un código nuevo en el momento de ejecutarse, en vez de dar por buena una sesión que pasó el 2FA una hora antes. Añadir una dirección de retiro, quitarla, editar la lista blanca de IP de una clave de API y desactivar el 2FA son ámbitos distintos, así que un código capturado para uno de ellos no autoriza otro.

Activarlo o desactivarlo manda un aviso de seguridad por correo y por Telegram, digan lo que digan las preferencias de notificación. Configúralo en seguridad de la cuenta.

Inicia sesión con una passkey: Face ID, Touch ID, Windows Hello o una llave de seguridad. WebAuthn y FIDO2, sin ninguna contraseña en todo el flujo, porque aquí nunca ha habido una contraseña que robar.

Una passkey es un par de claves. La mitad privada se queda en el dispositivo y no llega nunca hasta nosotros; el servidor guarda la mitad pública y verifica una firma sobre un reto que vale para un solo uso. De nuestro lado no hay nada que merezca la pena robar, y del tuyo no hay nada que teclear en una página de acceso falsa por convincente que sea.

En una cuenta se pueden registrar varios dispositivos, y añadir o quitar cualquiera de ellos dispara un aviso de seguridad que no se puede desactivar. El enlace mágico, Google y Telegram siguen funcionando: una passkey es otra puerta de entrada, no un sustituto de las demás.

Regístrala en seguridad de la cuenta.

El bot de Paymos lleva un hilo de soporte. Abre Consultas, escribe un mensaje y llega a los operadores que contestan desde el lado de la plataforma.

Es una conversación, no una cola de tickets. Las respuestas vuelven al mismo chat, los mensajes recientes se quedan a la vista y un segundo mensaje enviado antes de que el operador conteste no se entrega: el bot lo dice con todas las letras en vez de tragárselo en una cola que nadie está leyendo.

Estar vinculado a una cuenta de Paymos no es un requisito previo. Para un pagador, no estarlo es lo normal, así que quien se quede a medias en un pago puede preguntar por una factura sin tener cuenta; la vinculación solo importa en las partes del bot que muestran el estado de la cuenta.

Hay plugins publicados para WooCommerce, WHMCS, OpenCart, PrestaShop, Magento 2, Shopware 6, CS-Cart y Easy Digital Downloads.

Conectar es un clic, no un copiar y pegar. La tienda abre una pestaña de Paymos, el comercio aprueba la petición contra el proyecto que ya tenía seleccionado y el plugin recibe directamente las credenciales de ese proyecto. No se teclea nada sensible en un formulario de ajustes, y los valores guardados no vuelven nunca al navegador: un archivo de la versión que se filtre es idéntico para todos los comercios y no lleva ninguna clave dentro.

El estado del pedido viene del webhook firmado, nunca de que el comprador aterrice en la página de retorno. Una pestaña cerrada no puede perder un pedido pagado, así que la fuente de verdad es la llamada de vuelta y la URL de retorno es una cortesía.

Las guías de instalación de los ocho plugins están en /docs.

Plasma acepta USDT. Es la red principal número trece, que es donde está hoy la lista.

USDT es el único activo en ella. Un activo aparece en la página de pago sobre una red porque se activó ahí, no porque la cadena sea capaz de moverlo: lo decide el registro, red a red y token a token, y no se deduce nada del hecho de que exista un contrato.

Trece redes y cinco activos caben ya detrás de una sola llamada de creación de factura. Un comercio que integra hoy escribe la misma petición que quien integró en enero: la lista de redes es un dato, no una versión de la API.

Ya están publicados los clientes oficiales de TypeScript, Python, PHP, Go, .NET, Java, Ruby y Rust.

Cada uno cubre el contrato entero y no un subconjunto: facturas, retiros, saldos, hora del servidor, paginación por cursor, el formato de error, los reintentos, la firma de las peticiones y la verificación de webhooks. La firma es la parte que más justifica una biblioteca. La cadena canónica, la ventana de tiempo y el HMAC en base64 se tuercen con facilidad al escribirlos a mano, y un error sutil se presenta como un 401 sin nada más de lo que tirar.

La verificación de webhooks es una segunda firma con sus propias reglas, así que todos los verificadores toman los bytes en crudo de la petición antes de interpretar el JSON. Si les pasas un cuerpo reserializado, la comprobación falla, y hace bien.

Los repositorios, las etiquetas de versión y los requisitos de ejecución están en /docs/server-sdks.

XAUT se acepta en Ethereum. Es el primer activo de aquí que no es una stablecoin, y no debe leerse como tal.

Un XAUT representa una onza troy fina de oro en un lingote London Good Delivery, así que un saldo en XAUT sigue al metal y no al dólar. Para un comercio que prefiere tener oro antes que un derecho sobre dólares, ahí está el sentido. Y ahí está también la contrapartida: un saldo que se mueve en las dos direcciones, que no es para lo que sirve un token anclado al dólar.

Por dentro no tiene nada especial. Solo Ethereum, la misma política de confirmaciones escalonada por importe, el mismo saldo por activo y la misma lista blanca a la salida. El conjunto aceptado son ya cuatro stablecoins y un activo respaldado por oro.

Sui empieza a aceptar pagos, y USDC es el único activo en ella.

Sui no es EVM ni un fork de nada que ya estuviera en la lista. Sus direcciones son 32 bytes escritos como 0x más 64 caracteres hexadecimales: el doble de largas que una dirección EVM, algo que ya basta por sí solo para no mezclar las dos en los registros de un comercio. Su modelo de monedas tampoco se parece a un saldo ERC20, así que la detección de depósitos sigue su propio camino en vez de uno prestado.

Nada de eso se ve desde el comercio. Activa Sui en un proyecto y aparece en la página de pago junto a las demás; la factura, el webhook y el saldo se comportan igual que en cualquier otra red.

Se aceptan dos stablecoins más: USD1 en Ethereum y Solana, DAI en Ethereum.

No son el mismo tipo de instrumento. USD1 está respaldada por dinero fiat, igual que USDT y USDC. DAI se colateraliza en cadena con cripto en lugar de con un depósito bancario: otro modelo de respaldo detrás de la misma unidad en dólares, y conviene saber en cuál de los dos está denominado un saldo.

Ninguna de las dos se convierte al entrar. Una factura en DAI abona saldo en DAI y se retira en DAI, sin salto interno por USDT y sin margen por el camino. Con esto, el conjunto aceptado sube a cuatro stablecoins.

La política de confirmaciones lee ya dos entradas: la red y el valor en dólares de la factura. Una factura de 40 $ y otra de 40.000 $ en la misma cadena ya no esperan el mismo número de bloques.

Ethereum pide 2 confirmaciones hasta 100 $, 6 hasta 1.000 $, 12 hasta 10.000 $ y 32 por encima: unos 24 segundos en el tramo más corto y cerca de seis minutos en el más profundo. Tron pide 2, luego 6, y se detiene en 19, el estándar de solidificación de 19 de sus 27 superrepresentantes. Los recuentos de Arbitrum —40 / 120 / 240 / 800— parecen desmedidos solo porque sus bloques duran menos de un segundo: medidos en segundos reales, sus horizontes coinciden con los de Base y Optimism.

Las cadenas con finalidad nativa se saltan los tramos. BSC y Polygon confirman en la finalidad de la red; Solana, en el compromiso finalized; TON, en un solo bloque, porque allí cada bloque de la masterchain ya es definitivo.

Los recuentos son un valor de configuración y solo se mueven cuando los movemos nosotros. Los tiempos que salen de ellos, no: con la red congestionada los bloques llegan más despacio, así que cualquier cifra de aquí es una aproximación, nunca una garantía de liquidación.

Solana está en producción. En ella liquidan USDT, USDC y USD1.

Solana no cuenta las confirmaciones como una cadena EVM, y la plataforma no finge lo contrario. Los depósitos se escanean en el compromiso finalized y se confirman en cuanto aparecen ahí: un solo nivel, sin tramos por importe. Lo que finalized significa en Solana es exactamente lo que aquí significa un pago confirmado.

Las direcciones de depósito son claves públicas ed25519 en base58 y no cadenas 0x, así que en los registros de un comercio una dirección de Solana no se puede confundir con una de EVM. Los saldos se siguen agrupando por activo: el USDC cobrado en Solana y el cobrado en Base suman una sola cifra.

Avalanche ya acepta pagos. USDT y USDC liquidan los dos en la C-Chain.

Las direcciones y los hashes de transacción tienen forma EVM, así que un comercio que ya concilia Ethereum o Base no tiene nada nuevo que interpretar. Aquí la confirmación no va por tramos de importe: la finalidad de Snowman resuelve la cuestión de una vez para cualquier tamaño de pago, así que un depósito se abona cuando la cadena lo declara final. Es el trato de tramo único que reciben BSC y Polygon, no los recuentos de bloques escalonados que esperan Ethereum y los rollups.

Los retiros a Avalanche salen solo hacia direcciones que ya están en la lista blanca del comercio. La comisión de la ruta y su mínimo se ven antes de confirmar el retiro.

La plataforma corre ya con varias instancias. Los pipelines de bloques, los procesos de consolidación, los repartidores de webhooks y los procesadores de la outbox se coordinan mediante bloqueos de aviso de PostgreSQL: exactamente una instancia es la líder de una carga de trabajo dada en un momento dado.

Si la líder cae, otra instancia toma el bloqueo en el siguiente ciclo de sondeo. Sin cerebro dividido, sin procesamiento duplicado y sin conmutación manual. Los procesos están escritos para ser idempotentes por diseño: si el mismo rango de bloques se procesa dos veces por un relevo de líder, el resultado es idéntico a procesarlo una sola vez.

La base de datos es la única fuente de verdad del estado mutable. Las cachés en memoria solo se permiten para consultas inmutables (decimales de token, constantes de red). Todo lo que puede cambiar vive en PostgreSQL.

Las políticas de comisiones se configuran ya por proyecto, no solo por comercio. La comisión de plataforma de cada factura se calcula al crearla y queda fijada en la factura: lo que el cliente ve en la página de pago es lo que se liquida en cadena.

Dos mandos por proyecto: la comisión de plataforma (el porcentaje que se cobra al comercio) y el recargo al cliente (el porcentaje de esa comisión que se suma al importe mostrado y se cobra al pagador). Pon los dos a cero y el comercio lo absorbe todo; sube el recargo al 100 % y el cliente paga la comisión completa.

Las comisiones se guardan en la propia factura y no se recalculan después a partir del importe del depósito. Recalcular es una clase de error contable que no nos permitimos.

Los retiros que se quedan atascados en cadena —gas insuficiente, conflicto de nonce, expulsión del mempool— los detecta ya un watchdog dedicado que los empuja de forma automática.

En las cadenas EVM el watchdog usa reemplazo por comisión: si una transacción no se ha incluido pasado el tiempo configurado, se reenvía con un precio de gas más alto usando el mismo nonce. La original queda sustituida en el mempool sin cambiar la identidad de la operación.

La plataforma clasifica los errores de difusión en categorías accionables: revert (decide el handler), conflicto de nonce (reenviar con nonce nuevo), comisión demasiado baja (subida por RBF) y fondos insuficientes (avisar a operaciones). Cada clasificación se expone en el estado del retiro, así que no hay que adivinar qué salió mal.

Invita a compañeros de equipo a una cuenta de comercio sin repartir las credenciales maestras. Cada miembro recibe un rol que se despliega en un conjunto detallado de permisos, aplicados en el pipeline de autorización y no solo escondidos en la interfaz.

La gestión de retiros y de la lista blanca es por defecto exclusiva del rol Propietario. El rol Administrador gestiona facturas, webhooks, proyectos y la composición del equipo, pero no puede mover dinero sin una concesión explícita.

Gestiónalo en Ajustes.

Un entorno de Sandbox completo funciona en paralelo con producción. Mismo panel, misma superficie de API, base de datos separada, claves de firma separadas y endpoints de webhook separados: nada cruza la frontera.

En Sandbox puedes simular un pago sin tocar la red principal. Llama al endpoint de simulación con un valor de escenario (paid, overpaid, underpay, cancel) y la plataforma calcula el importe de depósito correcto y dispara exactamente los eventos de ciclo de vida que dispararía producción. Webhooks, firmas, calendarios de reintento: todo idéntico.

La idea es simple: lo que pasa las pruebas de integración en Sandbox sale a producción. Sin sorpresas del tipo «es que el entorno de pruebas es distinto». Cambia con el selector de entorno de la barra superior.

La página de pago alojada lleva ya la marca del comercio. Logotipo, estilo predefinido, color de acento, colores de fondo y de superficie y radio de las esquinas: se configuran una vez por proyecto y se aplican a todas las facturas que ese proyecto emite.

El constructor de widgets parte de esos mismos ajustes de marca: la paleta y el logotipo configurados pasan al widget incrustable, así que un sitio que ejecuta el fragmento de JavaScript se ve coherente con la página de pago alojada a la que enlaza.

Configura la marca en Formulario de pago. El constructor de widgets vive en Low-Code.

La entrega de webhooks usa ya un patrón outbox. Los eventos de dominio se escriben en la outbox dentro de la misma transacción de base de datos que cambia el estado de negocio, así que el evento queda registrado de forma duradera o el cambio de estado nunca ocurrió. Un proceso aparte recoge los eventos y los entrega.

Cada contenido se firma con HMAC-SHA256. La firma se calcula sobre los bytes del cuerpo en crudo más una cabecera con marca de tiempo, de modo que la protección contra reenvíos viene incorporada: quien recibe rechaza las firmas más antiguas que la ventana configurada. El secreto se puede rotar por endpoint desde el panel.

La entrega es al menos una vez. Un ciclo suma 11 intentos —el inicial y diez reintentos— con retardos que crecen desde un minuto hasta ocho horas, lo que da una ventana total de unas 16 horas. Quien recibe debe ser idempotente por el identificador del evento, que viaja en el contenido.

La plataforma incorpora ya un terminal tipo POS. Crea la factura con un clic y genera un código QR: la persona en caja acerca el teléfono al cliente, el cliente escanea y el pago aterriza en el saldo del comercio.

La página del terminal está pensada para tabletas y teléfonos, no para escritorio. Teclado grande para el importe, botón de Cobrar destacado y estado que pasa a confirmado en tiempo real en cuanto el depósito es firme. Un proyecto tiene una URL de terminal, y esa URL se abre en tantos teléfonos o tabletas como necesite el mostrador: nada que emparejar, ninguna configuración por dispositivo.

Ábrelo en /pos.

La API REST pública está en producción. JSON a la entrada, JSON a la salida y especificación OpenAPI.

Las credenciales tienen ámbito por comercio, entorno y tipo de clave, así que una clave de cobro y una clave de pagos son credenciales distintas con alcance distinto: una clave de cobro filtrada a un bundle de cliente crea facturas y nada más. Los límites de peticiones se cuentan por comercio con contadores de ventana fija respaldados por PostgreSQL: un único presupuesto, llegue la llamada por la clave que llegue, y sin estado de caché en el borde que mantener sincronizado.

El pipeline de autenticación es el mismo que protege el panel: cada endpoint lleva un atributo de permiso, la propiedad se verifica contra el ámbito de la credencial y el entorno se comprueba primero. La plataforma se niega a leer datos de sandbox con una clave de producción, sin excepciones.

Gestiona las credenciales en Desarrolladores → Claves de API. Documentación completa en /docs.

El constructor de widgets ya está en el panel. Monta un widget de pago de forma visual — colores, logotipo, redes admitidas, importe por defecto, comportamiento de la redirección — y ve cómo la vista previa se actualiza mientras lo ajustas.

El estado se codifica en la URL de la página, así que un widget configurado se puede compartir como un solo enlace. Opciones de exportación: un fragmento de JavaScript listo para pegar en cualquier sitio, o un iframe con dimensiones explícitas para controlar mejor la maquetación. El widget habla con un endpoint público estable, de modo que una integración desplegada no se rompe cuando publicamos cambios internos.

Abre el constructor en Low-Code.

Todos los comandos y consultas pasan ya por un pipeline tipado: registro → validación → autorización → reintento → transacción → handler. Cada paso es genérico sobre el tipo de la petición, así que añadir un comportamiento es un registro en el contenedor de dependencias, no una refactorización.

La autorización se compila al arrancar, no se resuelve por reflexión en cada petición. Cada comando lleva un único atributo que se asigna a un ámbito de permisos, a una comprobación de propiedad y a una guarda de entorno. Con las tablas compiladas, autorizar una petición es una consulta a un diccionario y no un recorrido de atributos.

La validación va primero porque rechazar una entrada mala antes de que toque la base de datos es el fallo más barato posible. La transacción es el último comportamiento antes del handler: los handlers no abren transacciones, las reciben.

Hoy sale la página de pago alojada. El cliente llega a una sola URL, elige la red desde la que quiere pagar, ve la dirección y el código QR, y la página se actualiza en vivo a medida que llega el depósito.

Cómo funciona por dentro: la página de pago es un host de Blazor aparte con su propio canal de SignalR. En cuanto el cliente elige una red, se toma prestada una dirección del pool de esa red en la plataforma y la página se suscribe a las novedades de esa factura concreta. Sin sondeo, sin recargar la página y sin botón manual de «comprobar estado».

Una sola factura cubre todas las redes que el proyecto tenga activas: se emite una vez y el cliente liquida en Tron, BSC o Polygon, la que tenga a mano. Es esa elección la que crea la dirección: antes no hay ninguna, después hay exactamente una, y el importe que se debe queda fijado contra esa elección.

Disponible en /invoice/{invoice-id}.

El panel del comercio está en producción. Construido sobre Blazor Server con renderizado en el servidor y un canal interactivo de SignalR: las novedades llegan a la interfaz sin sondeo y sin una base de código de frontend aparte.

Lo que entra en la primera versión:

• Resumen: volumen diario, tasa de éxito, eventos pendientes y depósitos recientes (Resumen →)
• Facturas: historial con búsqueda, filtros por estado, desglose por red y cronología del depósito (Facturas →)
• Saldos: saldos por token en vivo en todas las redes activadas, con el historial de retiros a la vista (Saldos →)
• Proyectos: ajustes por proyecto, redes y tokens activados y marca (Proyectos →)
• Claves de API: credenciales, endpoints de webhook y registro de eventos (Claves de API →)

El selector de entorno de la barra superior cambia entre Producción y Sandbox sin perder el punto donde estabas.

Una factura solo puede resolverse si la cadena ha avanzado más allá de su marca de vencimiento. Esto se impone en la capa de dominio: no como una comprobación repartida por los handlers, sino como un invariante que falla de forma ruidosa si se incumple.

Por qué importa: con una firmeza basada en confirmaciones, un depósito puede aterrizar «antes» del vencimiento desde el punto de vista de la cadena y ser observado por el pipeline «después» del vencimiento. Es una condición de carrera que, tratada con ingenuidad, produce cobros duplicados o pérdidas silenciosas de fondos. La plataforma sigue tanto el último bloque procesado como el último bloque firme, y la resolución espera a los dos.

Las pruebas de regresión de la suite machacan este invariante en cada commit. Aquí no nos permitimos publicar un error silencioso.

Los fondos que llegan a las direcciones de cada factura se consolidan ya de forma automática en las billeteras calientes, sin intervención del comercio. La consolidación corre como proceso en segundo plano y es una operación de plataforma: el saldo del comercio se abona en cuanto el depósito se confirma, no cuando se consolida.

En las cadenas EVM la consolidación tiene dos fases: primero una transacción que aporta el gas y después la transferencia del token. La plataforma paga ambas. En Tron, la plataforma cubre la comisión de red con su propio saldo, así que el comercio nunca ve una línea de gas. Las consolidaciones fallidas se reintentan con espera creciente; el watchdog detecta lo que se queda atascado y lo eleva a operaciones.

El resultado: el comercio recibe un saldo, no una billetera que mantener.

El subsistema de tipos de cambio está en producción. Las conversiones de cripto a fiat y de cripto a cripto se resuelven ya contra precios de mercado en vivo en lugar de consultas caducadas.

La fuente principal es CoinGecko, a la que se llega mediante un pool HTTP round-robin con espera creciente por endpoint cuando aparecen límites de peticiones. Las cotizaciones se guardan en memoria con un TTL corto: lo bastante largo para absorber la latencia de consultar el precio en la página de pago y lo bastante corto para seguir los movimientos reales. Un comercio que factura en EUR obtiene una cifra en USDT resuelta en el momento en que quien paga elige token y red, y ese tipo queda clavado en la factura: el mercado sigue moviéndose, el importe que se debe no.

Si una cotización se queda obsoleta, se recurre al último valor conocido; si el proveedor sigue sin responder pasada la ventana del TTL, las operaciones que dependen del tipo fallan de forma ruidosa en lugar de poner precio a ojo.

USDC se acepta ya en las seis cadenas EVM que admitimos: Ethereum, BSC, Polygon, Arbitrum, Optimism y Base. El registro de tokens guarda la dirección de contrato canónica en cada red, así que no hay forma de confundir el USDC nativo con una variante puenteada.

Los comercios pueden activar USDC proyecto a proyecto desde la página de ajustes del proyecto. Cada proyecto lleva su propia lista de tokens aceptados; las reglas de precios se aplican por token, no por proyecto.

TON se suma a la lista de redes. Con Tron, seis cadenas EVM y TON, la plataforma liquida ya en ocho redes desde una sola API.

La arquitectura de TON no se parece en nada a la de EVM. Las billeteras de contrato inteligente se despliegan por dirección, los jettons viven en sus propias parejas de contratos (maestro y billetera de cada usuario) y la firmeza pasa por conjuntos de validadores que rotan cada pocos segundos. Nuestro pipeline incorpora clientes RPC específicos de TON, derivación de billeteras de jetton y un parser de transferencias propio de TON.

Las transacciones de TON usan una ruta de firma compatible con Ed25519 en lugar del esquema secp256k1 de las redes ECDSA, y mantienen los mismos controles de destino de retiro y de auditoría que las demás rutas de Paymos.

Tres rollups L2 se suman a la lista de redes: Arbitrum One, Optimism y Base. Los tres comparten el pipeline EVM y heredan su prefiltro y su tratamiento de reorganizaciones.

El gas en los rollups es bastante más barato que en la L1 de Ethereum, lo que convierte la liquidación en USDC sobre Base o Arbitrum en una opción real para el comercio de ticket bajo. Los umbrales de confirmación se ajustan por cadena: Base y Optimism liquidan con la firmeza del secuenciador una vez alcanzada la profundidad de confirmación configurada.

Actívalos por proyecto en Proyectos.

Tres redes EVM salieron juntas: la red principal de Ethereum, BNB Smart Chain y Polygon PoS. Un único pipeline de bloques mueve las tres, y la estrategia de firmeza propia de cada cadena se enchufa por red.

La detección de depósitos usa eth_getLogs sobre una ventana deslizante, con un prefiltro por filtro de Bloom contra el registro canónico de tokens, de modo que solo pedimos los logs de los tokens que nos interesan. El tratamiento de reorganizaciones retrocede por los hashes padre, marca los bloques huérfanos y reproduce desde el nuevo punto de bifurcación.

Cada cadena tiene su propio pool de RPC con reparto round-robin y espera creciente por endpoint cuando aparecen límites de peticiones. Añadir una cadena EVM nueva es un cambio de configuración, no de código.

La primera stablecoin está en producción: USDT en Tron. Las facturas emitidas en USDT TRC20 se aceptan, se confirman contra la firmeza del bloque y se abonan en el saldo del comercio; las comisiones de consolidación las paga la plataforma, no el importe liquidado del comercio.

Los decimales del token se leen directamente del contrato al cargar el registro canónico. Los cálculos de importes trabajan sobre la unidad nativa del token, nunca sobre cadenas de texto de la interfaz, para que los errores de redondeo no se propaguen desde la pantalla hasta los libros.

La primera red está en producción. El USDT-TRC20 recorre Paymos de punta a punta: creación de la factura, detección del depósito, seguimiento de las confirmaciones y abono en el saldo.

El número de confirmaciones exigidas depende de la red y del importe del pago, así que no hay una cifra ni un tiempo únicos para cada factura. El pipeline de bloques lee de un pool de RPC propio con conmutación automática. La detección de depósitos usa un parser que lee primero la calldata en lugar de recorrer cada log emitido: más barato y más fiable.

Tron fue lo primero. El tramo más profundo espera a la solidificación —19 de los 27 superrepresentantes—, así que un pago por encima de 1.000 $ queda firme en torno a un minuto.

Los retiros solo pueden ir ya a direcciones controladas por el comercio y aprobadas de antemano. Una lista blanca vacía deshabilita las transferencias de salida en lugar de caer en un destino sin restricciones.

Los cambios sensibles en la lista blanca exigen autenticación reforzada y se escriben en el registro de auditoría. Las peticiones de retiro siguen siendo idempotentes, así que repetir la misma petición no puede generar un segundo pago.

El equipo de operaciones también puede detener todas las transferencias de salida o congelar una pareja concreta de activo y red mientras se investiga un incidente.

Un libro mayor por partida doble registra ya todos los movimientos de la plataforma. Depósitos, comisiones, liquidaciones, devoluciones, reversiones: cada uno queda cuadrado contra el otro lado del libro antes de confirmar la transacción.

El debe iguala al haber. La comprobación se ejecuta dentro de la misma transacción de base de datos que escribe los apuntes, así que un asiento descuadrado no puede aterrizar. La desviación entre el saldo del comercio y la realidad en cadena es una clase de error que no nos permitimos.

El libro mayor es de solo adición. Los ajustes se registran como transacciones nuevas que referencian a la original: el historial queda intacto y se puede reproducir.

La capa de dominio ya está en su sitio. Modelos ricos con setters privados, métodos de fábrica que validan cada entrada y objetos de valor para todo lo monetario.

Money es un objeto de valor atado a un token, no un decimal suelto. La aritmética entre tokens distintos falla de forma ruidosa en tiempo de ejecución y no se sostiene en tiempo de compilación: sumar USDT y TRX no es algo que compile ni se ejecute.

Las operaciones de negocio devuelven Outcome<T, Error> en lugar de lanzar excepciones. Las excepciones quedan reservadas para los errores reales del código. Los fallos previstos viajan por el pipeline como valores.

Hoy empieza el desarrollo de Paymos. El stack es .NET 10 con Blazor Server para la capa de host, PostgreSQL con EF Core 9 para la persistencia y MediatR para el pipeline de comandos y consultas.

El código se organiza en cuatro capas — dominio, aplicación, infraestructura y host — con inversión estricta de dependencias. El dominio no depende de nada. La infraestructura se adapta a los puertos definidos en la capa de aplicación. El host lo conecta todo.

Escribir primero la prueba es la norma, no la excepción. La CI ejecuta la suite completa en cada push.