A complete integration
All the steps necessary to complete a successful integration with Safe-e
Last updated
Was this helpful?
All the steps necessary to complete a successful integration with Safe-e
Last updated
Was this helpful?
Safe-e lets you visualize your customers' journeys during the entire interaction phase with your online product, so you can identify the most sophisticated types of fraud that otherwise go unnoticed.
Using the Safe-e API, you can send user activity (which we call events) from both your backend, and it will assess the risk associated with each action.
The following guide explains all the events supported by Safe-e, with recommendations on which ones to integrate. At a high level, the steps to a successful integration:
Send server-side activities such as registration, login, profile updates, and transactions, as well as any business-critical custom events. Server-side events can also be used for real-time blocking of activity, and they will return a set of data such as risk score, risk signals and policy settings.
Configure inline blocking to make use of the inline risk assessment capabilities of the Risk and Filter APIs and take action against suspicious users in real-time.
The login activity is sent to Safe-e whenever a user authenticates on your platform, and provides important information for detecting login related fraud, such as credential stuffing attacks or account takeovers. The inline response from the Risk endpoint can be used at any point in your application to determine when to step up verification.
How to add the Login activities:
The user submits a form with credentials, e.g. email and password;
The email and password are checked against the user database;
If the credentials are correct, send $login
with $succeeded
status.
The response from the API call to Risk can then be used to take different actions, typically:
Upon deny
, block the request and redirect the user back to the login form, with a message that the credentials were incorrect';
Upon challenge
, prompt the user for additional verification, e.g. via email or 2FA, if applicable.
Use the Risk API to send information about the user at the point where the credentials are validated. It doesn't necessarily mean that you have created a session yet (despite the name of the event being "login succeeded"). You should send this event before any additional multi-factor authentication is triggered by your app.