Ravelin’s payment fraud product for payment service providers aims to manage fraud at scale for a collection of small-to-medium sized businesses.
Online payment fraud is when a fraudster uses stolen card details to make purchases online. Fraudsters can buy large numbers of stolen card details on the dark web and then attempt to use them to make purchases.
Bad actors may use stolen credentials to get products or services for free themselves, or so that they can sell these goods or services for their own profit.
Read MoreThis page explains the payment fraud integration process.
Our dedicated guides will help you to integrate with Ravelin seamlessly. The Ravelin team will help you through the integration from start to finish. We will work with you to understand how your platform and Ravelin can best work together to stop payment fraud, optimise conversion and support growth.
During the initial sales meetings, we will:
A dedicated project manager and integration engineer will be assigned to support you and will organise a kick-off meeting with you. We will discuss technical details of the project, target outcomes and any time constraints you may have.
Read MoreThis is our recommended payment flow integration.
The diagram below shows the payment flow for requesting a recommendation before authorisation. This integration allows us to help you decide which transactions to send to 3D Secure, as well as avoid the cost of authorisation transactions that we recommend preventing.
In order to score before authentication and authorisation, the pspBeforeAuth checkpoint should be called (by adding a parameter of ?checkpoint=pspBeforeAuth) as you send your transaction data to the transaction endpoint.
You can send dispute data to our dispute endpoint.
The following fields are required when sending disputes.
Dispute ID: This is a unique identifier for the dispute that allows us to keep track of it.
Stage: The stage at which the dispute is at—for example, “Request for Information” or “Chargeback”. Understanding what stage the dispute is at in its lifecycle will help us with fraud reporting.
Transaction identifier: In order for us to link a dispute with a transaction, we need the transaction identifier to be sent. This must be the same as the unique identifier used in the transaction scoring request; that is, it must be one of the following.
Read MoreIt is 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.
Read MoreWas this page helpful?