FraudEG no evalúa toda transacción de la misma forma. El motor adapta qué evalúa según el
riel de pago — la familia de instrumento por la que se mueve el pago — porque un fraude
de tarjeta no se parece a un fraude de transferencia, ni uno de cripto se parece a ninguno
de los dos. Cada riel activa un conjunto de señales distinto, pensado para ese tipo de pago.
Por qué payment_method es obligatorio
El riel se deriva del payment_method que envías — por eso es uno de los cuatro campos
obligatorios (ver Campos). El nombre canónico es payment_method;
paymentInstrumentType es un alias de wire del mismo campo, no otro concepto. Sin un
valor reconocible, FraudEG no tiene forma de saber qué familia de señales aplicar.
Los 8 rieles
La tabla canónica de rieles y de cada valor que cae en ellos vive en un solo lugar:
Métodos de pago y rieles. Resumen: card,
account_transfer, bnpl_credit, crypto, cash, wallet_balance, qr,
payment_link. Alias regionales (pse, bre-b, boton_bancolombia, wallet, link,
…) caen en esos rieles; no son rieles extra.
Cuando el riel no se reconoce: unknown
Si el payment_method que envías no coincide con ninguno de los valores de la tabla —o no
lo envías con un valor reconocible— el riel queda en unknown.
unknown es una decisión de diseño, no un descuido. El motor deliberadamente no asume
que un payment_method no reconocido es card — porque card es el riel que más señales
habilita, y asumirlo de forma automática activaría evaluación de tarjeta sobre un pago que
quizás ni siquiera se hizo con una. Bajo unknown, la evaluación es conservadora a
propósito: no se activan señales que dependan de evidencia que la transacción, en los
hechos, no trae. Esto protege al comercio de que se le fabriquen señales de riesgo que no
corresponden al pago real.
unknown es simple: envía un payment_method de la
tabla de rieles, incluidos los alias regionales si tu
integración los usa (pse, bre-b, boton_bancolombia, wallet, link, etc.).
Siguiente paso: Modos de integración.