​
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.

​
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. Sign up from the Dashboard

​
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:
1

Profiling session (optional)

Optionally, the profiler runs a profiling session to collect data (if integrated).
2

Event to be screened

A user proceeds to checkout and makes a payment on your app or website.
3

Pay-in request

Your server requests a pay-in (and includes the ProfilingAttemptReference if applicable).
4

Inquiry

Your pay-in request triggers an inquiry, which is a request to screen the pay-in event.
5

Rule sets

The fraud prevention solution runs your custom rules and Mangopay’s default rules.
6

Recommendation

The solution generates a recommendation for the inquiry: Accept, Review, or Refuse.
7

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 screenedAll 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 setsThe 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:
RecommendationPay-in: Card, Google PayPay-in: Other
AcceptPayment requestedPayment requested
ReviewPayment with 3DS requested (regardless of SecureMode value)Payment requested
RefusePayment not requestedPayment 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 panelMangopay API data
Inquiry reference, transaction referenceTransaction’s Id
Inquiry originIndicates the payment method
User referenceTransaction’s AuthorId
Person typeWhether a Natural or Legal user
KYC validatedTrue if User’s KYCLevel is REGULAR
Is blockedTrue if User has either outflows or inflows blocked (see User Regulatory Status)
Registration datetimeUser’s CreationDate
Registration addressUser’s Address (if Natural) or HeadquartersAddress (if Legal)
Billing addressBilling address of the pay-in
Delivery addressShipping 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, the Fingerprint identifier is unique to a physical card, meaning the same Fingerprint always corresponds to the same card_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. Learn more about rules

​
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