Personalización contra el fraude
Diseñe, pruebe y gestione las señales de fraude, las decisiones del proveedor, el enrutamiento y los comentarios de resultados sin vincular la ejecución a un resultado del navegador.
En esta página
Personalice los controles de fraude como un sistema de decisión integral: recopile las señales permitidas, solicite una decisión al proveedor configurado, traduzca esa decisión en una acción de pago y devuelva los resultados confirmados para que el modelo pueda mejorar.
Ciclo de vida de la decisión de fraude#
01 · observe
Recopile las señales aprobadas
Envíe el contexto preciso del pedido, del cliente, del vendedor, de la dirección y del dispositivo que el proveedor seleccionado admita.
02 · assess
Evalúe el riesgo
DEUNA invoca la conexión anti-fraude activa en el punto configurado de la estrategia de pago.
03 · act
Aplique la política
Continúe, solicite autenticación, suspenda para revisión, dirija de forma diferente o rechace según el resultado estandarizado.
04 · confirm
Reconcilie el estado del pago
Utilice el estado de pago autorizado o un webhook verificado antes de la ejecución.
05 · learn
Devuelva los resultados
Envíe los resultados de fraude y de reclamación acordados para que el proveedor pueda evaluar el rendimiento del modelo.
Diagrama de flujo
El nivel de riesgo por sí solo no es un resultado de pago. Una transacción de bajo riesgo aún puede ser rechazada por un procesador, y una autenticación completada aún puede dar lugar a una autorización fallida. Mantenga el fraude, la autenticación y el estado del pago como campos separados.
Elija la tarea de personalización#
Huella digital del dispositivoGenere y transmita el identificador de dispositivo requerido por el proveedor de fraude o de pago configurado.Web and supported SDK flowsModo "Shadow"Compare las decisiones del proveedor en el tráfico de producción antes de que un nuevo modelo afecte al recorrido del cliente.Observe without blockingRetroalimentación de resultadosEnvíe los resultados históricos de reclamación acordados sin confundir la ingestión de comentarios con la gestión de disputas.Email or provisioned SFTPEstrategias de pagoRealice la evaluación de fraude antes o después de la autorización y defina la acción para cada resultado admitido.Decision to actionEstados de fraudeEvalúe el fraude por separado del ciclo de vida financiero y del estado de revisión manual.State and decisionsCapacidades de proveedoresConfirme dónde está publicado cada proveedor anti-fraude y abra su guía de conexión.Country and capability filters
Decida dónde se ejecuta el fraude#
| Ubicación | Qué protege | Principal compromiso | Manejo requerido |
|---|---|---|---|
| Antes de la autorización | Evite enviar intentos bloqueados por la política al procesador | Un tiempo de espera de fraude puede retrasar o detener el pago antes de que exista una autorización | Defina el tiempo de espera y el comportamiento de respaldo; no invente un resultado de pago |
| Después de la autorización | Permite que el proveedor evalúe el contexto del procesador y de la autorización | Una autorización aprobada puede necesitar ser anulada cuando el riesgo rechaza el pedido | Mantener la operación bloqueada y verificar el resultado de la anulación o captura. |
| Modo "Shadow" | Medir un proveedor sin alterar las decisiones de pago. | Los resultados son observacionales y no deben convertirse automáticamente en un mecanismo de control. | Separar las métricas de comparación de las entradas de enrutamiento en tiempo real. |
| revisión manual | Añadir una revisión humana o del proveedor antes de la acción final. | El flujo del cliente y de la operación permanecen pendientes por más tiempo | Trate manual_review y consumen el estado autoritativo posterior. |
Uso Autenticación dinámica Cuando el resultado de la detección de fraude selecciona un control de verificación, como 3DS. Utilice revisión manual para las transacciones retenidas y 3DS para el comportamiento de autenticación del emisor.
Señal de contrato#
Enviar solo los datos que sean precisos, permitidos y soportados por el proveedor seleccionado. Más campos no producen automáticamente una mejor decisión.
| Grupo de señales | Ejemplos | Regla de integración |
|---|---|---|
| Orden | Monto, moneda, artículos, envío, descuentos | Mantener los totales consistentes con el pedido procesado por el backend. |
| Cliente | Referencia del cliente estable, historial de cuenta, contexto de contacto | No incluir credenciales secretas ni datos personales irrelevantes en campos de texto libre. |
| Dispositivo | Huella o identificador de sesión de dispositivo compatible con el proveedor. | Generarlo en el flujo del cliente soportado y vincularlo al mismo intento de pedido. |
| Plataforma de comercio electrónico | Identificadores de vendedores y atributos de vendedores aprobados | Confirmar cuáles marketplace_sellers campos realmente consume el proveedor. |
| Resultado | Resultado de pago, fraude confirmado o estado de disputa acordado | Enviar de forma idempotente con el identificador de transacción de DEUNA |
Implementar de forma segura#
- Confirmar el soporte. Seleccionar el proveedor, los mercados, los canales y la ubicación de la evaluación a partir de la funcionalidad y el contrato comercial publicados.
- Definir la política. Escribir la acción para cada resultado de proveedor soportado, tiempo de espera, respuesta no disponible y resultado de revisión manual.
- Mapear las señales. Documentar la fuente autoritativa, el formato, la base de consentimiento y la alternativa para cada campo que se envía.
- Validar en sandbox. Ejercitar los casos de cobertura baja, media, alta, no disponible, tiempo de espera, duplicado y señal malformada.
- Comparar en modo de sombra. Medir la cobertura y la discrepancia antes de cambiar un nuevo proveedor o modelo a la ejecución.
- Liberar gradualmente. Monitorizar los resultados de aprobación, desafío, revisión, falsos positivos, fraude y pago juntos.
- Cerrar el ciclo. Devolver los resultados aprobados a través de Flujo de retroalimentación en casos de reclamación.
Lista de verificación operativa#
- Mantenga las credenciales del proveedor privadas en DEUNA Admin o en un backend seguro, nunca en el código del navegador o móvil.
- Relacione la evaluación de fraude, el intento de pago, el pedido y el resultado posterior con identificadores estables.
- Haga que los reintentos sean idempotentes; un tiempo de espera del cliente no prueba que una evaluación o pago haya fallado.
- Conserve la referencia del proveedor original requerida para el soporte, exponiendo solo la decisión normalizada para la lógica de negocio.
- Notifique sobre la falta de datos del dispositivo, la latencia de la evaluación, las respuestas no disponibles, la deriva de la decisión y los fallos en el procesamiento de la retroalimentación.
- Revalide la estrategia cada vez que un proveedor, SDK, mercado o señal requerida cambie.