Un recibo de pago con criptomonedas es el reconocimiento por parte del comercio de un pago verificado correspondiente a un pedido concreto. Debe indicar al comprador qué se ha pagado, a qué compra corresponde y cómo plantear una consulta. Un hash de transacción por sí solo no aporta ese contexto comercial.
Esta guía ofrece a los comercios una lista de comprobación para los recibos y una estructura de mensaje reutilizable. Son controles empresariales recomendados, no una afirmación de que Yolfi genere recibos descargables o facturas fiscales. Los requisitos legales de los documentos dependen de tu jurisdicción; consulta a tu asesor contable qué campos y tipos de documentos debe proporcionar tu empresa.
Distingue entre factura, recibo y registro de la cadena de bloques
Una factura solicita un pago. Un recibo reconoce un pago ya verificado. Un registro de la cadena de bloques documenta una transacción en una red determinada. Mantén estos documentos vinculados sin tratarlos como si fueran intercambiables.
| Registro | Qué comunica | Qué no demuestra por sí solo |
|---|---|---|
| Factura comercial | Vendedor, compra e importe adeudado | Que el comprador haya pagado |
| Recibo de pago del comercio | Pago aceptado para un pedido específico | Que se cumplan todos los requisitos de documentación fiscal |
| Hash de transacción y datos de la transferencia | Movimiento de activos en una red identificada | La identidad del cliente o qué compra liquida |
| Confirmación de entrega | Bienes entregados o acceso proporcionado | El importe del pago o su tratamiento fiscal |
Un objeto de un proveedor llamado «Invoice» también puede tener un significado técnico. En Yolfi API Checkout, se crea un objeto Invoice después de que el comprador elija una red y un token admitidos. No des por hecho que ese objeto técnico sea la factura comercial con validez fiscal que exige la normativa local.
Envía el recibo después de verificar el pago, no después de una redirección
En un proceso integrado, verifica la notificación de pago en tu servidor antes de marcar un pedido como pagado o enviar un recibo que acredite su pago. La documentación de webhooks de Yolfi identifica payment.confirmed como el evento principal para proceder a la entrega. invoice.created significa que se ha iniciado un pago, no que se haya recibido el dinero.
Autentica el evento mediante el procedimiento de firma documentado, asócialo con el pedido correcto y gestiona los reintentos sin enviar varios recibos independientes. Un evento de prueba no debe generar un recibo de pago real. Mantén una referencia de recibo única y reutilízala al reenviar el mismo documento.
Una página de confirmación en el navegador, una captura de una billetera o un retiro pendiente de una plataforma de intercambio no son suficientes. Si las pruebas no son concluyentes, envía una actualización del estado del pago en lugar de reconocer que el pedido está pagado. Utiliza la lista de pruebas para atención al cliente para investigar sin solicitar secretos de la billetera.
Si el pago se revisa manualmente, registra quién comprobó la dirección receptora, el activo, la red, el importe y las pruebas de confirmación. Tu procedimiento interno debe establecer cuándo esas pruebas son suficientes; este artículo no prescribe un número de confirmaciones único para todas las cadenas.
Incluye detalles suficientes para identificar la compra y el pago
El recibo destinado al cliente debe ser fácil de leer, con las pruebas técnicas adjuntas o disponibles en un registro privado del pedido. El comprador no debería tener que interpretar un registro de transferencias de tokens para reconocer su compra.
| Campo del recibo | Contenido recomendado |
|---|---|
| Identificación del documento | Referencia única del recibo y fecha de emisión con zona horaria |
| Vendedor y comprador | Identidad de la empresa y datos del cliente necesarios para esta transacción |
| Referencia de compra | Referencia del pedido o de la factura comercial, junto con una descripción breve |
| Importe comercial | Importe original y moneda en la que se fijó el precio, separados de la cantidad de criptomonedas |
| Pago aceptado | Cantidad exacta, nombre del activo y red que se verificaron realmente |
| Pruebas del pago | Referencia de pago del proveedor y referencia de la transacción pertinente, si están disponibles |
| Imputación | Importe aplicado a este pedido y cualquier saldo pendiente o exceso sin resolver |
| Contacto para consultas | Canal de atención establecido y referencia del recibo que debe indicarse |
En el caso de los tokens, conserva en el registro de base el identificador verificado del contrato o de acuñación (mint). Un símbolo por sí solo no identifica un activo de forma unívoca. Si el documento destinado al cliente abrevia una dirección o un hash largos, conserva la referencia completa en el registro privado de pruebas.
Separa el precio del pedido de la cantidad de criptomonedas aceptada. Si muestras un equivalente en moneda local, indica la base y el momento de valoración adecuados para tus registros. No describas cada pago recibido en USDC o USDT como un depósito bancario en dólares ni trates automáticamente las cantidades de tokens como valores para la declaración fiscal.
Las comisiones también necesitan etiquetas claras. La comisión de red del remitente no forma necesariamente parte del importe recibido por el comercio. No inventes un desglose de comisiones a partir de la diferencia entre el saldo de una billetera y el total de una factura.
Utiliza esta estructura de mensaje para el recibo
Lo siguiente es una plantilla de redacción, no un recibo de un cliente real. Completa cada línea a partir de tus registros verificados en lugar de pedir a un modelo de lenguaje que invente identificadores de transacciones.
Pago recibido — referencia del recibo: tu número de recibo único.
Vendedor y compra: la identidad de tu empresa, la referencia del pedido y una descripción breve de lo que compró el cliente.
Pago: la cantidad de criptomonedas y el activo verificados, la red y el importe original del pedido con la moneda en la que se fijó el precio.
Aplicado a este pedido: el importe aceptado para la compra, indicando expresamente cualquier saldo pendiente o exceso sujeto a revisión por separado.
Pruebas: la referencia del pago y la referencia de la transacción pertinente, además de la fecha y hora de confirmación del pago y de emisión del recibo, con sus zonas horarias.
Consultas o correcciones: contacta con el canal de atención establecido e indica esta referencia de recibo. Nunca envíes una clave privada ni una frase de recuperación.
Añade los datos del comprador, los identificadores de registro y otros campos obligatorios solo según lo requieran tu actividad y las normas locales. Evita incluir la dirección de correo electrónico, el nombre o los detalles de compra de un cliente en notas públicas de la cadena de bloques.
Envía el recibo a través de una página del pedido que requiera autenticación o del contacto verificado del cliente para esa compra. No expongas registros completos de pedidos mediante un enlace público sin protección a un documento. Una transacción pública puede revelar actividad financiera si se vincula a un cliente identificado por su nombre.
Mantén la utilidad de las pruebas de transacción sin exagerar su alcance
Una transacción puede contener más de una transferencia. Si un solo hash abarca varios movimientos de tokens, identifica la transferencia pertinente en tus pruebas internas en lugar de adjuntar el mismo hash sin distinguir movimientos a varios pedidos.
Para los tokens EVM, la referencia del recibo de transacción de Ethereum documenta el estado de la transacción y sus registros. Una ejecución correcta por sí sola no demuestra que la cantidad esperada de tokens haya llegado a la dirección de destino del comercio. Comprueba los detalles de la transferencia pertinente; el destinatario que figura a nivel de la transacción puede ser un contrato de token.
Utiliza un explorador de confianza de la red correcta si enlazas pruebas públicas. Abrir una transacción pública no debería requerir conectar una billetera, firmar ni autorizar el gasto de tokens. Un recibo no debe convertirse en una invitación a «verificar» el pago a través de un sitio desconocido que solicite acceso a la billetera.
Registra pagos parciales y reembolsos sin reescribir el historial
En un pago parcial, reconoce únicamente el importe verificado y aplicado. No marques todo el pedido como pagado mientras quede un saldo sin resolver. Si se reciben fondos de más, distingue entre el pago aplicado al pedido y el importe pendiente de revisión. La guía sobre pagos insuficientes y excesivos aborda esas decisiones.
Un reembolso posterior necesita su propio registro vinculado. Conserva el recibo original, la decisión de reembolso y las pruebas verificadas del pago saliente; no te limites a sustituir el importe aceptado originalmente por una cifra menor. Sigue el procedimiento de revisión de reembolsos antes de transferir dinero a una dirección proporcionada en un mensaje.
Corrige los errores administrativos mediante un proceso de corrección trazable. La necesidad de una nota de crédito formal, un documento sustitutivo u otro ajuste es una cuestión contable que depende de la jurisdicción. Conserva la relación entre versiones en lugar de eliminar las pruebas anteriores.
Qué papel desempeña Yolfi
Los enlaces de pago de Yolfi ofrecen un punto de entrada al pago para ofertas de precio fijo. La documentación de API Checkout distingue los Paylinks reutilizables de las Checkout Sessions creadas en el servidor para pedidos dinámicos; una sesión independiente no requiere un Paylink.
Tu empresa debe conservar la descripción del pedido y la relación con el cliente, y después vincular las referencias de pago disponibles a su propio proceso de emisión de recibos. Verifica qué campos expone tu proceso actual antes de automatizar documentos. Ni una página pública de una criptomoneda ni este artículo acreditan una combinación concreta de activo y red disponible en producción, una función de exportación de documentos o una integración contable.
Para los controles al final del día, la lista de comprobación de conciliación explica cómo relacionar los importes aplicados a los pedidos con los movimientos de la billetera. Los recibos de los clientes responden a «¿qué he pagado?»; la conciliación diaria permite comprobar si los registros de la empresa están completos.
Preguntas frecuentes
¿Es un hash de transacción un recibo de pago con criptomonedas?
No por sí solo. Identifica una transacción en una red, pero no acredita la identidad del comprador, la descripción de la compra ni su imputación a un pedido. El recibo del comercio añade ese contexto empresarial después de la verificación.
¿Puedo enviar un recibo mientras la transferencia está pendiente?
Envía una actualización del estado, no un recibo que acredite el pago. Reconoce el pago verificado solo cuando lo acepte tu proceso documentado de confirmación de pagos. No prometas que un retiro pendiente llegará a una hora determinada.
¿Sustituye un recibo de criptomonedas a una factura fiscal?
No automáticamente. El reconocimiento del pago y la facturación exigida por la ley pueden cumplir funciones distintas. Consulta a un asesor local cualificado qué información y documentos debe conservar y emitir tu empresa.
¿Debe el recibo mostrar todo el historial de la billetera?
No. Limita las pruebas al pago pertinente. Utiliza registros privados para los detalles técnicos necesarios, restringe el acceso y nunca solicites claves privadas ni frases de recuperación.
Conclusión: reconoce el pago y conserva el contexto
Un recibo útil vincula los fondos verificados con una compra reconocible sin afirmar más de lo que respaldan las pruebas. Empieza con unas instrucciones de pago claras, emite un único reconocimiento trazable por cada registro de pago aceptado y conserva las correcciones o los reembolsos vinculados en lugar de reescribir la venta original.
