¿Cuánto tarda un retiro en criptomonedas?

«¿Cuándo tengo el dinero?» tiene dos respuestas, y solo la primera sale de aquí.

Quien viene de cobrar con tarjeta trae la pregunta con vicios de fábrica: una fecha de corte, una liquidación que cae días después y una reserva que el adquirente suelta cuando le parece. Ninguna de las tres existe en esta ruta, y aun así la respuesta honesta no es un número.

La primera mitad no tiene duración que citar. El retiro arranca en cuanto lo pides: sin ventana de lote, sin calendario de pagos, sin cola de aprobación y sin nada retenido mientras alguien lo mira. Eso no es un récord de velocidad. Es la ausencia de una cola, que es otra clase de afirmación y aguanta mucho mejor el paso del tiempo.

La segunda mitad es de la cadena. Va al ritmo de la red que elegiste y del tráfico que esa red lleve encima esta tarde, y eso no es un tiempo de Paymos. Ninguna página de aquí cita un plazo de liquidación para esa parte, y el motivo es el resto de este artículo.

Aquí no hay fecha de corte

Al pedir un retiro, dos cifras dejan el saldo disponible y una transacción sale hacia la red.

El importe y la comisión de red de esa ruta pasan juntos a una retención. Por eso la página de saldos lleva Disponible y Retenido en líneas separadas: el retiro siguiente lo financia la primera y nada más.

Después se envía. En medio no se sienta nadie, porque no hay hora límite que perder ni quien tenga que aprobarlo. La red de destino la eliges al crear el retiro, entre las rutas habilitadas para ese activo, y una pareja de activo y red que no esté disponible en ese momento no aparece en el selector y se rechaza en la puerta en lugar de quedarse aparcada. Mientras eso sea así, tu saldo no se toca.

Por qué no verás aquí un plazo de liquidación

Porque el reloj que lo decide no es nuestro ni para arrancarlo ni para pararlo.

Tras difundir la transacción, la llegada es una propiedad de la red: cómo produce bloques, qué regla de finalidad tiene y cuánta carga lleva ese día. Publicar una cifra para eso es citar la infraestructura de otro como si fuera un compromiso nuestro.

Confundirlas cuesta poco, porque el comercio vive una espera y no dos. El dinero sale del saldo, pasa un rato, el dinero aparece en la billetera. Un procesador que anuncia retiros en menos de un minuto ha cogido la segunda mitad, la que no opera, y la ha impreso como promesa. Lo que sí puede afirmar con honestidad es la primera: que de su lado no hay nada esperando a nada.

La diferencia solo se nota un día cargado, que es exactamente el día en que un comercio va a buscar esta página. Quien prometió la ausencia de una cola sigue diciendo la verdad esa tarde. Quien prometió un minuto está explicándole una cadena a un cliente al que le dieron un número.

«Confirmado» no significa lo mismo en dos redes

Cada protocolo define la finalidad por su cuenta, y las definiciones no se parecen entre sí.

En Ethereum con prueba de participación el tiempo se corta en slots y en épocas. La finalidad se resuelve hoy a lo largo de dos épocas y no dentro de un solo slot, y la propia hoja de ruta lo dice al describir lo que viene: «El procesamiento más eficiente permitirá que la finalidad se determine dentro de un solo slot, en lugar de a lo largo de dos épocas».

Tron no mira un reloj, cuenta cabezas. Un bloque queda solidificado «once at least 19 distinct active SRs have each produced a block at that height or above», y a partir de ahí «it is no longer subject to fork choice».

TON resuelve la pregunta entera en un bloque: «TON achieves transaction finality after a single masterchain block confirmation», y «once a transaction from a shardchain appears in a masterchain block, it becomes irreversible».

Ahí hay tres objetos distintos vestidos con una misma palabra. Vistas desde el lado de entrada, las redes de Paymos ya están ordenadas por esa línea: seis de ellas —BSC, Polygon, Solana, TON, Avalanche y Plasma— liquidan un pago con la finalidad de la red y no por número de bloques, mientras que en el resto la política de confirmación la fijan la red y el importe del pago. Multiplicar cualquiera de esas reglas para sacar minutos lo sabe hacer cualquiera. Responder del resultado es otra cosa, y tampoco lo ha prometido la cadena.

Siete estados, tres finales y una ventana corta

Un retiro puede pararse en siete sitios y tres de ellos son el final.

En la API son created, signed, completed, failed, cancelled, pending_review y cancelling. Cada payload lleva además is_final, cierto exactamente para completed, failed y cancelled. Ramifica por la bandera y no por una lista de nombres que tengas que mantener a mano.

Los estados del medio describen nuestro lado del trabajo y ninguno es una barra de progreso. Uno conviene reconocerlo de un vistazo: pending_review se le enseña al comercio como Sin confirmar, que quiere decir que la red aún no ha confirmado el retiro y que el importe sigue en su retención.

Cancelar funciona mientras el retiro sigue en created y no ha empezado a ejecutarse; pasado ese punto, la llamada se rechaza. Una segunda cancelación sobre uno ya cancelado vuelve con 200 y el mismo retiro en lugar de un error, así que un cliente que reintenta no necesita ningún caso especial para eso. El endpoint se comporta igual.

Cancelar no es recuperar. Una transferencia que ya va por una cadena no se deshace desde este lado: el dinero vuelve como una transferencia nueva, mandada por quien recibió la primera. Lo que puede evitar que un retiro salga está todo antes de ese punto, y ahí entra la seguridad de la billetera caliente.

¿Qué cuesta un retiro que no llega a salir?

Nada en absoluto.

Un retiro que termina fallido o cancelado devuelve su retención entera: el importe y la comisión de red vuelven los dos a Disponible y por el camino no se descuenta nada de ninguno. A nadie se le cobra por una transferencia que no salió. En Sandbox la pregunta ni se plantea, porque allí no se apunta ninguna retención.

Quién se entera es donde tropiezan las integraciones. Un retiro fallido dispara su webhook —withdrawal.failed y withdrawal.cancelled están los dos en el contrato de eventos— y no manda ni un correo ni un aviso en la campana. Se entera el sistema; quien vigila un buzón, no. El aviso que sí ve el comercio es corto a propósito: el retiro no salió, la retención ya volvió a tu saldo, y ninguna de las dos frases viene con un motivo detrás.

Cincuenta destinatarios son cincuenta transacciones

No un lote que espera a que den las siete, y esa es la distinción que importa.

El panel manda una tanda de retiros: como mucho 50 destinatarios en un diálogo, un activo en una red, aprobados todos contra la lista blanca. Una tanda es cosa de Producción y no se puede ensayar en Sandbox, y cada ruta de retiro de la Merchant API sigue admitiendo exactamente un destinatario, así que esta forma pertenece al panel y no a la API.

Alrededor hay dos límites de cuenta y los dos se ven antes de mandar nada: un techo para el tamaño de un retiro y un tope de cuántos pueden estar en vuelo a la vez. Los huecos que te quedan vuelven al formulario antes de que hayas escrito nada, que es la diferencia entre un límite y un rechazo. Una tanda que pida más huecos de los que tiene libres la cuenta se rechaza entera, con las cifras dentro del mensaje.

En ninguna parte de eso hay una ventana temporal: nada junta los cincuenta para esperar a un reloj.

La red de salida la eliges tú

Es la única parte de la espera que se elige.

La ruta queda fija al crear el retiro, y la elección es más estrecha que la lista de redes en las que Paymos acepta pagos. Un retiro necesita un destino en lista blanca, y solo cuatro familias de direcciones admiten lista blanca: EVM, Tron, TON y Solana. Por eso se puede retirar a 11 de las 13 redes aceptadas, y por eso NEAR y Sui cobran sin poder recibir un retiro. Una sola entrada EVM cubre de golpe todas las redes EVM de salida, porque una fila de la lista va por dirección y familia en vez de por red.

El coste viaja con esa elección y no es el tema de esta página. Paymos no cobra comisión de procesamiento sobre un retiro; la comisión de red de la ruta se enseña antes de que confirmes, y se queda por debajo de lo que esa ruta cuesta de verdad. Esa cifra vive en la lista de precios.

Qué hacer con la espera en tu propio sistema

Seguir el estado y borrar el cronómetro.

• Ramifica por is_final. Viaja en cada payload, lo que te ahorra mantener a mano una lista de nombres de estado.
• Trata el webhook como el canal de aviso de los retiros, no como una comodidad. Un fallo no llega por ningún otro sitio por su cuenta: ni correo, ni campana. La entrega reintenta en escalera, así que un receptor que estuvo caído vuelve y se encuentra el evento.
• A tu propio cliente enséñale el estado y la red, nunca una cuenta atrás. Una cuenta atrás es una promesa sobre la cadena de otro, y quien la lea te la va a reclamar a ti.

El lado de entrada de esta pregunta tiene otra respuesta y otra forma. Lo que espera quien paga es una política de confirmación que se mueve con la red y con el tamaño del pago, y por qué varía esa espera es un artículo aparte. Dónde se queda el dinero entre las dos mitades, y por qué devolver una retención deja dos apuntes y no una resta, es trabajo del libro mayor.

Así que la versión honesta de la respuesta tiene forma en vez de duración. La mitad que opera un procesador termina antes de que haya nada que cronometrar, y la mitad que se lleva el tiempo es una cadena pública que liquida a su ritmo. Planificar con eso no cuesta nada. Lo caro es haberle dado un minuto a un cliente y tener que explicarle una red congestionada un martes por la tarde.