Respuestas claras antes de conectar una dirección de cartera.

No. Cryptanio lee datos públicos de blockchain y envía eventos operativos. Los pagos van directamente a las carteras que controlas y Cryptanio no requiere claves privadas.

Cryptanio enumera actualmente 23 redes: Bitcoin, Litecoin, Dogecoin, Bitcoin Cash, Dash, Ethereum, BNB Smart Chain, Base, Polygon, Avalanche, Optimism, Arbitrum, Solana, TRON, XRP Ledger, Stellar, Cosmos Hub, Osmosis, Injective, Celestia, Noble, TON y Cardano. Donde figure «+ tokens», también pueden vigilarse los activos compatibles de esa red.

No. Cryptanio utiliza planes fijos y volúmenes incluidos en vez de una comisión porcentual sobre ventas. El volumen exacto y las reglas opcionales de exceso se muestran en cada página de servicio.

La confirmación sigue las reglas de cada red. Cryptanio expone los estados pending, confirmed y rolled-back para que tu producto tome decisiones a partir de eventos explícitos en vez del silencio.

No. El cliente aprueba cada pago de renovación en su propia cartera. Cryptanio controla el periodo, el estado del pago, los recordatorios y los eventos de acceso.

Sí. Los enlaces de donación y pago puntual pueden crearse sin código. La API y los webhooks firmados están disponibles cuando necesitas integrar tu producto.

El sitio de presentación está disponible en inglés, francés, español, ruso, alemán, portugués, coreano, japonés y chino simplificado. El inglés es el idioma predeterminado.

Usa el formulario de contacto e indica el servicio, la red y el contexto necesarios para dirigir tu consulta.

La factura identifica un pedido; el intento de pago contiene la red, el activo, el importe, los datos de recepción y el plazo elegidos. Cambiar de método crea otro intento de la misma factura. Varias transferencias pueden financiar un intento; pagar dos intentos no debe ejecutar dos veces el pedido. Concilia el pedido por su identificador de factura. El identificador de cliente agrupa solo recargas de su saldo, no sus pedidos distintos.

Crea la factura con el importe del pedido y copia el enlace de pago. En la página de esa factura, el pagador elige una red y un activo disponibles y recibe el importe exacto y los datos. El enlace se mantiene al cambiar de método. Compártelo solo con el pagador previsto: no permite entrar en tu cuenta. Copia sin cambios cualquier tag, memo o comentario obligatorio. Una referencia Solana Pay debe enviarse mediante Solana Pay, no en un memo de texto.

Para la red y el activo exactos, Cryptanio usa primero un tag, memo, comentario o referencia únicos compatibles que el receptor pueda asignar. Después usa una fuente automática lista, conectada expresamente al proyecto y al servicio, y luego un conjunto manual adecuado si no hay una fuente automática configurada. Una fuente configurada pausada o averiada no equivale a una ausente y no provoca un cambio silencioso al conjunto manual. La dirección y la etiqueta impuestas por un exchange permanecen como un conjunto sin cambios.

Se prefieren los datos aptos de la misma factura, o del mismo cliente para recargas, durante 5 días tras su emisión si siguen libres. En caso contrario se elige la dirección que lleva más tiempo sin emitirse; las nunca emitidas van primero. Esta preferencia no prolonga plazos, reservas ni periodos de espera. Se avisa cuando los datos libres son como máximo el 20% del conjunto único, redondeado hacia arriba. Con 0 libres se detiene la emisión y un aviso crítico pide añadir direcciones. Los datos ocupados, en espera o no disponibles no cuentan como libres.

Solo las recargas de saldo identificadas por ese cliente pueden tener datos permanentes, mediante generación configurada de direcciones o subdirecciones únicas, o un marcador único compatible bajo tu control. Puede servir una dirección compartida con marcador individual. No se puede sustituir un marcador impuesto por un exchange. Estos datos no se reasignan a otro cliente por el temporizador del conjunto manual. Sin generación única ni marcador propio, los datos manuales son temporales: solicita los actuales para la siguiente recarga.

Los valores iniciales del proyecto son: espera de pago de 60 minutos, espera de reutilización tras factura pagada de 60 minutos, tras intento impagado de 1440 minutos y tras recarga temporal del conjunto manual de 1440 minutos, sea cual sea su resultado. La espera de pago empieza con la emisión correcta; la pagada, con la confirmación del pago completo; las demás, al terminar el intento. Los ajustes son configurables y se guardan con cada nuevo intento. Cambiarlos no recalcula plazos ya emitidos. Un pago parcial o su primera detección no inicia la espera de una factura pagada.

Antes de detectar una transferencia apta, elige otro método y confirma: «¿Cambiar el método de pago? Los datos de pago anteriores dejarán de ser válidos para este intento. No envíes fondos a esos datos. Si ya realizaste una transferencia, espera a que se procese y NO solicites nuevos datos de pago.» Botones: Volver / Cambiar el método de pago. Abrir la lista no cambia nada. Los datos anteriores se cancelan solo después de preparar y activar correctamente los nuevos; si falla la solicitud, se conservan. Un pago válido detectado vincula la factura a ese intento, incluso para solicitudes desde otra pestaña.

Una transferencia válida que coincide con los datos emitidos vincula la factura a su intento. Espera las confirmaciones exigidas por la red: un pago parcial o la primera detección no son un pago completo confirmado. El fin del temporizador no elimina la transferencia detectada ni detiene las comprobaciones. Decir «ya envié», una cookie, una IP o una dirección de origen no prueban el pago. Antes de entregar bienes o acceso, comprueba el estado final de la factura.

Tras un cambio correcto de método, el intento anterior dispone de una ventana completa de aceptación de 60 minutos desde la activación de los nuevos datos, siempre que los anteriores sigan reservados para esta factura en ese momento. El plazo de pago original no acorta esta ventana: un cambio a las 12:50 la mantiene abierta hasta las 13:50, aunque el plazo original fuera las 13:00 o ya hubiera vencido. Cambiar de red o emitir nuevos datos no restablece una reserva que ya terminó ni amplía su ventana histórica de aceptación. El intento anterior conserva el importe y la cotización emitidos. Los cambios posteriores y reintentos de la solicitud no reinician ni prolongan la ventana de un intento ya cerrado por un cambio anterior. Esta protección cubre transferencias ya enviadas; usa los datos actuales para un pago nuevo. En cada cuenta de comercio se considera primero la asignación histórica demostrada y después una reserva actual válida. Sin ninguna, se registra el pago recibido sin factura identificada y se avisa al comercio. La hora del bloque puede demostrar una asignación antigua aunque la detección llegue tarde. La espera de reutilización no prolonga por sí sola la aceptación; pagar ambos intentos no ejecuta dos veces el pedido.

No. El historial de asignación y la protección contra dobles abonos están separados para cada comercio de Cryptanio. Dentro de una cuenta, los mismos datos comparten una reserva entre listas y proyectos; marcadores únicos compatibles pueden separar asignaciones de una dirección común. Reutilizar una dirección no reescribe su historial. La red, el activo exacto, el marcador obligatorio, el importe y las confirmaciones deben coincidir: una reserva no convierte cualquier transferencia en pago completo.

No se emiten nuevos datos para el método afectado. Un fallo de red afecta a sus métodos; una fuente compartida puede afectar a varios activos. Los métodos independientes que funcionan siguen disponibles. Pausar detiene la emisión sin borrar datos ni historial. Una fuente configurada pausada o averiada no se sustituye silenciosamente por el conjunto manual. Comprueba la causa y restablécela o elige un método independiente; los pagos detectados siguen vinculados a su intento. El comercio recibe un aviso si necesita actuar.