Skip to main content
El sistema central del comercio actúa como cliente HTTP. La aplicación Pay-me PinPAD instalada en el Wiseasy P5L actúa como servidor HTTP sobre la red local. Reemplaza <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

Los datos estructurados del peaje van en 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

Usa -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

La respuesta informa el resultado de la solicitud de cancelación. Usa el GET del cobro únicamente para recuperarlo ante fallo, timeout o incertidumbre; no existe un GET de 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

En Java, cada envío crea su cliente y usa HTTP/1.1; el servidor responde Connection: close. No configures reutilización de conexiones.

C# con .NET

Python con requests

Node.js 18 o posterior

Reglas para cualquier lenguaje

  • Persiste operationNumber antes del POST.
  • Envía operationNumber como String de 1–64 caracteres sin espacios; evita / para consultarlo por ruta. amount acepta entero o String numérico positivo. Moneda y método son opcionales (604 y CARD); 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" y result.state: "AUTORIZADO". En consulta 200/00, interpreta transaction.state: 00 solo significa encontrada.
  • Reconoce cancelación validada con CANCELLED y 00, 16 o 17. DENIED/14 y HTTP 200 aislado 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 /cancel ni cierre de pantalla.
  • Los ciclos repiten solo el GET correspondiente; no reenvían /cancel ni 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, UNKNOWN o ERROR finales, 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_RESULT tardío de /authorize.
  • Autorización 202 usa WAITING_RESULT y result: null. La consulta del cobro no tiene status propio ni devuelve 202. Extorno UNKNOWN devuelve 502 y es final localmente; revisa si se ejecutó sin asumir éxito.
  • El cuerpo compacto de extorno UNKNOWN utiliza message.
  • Conserva los códigos SDK; en cancelación y extorno, P22 se clasifica como PENDING. No extrapoles el modelo propio a la autorización o consulta del cobro.
  • Respeta Retry-After: 2 en HTTP 202.
  • Serializa los cobros dirigidos al mismo terminal.
  • No registres datos sensibles de tarjeta.
La solicitud y consulta de extorno están en Extorno de una venta CARD aprobada.
Los ejemplos se concentran en el contrato HTTP. En producción, serializa JSON con la biblioteca estándar del lenguaje, valida las respuestas y persiste el estado antes de ejecutar una acción de negocio irreversible.