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

Sign up from the Hub

​

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:

​

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

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

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

​

Inquiry data

The following table shows how the data points of the Mangopay API feed the fraud prevention panel displayed in the Mangopay Hub.

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, 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 signals 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