Probar una integración de pagos cripto significa demostrar que se entrega el pedido correcto una sola vez y únicamente tras verificar el pago, no solo que se abre una página de pago. Separa las pruebas de entrega de mensajes, las del estado de los pedidos en tu aplicación y cualquier comprobación de aceptación autorizada con fondos reales. Cada una responde a una pregunta distinta.
Esta lista está dirigida a desarrolladores y comercios que preparan un proceso de pago para su lanzamiento, incluidos los pagos en USDC o USDT cuando el activo y la red seleccionados están realmente disponibles. Es un procedimiento de prueba recomendado, no una afirmación de que Yolfi haya superado estas pruebas para tu aplicación ni de que ofrezca un proceso de pago completo en una red de prueba.
Identifica el tipo de prueba que estás realizando
Una notificación de pago simulada no es una transferencia en la cadena de bloques. Una transferencia en una red de prueba no es un pago en la red de producción. Una redirección correcta del navegador no es ninguna de las dos cosas.
| Nivel de prueba | Qué permite comprobar | Qué no permite comprobar |
|---|---|---|
| Pruebas de aplicación con datos controlados | Transiciones de pedidos, reglas de rechazo y gestión de duplicados | Que el proveedor pueda acceder al receptor desplegado |
| Webhook de prueba del proveedor | Accesibilidad del punto de recepción y tratamiento de los datos de prueba del proveedor | Que se hayan transferido fondos o pagado una factura real |
| Transferencia en una red de prueba, cuando se admita expresamente | Comportamiento en esa red de prueba concreta | Disponibilidad del activo en producción o liquidación en la red principal |
| Comprobación de aceptación autorizada en producción | Resultado observado de un pago real en producción | Que funcionen todas las redes, los tokens y los casos de fallo |
La guía de redes de Ethereum explica que los saldos de las cuentas y el historial de transacciones no se comparten entre redes independientes. Que una dirección tenga el mismo aspecto no permite gastar fondos de una red de prueba en la red principal. Consulta la documentación actual del proveedor en lugar de suponer que una prueba genérica de billetera sirve para su servicio de pagos.
Empieza por definir por escrito el alcance de las pruebas
Registra el entorno de la aplicación, la cuenta del proveedor, la URL del receptor, la ubicación del secreto de firma, los identificadores de pedido y los efectos previstos antes de enviar nada. Utiliza registros de clientes desechables y desactiva la entrega real, el acceso de pago y los correos a clientes en los escenarios simulados.
Mantén separadas las configuraciones de prueba y producción. Nunca copies un secreto de firma en un artículo, una captura de pantalla, una incidencia o una transcripción de chat. Las evidencias de prueba deben identificar la versión del secreto utilizada, sin revelar su valor. No pidas a un comprador su frase de recuperación ni sus claves privadas para investigar una prueba fallida.
Para una comprobación con fondos reales, obtén autorización interna expresa sobre el importe, las comisiones, el destino y la persona responsable. Utiliza una billetera controlada por la empresa y un importe cuya pérdida puedas asumir. No envíes dinero a una dirección o red solo porque aparezca en una captura antigua, una página generada sobre una moneda o unas instrucciones de prueba no oficiales.
Demuestra que el servidor controla el importe del pedido
En Yolfi API Checkout, el servidor del comercio crea una Checkout Session con el importe y la moneda definitivos. Después, el comprador selecciona una red y un token admitidos y crea una Invoice a partir de esa sesión. Un Paylink reutilizable cumple una función distinta de la de un pedido dinámico cuyo precio determina el servidor.
Para un carrito dinámico, prueba el cálculo de precios y la asociación de sesiones en tu propio servidor antes de probar el movimiento de fondos:
- Modifica el total enviado por el navegador y confirma que no puede sustituir el precio oficial del pedido.
- Intenta utilizar la referencia de pedido de otro cliente y confirma que la aplicación impide el acceso no autorizado.
- Actualiza o vuelve a abrir el proceso de pago y comprueba que los intentos repetidos siguen asociados al pedido previsto.
- Modifica el carrito después de crear la sesión y confirma que la aplicación tiene una regla explícita para sustituir o rechazar el intento de pago anterior.
Estos son criterios de aceptación de la aplicación, no afirmaciones de que un punto de acceso del proveedor rechace cualquier solicitud posible. Guarda juntas la referencia del pedido del servidor y la referencia de sesión devuelta. No inventes un campo de API ni supongas que un identificador controlado por el navegador demuestra la titularidad.
Envía un webhook de prueba sin crear una venta real
La documentación actual de webhooks de Yolfi describe un evento de prueba que se envía desde el panel de administración por la misma vía de entrega, el mismo adaptador y la misma cabecera de firma que los eventos reales. Sus datos contienen livemode: false y un identificador de evento evt_test_. La prueba no crea facturas, eventos de pago, suscripciones ni registros de clientes.
Utiliza ese evento para comprobar la entrega y el tratamiento de los datos, no la liquidación. Un receptor que devuelve 200 OK puede estar concediendo acceso indebidamente o descartando el mensaje sin avisar. Inspecciona el estado resultante de la aplicación, además del resultado de la entrega.
Verifica las firmas con el procedimiento documentado y el secreto de firma específico del punto de recepción, no con la clave de API de la organización. Confirma que tu proceso de entrega en producción no puede interpretar un evento de prueba como un pedido pagado. Si pruebas la entrega con datos controlados en un entorno de prueba aislado, utiliza registros desechables e inspecciónalos por separado de los de producción.
Yolfi exige un destino público HTTP o HTTPS y no sigue redirecciones. Para el desarrollo local, su documentación recomienda un túnel HTTPS público. Comprueba la URL final exacta del receptor; una solicitud correcta a otra ruta o a una dirección accesible solo en local no demuestra que el proveedor pueda entregar el mensaje.
Utiliza una matriz de fallos, no solo una captura del caso ideal
Ejecuta pruebas con datos controlados en tu propio entorno de prueba aislado para los casos que el emisor de pruebas del proveedor no permita reproducir. Identifícalas claramente como pruebas de aplicación; no presentes eventos inventados del proveedor como pruebas de un pago real.
| Escenario | Observación necesaria en tu aplicación |
|---|---|
| Evento de prueba válido | Se registra como prueba; sin entrega real ni recibo de pago |
| Firma ausente o no válida | Se rechaza antes de modificar un pedido |
| Pago iniciado pero no confirmado | El pedido sigue sin pagar |
| Pago confirmado para un pedido desconocido | Se retiene para investigación; sin atribuirlo a un cliente por conjetura |
| El mismo evento firmado se entrega dos veces | Un único resultado de negocio persistente, sin entrega duplicada |
| Dos procesos de trabajo gestionan el mismo evento | Una sola decisión de entrega pese al procesamiento simultáneo |
| Receptor no disponible y posteriormente restablecido | Se observa la recuperación sin duplicar la entrega |
| El navegador se cierra antes de regresar | El procesamiento del pago no depende de la página de retorno |
En Yolfi, invoice.created indica el inicio; payment.confirmed es el desencadenante documentado de la entrega. No marques un pedido como pagado solo porque haya llegado el primer mensaje. La guía de webhooks idempotentes explica la deduplicación persistente; esta lista se centra en reunir pruebas de que tu implementación realmente se comporta así.
Prueba la recuperación de forma deliberada. Un proceso que devuelve una respuesta correcta antes de guardar un evento puede perder trabajo si se interrumpe. Un proceso que entrega productos antes de registrar la finalización puede repetir la entrega tras un reintento. Elige un diseño de procesamiento persistente y prueba los puntos de interrupción en lugar de suponer que una sola solicitud correcta demuestra la fiabilidad.
Revisa las instrucciones al comprador y el proceso para pagos sin resolver
Abre el proceso de pago real en un teléfono y en un ordenador. Comprueba que el importe mostrado, el activo seleccionado, la red, el destino y la información de vencimiento se entiendan antes de transferir fondos. Prueba los controles de copia y el escaneo de códigos QR sin suponer que un código QR configura automáticamente de forma correcta cualquier billetera emisora.
No envíes un token no admitido, no utilices deliberadamente la red equivocada ni realices una transferencia irreversible solo para probar un mensaje de error. Ensaya esas situaciones de asistencia con registros controlados. La guía para evitar pagos en la red equivocada explica qué comprobaciones debe ver el comprador.
Ensaya el caso de un pedido sin pagar o vencido: el comprador debe recibir un estado claro y un siguiente paso seguro, no una promesa de recuperación sin fundamento. Utiliza el procedimiento para facturas vencidas para decidir qué investigar antes de solicitar otro pago. Un segundo pago no debe convertirse en la respuesta automática ante un primer intento cuyo resultado no está claro.
Si tienes autorización, documenta una comprobación de aceptación en producción
Continúa solo después de confirmar que el activo y la red de producción elegidos están disponibles en el proceso real. Ten en cuenta las comisiones de red necesarias y mantén el destino bajo control de la empresa. Un webhook de prueba del proveedor no justifica enviar fondos reales por una vía no verificada.
Registra las referencias del pedido y del pago, el activo y la red utilizados, el importe, la confirmación observada, las evidencias de la billetera receptora y el estado de entrega resultante. Evita prometer un número universal de confirmaciones o un plazo fijo de liquidación. Comprueba el resultado que realmente observaste, no solo una captura de una billetera.
Después, concilia ese pago con los registros de pedidos y recibos. La lista de conciliación ayuda a distinguir los fondos recibidos de su asignación a pedidos y de las comisiones. Si prevés reembolsar el pago de aceptación, autoriza y verifica el reembolso por separado; no supongas que es una reversión automática.
Una comprobación superada demuestra una vía observada en un momento concreto. Repite las pruebas de aceptación pertinentes cuando cambien la lógica de pagos, el despliegue del receptor, los secretos o las vías admitidas. Nunca extrapoles un único pago en USDC como prueba de que funcionan todas las redes de USDT.
Conserva un registro de evidencias del lanzamiento
Guarda un informe breve con la versión de la aplicación probada, el entorno, los escenarios, los resultados esperados, los resultados reales y los problemas pendientes. Enlaza registros privados y fichas de pedidos en lugar de publicar identificadores de clientes o historiales completos de billeteras.
Bloquea el lanzamiento si un evento de prueba puede provocar la entrega de un pedido real, un duplicado puede causar dos entregas, las firmas no válidas pueden modificar el estado o los pagos confirmados no pueden asociarse con seguridad. Asigna un responsable a cada asunto pendiente. Un indicador verde de entrega no sustituye estos resultados de negocio.
Preguntas frecuentes
¿Un webhook de prueba de Yolfi mueve criptomonedas?
No. La prueba documentada valida la entrega y el tratamiento de los datos sin crear facturas ni registros de pago. No demuestra que un pago real en la cadena de bloques haya tenido éxito.
¿Un pago en una red de prueba equivale a un entorno de pruebas de un servicio de pagos?
No. Una red de prueba es una red de cadena de bloques independiente. El entorno de pruebas de un proveedor es específico de su servicio. Comprueba si el proveedor admite el modo concreto que necesitas; este artículo no acredita que Yolfi ofrezca un proceso de pago en una red de prueba.
¿Puedo lanzar el servicio si la página de pago redirige correctamente?
No basta con esa prueba. Verifica la gestión de pagos en el servidor, la asociación de pedidos, la protección contra duplicados y la recuperación ante fallos. El comprador puede cerrar el navegador antes de que se abra cualquier página de retorno.
¿Tengo que probar todos los fallos enviando dinero real?
No. Utiliza pruebas aisladas de aplicación y simulaciones documentadas del proveedor para comprobar la gestión de fallos. Toda comprobación de aceptación en producción requiere autorización y una vía admitida verificada, no transferencias deliberadas a redes equivocadas.
Conclusión: prueba el resultado de negocio antes del lanzamiento
Empieza por definir un alcance claro, demuestra la gestión de pedidos en el servidor y distingue un evento simulado de los fondos verificados. Utiliza los enlaces de pago de Yolfi para ofertas de precio fijo adecuadas o el proceso de API documentado para pedidos dinámicos; después, conserva pruebas de que el procesamiento del pago, no la redirección del navegador, controla la entrega.
