Once you are happy with the payment fraud results Ravelin is providing, and both parties have deemed your detection quality satisfactory, the process of going live with payment fraud recommendations can begin.
There are different approaches you can take to achieve this, but you must still send all data to Ravelin, across all markets and across all customers, even if you are only listening to us for a percentage of this traffic. This is so Ravelin continues to acquire data and can continue to refine our detection capabilities, even during a staggered rollout.
Also, you must inform Ravelin of your current fraud prevention strategy, as any other systems in place may contradict or even overrule Ravelin, making it more difficult to accurately assess the performance of Ravelin.
The simplest way to rollout Ravelin is to react to all of our recommendations, across all customers, across all markets. While this makes the rollout itself simpler, and will provide immediate protection against incoming fraud, the system will be relatively untested, so integrations completed without sufficient backfill or without several months of live data ingested may be produce less reliable results. To mitigate against this, Ravelin will assist in providing additional rules and tune your thresholds to minimise losses to fraud and maximise conversion rates while continuing to train your model against newly acquired data.
This approach is recommended for merchants with an urgent need for additional fraud prevention.
An alternative approach would be to react to all of our recommendations, but only for a single, or small group, of markets initially. You can select these markets as per your current needs. If you have markets currently at a high percent of fraud, perhaps even on a chargeback scheme, they might be a good candidate for going live first, as Ravelin will be able to have an impact reducing fraud even in the short-term. Conversely, a safer, more established, low-fraud market might be preferable for you if you are looking for a lower risk approach.
A per market approach is a good candidate for all merchants.
It may be preferable to listen to our recommendations for only a single platform, choosing between either your web or app based traffic. This helps reduce the initial scope of customers handled by Ravelin, but can also be used to provide more immediate coverage to a platform that is currently more exposed to fraud. If you choose to adopt this approach, it is vital Ravelin receive enough device information to be able to distinguish the source of an order back to the platform it was made from.
A platform based routing approach is a good candidate for merchants with differing requirements between their platforms.
Merchants may also choose to react according to Ravelin’s recommendations only for a subset of traffic, randomly determined during the checkout process. This can be the safest approach for merchants averse to a risk, as the initial percentage can be configured to be very low, slowly ramping up the percentage over time. This can also be the most difficult approach to implement, and to analyse our performance against.
When taking this approach your integration, you should continue to react to Ravelin’s recommendation across the life of any customers selected to be handled by Ravelin. This means that if a customer is initially determined to be handled by Ravelin, all subsequent orders and all transaction attempts performed by this customer should also be handled by Ravelin. This is to simplify evaluation for customers whose score drastically varies over time, so all parties can be sure Ravelin was issuing accurate scores at the appropriate time.
Additionally, you must inform Ravelin of which customers have been selected to be handled by Ravelin. This can be achieved by adding a custom field to the customer or their orders of "handledByRavelin":true. We will use this field when analysing our performance.
When deciding which of your customers are to be handled by Ravelin, random distribution is important; fraudsters often use similar email addresses or create a large number of accounts within a short period of time. As such, Ravelin recommends using a cryptographic hash of the customerId or email address to determine the handling for a given customer.
Percentage based routing is a very safe approach, but also the most complex to evaluate against and does require additional integration work.
Ravelin will provide recommendations for suitable thresholds, optimised to minimise your fraud rate while maximising conversion. However, during the initial deployment of Ravelin, you may wish to up your thresholds to reduce the number of customers being blocked, or decrease them to more aggressively block fraud. Let us know if this is the case and we can config them accordingly. Once you are happy with the quality of our detection, we can begin the process of adjusting them back towards our recommended values.
While it may initially seem preferable to run several fraud prevention systems simultaneously, it may not be wise to do so. Your overall block rate may become the sum of all individual block rates, and customer support cases become much more difficult to reason about when there are several potential actors that could have influenced any single decision. Ravelin recommend disabling other fraud prevention systems where possible when switching to act on Ravelin’s recommendations. Where this is not possible, Ravelin must be aware of what other decision makers are influential during the checkout process.
To ensure a smooth transferral of responsibilities from your existing set-up to Ravelin, there may be some existing rules you wish to transfer over. Not all rules may be suitable for transferral though, as many of your existing rules may be made obsolete through our network features and machine-learning capabilities, while others may be too aggressive to consider porting. Please discuss the transferral of these rules with the team here at Ravelin.
Regardless of your approach, there will be a moment in which your Ravelin integration stops being passive and starts blocking customers in real time. When this happens, it is critical that you inform us of when this moment is scheduled to happen so we can ready our engineers, data scientists and analysts to oversee the process. In addition, it is crucial you have real time information on your overall transaction rates, as seen from your system, so you can be sure that the integration is behaving as expected. Being able to rollback this deployment is also highly recommended, in case your system experiences issues during the go-live. This will often mean having your engineers on-hand, and potentially communicating with any existing fraud prevention systems you were previously using to ensure it is possible to re-enable them in case of an emergency.
Ravelin is considered live:
If, when Ravelin issues a PREVENT, that customer is blocked from completing their order, regardless of the decision made by other fraud providers or by your payment gateway.
If, when Ravelin issues an ALLOW, that customer is allowed to continue through the checkout flow and complete their order. It is possible that when Ravelin issues an ALLOW, an existing fraud prevention rule configured in your payment gateway might block the order. If there are reasons these rules should not be or can not be turned off, then you must inform Ravelin of why the order was prevented despite our ALLOW recommendation. This is most often achieved through either the order status "status":{"stage": "cancelled", "reason": "other_fraud_tool"}" or the decline code of the transaction "declineCode":"FRAUD".
Was this page helpful?