It is also crucial that your system can handle non-2xx HTTP response codes from Ravelin. Failure to do so could result in customers being unable to complete orders on your platform, translating any Ravelin downtime into downtime for your system as well.
In the scenario Ravelin returns a non-2xx HTTP status code, we recommend accepting the order.
If we return a 429 or 500 HTTP response code we will reattempt to process request to ensure the data provided in the unsuccessful request is considered for all future scores, however this is done on a best-effort basis and cannot be guaranteed.
In case of receiving 429 “Too Many Requests” response codes, we recommend that you only start retrying requests when the rate of 429 responses has dropped.
See our Rate Limits guide for more information.
We have an advanced monitoring and alerting system to ensure your integration continues to work correctly, however you should also configure your own logging and metrics to provide observability into how your Ravelin integration is behaving, alerting you to any issues originating from integration.
Depending on your risk appetite, you could also consider issuing a challenge such as a 3DS check for scenarios in which Ravelin is unable to respond with a score. Be wary when considering this option, as this can correspond to increases of customer drop-outs and abandoned baskets, so issuing these checks for all customers across your platform can hold a greater cost than that of potentially letting a small portion of fraud through.
You must also configure a sensible request timeout for scenarios in which Ravelin may be slower to respond than usual.
We recommend configuring a 750ms timeout.
Persistent responses at this latency suggest degraded performance of our services. Configuring a lower timeout threshold will result in more customers placing orders through your system, without being scored. Configuring a higher timeout threshold can cause shoppers to notice increased latencies on your platform or cause an over-saturation of connections in your system.
We will publish details of any issues or downtime on our Status Page.
We recommend subscribing to our Status Page to receive notifications of any disruptions to our service.
Test your payment fraud integration
Get ready to go live with payment fraud recommendations
Was this page helpful?