Payment Fraud Integration

Error Handling

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.

Handling Non-2xx Status Codes

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.

Rate Limiting

In case of receiving 429 “Too Many Requests” response codes, we recommend that you do not retry requests even when the rate of 429 responses has dropped. We will put the data in a queue and will process it.

See our Rate Limits guide for more information.

Monitoring

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.

3D Secure

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.

Timeouts

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.

Status Updates

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.

Next steps

Test your payment fraud integration

Get ready to go live with payment fraud recommendations

Feedback