Avoid using a "N/A" risk evaluation in the Transaction details

[csmcneill]

Describe the bug

When a payment is made via a BNPL payment method, there is no risk evaluation made. However, what happens as a result is that there is a value of N/A for the risk evaluation in the transaction details at Payments > Transactions without any further information.

To Reproduce

1. Purchase a product via a BNPL payment method.
2. View that transaction's details via Payments > Transactions.
3. Note the RISK EVALUATION is N/A.

Actual behavior

There is no indication as to why a risk evaluation was undertaken for this payment. While this was highlighted during an evaluation of BNPL payment methods, this could also apply to other instances where there was no risk evaluation made.

Screenshots

Expected behavior

When it’s expected for no risk evaluation to occur for a transaction, we would want to consider either:

1. Conditionally hiding this.
2. Showing the N/A but including a tooltip that informs the merchant why no risk evaluation was performed.

Additional context

Surfaced in pbUcTB-4el-p2#risk-evaluation-n-a

[pierorocca]

Marking as an enhancement request. @elizaan36 @nikkivias BNPL payment methods have no fraud chargebacks. It's up to the BNPL providers to approve or decline and they assume all risk. So there's never a fraud assessment on our side. While we know that's what N/A means, it may be ambiguous for a merchant.

Do you feel N/A is sufficient? Would a tooltip with a legend be useful to explain what each value means? Thanks for the help

[elizaan36]

I don't think N/A is the best way to communicate that no risk evaluation was completed. I'd lean towards hiding the risk evaluation section from BNPL transactions (including on order details). I think any explanation would just generate more questions and this type of information could more easily be explained in the docs.

[pierorocca]

@elizaan36 I'm in the process of stress testing WooPay. For this 3D secure transaction, when I look at the Transaction details, I don't understand what Risk Evaluation 'Normal' means. Searching for "risk evaluation" in the docs yields no result.

[elizaan36]

That's a great point, @pierorocca. The Fraud tools documentation is quite detailed but the user may not know how to find it if they search for the terminology used in the admin.

@csmcneill What are your thoughts on changing the language in the admin vs adding the "Risk evaluation" term in the docs? For example, I think the metabox in the order details should be labeled "Risk evaluation" for consistency. Currently it's "Fraud & Risk".

[csmcneill]

I think the metabox in the order details should be labeled "Risk evaluation" for consistency. Currently it's "Fraud & Risk".

100% agree here, as I think consistency is a vital component of delight :)

It seems as though the Risk evaluation section of the Transactions page and the Fraud & Risk metabox in the order details page are quite different. The Risk evaluation is pulled from Stripe, which also explains why there may be a N/A for BNPL transactions.

If an order is blocked by our FRT, there's no risk evaluation performed, and the value on the transactions page is –:

What are your thoughts on changing the language in the admin vs adding the "Risk evaluation" term in the docs?

I'll work on adding some information about Risk evaluation to our docs. It's likely that it will fall under https://woo.com/document/woopayments/fraud-and-disputes/fraud-protection/

[pierorocca]

Nice analysis @csmcneill.

If an order is blocked by our FRT, there's no risk evaluation performed, and the value on the transactions page is –:

I suspect this will vary based on the fraud check, by who and when it's being checked. Roughly the fraud and risk steps done in a typical transaction are:

1. WooPayments pre-auth fraud & risk checks & SIFT scoring
2. Stripe pre-auth fraud & risk checks (Radar)
3. Issuer fraud checks and auth response (decline or approve + useful metadata e.g. approved but zip didn't match). This could also include a 3DS check within the auth flow where the user is forced to validate identity.
4. Stripe post-auth fraud & risk checks (Radar - they may decide to decline an issuer approved transaction to limit risk)
5. WooPayments post-auth fraud & risk checks

2-4 is combined in the auth response message we get from Stripe.

1 & 5 are related to the new WooPayments Advanced fraud rules.

• AVS Mismatch - post-auth
• International IP Address - pre-auth
• IP Address Mismatch - pre-auth
• Address Mismatch - pre-auth
• Purchase Price Threshold - pre-auth
• Order Items Threshold - pre-auth
• CVC Verification - post-auth

If you simulate an AVS mismatch I think you'll get both a risk evaluation and an AVS mismatch based on the Advanced fraud rule firing post-auth. How these scenarios combine if at all to populate "Risk Evaluation" I'd recommend a fresh look and have the owning PM weigh in.

Line1 check fails	4000000000000028	The address line 1 check fails.The payment succeeds unless you block it with a custom Radar rule.

[csmcneill]

My tests suggest that we model the Risk evaluation section based on the Stripe risk outcomes. I did a bit of digging and found some evidence in the plugin code that supports this hypothesis:

https://github.com/Automattic/woocommerce-payments/blob/ca8c7c0d04400b6e4753e6baa919209e88752154/client/transactions/strings.ts#L38-L43

https://github.com/Automattic/woocommerce-payments/blob/ca8c7c0d04400b6e4753e6baa919209e88752154/client/components/risk-level/index.tsx#L14-L16

https://github.com/Automattic/woocommerce-payments/blob/ca8c7c0d04400b6e4753e6baa919209e88752154/client/components/risk-level/strings.ts#L8-L14

It's possible that I could be missing something. However, I do want to note that I'm unable to get this section of the payment details page to display anything other than Normal, Elevated, or N/A.

[csmcneill]

If you simulate an AVS mismatch I think you'll get both a risk evaluation and an AVS mismatch based on the Advanced fraud rule firing post-auth.

I've never been able to get AVS mismatch failures to work in test mode, so I tried to do this on my live account with a live payment method.

The payment was authorized as expected, but failed due to the AVS mismatch. However, as a result, an order was created in wp-admin, but there is no associated transaction in Payments > Transactions.

Since there's no transaction, there's no risk evaluation. What's more interesting is that the FRT metabox suggests no action was taken here, even though it was blocked by an adjustment in my FRT settings:

I'll open up a separate issue about mismatch between the FRT settings and the metabox information :)

[pierorocca]

Awesome super helpful @csmcneill. I found Stripe's docs for Risk Evaluation.

I don't know enough about the WooPayments advanced fraud implementation and SIFT scoring to know how they interplay with each other, and then how that's all packaged and communicated to the merchant. For example if Radar comes back with a Normal score but an advanced fraud rule triggers and declines the transaction, are the order notes, F&R notes, and risk evaluation conveying a clear or a muddied picture?

[pierorocca]

@csmcneill last week I also noticed during testing that anytime an order is blocked due to a fraud rule like IP mismatch which happens before authorization, an order is created in a “Pending payment” state. I pinged my team and Sourav provided a first response and I've followed up with another. I'm waiting on more feedback.

[pierorocca]

Despite it being a "Pending payment" order, which to me is odd and should be either Failed or Sourav is suggesting "On Hold", I do now see the blocked transaction.

[tpaksu]

Hello all, I'm triaging issues assigned to us, and I wanted to check if this task has a final decision about what should be done. This issue contains many good investigations and info, but I couldn't spot a decision about how we should replace N/A on the screen, which may indicate Stripe didn't return a risk evaluation result to us, which can be many things, like Radar isn't active on the account.

Wild guess, didn't check the code, but - can mean the process didn't reach to a point where a risk evaluation can be done on the transaction, like FRT blocking the intent creation before it reaches Stripe. AFAIK, the transaction data on the "blocked" tab isn't showing data received from Stripe, it is mimicking the data as it was received from Stripe. We use what we have to build that screen, to look like the other "failed/succeeded" records screen. Right @eduardoumpierre?

[eduardoumpierre]

AFAIK, the transaction data on the "blocked" tab isn't showing data received from Stripe, it is mimicking the data as it was received from Stripe. We use what we have to build that screen, to look like the other "failed/succeeded" records screen.

Hey! That's correct. Since the checkout is blocked before reaching Stripe, we generate a charge based on the data available in the order. We set charge.outcome to null here, so a "-" is rendered in this case (and any other case where charge.outcome is unavailable).

Here is where the Risk Evaluation item in the summary page is generated.