Reintenta el mismo pedido con su request_id original y sus parámetros sin cambios. No crees otra clave porque haya expirado la conexión. NotPanel puede devolver el pedido ya aceptado o pedirte que esperes si todavía se está procesando.
El cliente hizo una compra. Si la respuesta desaparece después de enviarla al panel, tu siguiente paso debe recuperar esa compra sin convertir la incertidumbre en otra compra.
Un timeout deja tres posibilidades
- La solicitud nunca llegó y no se aceptó ningún pedido.
- El pedido se aceptó, pero la respuesta se perdió.
- La solicitud sigue en proceso y su resultado todavía no se conoce.
El timeout no distingue estos casos. HTTP no hace seguro repetir un POST de compra por sí solo; esa protección depende del contrato de la API. Consulta RFC 9110, §9.2.2.
Cómo reconoce NotPanel un reintento
request_id es opcional, no puede estar vacío y admite hasta 128 caracteres. idempotency_key es su alias; si envías ambos, prevalece request_id. Para el mismo pedido, conserva la cuenta, la clave y todos los parámetros. Un pedido aceptado devuelve su ID original; reutilizar la clave con parámetros distintos se rechaza.
Sin ambas claves, NotPanel protege durante 60 segundos los add idénticos de la misma cuenta. No dependas de esa ventana para reintentos posteriores. Las solicitudes sin resultado confirmado siguen protegidas mientras se comprueba su resultado.
Dos compras intencionadamente idénticas también se agrupan dentro de esa ventana. Asigna un request_id distinto a cada compra nueva para separarlas inmediatamente. No cambies la clave para eludir un resultado incierto.
Parámetros y respuestas de creación de pedidos
Conserva el request_id original tras un timeout.
Reintenta con la misma clave y los detalles del pedido sin cambios.
Guarda el ID recuperado o espera si el resultado sigue sin confirmarse.
Identifica la compra antes de enviarla
Para la línea de compra 8427, guarda el request_id y los parámetros completos antes del primer intento. El esquema usa marcadores y saltos de línea; codifica normalmente el formulario real. Solo envíalo con valores reales si quieres realizar un pedido de pago.
POST https://notpanel.com/api/v3
Content-Type: application/x-www-form-urlencoded
key=YOUR_API_KEY
&action=add
&service=YOUR_SERVICE_ID
&link=YOUR_TARGET_URL
&quantity=YOUR_VALID_QUANTITY
&request_id=checkout-8427-line-1Después del timeout, vuelve a enviar checkout-8427-line-1 con el mismo servicio, destino, cantidad y campos opcionales, incluso tras reiniciar la aplicación. Guarda el ID devuelto y úsalo en status. request_id identifica la creación; no sustituye al ID de pedido en una consulta de estado.
Lee el resultado completo
- Timeout o respuesta incierta
- Conserva clave y parámetros. Limita los reintentos, espera entre ellos y respeta Retry-After. Si agotas los intentos, conserva el registro pendiente.
- REQUEST_PROCESSING o REQUEST_UNCONFIRMED
- Espera y repite únicamente la solicitud original. No crees un reemplazo con otra clave.
- REQUEST_ID_CONFLICT
- Compara los parámetros guardados. Recupera el pedido con los originales; una clave nueva corresponde a una compra deliberadamente distinta.
- Validación, autenticación o límite de solicitudes
- Lee error_code y retryable. Corrige datos o credenciales y respeta las esperas del límite. No repitas automáticamente cualquier error.
Prueba la recuperación antes de atender compras
Empieza con una API simulada en tu entorno de pruebas. No necesitas una compra real ni una clave especial de NotPanel.
- Simula un pedido aceptado cuya respuesta se pierde; comprueba que se reutilizan clave y parámetros.
- Reinicia el cliente y recupera la misma identidad guardada.
- Simula primero procesamiento y luego éxito; guarda un único ID de pedido.
- Simula un conflicto o error no reintentable; comprueba que el bucle se detiene.
- Crea dos compras nuevas idénticas con claves diferentes. Para una prueba real posterior, usa un pedido que quieras y revisa pedido y movimientos del monedero.
Preguntas frecuentes
¿Un timeout significa un doble cobro?
No. Significa que no recibiste una respuesta utilizable. Revisa el pedido recuperado y los movimientos del monedero antes de concluir que hubo dos cargos.
¿Es obligatorio request_id?
No. request_id e idempotency_key son opcionales. Sin ellos hay protección de 60 segundos para add idénticos de la misma cuenta. Una clave explícita identifica cada compra.
¿Genero otra clave en cada reintento?
No. Guarda una clave antes del primer intento y reutilízala sin cambiar el pedido. Una compra nueva recibe una clave nueva.
¿Puedo consultar status con request_id?
status requiere el ID del pedido. Recupéralo repitiendo el add original con su clave y parámetros. Si sigue sin confirmarse, conserva los detalles para soporte sin crear otro pedido.
Continúa con: la guía de integración · webhooks y consultas de estado · la referencia de errores.
