Cómo evitar pagos con criptomonedas en la red equivocada: guía de respuesta a incidentes para comercios

Una transacción puede estar confirmada en una blockchain y, aun así, no considerarse el pago solicitado por tu negocio. El cliente puede haber enviado el importe correcto del token correcto, pero a través de la red equivocada; un token distinto a la dirección esperada; un importe insuficiente; o fondos a una dirección que no guarda relación con el pago. Tu equipo de atención al cliente debe distinguir entre la prueba de que se realizó una transferencia y la prueba de que el pedido se pagó correctamente.

Esta es una guía operativa para comercios, no un tutorial para recuperar billeteras. Abarca la prevención, la recopilación de pruebas, la verificación en exploradores de bloques, la clasificación de incidentes, las solicitudes de reemplazo, la prevención de duplicados y la comunicación con el cliente. Las preguntas frecuentes para quienes pagaron mediante la red equivocada ofrecen una explicación breve para los clientes; esta guía indica al comercio qué hacer antes de responderles.

Una transacción confirmada no equivale a un pago reconocido

Una blockchain confirma una transacción conforme a las reglas de esa red. Tu proceso de pago solo reconoce el pago cuando la transferencia observada coincide con la solicitud y alcanza el estado de aceptación definido por tu negocio.

En un pago normal, verifica todos estos campos:

Campo	Qué debe coincidir
Referencia del pedido o pago	La solicitud abierta para ese cliente y esa compra
Red	La red seleccionada en el proceso de pago activo
Activo	El token o activo nativo exacto solicitado, incluido el contrato o la dirección de emisión cuando corresponda
Destino	La dirección receptora configurada para ese método de pago
Importe	El importe exigido por la solicitud y por tu política de tolerancia de importes
Resultado de la transacción	Debe constar como correcta en la red pertinente, no solo como enviada o pendiente
Estado de confirmación	El umbral o estado exigido por tu política de entrega
Unicidad	La transacción no debe haberse aplicado ya a otro pedido o acción de entrega

La referencia sobre confirmaciones en blockchain de Circle explica que las transacciones comienzan en estado pendiente, que el proceso de confirmación varía según la blockchain y que los bloques recientes pueden verse afectados por reorganizaciones. Por lo tanto, un hash, una captura de pantalla de una billetera o una página que muestre «correcta» constituyen pruebas que deben investigarse, pero no autorizan por sí solas la entrega.

Distingue los principales tipos de incidentes

Los clientes suelen describir cualquier discrepancia como «red equivocada». Clasifica los hechos antes de elegir una solución.

Incidente	Qué ocurrió	Respuesta del comercio
Red equivocada	Es posible que se haya enviado el activo esperado, pero a través de una red distinta a la seleccionada en la solicitud	Verifica la transacción en la red realmente utilizada; comprueba si se controla la dirección de destino y si el activo puede utilizarse en esa red; no prometas que se podrá recuperar
Token o moneda equivocados	Puede que la red sea correcta, pero el activo transferido no coincide con el solicitado	Verifica el contrato o la dirección de emisión del token y el destino; sigue el procedimiento para monedas equivocadas
Dirección equivocada	La transferencia llegó a una dirección distinta del destino indicado en la solicitud	Verifica ambas direcciones carácter por carácter; el comercio no puede revertir una transferencia que no recibió
Pago parcial	Se utilizó la ruta correcta, pero el importe recibido es inferior al requerido	Detén la entrega y sigue el procedimiento para pagos parciales; no improvises instrucciones para completar el importe
Confirmación demorada	La transacción coincidente está pendiente o no ha alcanzado el estado de confirmación exigido por el comercio	Mantén el caso pendiente, supervísalo y desaconseja un segundo pago hasta conocer el resultado
Pago duplicado	El cliente envió el pago más de una vez, o tanto la solicitud anterior como la de reemplazo se completaron correctamente	Realiza una sola entrega, conserva todas las transacciones y remite el cobro adicional para su revisión

No supongas que un símbolo conocido demuestra que el activo es correcto. Circle describe USDC como un dólar digital emitido en varias blockchains, mientras que Tether publica una lista actualizada de protocolos compatibles con los tokens de Tether. Esas listas de los emisores no determinan qué admite Yolfi, tu billetera o tu negocio. Ofrece únicamente las combinaciones exactas de activo y red que aparecen en tu configuración activa de Yolfi.

Evita el incidente antes de que el cliente firme

El mejor proceso para evitar errores de red comienza en la página de pago, no en atención al cliente.

Trata el activo y la red como un único método de pago

No etiquetes una opción solo como «USDC» o «USDT». Utiliza siempre una etiqueta combinada, como «USDC en [la red seleccionada]»: en la selección, la pantalla de revisión, las instrucciones del código QR, el traspaso a la billetera, el recibo, los registros de atención al cliente y las exportaciones de conciliación.

La guía para aceptar pagos con USDC y la guía para aceptar pagos con USDT explican por qué la elección de red forma parte del método de pago. Tus instrucciones públicas solo deben enumerar las combinaciones disponibles actualmente en el proceso de pago, no todas las redes en las que un emisor ofrezca un token.

Repite los datos esenciales en el momento de decidir

Antes de que la billetera firme, muestra:

el nombre y el símbolo exactos del activo;
el nombre exacto de la red;
el importe exacto;
la dirección de destino, con controles para copiarla;
la referencia del pedido o pago;
la regla de caducidad o plazo, si corresponde;
una advertencia para no elegir otra red aunque su dirección parezca similar;
una indicación para volver a la página de estado del pago después de enviarlo.

No digas a los usuarios que cambiar de red desplaza los tokens. Cambiar la red seleccionada en una billetera modifica la blockchain que esta muestra y con la que interactúa; no transfiere un saldo existente entre blockchains. Usar un puente o retirar fondos de una plataforma de intercambio sería una operación distinta, con sus propios riesgos y límites de asistencia.

Reduce las opciones innecesarias

Activa únicamente las opciones que utilizan tus clientes y que tu equipo puede atender. Cada combinación adicional incorpora otra dirección de liquidación, otro identificador de token, otro explorador, otra regla de confirmación y otra vía de excepción. Revisa las opciones disponibles en tu configuración activa y consulta el directorio de blockchains para acceder a las páginas de Yolfi específicas de cada red.

Realiza una prueba real de bajo valor para cada combinación activada. Confirma la etiqueta de la página de pago, el destino, el mensaje de la billetera, el registro del explorador, el cambio de estado, la notificación o el webhook, el registro de conciliación y el comportamiento de la entrega.

Prepara un expediente de pruebas del incidente

Solicita toda la información necesaria una sola vez. Las peticiones repetidas aumentan la demora y animan al cliente a intentar soluciones no autorizadas.

Pruebas que debe aportar el cliente

URL del enlace de pago o identificador de la referencia de pago;
referencia del pedido, la factura o la cuenta;
hash de la transacción y enlace a un explorador de bloques, si está disponible;
activo e importe que el cliente cree haber enviado;
red que seleccionó realmente;
dirección de la billetera emisora;
hora aproximada de la transferencia.

Pruebas del comercio

activo, red, importe y destino mostrados en la solicitud original;
marcas de tiempo de creación, caducidad, detección y cambio de estado de la solicitud;
dirección de liquidación configurada para la combinación solicitada;
notificaciones de pago pertinentes, identificadores de webhooks y resultados del procesamiento;
resultado del explorador correspondiente a la red utilizada, verificado de forma independiente;
mensajes del cliente e instrucciones emitidas por tu equipo;
referencias de pagos anteriores y de reemplazo vinculadas al mismo pedido;
acciones de entrega, abono, reembolso o acceso que ya se hayan realizado.

Una captura de pantalla puede estar alterada, desactualizada o proceder de la red equivocada. Úsala para localizar la transacción y después verifícala de forma independiente.

Verifica la transferencia en el explorador correcto

Comienza por la red que el cliente afirma haber utilizado, pero confírmala con los datos del explorador. Las indicaciones de MetaMask para envíos a un destino equivocado también recomiendan comprobar el estado de la transacción y el explorador de bloques antes de determinar qué ocurrió.

Abre un explorador de confianza para la red realmente utilizada.
Busca el hash completo de la transacción. No te fíes del texto visible de un enlace; confirma el dominio del explorador según tu procedimiento interno.
Comprueba si la transacción está pendiente, se completó correctamente, falló, se descartó o fue reemplazada.
Verifica las direcciones del remitente y del destinatario carácter por carácter.
Verifica el activo transferido. Si se trata de una transferencia de tokens, comprueba el contrato o la dirección de emisión, no solo el símbolo.
Confirma el importe bruto del token en el evento de transferencia. Obtén la precisión decimal por separado del contrato o la dirección de emisión canónicos, o de metadatos fiables del explorador.
Registra el bloque, la marca de tiempo, las confirmaciones actuales o el estado de finalidad, y cualquier registro pertinente.
Compara todos los campos con la solicitud de pago original.
Comprueba tu billetera de liquidación o su registro de supervisión en esa misma red.
Busca en los registros internos para asegurarte de que el hash no se haya reconocido ni aplicado ya en otro lugar.

La guía rápida para transferir USDC en redes EVM de Circle muestra por separado los pasos para elegir una red, enviar una transferencia, recibir un hash y consultarlo en un explorador. También señala que el remitente necesita el token nativo de esa red para pagar las comisiones de gas. Tómala como un ejemplo del funcionamiento de una transferencia, no como una lista de combinaciones disponibles en tu cuenta de Yolfi.

Utiliza un árbol de decisiones en lugar de prometer la recuperación

Sigue las ramas en orden.

1. ¿Existe una transacción válida en la red indicada?

No, o sigue pendiente: no completes el pedido. Pide al cliente que no vuelva a enviar el pago mientras lo supervisas o mientras su proveedor de billetera gestiona la transacción pendiente.
Falló o se revirtió: no se produjo ningún pago correcto en esa transacción. Confirma el estado en la billetera del cliente y en el explorador antes de emitir una solicitud de reemplazo.
Se completó correctamente: continúa con la comparación de campos.

2. ¿Coincide con la red, el activo, el destino, el importe y la política de confirmación?

Sí: procésalo mediante la vía normal de reconocimiento y el control idempotente de entrega.
No: remítelo a revisión como excepción. No lo marques manualmente como pagado solo porque se transfirió valor a algún lugar.

3. ¿Controla el comercio el destino en la red realmente utilizada?

No se ha determinado: no afirmes que los fondos se recibieron ni que pueden recuperarse. Remite el caso al propietario de la billetera o al custodio responsable de esa dirección.
Sí: confirma que el activo exacto existe en esa dirección y que puede gestionarse de forma segura conforme a tus procedimientos de billetera, seguridad, contabilidad y cumplimiento normativo. Controlar la dirección no convierte automáticamente la transferencia en un pago correcto del pedido original.
No: explica que tu negocio no puede mover fondos desde una dirección que no controla. Las preguntas frecuentes de asistencia de Ethereum.org señalan que un operador central no puede revertir las transacciones de Ethereum; si un servicio conocido controla el destino, su equipo de atención al cliente puede ser el contacto adecuado.

4. ¿Se ha aprobado alguna medida correctiva?

Entre los posibles resultados se encuentran reconocer la transferencia manualmente, solicitar un pago de reemplazo correcto, devolver los fondos accesibles mediante una nueva transacción, aplicar un abono documentado o rechazar la recuperación. La opción adecuada depende de la red, el control de la dirección, el token, el sistema de custodia, la capacidad técnica, los costes, los controles de riesgo y la política comercial.

Nunca digas que los fondos «siempre se pierden» o «siempre pueden recuperarse». MetaMask documenta un caso habitual en redes EVM en el que se puede acceder a la misma dirección de billetera desde otra red compatible con EVM, pero también describe casos sin recuperación garantizada. Esas indicaciones no demuestran que un comercio, una plataforma de intercambio, un contrato inteligente, una billetera multifirma o un sistema de pagos pueda acceder a una transferencia concreta o devolverla.

Emite enlaces de pago de reemplazo de forma segura

Cuando la solicitud original no pueda reconocerse y la política permita otro intento, crea un nuevo enlace de pago de Yolfi. No alteres el historial ni te limites a decirle al cliente que «lo intente de nuevo».

La solicitud de reemplazo debe:

conservar el mismo identificador de pedido o factura;
recibir un nuevo identificador único de referencia de pago;
indicar el activo, la red, el importe y el destino exactos que aparecen en el proceso activo;
señalar que la solicitud anterior ha sido sustituida o está en revisión;
explicar que la transacción original sigue siendo un incidente independiente;
indicar al cliente que no pague ambos enlaces;
conservar cualquier regla de caducidad;
someter ambas solicitudes a la detección de duplicados antes de la entrega.

No indiques al cliente que envíe una diferencia sin seguimiento, que reenvíe fondos a una dirección copiada de un chat o que cambie de red después del envío como si eso trasladara los fondos originales.

Evita los pagos y las entregas duplicados

Una transacción demorada puede confirmarse después de crear una solicitud de reemplazo. El cliente también puede enviar dos veces mientras espera respuesta. Diseña el proceso para afrontar ambas situaciones.

Utiliza un único identificador de pedido a nivel comercial con varios intentos de pago inmutables. Aplica estos controles:

un hash de transacción solo puede reconocerse una vez;
un intento de pago no puede completar varios pedidos;
un pedido solo puede activar la entrega o el acceso una vez;
las solicitudes original y de reemplazo permanecen vinculadas;
todos los intentos abiertos se comprueban justo antes de la entrega;
las confirmaciones tardías y los importes recibidos de más pasan a revisión;
el procesamiento de webhooks y notificaciones es idempotente;
los reembolsos requieren una aprobación independiente, la verificación del destino y registros de la transacción.

Si dos transferencias se completan correctamente, no elimines una, no la apliques en secreto a otra compra ni envíes automáticamente los fondos a una dirección facilitada en un nuevo mensaje de atención al cliente. Bloquea la entrega duplicada y sigue la política documentada de abonos o reembolsos.

Establece reglas de atención al cliente y seguridad para el comercio

Proporciona al personal de primera línea un guion y criterios claros para remitir casos.

El equipo de atención al cliente puede solicitar datos públicos de la transacción, referencias de pago, datos del pedido y capturas de pantalla que no revelen secretos. Nunca debe pedir una frase semilla, frase de recuperación, clave privada, contraseña de la billetera, código de un solo uso ni acceso remoto al dispositivo del cliente. Quien tenga una frase semilla o una clave privada puede llegar a controlar la billetera.

Utiliza un mensaje como este:

Vemos que se envió una transacción en [red]. Estamos comprobando si el activo, el destino, el importe y el estado de confirmación coinciden con la solicitud de pago [referencia]. No envíe otro pago hasta que le proporcionemos un nuevo enlace aprobado o confirmemos el siguiente paso. Nunca le pediremos su frase semilla ni su clave privada.

Establece plazos para acusar recibo, revisar las pruebas, remitir el caso, aprobar una medida y actualizar al cliente. No prometas una fecha de recuperación hasta haber comprobado el acceso y la viabilidad de la transacción.

Yolfi es un servicio sin custodia: los pagos se envían a la billetera configurada por el comercio, en lugar de quedar en poder de Yolfi. Por eso son esenciales una configuración correcta de la billetera, la titularidad del acceso y una política de incidentes gestionada por el comercio.

Lista de comprobación para incidentes del comercio

Antes de aceptar pagos

Muestra juntos el activo y la red en cada paso.
Activa únicamente las combinaciones disponibles en la configuración activa de Yolfi.
Verifica todas las direcciones de liquidación y los identificadores de token.
Prueba de principio a fin cada ruta activada.
Define reglas de confirmación, discrepancias, duplicados, reembolsos y remisión de casos.
Forma al equipo de atención al cliente para que nunca solicite secretos de una billetera.

Cuando se notifica un incidente

Detén la entrega y desaconseja un pago duplicado.
Conserva la solicitud original y el informe del cliente.
Prepara el expediente de pruebas.
Verifica la transacción en la red realmente utilizada.
Compara la red, el activo, el destino, el importe, el estado y las confirmaciones.
Comprueba el control de la dirección sin suponer que los fondos son recuperables.
Busca reconocimientos anteriores e intentos vinculados.
Registra una decisión aprobada y el mensaje enviado al cliente.

Preguntas frecuentes

¿Puede confirmarse una transacción y seguir constando el pago como impagado?

Sí. La confirmación demuestra que una red procesó una transacción. Para que un pago se reconozca, también debe coincidir con la red, el activo, el destino, el importe y la referencia solicitados, además de cumplir la política de confirmación del comercio.

¿Cambiar la red de la billetera recupera o desplaza los fondos?

No. Cambiar la red seleccionada modifica la blockchain que la billetera muestra y con la que interactúa. No desplaza tokens entre redes. En algunos casos de redes EVM, el propietario de la misma dirección puede ver los activos en la red utilizada, pero cualquier transferencia posterior o uso de un puente es una acción independiente cuya disponibilidad o conveniencia no están garantizadas.

¿Debemos pedir al cliente que vuelva a pagar de inmediato?

No. Primero determina si la transacción original está pendiente, falló, se completó correctamente o presenta alguna discrepancia. Si se aprueba otro intento, emite una nueva solicitud de pago vinculada y activa la detección de duplicados para ambos intentos.

¿Puede Yolfi recuperar un pago enviado a la red equivocada?

No des por sentado que sea posible. En un proceso sin custodia, los fondos llegan a la billetera configurada por el comercio. La solución disponible depende del destino real, la red, el activo, el control de la billetera, la capacidad técnica y la política del comercio.

¿Qué ocurre si el cliente utilizó la red correcta, pero envió el token equivocado?

Trátalo como un incidente de moneda equivocada. Verifica el contrato o la dirección de emisión del token, el importe, el destino y la recepción en la billetera; después sigue el proceso documentado para excepciones en lugar de marcar el pedido como pagado.

¿Qué ocurre si la transacción sigue pendiente?

Mantén el pedido pendiente y no realices la entrega. Supervisa el explorador y el estado del pago conforme a tu política de confirmación. Desaconseja una segunda transferencia hasta que se resuelva la transacción pendiente o se apruebe un reemplazo controlado.

¿Basta con una captura de pantalla para aprobar la entrega?

No. Usa el hash para localizar la transacción y verifícala de forma independiente en el explorador correcto. Después, compárala con la solicitud de pago y comprueba que no se haya utilizado ya.

Conclusión

Para evitar errores de red, es necesario especificar sin ambigüedades el activo, la red, el destino, el importe y el estado de confirmación. La gestión de incidentes exige datos de transacción verificados, comprobaciones prudentes del control de la billetera, ninguna promesa de recuperación y medidas para evitar duplicados.

Empieza por las combinaciones que aparecen en tu configuración activa de Yolfi, pruébalas y proporciona al equipo de atención al cliente un único árbol de decisiones. Cuando sea necesario otro intento, crea una solicitud de reemplazo vinculada en lugar de improvisar por chat. El objetivo es reconocer el pago correcto, realizar una sola entrega y conservar todas las decisiones tomadas ante excepciones.