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.
    • Assess how your business can get the most out of Ravelin.
    • Share information from initial discovery calls with our integrations team.

    During Integration

    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 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:

    1. 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.

    2. 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. The page will reload to open your sandbox account.

      Read More
    3. Payment Flows

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

      Read More
    4. 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.

      Generating a device ID

      The primary purpose of our libraries is generating unique device identifiers, referred to by Ravelin as Device IDs. Device IDs are consistent for different customers using the same device, allowing us to track when a single device is used to access multiple customer accounts on your platform. The Device ID is used to populate our graph networks with connections between customers who are identified as having shared the same device.

      Read More
    5. 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 or Checkout Post-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. If customers are not required to sign up to your service in order to make a purchase, we recommend using their email address as the customerId in all cases.

        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:

        POST https://api.ravelin.com/v2/checkout HTTP/1.1
        Authorization: token ...
        Content-Type: application/json
        
        {
          "timestamp": 1512828988826,
          "customerId": "abc-123-ZYZ",
          "order": {
            "orderId": "abcde12345-ZXY",
            "status": {
              "stage": "accepted",
              "actor": "merchant"
            }
          },
          "transaction": {
            "transactionId": "123-abc-XYZ",
            "time": 1512828988826,
            "amount": 1500,
            "currency": "GBP",
            "type": "auth",
            "gateway": "example-gateway",
            "gatewayReference": "1234",
            "success": true,
            "3ds": {
              "attempted": true,
              "challenged": false,
              "success": true,
              "version": "2.2.1",
              "eci": "05"
            }
          }
        }

        Completed orders

        When an order has been completed you should send a Checkout request with an updated order status.

        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. Using historical data can mean we’re able to train your model sooner without needing to wait for enough live data.

        Read More

      Feedback