How Ravelin prevents payment fraud for PSPs Ravelin’s payment fraud product for payment service providers aims to manage fraud at scale for a collection of small-to-medium sized businesses. What is payment fraud? 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. Before Integration During the initial sales meetings, we will: Develop a deep understanding of your checkout and payment flow.
Read MoreRequesting a recommendation This 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 must be used. PSP payment fraud integration guide pre-authorisation flow %%{ init: { 'theme': 'base', 'themeVariables': { 'primaryColor': '#ececff' } } }%% sequenceDiagram autonumber participant PAYMENT_PAGE as Payment page participant PSP_BACKEND as PSP backend participant RAVELIN as Ravelin participant CARD_SCHEMES as Card schemes PAYMENT_PAGE ->> PSP backend: Attempt payment PSP_BACKEND ->> RAVELIN: Request recommendation RAVELIN ->> PSP_BACKEND: Recommendation opt If Allow recommendation PSP_BACKEND ->> CARD_SCHEMES: Attempt authorisation and capture CARD_SCHEMES ->> PSP_BACKEND: Authorisation and capture response end opt If Review recommendation PSP_BACKEND ->> CARD_SCHEMES: Attempt authentication CARD_SCHEMES ->> PSP_BACKEND: Authentication response opt If Authentication was successful PSP_BACKEND ->> CARD_SCHEMES: Attempt authorisation and capture CARD_SCHEMES ->> PSP_BACKEND: Authorisation and capture response end end opt If Prevent recommendation PSP_BACKEND ->> PSP_BACKEND: Stop processing end PSP_BACKEND ->> PAYMENT_PAGE: Payment response Requesting a recommendation after authorisation Only use this flow if you authorise and capture separately.
Read MoreSending disputes 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.
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. 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.
Read MoreWas this page helpful?