This page explains what checkpoints are and how to use them.
A checkpoint is a key event within a customer’s journey where you can request a recommendation from Ravelin. The checkpoints you want to use within your integration will likely depend on the kind of behaviour you are trying to address and where you would like to intervene in the customer journey.
For example, to stop payment fraud you might want to request a recommendation when a customer registers a new payment method or at checkout. If you want to counter account takeover, you might want to request a recommendation at login and checkout.
As part of your integration, we will work with you to best understand which checkpoints you should be using, when you should be using them, and what you should do with recommendations at that point in the customer journey.
To request a recommendation at a checkpoint, add the score query parameter to the request URL with
the corresponding query parameter value
For example, to request a recommendation at the Login Checkpoint, the URL should be: /v3/login?score=login.
If you do not specify a checkpoint we will not return a recommendation. We will still process the request, and it will still be available to view in the Ravelin dashboard.
We will return all relevant recommendations for the checkpoint. For example, for the Checkout Pre-Auth Checkpoint we will return both a payment fraud recommendation and an account takeover recommendation.
We support the following checkpoints:
The point at which a customer or supplier is trying to create an account.
Used by Account Registration,
Payment Fraud and
Refund Abuse.
Query parameter: score=accountRegistration
The point at which a customer is trying to log into your service.
Used by Account Takeover.
Query parameter: score=login
The point at which a customer is adding a new payment method to their account.
Used by Payment Fraud.
Query parameter: score=paymentMethodRegistration
The point at which a customer is selecting a payment method before placing an order.
Used by Payment Fraud.
Query parameter: score=paymentMethodSelection
The point at which a customer is trying to place an order, but before you have performed authentication (3DS) or authorisation.
Used by Payment Fraud,
Account Takeover
and Refund Abuse.
Query parameter: score=checkoutPreAuth
The point at which a customer is trying to place an order, after you have authorised the transaction.
Used by Payment Fraud and
Account Takeover.
Query parameter: score=checkoutPostAuth
The point at which a customer is asking for a refund.
Used by Refund Abuse.
Query parameter: score=refundRequest
You may optionally limit your recommendation to rules from a specific category or set of categories, using the category parameter. For example, &category=refundAbuse will return a recommendation only based on rules in the Refund Abuse category, or &category=payment,refundAbuse will return a recommendation only based on rules in the Refund Abuse or Payment Fraud category.
Currently support exists for limiting recommendations for the following rule categories:
payment - Rules to target payment fraud.ato - Rules to target Account Takeover.refundAbuse - Rules to target Refund Abuse.supplier - Rules to target Supplier fraud and marketplace abuse.The following categories can be specified for the given checkpoint:
checkoutPreAuth - payment, ato, refundAbuse, suppliercheckoutPostAuth - payment, ato, refundAbuse, supplieraccountRegistration - payment, ato, refundAbuse, supplierpaymentMethodRegistration - payment, atopaymentMethodSelection - paymentlogin - atorefundRequest - refundAbuseAs an example, if you are only interested in receiving recommendations produced by our Refund Abuse product at the point of the customer checking out, the query parameter would look as follows:
score=checkoutPostAuth&category=refundAbuse.
Note that if the category parameter is not provided, all rules at the checkpoint will be executed regardless of their category.
The legacy way of requesting payment fraud recommendations was to use the score=true query parameter,
rather than specifying a checkpoint.
For example, to request a payment fraud recommendation, the URL would be: /v2/checkout?score=true.
This method of requesting a recommendation is still supported, however we encourage you to use checkpoints to ensure you are receiving the recommendation relevant to the specific stage of the customer journey.
Was this page helpful?