Añada un comercio o un mercado desde el portal
Su decisión ocurre dentro del checkout de otro, con su tráfico y su presupuesto de latencia. Tiene que responder rápido, responder igual siempre y responder a la pregunta correcta: qué financiación se le puede ofrecer de verdad a este cliente aquí.
Reglas deelegibilidad
Política porcomercio
Scoringinstantáneo
Endpointsregionales
La decisión detrás del botón
La elegibilidad en finanzas embebidas casi nunca es una regla. Es un conjunto de restricciones que hay que resolver juntas, en una sola llamada.
Qué financiación aplica
Cruza cliente, cesta, comercio, mercado y catálogo de producto en una sola decisión, en lugar de codificar la elegibilidad a mano en cada integración.
Reglas por comercio y por mercado
La misma plataforma con restricciones distintas por comercio, segmento y jurisdicción. La lógica sigue siendo un solo flujo, sin una variante por socio.
Crédito y capacidad al instante
Scoring, capacidad de pago y señales de fraude resueltos dentro del flujo, con las consultas externas en paralelo para que la latencia la marque la llamada más lenta y no la suma.
Consistencia entre canales
La respuesta de elegibilidad en el checkout y la del portal del socio salen del mismo flujo de decisión, así que no pueden discrepar.
De la política a una respuesta en el checkout
La tabla de decisiones, sus entradas y una versión de prueba con nombre forman un flujo conectado.
Tiempo real, y casi solo tiempo real
Es lo más sensible a la latencia que hacemos, y la superficie que importa son las decisiones instantáneas.
- Endpoints en tiempo real, en su región. Una llamada REST desde la integración del socio, respondida en milisegundos con decisiones en tiempo real.
- Consultas en paralelo con planes alternativos. Buró, fraude y dispositivo se llaman a la vez dentro del flujo, con los timeouts y alternativas que usted fija: un proveedor lento degrada la decisión, no cuelga el checkout.
- Cambie las reglas sin una release del socio. Los cambios de elegibilidad se publican como un release de su lado, no como un cambio de código en cada integración.
Alguien sigue teniendo que responder por la decisión
Distribuir a través de un socio no traslada la obligación. Cuando el producto subyacente es crédito al consumo, la evaluación de solvencia entra en el Anexo III del Reglamento de IA desde el 2 de diciembre de 2027, y el artículo 22 del RGPD ya aplica a la denegación de hoy. La traza tiene que existir aunque el cliente nunca haya visto su marca.
Preguntas que nos hacen
¿Qué latencia debemos esperar?
Espere una latencia de milisegundos para las reglas y los modelos.
¿Puede variar la elegibilidad según el comercio y el mercado?
Sí. Las restricciones del comercio, el mercado, el segmento y el producto se resuelven conjuntamente en una sola decisión, en lugar de estar dispersas entre integraciones.
¿Qué sucede cuando un proveedor de datos es lento o no está disponible?
Usted define el tiempo de espera y la alternativa de respaldo. La decisión sigue la alternativa de respaldo que usted especifique, en lugar de fallar o quedarse bloqueada.
¿Cómo implementamos un cambio de reglas entre nuestros socios?
Usted lo implementa como un release por su parte. Los socios siguen llamando al mismo endpoint, mientras la lógica avanza por su proceso de aprobación.
¿Necesitamos gestión de casos para esto?
Normalmente, no. Las decisiones de finanzas integradas se responden en una sola solicitud. Si también gestiona disputas o investigaciones de contracargos, estas corresponden a la gestión de casos.
Verlo responder en milisegundos
Envíe una petición, mire cómo se resuelven las restricciones de elegibilidad y abra la traza detrás de la respuesta.