Lista de comprobación operativa para pagos cripto

Antes del lanzamiento

Hazlo una vez y repítelo tras cualquier cambio en tu servidor.

• La clave de API solo está en el servidor, en una variable de entorno o un gestor de secretos, nunca en el código del front-end ni en un repositorio.
• La URL de callback está guardada, es pública y usa HTTPS, y se alcanza desde fuera de tu red.
• El manejador del webhook responde exactamente HTTP 200, rápido, y es seguro ejecutarlo dos veces. Cualquier otro estado, un tiempo de espera o una redirección cuentan como entrega fallida. Consulta cómo proteger los webhooks de pagos cripto.
• Un pago de prueba funciona de principio a fin. Paga una pequeña cantidad real, comprueba que llega el webhook y que el pedido pasa a pagado. Aún no hay sandbox, así que usa cantidades reales pequeñas.
• Un reintento funciona. Haz que el endpoint falle una vez y confirma que Qvard reintenta (cinco intentos en unos seis minutos) sin cumplir el pedido dos veces.
• Un retiro funciona. Retira una pequeña cantidad a tu propia wallet. Cuesta solo la comisión de red.
• Las reglas están escritas: qué haces con un pago corto, cómo reembolsas y quién atiende a los clientes.

Cada día

Unos minutos, idealmente a la misma hora.

• Pedidos sin pagar fuera de la ventana de tasa. La tasa de la página de pago se fija durante una hora. Revisa los pedidos que siguen esperando después: se abandonaron o se perdió una notificación.
• Pagos cortos. Un pago con estado partial no envía webhook de finalización. Revísalos en el panel, mantén el pedido en espera y contacta con el cliente. Consulta cómo gestionar los pagos incompletos en USDT.
• Errores en el endpoint del webhook. Una racha de peticiones fallidas o de respuestas 401 indica un endpoint roto o una clave que no coincide. Configura una alerta en vez de descubrirlo al final del día.
• El total diario. Compara los pedidos que marcaste como pagados con los pagos del panel. La API pública no tiene ruta para listar pagos, así que es una comparación con tu propio registro de webhooks. Consulta la conciliación de pagos para comerciantes cripto.

Cada semana

• Notificaciones perdidas. Si el panel muestra un pago completado que tu sistema de pedidos no, reenvía la notificación desde el panel y deja que el manejador idempotente la aplique.
• Patrones de soporte. Cuenta los tickets sobre redes equivocadas, pagos cortos y «pagué y no pasó nada». Si uno se repite, corrige el texto en el checkout o en la página del pedido, no cada ticket.
• Reembolsos. Comprueba que cada reembolso enviado está registrado contra su pedido original y que fue a una dirección y red que el cliente confirmó.
• Saldos por activo y red. Los pagos en redes distintas se acumulan por separado. Mira qué hay dónde antes de decidir qué retirar.
• Stock y caducidad. Si reservas stock para pedidos sin pagar, confirma que los pedidos caducados lo liberan.

Cada mes

• Concilia por completo. Cruza los pedidos del mes, el registro de webhooks y los pagos del panel, y explica cada diferencia. Contabiliza los ingresos en dólares al valor del pedido y registra la comisión y las comisiones de retiro como líneas aparte.
• Revisa los retiros. No hay cuota de suscripción; la comisión es individual para tu proyecto y, según la página de precios, empieza en el 1 % y puede bajar hasta el 0,1 %. Un retiro cuesta solo la comisión de red, normalmente una cantidad fija por transferencia, así que retira en tamaños razonables en vez de muchos pequeños. Consulta las comisiones de red en las operaciones de pago cripto.
• Rota y audita los accesos. Comprueba quién ve la clave de API y el panel, y cambia la clave si se fue alguien que la tenía o si sospechas una fuga.
• Relee el texto para clientes. ¿Sigue el checkout indicando los activos y redes aceptados, la nota sobre comisiones y la regla de reembolso? ¿Sigue siendo cierto?
• Consulta a tu contable. El tratamiento fiscal y contable de los cobros cripto depende de tu país; revisa la práctica con regularidad.

Cuando algo parece ir mal

Un guion corto para los casos habituales.

• Un cliente dice que pagó y el pedido figura sin pagar. Mira el pago en el panel. Si está completado, reenvía la notificación. Si es partial, pide la diferencia. Si no existe, pide los datos de la transacción y la red que usó.
• Red equivocada. Los fondos no llegan como se esperaba y requieren gestión manual. Mantén visible un contacto de soporte en el recorrido de pago.
• Un pedido pagado se cumplió dos veces. El manejador no es idempotente. Haz la actualización condicional («pagado solo si aún no está pagado») en una sola sentencia de base de datos.
• El webhook dejó de llegar. Prueba el endpoint desde fuera de tu red, mira el código de respuesta en el log de acceso y busca un firewall, una redirección o un manejador lento. Consulta la estrategia de reintentos de webhooks.
• No estás seguro de qué hace la API. La referencia es la API de pagos cripto para desarrolladores.

Guarda esta lista donde todo tu equipo la vea y anota quién se encarga de cada línea.

FAQ