Comprehensive fraud protection begins with your customers’ pre-purchase behaviour. Ravelin utilises signals from their device, current browsing session and activity during the checkout process to help differentiate bad actors from legitimate customers, as well as potentially identifying cases of potential account take-over or scripted attacks against your platform.
To aide us in the acquisition of this data, Ravelin provides a series of client-side libraries and SDKs:
The data acquired from these libraries is critical to our ability to provide informed decisions: the integration of one, or all (where applicable) of these libraries is integral to a successful integration.
Ravelin’s 3DS2 Mobile SDKs provide EMVCo 3DS Authentication APIs directly on your mobile application for a smoother customer checkout.
The SDKs are implemented according to the EMVCo 3-D Secure Mobile SDK specification, and therefore include all the features required by it, such as:
An app-based flow for the 3DS2 SDKs is available here.
You can also find platform-specific integration documentation here:
A primary aim of all of these libraries is the generation of a unique device identifier, referred to in Ravelin as the DeviceID. These DeviceIDs persist between user sessions, allowing us to track when a single device is used to access one or more customer accounts on your platform. This value is used to populate our graph networks with connections between customers who are identified as having shared the same device. DeviceID reliability is paramount: an incorrectly assigned DeviceID results in unrelated customers becoming connected in the network.
For this reason, Ravelin insists you use one of our available libraries for generation of DeviceIDs.
If for whatever reason, you are unable to integrate one of our libraries to fulfill this purpose, we do not recommend generating and submitting to Ravelin your own DeviceID.
Ravelin refers to the activities of your customers while using your service as sessions. There are several suspicious actions a fraudster is likely to perform during these sessions that our libraries can help identify and track.
Our libraries track these suspicious actions and directly notify our servers on their occurrence, as well as provide the ability for you to track and submit events custom to your platform.
For merchants who wish to maintain their PCI compliance at SAQ-A or SAQ-AEP, and therefore do not wish to handle full PANs on their servers, our Ravelin SDKs offer client-side encryption functionality for securely submitting credit card information from your site/app to our servers without expanding your PCI scope.
Without use of client-side encryption, SAQ-A and SAQ-AEP merchants may struggle to provide accurate and detailed card information to Ravelin pre-authorisation.