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 toDecide
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 toAdvise
if 3DS should be used or not, and whether we should proceed with the authorization. - Post-authorization check
We ask Riskified toDecide
, 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 actionCheckout Denied
when the payment is not authorized, and the actionDecision
when the payment is authorized. - If Riskified is configured so that
Decide
is called before the authorization, call the actionCheckout 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, setcustomer.emailAddress
to start without_of_scope
. - To trigger a
Reject
outcome, setcustomer.emailAddress
to start withfraud
. - To trigger a
3DS
outcome, setcustomer.emailAddress
to start withsca
. - To trigger a
Fail
outcome you will need to pass a request that is incorrect. An example of this is to set thecurrency
tosomething
as this field needs to be a recognised currency code.
Post-authorization fraud check
- To trigger a
Pass
outcome, setcustomer.emailAddress
to equaltest@approve.com
- To trigger a
Reject
outcome, setcustomer.emailAddress
to equaltest@decline.com
General Notes
- You must update the Primer
orderId
for each Riskified test. Reusing the sameorderId
returns a previous result. You can override the fraud order id by providing afraudContext.fraudOrderId
insidemetadata
.