Payment Fraud Integration

Payment Fraud

  • Overview

    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. Fraudsters can use payment fraud to get products for free for themselves or they can monetise payment fraud by selling the goods for a profit. You can read more about online payment fraud in our Insights Guide.

    Read More
  • Integration Process

    This page explains the payment fraud integration process. Our dedicated guides will help you to integrate with Ravelin seamlessly. 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 More
  • Getting Started

    Access your sandbox account You should perform all integration testing with your sandbox account. Follow these steps to access your sandbox account: Log in to the Ravelin dashboard. If you do not have a Ravelin account please ask your account admin to grant you access. Instructions can be found in our Help Centre. Click your company name in the top right corner to open the account menu and click the Sandbox mode toggle button to switch to your sandbox account.

    Read More
  • Payment Flows

    The sequence in which a fraud solution is integrated into a payment flow is crucial to maximising its effectiveness.

    Read More
  • Sending Device Info

    Comprehensive fraud protection begins with customer pre-purchase behaviour. Ravelin utilises signals from customer devices, current browsing session and activity during the checkout process to help differentiate bad actors from legitimate customers. The data acquired from these libraries is critical to our ability to provide informed payment fraud recommendations. Ravelin provides JavaScript, Android and iOS client-side libraries which can generate and gather this customer device data on both web and mobile platforms.

    Read More
  • Requesting Recommendations

    Recommendations at checkout To request a payment fraud recommendation when a customer attempts to place an order, send a request to our Checkout endpoint using the Checkout Pre-Auth Checkpoint. To use the Checkout Pre-Auth Checkpoint add score=checkoutPreAuth as a query parameter to the URL. The request should contain the customer, device, payment method, order and transaction data. Each of these entities is described below: Customers Customers place orders, attempt payment transactions, spend on payment methods, log in from devices and file chargebacks.

    Read More
  • Sending Updates

    Accepted orders If you have accepted an order you should send a Checkout request with an updated order status. Since you are not requesting another recommendation, you do not need to add a checkpoint query parameter to the URL. You should set the following two fields: order.status.stage = "accepted" order.status.actor = "merchant" You should also provide the latest transaction details in the transaction object. An example request is shown below:

    Read More
  • Sending Disputes

    Disputes (including chargebacks) are essential labels for fraud prevention.

    Read More
  • Testing Your Integration

    Taking the time to test your integration well can yield payoffs long into the future.

    Read More
  • Error Handling

    The balance of frictionless checkout process and fraud-protecting practices should be kept in all merchants' minds, even during service degradation.

    Read More
  • Going Live

    Choosing the right approach to enabling your Ravelin integration is critical to ensuring a smooth and successful launch.

    Read More
  • Manual Reviews

    Knowing when, why and who to review ensures the highest quality feedback for Ravelin's machine learning models.

    Read More
  • Providing Historical Data

    As part of preventing payment fraud we will train a machine learning model which uniquely identifies the fraud you are experiencing. We will then use your model to evaluate your live traffic and return recommendations. We recommend using live data to train your initial model. We typically need to collect live data for at least a month to train your initial custom model. However, we can also use historical data to train your initial model.

    Read More

Feedback