No. Binance Pay C2C usa una API key de cuenta personal de Binance con permisos Read y Pay. No se requiere KYB.

Cada orden recibe un código aleatorio de match con ancho configurable: 1 a 3 dígitos para cadenas cripto (codificado en los decimales finales del monto, p.ej. $10.0123) y 3 a 5 dígitos para Binance Pay (puesto en el campo de nota). Los códigos están limitados por inquilino; el matcher desambigua por dirección maestra para que distintos inquilinos puedan tener el mismo código activo.

USDT en Tron (TRC20). USDT y USDC en BNB Smart Chain (BEP20). USDT y USDC en Binance Pay C2C. Ethereum y Polygon están en el roadmap cuando la economía de gas tenga sentido para facturas menores a $50.

Los listeners TRC20 y BEP20 escanean cada 3 segundos, Binance Pay cada 5. El crédito de extremo a extremo es típicamente de 3–7 segundos para cripto y 5–10 segundos para Binance Pay, más la cola de confirmaciones de la cadena. Las suscripciones push de BSC y los webhooks merchant de Binance están en el roadmap para detección sub-segundo.

La transacción cae en la cola de huérfanas en lugar de auto-acreditar una orden expirada. Un admin puede revincularla a la factura correcta y disparar un recrédito manual. Los sobrepagos en órdenes aún válidas se acreditan y se marcan como sobrepago.

Solo difiere el periodo de facturación. Los compromisos más largos desbloquean descuento porque reducen churn y overhead de procesamiento de pagos. Cambia de periodo cuando quieras desde el panel.

Reembolso completo dentro de los primeros 7 días, sin preguntas. Después, los reembolsos son prorrateados por periodos de facturación no usados en planes anuales o semestrales.

El servicio continúa hasta el final del periodo de facturación actual. Los planes anuales y semestrales reciben reembolsos prorrateados por meses no usados. Sin cuota de reactivación si vuelves después.

Los campos sensibles se cifran en reposo, el tráfico es solo TLS y las contraseñas usan hashing memory-hard moderno. La autenticación de dos factores está disponible en cada cuenta. Cada acción privilegiada queda en el registro de auditoría con la IP real del cliente. Los detalles están documentados para integradores en nuestra documentación de desarrollador.

Cada entrega se firma criptográficamente y lleva timestamp; el plugin DHRU incluido maneja la verificación automáticamente. Para integraciones custom, el formato de firma y los pasos de verificación están en el spec de webhook en nuestra documentación de desarrollador.

Misma key + mismo payload retorna la orden original, sin duplicado. Misma key + payload distinto ahora retorna HTTP 409 con `code: "conflict"` para que las colisiones accidentales sean visibles en lugar de reusar silenciosamente la orden previa.

Sí. El login es una etapa de contraseña más un código de un solo uso entregado por correo (default), WhatsApp (cuando hay teléfono configurado) o app authenticator para cuentas que la tengan inscrita. La protección anti-replay impide que los códigos se usen dos veces. La opción de "recordar este dispositivo" por 7 días salta el código en un dispositivo conocido; puedes revocar dispositivos en cualquier momento desde el panel.

Sí. Abre Integración en el panel. Los webhook secrets live y las API keys live pueden regenerarse cuando quieras; las rotaciones requieren OTP por correo y quedan en auditoría. Las keys y secrets de sandbox pueden regenerarse libremente.

Cada inquilino tiene una key paralela de sandbox (`pk_test_*`) y un webhook secret de sandbox. Las órdenes creadas con la key de prueba están aisladas; los listeners de cadena no pueden tomarlas físicamente. Los endpoints force-match, force-credit y force-expire simulan el round-trip completo del webhook. El plugin DHRU honra `X-Payment-Mode: sandbox` y cortocircuita antes de acreditar cualquier factura real.

DHRU Fusion. El plugin usa hooks estándar de gateway, sin cambios de schema. Compatible con PHP 7.4+.

Las transacciones huérfanas aparecen en la UI de conciliación de admin. Un admin puede vincular manualmente cualquier transacción entrante a la factura correcta y disparar un recrédito. La acción de recrédito requiere una confirmación OTP fresca.

Los listeners registran cada transacción entrante. Si ninguna orden coincide, la transacción cae en la UI de conciliación de huérfanas donde los admins pueden vincularla a la factura correcta y disparar un recrédito. Ningún pago se pierde silenciosamente.

WhatsApp responde dentro de un día hábil en cada plan. Los incidentes críticos (listener caído, falla de crédito) escalan a respuesta el mismo día. El panel autoservicio cubre la mayoría de operaciones sin un ticket.