Skip to main content
Usa POST /cancel para solicitar la cancelación de una autorización iniciada con POST /authorize que todavía continúa en curso.

Cancelar autorización activa

Usa POST /cancel mientras la autorización original sigue en curso. El resultado final puede ser CANCELLED o DENIED.

Extornar venta aprobada

Si la venta ya terminó como APPROVED, usa POST /reversals.
No uses /cancel para una venta ya aprobada y no uses /reversals para cancelar una autorización activa. Son operaciones distintas.
​
endpoint

​
Solicitud

POST /cancel se consume en el mismo host y puerto configurados para POST /authorize.
URL completa:

​
Cuerpo JSON confirmado

No generes otra referencia y no envíes monto, moneda, medio de pago ni datos de tarjeta.

​
cURL

Reemplaza la IP y el puerto por los mismos valores usados para POST /authorize.

​
Respuestas confirmadas

Cuando el POST responde HTTP 200, el resultado final viene en el cuerpo de esa misma respuesta. Evalúa siempre status: un HTTP 200 no confirma por sí solo que la autorización fue cancelada.
HTTP 202 no es una cancelación exitosa ni fallida. No confirmes CANCELLED, no inicies un extorno y no cierres la operación solo por haber recibido 202.

​
Ejemplos de respuesta

Cancelación confirmada — 200 CANCELLED

Los ejemplos de HTTP 200 muestran únicamente los campos de decisión confirmados; conserva cualquier campo adicional que entregue la implementación.
CANCELLED confirma que la autorización en curso terminó cancelada. El resultado puede haberse obtenido en esta solicitud o provenir del resultado final guardado para el mismo operationNumber.
DENIED es un resultado final, pero no confirma una cancelación. Conserva el resultado y no marques la autorización como cancelada.
Respeta el valor de Retry-After antes de cualquier acción posterior. La espera interna venció, pero este cuerpo no informa todavía el resultado final.
El número de operación no existe en el PinPAD que recibió la solicitud. Verifica tanto la referencia como el terminal de destino.
El SDK no está listo o no existe una pantalla disponible para procesar la solicitud. Recupera la disponibilidad antes de reintentar.

​
Manejo de 202 y pérdida de conexión

  1. Conserva el operationNumber original y el estado pendiente en almacenamiento persistente.
  2. Respeta Retry-After; no interpretes el vencimiento de 90 segundos como resultado financiero.
  3. No uses GET /reversals/{operationNumber}: ese endpoint consulta extornos, no cancelaciones.
  4. No inventes ni implementes GET /cancel/{operationNumber} sin una confirmación contractual.
Pendiente de confirmar: la documentación disponible no define un endpoint de consulta ni otro mecanismo de recuperación para obtener el resultado final de /cancel después de HTTP 202, un timeout o una pérdida de conexión. Antes de producción, acuerda con Alignet el procedimiento de recuperación y conciliación.

​
Flujo recomendado para el sistema central

1

Comprueba que la autorización sigue activa

Usa /cancel solo mientras la autorización original continúa en curso. Si ya fue aprobada, sigue el flujo de extorno.
2

Reutiliza la referencia original

Envía el mismo operationNumber de POST /authorize al mismo host y puerto del PinPAD.
3

Procesa la respuesta del POST

Ante HTTP 200, usa el cuerpo recibido: CANCELLED confirma la cancelación y DENIED no la confirma.
4

Mantén abiertos los resultados pendientes

Ante HTTP 202, timeout o pérdida de conexión, conserva la referencia y no tomes una decisión final hasta aplicar el mecanismo que Alignet confirme.

Extorno de una venta aprobada

Revisa el contrato separado de POST /reversals.

Solicitud de autorización

Revisa POST /authorize y la creación del operationNumber original.