Add vendor reasons to proofing step analytics

[pkarman]

Why: Track vendor rationales for success/failure in each
verification step.

[zachmargolis]

LGTM, one quick question

[zachmargolis]

if form_valid? that means we didn't talk to our vendor, correct? Otherwise we want reasons for both success and failure right?

[pkarman]

we only get reasons if we have talked to the vendor, and we only talk to the vendor if the form is valid. Reasons will include everything the vendor responded with, good and bad, about the final pass/fail they gave.

[monfresh]

If the form itself is not valid (based on our internal validations), then we don't want to contact the vendor at all because it would be a waste of resources. The Form validation errors are already captured at this point. If the Form is valid, then we perform the second validation with the vendor, and we capture the errors.

However, I question the implementation of reasons in the proofer gem. It seems to me that the reasons should be part of the errors, just like they are in Rails. I would expect to see something like this:

result = {
  success: false,
  idv_attempts_exceeded: false,
  errors: {
    first_name: ['The name was suspicious.']
  }
}

as opposed to this:

result = {
  success: false,
  idv_attempts_exceeded: false,
  errors: {
    first_name: ['Unverified first name.']
  },
  reasons: ['The name was suspicious']
}

where it's not clear which fields the reasons are referring to.

[monfresh]

What do you think about consolidating the bad reasons into the errors hash, and display the good reasons only in the success scenario, and call it something like vendor_success_details?

[pkarman]

The vendor doesn't specifically tell us which fields the reasons belong to. They only give us a list of reasons. All this PR does is propagate that data to the logs.

[pkarman]

Also, errors are a subset of reasons, not the other way around. Reasons can be positive (indicating why something passed).

[pkarman]

@monfresh I'm open to doing that in future, but I think it should be done completely in the vendor-specific gem, where all that vendor-specific domain knowledge is located. At this point we want to simply log everything the vendor gives us.

[monfresh]

I see. Fair enough. How about just changing the field name from reasons to vendor_details to make it clear where those messages came from?

[pkarman]

Sure. Refactored to create vendor namespace at the top level with key reasons within it. I suspect we will be adding more to the vendor in near future (probably score etc).

[monfresh]

Sounds good. Thanks!

[monfresh]

LGTM