Cuando un cliente dice «Ya pagué, pero mi pedido sigue figurando como pendiente de pago», empieza por las pruebas, no por pedirle que pague otra vez. El soporte para pagos con criptomonedas necesita información suficiente para vincular una transferencia con un pedido, pero nunca una frase de recuperación, una clave privada ni la contraseña de la billetera.
Esta guía está dirigida a comercios que venden productos digitales, servicios o membresías. Abarca la recepción y derivación de consultas de soporte, no promete recuperar fondos. Es un procedimiento recomendado para el comercio; no describe una función automática de soporte o recuperación de Yolfi.
Recopila las pruebas de pago mínimas necesarias
Abre un único caso de soporte privado y solicita la referencia del pedido, la red en la que se debía realizar el pago y el hash de la transacción, si existe. Usa los datos del proceso de pago que ya tienes guardados como punto de comparación, en lugar de pedir al cliente que reconstruya toda la compra.
| Prueba | Para qué sirve | Tratamiento seguro |
|---|---|---|
| Referencia del pedido o de la factura | Permite localizar la compra prevista | Contrástala con el registro de pedidos del comercio |
| Red y token seleccionados | Indican dónde revisar la transferencia | Registra ambos; el símbolo de la moneda no basta |
| Hash de la transacción o enlace al explorador | Permite localizar una transacción transmitida a la red | Abre por tu cuenta un explorador de confianza |
| Importe enviado y hora aproximada | Ayudan a distinguir entre varios intentos | Conserva la unidad del activo y la zona horaria |
| Servicio de envío, si corresponde | Permite distinguir una transferencia desde una billetera de un retiro desde una plataforma de intercambio | Pide el nombre del servicio, nunca su contraseña |
| Mensaje de error con datos sensibles ocultos | Muestra dónde se detuvo el proceso de pago o el retiro | Oculta los saldos y datos personales que no sean pertinentes |
El hash de una transacción no es una clave secreta de la billetera, pero vincularlo con un nombre o correo electrónico puede revelar la actividad financiera de un cliente. Consérvalo en el caso privado, no en un comentario público. No pidas el historial completo de una billetera si una sola transferencia permite responder a la consulta.
Nunca conviertas la resolución de problemas en acceso a la billetera
Deja claro este límite en la primera respuesta: el equipo de soporte no necesita una frase de recuperación, una clave privada, la contraseña de la billetera, un código de acceso de un solo uso ni el control remoto del dispositivo del cliente. No le pidas que importe una billetera en un sitio web de «reparación», que firme un mensaje sin explicación ni que autorice el gasto de tokens para verificar un pago anterior.
Las indicaciones oficiales de soporte de MetaMask afirman que su equipo nunca solicitará una Secret Recovery Phrase y advierten contra los mensajes directos no solicitados. Aplica la misma regla de no solicitar información secreta al recibir tus propias consultas sobre pagos; no afirmes hablar en nombre de un proveedor de billeteras.
Si un cliente envía información secreta por accidente, restringe el acceso al caso y evita copiarla en registros o conversaciones internas. Indícale que siga cuanto antes las instrucciones oficiales de su proveedor para billeteras comprometidas. Eliminar un mensaje de soporte no vuelve segura una clave expuesta.
Distingue entre «no enviado» y «enviado, pero sin resolver»
Pregunta si hay un hash de transacción disponible. Una página de pago, un código QR o una solicitud de confirmación en la billetera no prueban que se haya transmitido una transferencia a la red. Si la operación en la billetera se canceló o falló antes del envío, puede que no haya ningún pago en la cadena de bloques que investigar.
La referencia de un retiro de una plataforma de intercambio puede ser un identificador interno del servicio, no el hash de una transacción en la cadena de bloques. Pide al cliente que consulte el estado del retiro en la aplicación oficial de ese servicio. No interpretes un retiro en espera como un ingreso confirmado para el comercio ni prometas un plazo fijo de llegada.
Cuando haya un hash disponible, verifícalo en la red seleccionada durante el proceso de pago. Accede por tu cuenta a un explorador de confianza, en lugar de conectar una billetera a un enlace incluido en la consulta. Consultar una transacción pública no requiere conectar una billetera. Contrasta el destino, el activo, el importe transferido y el resultado de la transacción con los registros del comercio. En las transferencias de tokens, revisa los detalles de la transferencia del token, no solo el valor en la moneda nativa que figura en la transacción.
Una transacción exitosa en otra red, o un token con un símbolo conocido pero un contrato diferente, no equivale automáticamente al pago esperado. Gestiona estas excepciones con la lista de comprobación para pagos en la red equivocada, en lugar de improvisar instrucciones de recuperación.
Vincula el intento de pago con el pedido comercial
Distingue entre el pedido comercial, el intento de pago y la transferencia en la cadena de bloques. Un cliente puede abrir más de un intento para la misma compra. Un enlace reutilizable identifica el punto de acceso al pago del producto, no necesariamente el pedido de un cliente concreto.
La documentación de API Checkout de Yolfi distingue entre los Paylinks reutilizables de precio fijo y las Checkout Sessions creadas desde el servidor para pedidos dinámicos. Una sesión independiente no requiere un Paylink. El equipo de soporte debe usar las referencias que se hayan guardado realmente para ese proceso, no rechazar un caso porque falte un objeto que el proceso nunca creó.
Para productos fijos, los enlaces de pago de Yolfi proporcionan el punto de acceso al pago. Tu proceso de soporte sigue necesitando una forma de asociar el caso del cliente con la factura o el pedido correspondiente. Evita publicar la URL completa de una página de pago alojada: puede revelar información del pedido o permitir que otras personas interactúen con esa página de pago.
Deriva el caso sin pedir al cliente que pague dos veces
Deja un registro breve de la decisión: qué se esperaba, qué pruebas se encontraron, quién es responsable del siguiente paso y cuándo recibirá el cliente una actualización. Comprometerse a informar en un momento determinado no garantiza la liquidación en la cadena de bloques ni la recuperación de fondos.
- Sin pruebas de transmisión a la red: ayuda a determinar si la billetera o el servicio de envío llegó a enviar la transferencia antes de sugerir un nuevo intento.
- Transferencia aún pendiente: consulta las indicaciones oficiales del servicio de envío o de la billetera; no solicites otro pago solo para agilizar el soporte.
- Destino, red o activo incorrectos: conserva las instrucciones originales y las pruebas de la transferencia y deriva el caso. No prometas recuperar los fondos ni pidas información secreta de la billetera.
- Pago registrado, pedido no entregado: investiga el proceso de gestión y entrega de pedidos del comercio antes de pedir al comprador que repita el proceso de pago.
- Intento vencido o que no coincide: sigue el procedimiento específico para facturas vencidas, en lugar de tratar un nuevo intento como sustituto del dinero ya enviado sin explicarlo.
La referencia de webhooks de Yolfi identifica payment.confirmed como el principal evento que debe activar la entrega. Un evento invoice.created no demuestra que se haya pagado. Una captura de pantalla del cliente y una redirección del navegador aportan contexto útil, pero no sustituyen una confirmación de pago verificada en el servidor.
Un explorador puede ayudar a determinar qué ocurrió en la cadena de bloques; por sí solo no demuestra que tu aplicación haya vinculado el pago o entregado el pedido. Mantén relacionadas, pero diferenciadas, la investigación del pago y la de la entrega.
Usa una plantilla breve y segura para la primera respuesta
Adapta este mensaje a tu canal de soporte y al número de caso:
Envíanos la referencia de tu pedido o factura, la red y el token que seleccionaste, el importe enviado y el hash de la transacción, si lo tienes. Si el retiro se hizo a través de una plataforma de intercambio, incluye su nombre y el estado del retiro. Oculta los saldos y datos personales que no sean pertinentes. Nunca envíes una frase de recuperación, una clave privada, la contraseña de la billetera ni un código de acceso. No repitas el pago mientras revisamos el intento existente. Te informaremos después de revisar los registros del pago y del pedido.
Antes de prometer un reembolso, verifica la relación con quien realizó el pago y sigue la lista de comprobación para revisar reembolsos. Una consulta de soporte no autoriza a enviar fondos a cualquier dirección alternativa indicada en el chat.
Preguntas frecuentes
¿Una captura de pantalla demuestra que el comercio recibió el pago?
Por sí sola, no. Puede mostrar una transferencia prevista, un retiro pendiente u otra transacción. Verifica la transferencia real y vincúlala con el registro de pago del comercio antes de entregar un pedido.
¿Es seguro pedir el hash de una transacción?
Normalmente es apropiado para investigar un pago de forma privada. Es información de una cadena pública, no un secreto que permita firmar operaciones, pero puede vincular al cliente con actividad financiera visible. Recopila solo lo necesario y restringe el acceso.
¿Debe el equipo de soporte pedir al cliente que conecte una billetera?
No para consultar una transacción pública ni revisar un registro de pago existente. Si otra acción legítima del producto requiere una billetera, explica esa acción con claridad a través del proceso de pago establecido. Nunca presentes una firma o una autorización de gasto como una verificación rutinaria de soporte.
¿Pueden Yolfi o un proveedor de billeteras revertir cualquier transferencia errónea?
No lo des por hecho. La recuperación depende del destino, la red, el activo y de quién controla los fondos recibidos. Ningún guion de soporte debe garantizar la reversión o recuperación basándose únicamente en el hash de una transacción.
Conclusión: basa el soporte en pruebas
Un proceso seguro de soporte de pagos recopila un conjunto reducido de referencias, verifica la transferencia de forma independiente y asigna el siguiente paso sin exponer las credenciales de la billetera. Combina los enlaces de pago de Yolfi con instrucciones claras para el cliente y una lista privada de comprobación de pruebas, para que un pedido sin resolver dé lugar a una investigación, no a una invitación a compartir información secreta o a pagar otra vez.
