En esta sección encontrarás información técnica importante para iniciar con tu integración.
Base URL
Existen dos ambientes distintos en el que tendran interacción las integraciones a nuestros productos: un ambiente de STAGING y un ambiente de PRODUCCIÓN.
STAGING
https://gw-staging-qrbind.epays.services
Copy code
PRODUCCIÓN
https://api.bindpagos.com.ar
Copy code
Autenticación y Autorización
Implementamos un modelo basado en OAuth 2.0.
Para interactuar con nuestros endpoints, cada solicitud debe estar autenticada mediante un token de acceso de tipo Bearer.
Deberás solicitar tu token de acceso exponiendo tus credenciales en nuestro endpoint de Obtener token. Luego, en cada request subsecuente a nuestras APIs, deberás incluir el token en el header HTTP de Authorization.
Nuestro equipo de soporte de integraciones es el responsable de gestionar y enviar a la entidad las credenciales para cada ambiente y producto, necesarias para obtejer el token de autenticación y autorización.
Cada API validará la vigencia de tu token y verificará que los scopes asociados coincidan estrictamente con los permisos requeridos para la operación que intentás ejecutar.
Si tenes un problema en la obtención del token o en el uso del mismo (errores HTTP 401 o HTTP 403) verificá estar usando las credenciales correctas para el ambiente y producto en el que querés operar.
Ejemplo de Header:
HTTP
Copy code
Obtener token
STAGING
POST
https://login.microsoftonline.com/61ef5b89-8df3-499d-8c13-38fed5d09c72/oauth2/v2.0/token
pRODUCCIÓN
POST
Devuelve el Bearer access token para poder consumir las APIs de Bind PSP.
Debe agregarse como Bearer token al Authorization header de todas las llamadas.
Tiene una duración de 60 minutos. Luego de vencerse, debe solicitarse uno nuevo con este mismo método.
Tanto el endpoint como las credenciales son distintos para cada ambiente.
Las credenciales cambian para distintos productos.
Request
client_id string
— REQUIRED
Identificador del usuario único para la Entidad consumiendo las APIs.
Valores posibles: Indicado por Bind PSP a la entidad.
client_secret string
— REQUIRED
Contraseña del usuario única para la Entidad consumiendo las APIs.
Valores posibles: Indicado por Bind PSP a la entidad.
grant_type string
— REQUIRED
Valor fijo: "client_credentials"
scope string
— REQUIRED
Valor fijo dependiendo del ambiente.
Valores posibles: "api://staging-bind.epays.services/.default" (ambiente de staging),
"api://bindpagos.com.ar/.default" (ambiente de producción)
curl request
Copy code
Response
token_type string
Tipo de token de autenticación.
Valor fijo: "Bearer"
expires_in int
Tiempo en que se expirará el token en segundos.
ext_expires_in int
Tiempo en que se expirará el token en segundos.
access_token string
Token a utilizar en el Authorization Header de todas las llamadas a las APIs del producto.
HTTP 200
Consulta exitosa
HTTP 401
Token de autenticación inválido
Seguridad en conexiones
Implementamos un modelo basado en OAuth 2.0 y comunicación cifrada para garantizar la integridad y confidencialidad de los datos financieros.
Solo HTTPS: Todas las llamadas a nuestras APIs deben realizarse obligatoriamente a través de HTTPS (TLS 1.2 o superior). No se admitirán conexiones HTTP tradicionales.
Conectividad: No implementamos canales de comunicación privada como VPNs. Toda la interacción se realiza de forma segura sobre la red pública mediante el cifrado de transporte mencionado.
Seguridad en Webhooks
Por defecto, las invocaciones de webhooks que nuestro servidor realiza hacia tus sistemas no incluyen mecanismos de seguridad adicionales en la capa de aplicación. Es decir, la carga útil (payload) se enviará directamente a la URL que hayas configurado.
Las invocaciones se realizan desde una ip fija por cada ambiente. Por lo que es una buena práctica que del lado del servidor de la entidad hagan una whitelist con estas IP desde las cuales recibiran webhooks.
Si necesitas nuestras direcciones de IP para tu whitelist, por favor ponete en contacto con nuestro equipo de soporte de ingraciones para que te facilite esa información.
Política de envío de webhooks
Ante el envío de un webhook de notificación de cualquier tipo de evento desde nuestro sistema hacia el servidor de la entidad cliente, nuestro sistema espera una respuesta HTTP 200 para determinar que el mensaje fue recibido exitosamente.
Cuando la URL destino del webhook no responde con un HTTP 200, según nuestra política de reintentos , nuestro sistema intentará enviar el webhook 10 veces con una estrategia de espera creciente, buscando darle tiempo a su servidor para recuperarse sin saturarlo.
Secuencia de Reintentos (Tiempo desde el intento anterior):
Intentos 1 al 6: Se realizan rápidamente, espaciados en 18-19 segundos (todo en menos de 2 minutos).
Intentos 7 al 8: El intervalo aumenta a 2 minutos y 10 segundos para esperar una recuperación de fallos temporales.
Intentos 9 al 10: El tiempo se extiende a 1 hora entre cada envío, dando margen para solucionar problemas mayores de infraestructura.
Si en cualquier intento recibimos un HTTP 200, el proceso se detiene de inmediato.
Si el décimo intento falla, la notificación se marca como fallo definitivo y no se realizarán más envíos.
Capa de Seguridad Avanzada (Opcional)
Si las políticas de cumplimiento de tu organización requieren un nivel de seguridad más estricto, ofrecemos soporte para certificados SSL mutuos (mTLS). Esta capa se puede habilitar de dos formas independientes o combinadas:
Inbound (Consumo de APIs): Validación de certificado de cliente cuando tu sistema consume nuestras APIs expuestas.
Outbound (Webhooks): Validación de certificado de nuestro lado cuando enviamos webhooks hacia tus servidores.
Si requerís la activación de esta capa avanzada mediante certificados, por favor ponete en contacto con nuestro equipo de soporte de integraciones para el intercambio de claves y configuración.
