Payment card fraud losses worldwide exceeded $32 billion in 2021 and will continue to rise. Protect your bottom line by deploying a fraud service, like Riskified, to stop bad actors from making it through your checkout

See our Fraud Overview for more general information about how we support fraud prevention.

What is supported?

Resulting decisions

  • Pass
  • 3DS (pre-authorization only)
  • Reject
  • Fail

Payment methods

  • Card
  • Apple Pay
  • Google Pay
  • Paypal

Fraud check flows

Riskified performs its main fraud check with an endpoint named Decide. Depending on your use case and fraud profile, Riskified will suggest you to leverage Decide either before or after the authorization. This is defined when Riskified creates your account and configures your fraud prevention model.

When connecting Primer to your Riskified account, make sure to specify when Decide should be called - either before or after the authorization.

🏦

Decide before the authorization

In this flow, the main fraud check happens at pre-authorization.

  • Pre-authorization check
    We ask Riskified to Decide if 3DS should be used or not, and whether we should proceed with the authorization.
  • Post-authorization check
    We do no send anything to Riskified. This check fails immediately.

Riskified expects to receive a notification after the authorization. This can be done in the workflow by

  • calling the action Decision when the payment is successfully authorized
  • calling the action Checkout Denied when the payment is not authorized
💳

Decide after the authorization

In this flow, the main fraud check happens after the payment is sent to the processor.

  • Pre-authorization check
    We ask Riskified to Advise if 3DS should be used or not, and whether we should proceed with the authorization.
  • Post-authorization check
    We ask Riskified to Decide, knowing the 3DS result and the authorization outcome, whether to proceed or cancel the payment.

Riskified expects to receive a notification after the authorization. This can be done in the workflow by

  • calling the action Checkout Denied when the payment is not authorized

Instructions

Set-up Instructions

  • Go to your Primer Dashboard.
  • Navigate to the "Integrations" section, select "Add Integration" at the top of the page and search for Riskified. Follow the dashboard instructions.
    Make sure to match "Fraud check flow" with how your Riskified account is configured.
  • Follow the rest of the steps to set up Primer Workflows for fraud checks.

Notifications

You can use Automation to also notify Riskified for updates that happen after the authorization step:

  • If Riskified is configured so that Decide is called before the authorization, call the action Checkout Denied when the payment is not authorized, and the action Decision when the payment is authorized.
  • If Riskified is configured so that Decide is called before the authorization, call the action Checkout Denied
  • When a dispute is opened for a payment, call the action Chargeback.
    See dispute management for details around processor coverage.

To do so, connect to the Workflow App for Riskified and either update your existing payment flows flows, or just apply the pre-configured Riskified templates.

Testing

Pre-authorization fraud check

  • To trigger a Pass outcome, set customer.emailAddress to start with out_of_scope.
  • To trigger a Reject outcome, set customer.emailAddress to start with fraud.
  • To trigger a 3DS outcome, set customer.emailAddress to start with sca.
  • To trigger a Fail outcome you will need to pass a request that is incorrect. An example of this is to set the currency to something as this field needs to be a recognised currency code.

Post-authorization fraud check

  • To trigger a Pass outcome, set customer.emailAddress to equal test@approve.com
  • To trigger a Reject outcome, set customer.emailAddress to equal test@decline.com

General Notes

  • You must update the Primer orderId for each Riskified test. Reusing the same orderId returns a previous result. You can override the fraud order id by providing a fraudContext.fraudOrderId inside metadata.