Skip to main content

Preguntas frecuentes

Ambiente de pruebas​

¿Qué tarjetas de prueba puedo usar para simular un pago aprobado y uno rechazado?​

Para simular un pago aprobado, pedile al equipo SiPago una tarjeta habilitada para el ambiente de pruebas.

Para simular un pago rechazado, podés usar cualquier tarjeta Visa o Mastercard que tengas. El ambiente de pruebas va a rechazar el pago.

Las credenciales de desarrollo son compartidas. ¿Los demás integradores pueden ver mis órdenes? ¿Puedo tener credenciales de prueba propias?​

Las credenciales de desarrollo son compartidas. Sin embargo, los demás integradores no pueden ver las órdenes que creás, porque necesitarían conocer el UUID de la orden para acceder a ella.

No es posible generar credenciales individuales para cada comercio en el ambiente de pruebas, por eso las credenciales son compartidas.

Paso a producción​

¿Hace falta alguna homologación o aprobación antes de operar en producción, o alcanza con generar las credenciales en el portal?​

Para operar en producción, tenés que generar las credenciales en el portal (Tiendas → Credenciales Checkout). Para eso, solicitá autorización a SiPago a través de la filial correspondiente. Una vez que Sistemas apruebe la solicitud, te habilitamos el acceso al módulo de credenciales.

¿Cuál es el dominio del checkout en producción?​

El dominio es https://checkout.sipago.coop.

Los links de pago tienen este formato:

https://checkout.sipago.coop/orders/{uuid}

Webhook y estados​

¿El webhook viene firmado o se envía desde IPs fijas que pueda validar?​

El webhook no viene firmado: no incluye ningún encabezado de firma, HMAC ni mecanismo de autenticación.

No tenemos confirmación de nuestro proveedor, pero, según nuestras pruebas, todos los pagos en producción generaron webhooks desde la IP 54.173.130.251, que pertenece a AWS.

No uses la IP como única validación

Esa IP no está garantizada y puede cambiar sin aviso. Si filtrás los webhooks solo por IP y cambia, vas a dejar de recibir los avisos sin enterarte. Para validar un webhook:

  1. Agregá un token secreto en tu webhookUrl (por ejemplo, ?token=UN_SECRETO_TUYO) y rechazá los avisos que no lo traigan.
  2. Confirmá siempre el estado con GET /api/v2/orders/{uuid} antes de dar el pedido por pagado.

¿El endpoint GET /api/v2/orders/{uuid} requiere el encabezado Authorization?​

No. Es un endpoint abierto, cuya seguridad se basa en que no se puede adivinar el UUID de una orden ajena.

¿Se envía un webhook cuando un pago es rechazado y el comprador reintenta dentro de la misma orden? ¿La orden pasa por otros estados?​

Sí. Cada intento de pago dentro de la misma orden genera su propio webhook. Lo verificamos en producción.

El intento rechazado llegó con la orden en estado PENDING y el pago en estado DENIED. En cambio, el reintento aprobado llegó con la orden en estado SUCCESS y el pago en estado APPROVED.

La orden se queda en estado PENDING mientras el comprador hace nuevos intentos de pago.

Los estados posibles de la orden son PENDING, SUCCESS, EXPIRED, FAILED_CHECKOUT y FAILED. No observamos otros estados.

Dos aclaraciones importantes:

  • Consulta de la orden por API: si hubo intentos rechazados, el campo payment puede venir en null, incluso cuando la orden está en estado SUCCESS. Todos los intentos están en el listado payments[], donde figura el intento rechazado con su código de error (por ejemplo, 05 – Denegada). Para confirmar el pago, buscá en payments[] el registro cuyo status sea APPROVED.

  • Vencimiento: si usás expireLimitMinutes y el link vence, no se envía ningún webhook. En esos casos, consultá el estado de la orden por API.

¿Cuáles son los valores mínimo y máximo de expireLimitMinutes?​

  • Mínimo: 0, que significa que la orden no vence. Lo mismo pasa si no enviás el campo. El vencimiento efectivo más corto es de 1 minuto, con unos segundos de margen.
  • Máximo: no tiene un límite de negocio establecido.
  • Formato: tiene que ser un número entero en el JSON.

Checkout​

¿Puedo personalizar el checkout con mi logo? ¿Cómo figura el comercio en el resumen de la tarjeta del comprador?​

No es posible personalizar el checkout, porque depende de nuestro proveedor, que ofrece un formato fijo.

¿Puedo enviar el email o el documento del comprador para precargarlos?​

No es posible precargar los datos del comprador en el checkout, por el mismo motivo: el formato depende de nuestro proveedor.

¿SiPago le envía un comprobante al comprador?​

Sí. Si el comprador ingresa su email, recibe una notificación cuando el pago se aprueba.

¿Hay restricciones de formato en los ítems?​

Por ejemplo, que el campo id sea numérico o que name tenga una longitud máxima:

  • id: no tiene restricciones de formato. Acepta números, texto, valores negativos y 0. También lo podés omitir. Sin embargo, el identificador no se guarda y la consulta de la orden devuelve itemId: null. No lo uses para conciliar operaciones: para eso, guardá el UUID de la orden.

  • name: no se valida la longitud. Se aceptan hasta 100.000 caracteres sin error, pero el valor se guarda truncado a 100 caracteres. Enviá como máximo 100 caracteres para que el texto no se corte en el checkout.

  • quantity: tiene que ser un número entero. Si enviás un decimal, recibís un error HTTP 400.

  • unitPrice.amount: tiene que ser un número entero que represente el importe en centavos. Por ejemplo, para $200,69 enviá 20069. Si enviás un decimal, recibís un error HTTP 422.