<IP_DEL_PINPAD> y <PUERTO> por la configuración de tu terminal. Estos ejemplos ilustran el contrato HTTP; no son evidencia de pruebas ejecutadas.
Consulta la referencia de endpoints y el contrato de cada operación antes de adaptar estos ejemplos.
cURL
Disponibilidad
Autorización
tollData. Se fusionan con additionalFields; ante claves coincidentes prevalece tollData. Usa additionalFields para información complementaria. Para CARD cambia únicamente paymentMethod a "CARD" en una operación nueva y resuelta de forma independiente; el PinPAD solicitará la tarjeta. En QR, generar el código ya crea la transacción pendiente.
Consulta del cobro
-i para comprobar Connection: close y Cache-Control: no-store. Solo los endpoints que devuelven HTTP 202 añaden Retry-After: 2; este GET consulta la pasarela y no devuelve 202.
Solicitar cancelación
En
/cancel, DENIED/14 indica abandono por cierre de autorización en curso; 15 indica abandono con intento (QR cancelado). Ninguno confirma cancelación aprobada ni rechazo típico de tarjeta. CANCELLED con 16 o 17 es éxito equivalente, validado por el servicio. Si el cobro QR aparece transaction.state: "AUTORIZADO" en una consulta 200/00, conserva el pago aprobado y registra la discrepancia. Ni /cancel ni refund devuelven pagos QR; no uses /reversals para QR.
Java 11 o posterior
Connection: close. No configures reutilización de conexiones.
C# con .NET
Python con requests
Node.js 18 o posterior
Reglas para cualquier lenguaje
- Persiste
operationNumberantes delPOST. - Envía
operationNumbercomo String de 1–64 caracteres sin espacios; evita/para consultarlo por ruta.amountacepta entero o String numérico positivo. Moneda y método son opcionales (604yCARD); el método no distingue mayúsculas. - Abre una conexión por petición, sin keep-alive; todas las respuestas usan
Connection: close. - Configura 110 segundos para los POST, por encima de la espera aproximada de 90 segundos. Cubre los 12–15 segundos de consulta del cobro; los ejemplos usan 20 segundos.
- Conserva por separado el código HTTP y el JSON.
- Confirma autorización con HTTP
200,success: true,resultCode: "00"yresult.state: "AUTORIZADO". En consulta200/00, interpretatransaction.state:00solo significa encontrada. - Reconoce cancelación validada con
CANCELLEDy00,16o17.DENIED/14y HTTP200aislado no confirman éxito. - Ante cancelación fallida o incierta, consulta el cobro original. Una consulta fallida o incierta (
200/03,404/05,503,504) no permite otro cobro ni confirma rechazo. - Una falla de conexión no garantiza recepción de
/cancelni cierre de pantalla. - Los ciclos repiten solo el GET correspondiente; no reenvían
/cancelni generan otra venta. - Ante timeout, desconexión o fallo del backend, muestra Cancelación no confirmada y consulta el estado.
- No repitas un extorno exitoso o en curso. Tras
DENIED,UNKNOWNoERRORfinales, un nuevo POST puede ejecutar otro intento; consulta y decide antes, sin reintento automático ante incertidumbre. - No sustituyas un resultado confirmado por un
202 WAITING_RESULTtardío de/authorize. - Autorización
202usaWAITING_RESULTyresult: null. La consulta del cobro no tienestatuspropio ni devuelve202. ExtornoUNKNOWNdevuelve502y es final localmente; revisa si se ejecutó sin asumir éxito. - El cuerpo compacto de extorno
UNKNOWNutilizamessage. - Conserva los códigos SDK; en cancelación y extorno,
P22se clasifica comoPENDING. No extrapoles el modelo propio a la autorización o consulta del cobro. - Respeta
Retry-After: 2en HTTP202. - Serializa los cobros dirigidos al mismo terminal.
- No registres datos sensibles de tarjeta.

