Sigue una factura desde la selección hasta la confirmación

Las selecciones de pago son BTC, ETH, SOL, LTC y TRX en sus redes nativas, USDT en Ethereum ERC-20 o TRON TRC-20, y USDC solo en Ethereum ERC-20. Estas son ocho rutas en siete activos. Monero, USDC en TRON, Lightning, tarjetas y otras redes de tokens no se ofrecen.

El servidor cotiza el total completo del pedido USD en el activo seleccionado, con una marca de tiempo de la tasa y una expiración explícita mostrada en el checkout. Lee la dirección, el activo, la red y el monto exacto en conjunto. La dirección de recepción es fija en lugar de generarse para cada factura; una referencia de pedido debe asociarse explícitamente con una transacción verificada. No inventes un memo ni asumas que un monto por sí solo identifica de manera única un pedido. Las comisiones de red o de retiro de la billetera permanecen separadas del total del pedido.

Los umbrales del backend son BTC 2, LTC 6, ETH y USDT/USDC ERC-20 12, TRX nativo y USDT TRC-20 20, y SOL 1, con un estado finalizado verificado de forma independiente requerido. Los tiempos de confirmación dependen de las condiciones de la red. Actualmente, ningún monitor conectado detecta esas transacciones ni proporciona actualizaciones de confirmación; los tiempos de la cadena no son una garantía de entrega.

Guarda la referencia del pedido y el ID de transacción de la cartera. Si una cotización impaga expira antes de cualquier observación, actualízala a través del proceso de pago. Si una transacción ya fue observada o el importe, la red o el destino son incorrectos, pide a facturación que concilie las pruebas. No sobrescribas un pago observado con una nueva cotización ni envíes automáticamente una segunda transferencia.

El pago autenticado muestra la dirección de recepción fija configurada, la red seleccionada, el importe exacto de criptomoneda y la caducidad de la cotización. El servidor obtiene las tasas de USD. No hay ningún monitor de transacciones de blockchain conectado: la detección y la confirmación requieren una integración de backend de confianza. Un estado de pago no crea un servidor real ni un derecho de servicio. Los términos de reembolso siguen siendo una propuesta de lanzamiento: utilizan el activo original y el valor de pago inicial de USD a la tasa de reembolso actual, con la elegibilidad del producto y las deducciones explicadas por separado.

Un pedido comienza pending_crypto antes de que se seleccione un método. Una solicitud puede esperar una cotización, aguardar el pago, expirar, ser observada o confirmarse. La verificación del backend también puede señalar un pago insuficiente o un pago en exceso. Un resultado pagado registra la verificación del pago; no asigna infraestructura.

• awaiting_quote: aún no hay disponible una tarifa de servidor válida.
• awaiting_payment: hay una cotización exacta y las instrucciones de recepción disponibles.
• detected / confirming: un observador de confianza ha asociado una transacción, con la verificación aún en curso.
• underpaid / overpaid: el monto observado requiere conciliación.
• pagado: pago verificado, con la prestación del servicio aún por separado.