# Confirming Status for Un-approved Documents

**URL:** <https://discuss.dwolla.com/t/confirming-status-for-un-approved-documents/6767>\
**Category:** Customers\
**Created:** [February 19, 2021, 1:45am UTC](https://discuss.dwolla.com/t/confirming-status-for-un-approved-documents/6767 "2021-02-19T01:45:30Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![andrewhartman](https://sea2.discourse-cdn.com/dwolla/user_avatar/discuss.dwolla.com/andrewhartman/32/2793_2.png) [@andrewhartman](https://discuss.dwolla.com/u/andrewhartman)\
**Post date:** [February 19, 2021, 1:45am UTC](https://discuss.dwolla.com/t/confirming-status-for-un-approved-documents/6767/1 "2021-02-19T01:45:30Z")

</div>

Hey Gang!

We’re working on managing document status and wanted to confirm the expected response.

If a user is in “Document” status and a document is submitted:

1. If the document is approved we’re anticipating the event customer\_verification\_document\_approved, and the customer status to be updated to “Verified”.
2. If the document is not approved, we’re anticipating the event customer\_verification\_document\_failed, and the customer status stays in “document” status.

In testing today, for scenario #2, we saw the customer status change to “Retry”. Is this the expected behavior?

Andrew

---

<div class="post-metadata">

**Author:** ![shreya](https://sea2.discourse-cdn.com/dwolla/user_avatar/discuss.dwolla.com/shreya/32/2154_2.png) [@shreya](https://discuss.dwolla.com/u/shreya)\
**Post date:** [February 19, 2021, 9:28pm UTC](https://discuss.dwolla.com/t/confirming-status-for-un-approved-documents/6767/2 "2021-02-19T21:28:40Z")

</div>

Hi @andrewhartman – what you explained in #1 and #2 is the expected behavior.

For the unexpected behavior in your Sandbox testing, would you be able to share an example Customer ID? I’d love to look closer and see if something is triggering it!

---

<div class="post-metadata">

**Author:** ![andrewhartman](https://sea2.discourse-cdn.com/dwolla/user_avatar/discuss.dwolla.com/andrewhartman/32/2793_2.png) [@andrewhartman](https://discuss.dwolla.com/u/andrewhartman)\
**Post date:** [February 23, 2021, 1:33am UTC](https://discuss.dwolla.com/t/confirming-status-for-un-approved-documents/6767/3 "2021-02-23T01:33:35Z")

</div>

Hi @shreya! We saw it in production with yours truly 🙂

[https://dashboard.dwolla.com/customers/25d34e87-4007-4337-85e1-93bec56b58bc/transactions](https://dashboard.dwolla.com/customers/25d34e87-4007-4337-85e1-93bec56b58bc/transactions)

1. User submitted the wrong birthday and was placed status “document”.
2. On document submit it was given status “Failed Review” for “Date of Birth on ID does not match”, which put the user in “Retry”
3. User retried with the full social and correct birthdate and were verified.

---

<div class="post-metadata">

**Author:** ![shreya](https://sea2.discourse-cdn.com/dwolla/user_avatar/discuss.dwolla.com/shreya/32/2154_2.png) [@shreya](https://discuss.dwolla.com/u/shreya)\
**Post date:** [February 23, 2021, 2:30pm UTC](https://discuss.dwolla.com/t/confirming-status-for-un-approved-documents/6767/4 "2021-02-23T14:30:43Z")

</div>

Hi @andrewhartman – Thanks for the ID! I just touched base with our Compliance team to confirm that this is an expected behavior if a document fails with `ScanDobMismatch`. It looks like we need to update our docs for clarity. There are cases where everything could be correct on the account but they mistype their DOB. This will result in the user being moved to `retry` from `document` again.

You’d likely want to account for this and build out the appropriate UI to edit full Account Info (including full SSN).

Thanks for bringing this up!

---

<div class="post-metadata">

**Author:** ![andrewhartman](https://sea2.discourse-cdn.com/dwolla/user_avatar/discuss.dwolla.com/andrewhartman/32/2793_2.png) [@andrewhartman](https://discuss.dwolla.com/u/andrewhartman)\
**Post date:** [February 23, 2021, 4:21pm UTC](https://discuss.dwolla.com/t/confirming-status-for-un-approved-documents/6767/5 "2021-02-23T16:21:56Z")

</div>

Thanks for the confirmation on that @shreya!