Risk analysis box update#4883
Conversation
waiting-for-dev
left a comment
There was a problem hiding this comment.
Thanks, @elia; I left some comments to understand it better and a non-blocking suggestion about moving the query up.
4510546 to
ed88c13
Compare
elia
left a comment
There was a problem hiding this comment.
@waiting-for-dev did a few changes, mostly pushing details of the risk analysis to the partial that is specific to the payment method, so we can stop assuming all payments will have AVS and CVV informations returned by payment providers.
ed88c13 to
fcb58ac
Compare
waiting-for-dev
left a comment
There was a problem hiding this comment.
@elia, it looks cohesive now 👍 Please, see my comment, I'm not sure if there's a line that is commented by error.
kennyadsl
left a comment
There was a problem hiding this comment.
Left a couple of questions, but overall this change works for me, thanks Elia.
fcb58ac to
384fafc
Compare
There's no point in providing the latest payment from outside when the partial is accessing `@order` directly.
`Order#is_risky?` is currently based on whether a payment is risky, but over time the API could be expanded and allow customization.
Should not be false when a CVV message is present; that's just a field to collect descriptions from the payment gateway, the code is what matters This makes it consistent with both Payment.risky and OrdersHelper#cvv_response_code.
Use AR and existing scopes to build the query instead of SQL. Add a spec ensuring failed payments are considered risky.
Match the behavior of Payment.risky.
AVS and CVV are a legacy coming from an age in which everything could be done with ActiveMerchant and PCI compliance didn't exist. Moving away from specific risk checks paves the way for payment-method specific risky checks and display, although the underlying tables didn't change.
384fafc to
8f8a331
Compare
| <fieldset class="no-border-bottom" id="risk_analysis"> | ||
| <legend><%= "#{t('spree.risk_analysis')}: #{t('spree.not') unless @order.is_risky?} #{t('spree.risky')}" %></legend> | ||
| <details id="risk_analysis"> | ||
| <summary><%= t('spree.risk_analysis') %>: <%= t('spree.risky') %></summary> |
There was a problem hiding this comment.
As a side note, if you say the translation very fast, it sounds like "spreeesky" 😆
Summary
While investigating how an order and its payments are marked as risky as part of the solidus_stripe rewrite I bumped into AVS/CCV codes.
Any modern payment provider and risk analysis tool will probably provide some structured data and a score (with thresholds) as the outcome of a risk analysis.
This is a first step toward distancing ourselves from the ruins of solidus_gateway toward per payment-method and per-order risk analysis tools.
Changes
Spree::Order#is_risky?was based on having any of the payments to be considered risky → now it lists information for all risky paymentsbefore
Checklist
Check out our PR guidelines for more details.
The following are mandatory for all PRs:
The following are not always needed (
cross them outif they are not):