Overview
Introduction
Mangopay’s fraud prevention solution lets you define custom logic to detect and mitigate fraudulent attempts on your platform.
On the Essential plan, you can use the solution without additional integration from within the Mangopay Dashboard to monitor transactions, create and test your rules, and leverage network-wide insights from Mangopay. In this case, the solution relies only on information already available in the transaction data (such as IP address, user and payment details, etc).
On the Advanced plan, you can also integrate the profiler in your user-facing pages to collect additional data from their browsing session which can enhance your fraud-detection capabilities thanks to proprietary technology. This option leverages a wide range of data signals that can help detect bots, VPNs, and abnormal network settings or user behavior.
See a full feature comparison on our pricing page.
Safeguard your platform
Enjoy a 30-day free trial of our Advanced fraud prevention plan and see our solution in action. No charges apply, subscribe when ready.
How it works
Mangopay’s fraud prevention solution safeguards your platform by screening events. The solution analyzes data of events screened and, based on your custom rules, generates recommendations.
The diagram below shows the example of pay-in fraud prevention:
Profiling session (optional)
Optionally, the profiler runs a profiling session to collect data (if integrated).
Event to be screened
A user proceeds to checkout and makes a payment on your app or website.
Pay-in request
Your server requests a pay-in (and includes the ProfilingAttemptReference
if applicable).
Inquiry
Your pay-in request triggers an inquiry, which is a request to screen the pay-in event.
Rule sets
The fraud prevention solution runs your custom rules and Mangopay’s default rules.
Recommendation
The solution generates a recommendation for the inquiry: Accept, Review, or Refuse.
Action to be applied
The recommendation is implemented by the API for Active rules in Active rule states:
- Accept – Request payment
- Review – Request payment with 3DS
- Refuse – Set pay-in status to
FAILED
Events screened
In the pay-in scope, the following API requests are screened:
- Pay-ins of all types, including pay-ins to virtual IBANs
- Recurring pay-in registrations
- Preauthorizations
- Deposit preauthorizations
Note - All API requests are screened
All API calls from the platform are screened by the fraud prevention solution, regardless of what rules you have configured and whether the profiler is integrated.
The API object must be successfully created to be screened, meaning it returns a 200 HTTP code, regardless of the object’s status.
Other scopes for event screening are planned in future, such as payouts.
Actions triggered by recommendations
Note - Actions only automated by Active rules in Active rule sets
The Mangopay API automatically applies the following actions in response to a recommendation generated by an Active rule in an Active rule set. The Simulation state does not automatically trigger action based on a recommendation. See States for more information.
For Active rules in Active rule sets, recommendations automatically trigger the following actions in the Mangopay API depending on the event:
Recommendation | Pay-in: Card, Google Pay | Pay-in: Other |
---|---|---|
Accept | Payment requested | Payment requested |
Review | Payment with 3DS requested (regardless of SecureMode value) | Payment requested |
Refuse | Payment not requested | Payment not requested |
Accept
For pay-ins, the payment is requested by Mangopay from the issuer (who may still refuse the transaction as usual).
Review
For card pay-ins, Mangopay requests 3DS authentication from the issuer, regardless of the choice of the platform indicated by the SecureMode
parameter. The issuer may not enforce SCA (see the 3DS article for more information).
For non-card pay-ins, the Review recommendation has the same effect as Accept.
Refuse
For pay-ins, the payment is not requested from the issuer and the pay-in object Status
is set to FAILED
with the following error:
- 008500 - Transaction blocked by fraud policy
Other recommendations
There are other recommendations which have the following functions:
- Overriding Accept - Accepted regardless of the other recommendations returned (by other rules in the rule set, or by other rule sets for the inquiry).
- Trust - Should not be used by platforms. In future, Mangopay intends to manage 3DS exemptions using the Trust recommendation. Until then, if used, Trust would have the same effect as Accept.
In the details of an inquiry you can see the full logic that generated the final recommendation, including which sets were run to generate which recommendations (at the level of the rule set and the rules within it).
Best practice – Send a maximum of inquiry data (where possible)
The more data you send to the Mangopay API for an event screened, the more effective your fraud prevention rules can be.
Inquiry data
The following table shows how the data points of the Mangopay API feed the fraud prevention panel displayed in the Mangopay Dashboard.
Fraud prevention panel | Mangopay API data |
---|---|
Inquiry reference, transaction reference | Transaction’s Id |
Inquiry origin | Indicates the payment method |
User reference | Transaction’s AuthorId |
Person type | Whether a Natural or Legal user |
KYC validated | True if User’s KYCLevel is REGULAR |
Is blocked | True if User has either outflows or inflows blocked (see User Regulatory Status) |
Registration datetime | User’s CreationDate |
Registration address | User’s Address (if Natural) or HeadquartersAddress (if Legal) |
Billing address | Billing address of the pay-in |
Delivery address | Shipping address of the pay-in |
Card data in inquiries
The fraud prevention solution uses a card_token
to identify a unique physical card. This token contains:
- The first 6 digits of the card number (the BIN)
- A series of random alphanumeric characters
- The last 4 digits of the card number
The card_token
is not itself a parameter of the Mangopay API, but it is closely related to two parameters of the Card object:
- Alias – This contains the same 6 initial and 4 last digits of the card number, but the random characters are replaced with Xs.
- Fingerprint – Like the
card_token
, theFingerprint
identifier is unique to a physical card, meaning the sameFingerprint
always corresponds to the samecard_token
.
Rules
Rules let you decide the specific cases in which you want to return a given recommendation.
The rule builder gives you complete control over how recommendations should behave, and allows you to tailor, test, and simulate the impact of your fraud rules before activating them for live data.
Profiler
The profiler is code implemented into the platform’s app or website which monitors browser and behavioral data during a user’s session. The profiling session runs on your payment page, and the profiler enables you to monitor a vast array of data which can be used when defining rules.
Once the profiler is integrated, you can create rules based on users’ behavioral interactions and browsing traits, and leverage enhanced data.
You can integrate the profiler directly, or by integrating Mangopay’s Checkout SDK which has the profiler built in.
For more about the profiler, see:
Profiler SDK
Integrate the profiler on web, iOS, and Android
For more about Checkout SDK, see:
Checkout SDK
Simplify your payment experience and leverage the profiler
Was this page helpful?