User verification status not changed after IAV flow


(Vladimir) #1

Hello!

I’m now building an mobile app backend and expected the following scenario to be working:

  1. User is logging in to app
  2. We’re automatically creating a unverified Customer on Dwolla side, using a first/last name and email from our app
  3. We’re forcing user to pass an IAV flow in order to let him initiate a transaction to another user (in scope of our app).

Now, the question is: Customer does not became “verified” after he completed an IAV flow (so he has a “verified” funding source and “unverified” customer’s status).
Is it normal? Are we required to explicitly create an “verified” customer account (and request additional data like address, SSN etc) from user directly?

Thanks.


(Shea Daniels) #2

Hi Vladimir. In this case there are two different kinds of verification that we’re talking about. The first is a verified funding source (bank account) and the second is a CIP verified customer (Customer Identification Program).

Verifying a bank account is required in order for you to be able to use it as a funding source in a transfer. The IAV flow is used to verify this bank account ownership. The other option is micro deposits. Neither of these are required if the bank account is only going to be used for payouts.

Verifying a customer does require passing in address, SSN last four etc. That’s necessary for the customer to hold a balance and to comply with the Patriot act. Unverified customers can only interact with either your account or verified customers.

Hopefully this answers your question, please let me know if I can clarify anything else!


(Vladimir) #3

Hi Shea!

Thanks for your reply. So new questions are:

  • Why user does not became a “verified” when he connects his own funding source (e.g his identity can be confirmed by bank)?
  • In order to process a payment between two users (using White Label), we should have two Customers (minimum one of them should be verified), and the sender should have a verified funding source (while receiver is not required to have a verified funding source)?
  • How can Customer withdraw a money, sent to his “Balance” funding source (while he has not access to Dwolla’s UI)? The only way is to add a new funding source and request an app to start transfer between “balance” and “bank” funding sources?
  • Are there a way to manually set Customer’s status to “document request” or another one, to test an our application flow and scenarios to upload documents for verification? (same for payments processing - how we can test a situation, when payment has been rejected?)
  • What will happen after we (as an app) will send to Dwolla a customer-provided documents to prove his verification? Will Dwolla notify us about customer status change (from “document” to “verified”, for example) ?

(Shea Daniels) #4

Why user does not became a “verified” when he connects his own funding source (e.g his identity can be confirmed by bank)?

Unfortunately verifying a bank account doesn’t satisfy the identity verification requirements we are required to follow.

In order to process a payment between two users (using White Label), we should have two Customers (minimum one of them should be verified), and the sender should have a verified funding source (while receiver is not required to have a verified funding source)?

Correct

How can Customer withdraw a money, sent to his “Balance” funding source (while he has not access to Dwolla’s UI)? The only way is to add a new funding source and request an app to start transfer between “balance” and “bank” funding sources?

If you’re using white label, you control the entire experience for the customer via your app. So if you need to move money in/out of a customer’s balance, you would initiate that with the API. You would create a transfer with the customer’s balance as the source and the customer’s bank account as the destination, for instance.

Are there a way to manually set Customer’s status to “document request” or another one, to test an our application flow and scenarios to upload documents for verification? (same for payments processing - how we can test a situation, when payment has been rejected?)

Yes, you can create a customer that will end up in Document or Retry statuses by using the status as the first name of the customer in our sandbox environment. You can simulate failed transfers using our Sandbox Console: https://developers.dwolla.com/resources/sandbox-console.html

What will happen after we (as an app) will send to Dwolla a customer-provided documents to prove his verification? Will Dwolla notify us about customer status change (from “document” to “verified”, for example) ?

Yes, you should get webhooks to notify you of changes. More info is available in our developer documentation: https://developers.dwolla.com/resources/customer-verification.html


(Vladimir) #5

Yes, you can create a customer that will end up in Document or Retry statuses by using the status as the first name of the customer in our sandbox environment.

I’ve failed to do so - I’ve created a customer with both first and last name equals to “retry” - but he shows as “unverified” in Sandbox console. Can you help me to clarify what I’m doing wrong?

Also, am I able to delete a customer? I haven’t found an corresponding API method.


(Shea Daniels) #6

You can suspend a customer, but not delete them. To create a verified customer, you need to pass in a customer type of “personal” or “business”


(Vladimir) #7

To create a verified customer, you need to pass in a customer type of “personal” or “business”

Yeah, you’re right, thanks.
But what about case, when I’ve created a user with “retry” status, and then simulated an document upload? How it can be switched to “verified” status?

You can suspend a customer, but not delete them.

So, if in scope of single Dwolla app I’ve created a customer object by mistake, I can’t delete it?
And, if I suspend a customer and then try to create another one (but with same personal data/email), will it works?


(Shea Daniels) #8

But what about case, when I’ve created a user with “retry” status, and then simulated an document upload? How it can be switched to “verified” status?

Right now there is no way to simulate this on your own in the sandbox. Something will be out soon for that in the Sandbox Console. In production our customer service team will review documents for customers.

So, if in scope of single Dwolla app I’ve created a customer object by mistake, I can’t delete it?
And, if I suspend a customer and then try to create another one (but with same personal data/email), will it works?

Correct, there is no deletion due to our retention requirements. I’ll have to check on whether an email address can be re-used after a customer is suspended.


(Shea Daniels) #9

Currently, you cannot re-use an email address for a suspended customer.


(Vladimir) #10

Ok, got it.

Am I able to set a “suspended” status programmatically (e.g by using method described above) ? Can the ‘suspended’ status be switched to ‘verified’ etc, or if user is already suspended - he is suspended forever?


(Shea Daniels) #11

Yes, you can suspend customers via the API by posting to their resource with a status of “suspended”. We can un-suspend customers internally, but there is not a way to do that through the API at this point.


(Vladimir) #12

What does “suspended” status means - it means “blocked by Dwolla” or something else? When it can be used?


(Shea Daniels) #13

You can see the available customer statuses in the docs here: https://docsv2.dwolla.com/#customers

A customer can be put in that status on our side for a number of various reasons. You, as the creator of the customer, can also suspend them through the API.


(Vladimir) #14

Thanks!

Next question is about micro deposits.
First of all - “I specify a some bank account, Dwolla will put some amount of money in two transactions here, and to order to make it verified - I should send to Dwolla an exact of money that they have put on this account” - is it correct (did I correctly understood the whole concept?)

Next… Seems to be, that Python SDK for “verify micro deposits” is partially broken, since there is no any return data from dwollaswagger.FundingsourceApi.micro_deposits method - so how I can correctly read a HTTP response code or response body, if any?


(Spencer Hunter) #15

Correct. When you call the API to initiate Micro-deposits then the two small amounts should show up in the bank account in 1-2 business days. (depending on if there were no issues with the bank account) These amounts will need to be POSTed to Dwolla before the bank account can be verified.

Hmm, strange. It looks like the python client is calling the API but not returning a response back out. This seems to be an issue with this method specifically; not returning the response. We’ll look into getting this fixed


(Vladimir) #16

Exactly, there is no “return …” in that methods.
Are there any ETAs to fix released?


(Vladimir) #17

Another question…
If user requsted a micro-deposits verification, and initiated an IAV in parallel for the same account - what will be with the micro-deposits request (which is pending)? What will be if we will try to activate it (e.g enter a correct amounts of deposits?)


(Spencer Hunter) #18

@en_austin, We’ll work on getting the dwolla-swagger-python SDK updated this week.

The micro-deposits will complete to the bank account after 1-2 business days. I believe if you attempt to verify the bank account that has been verified then we’ll respond with a 403 Forbidden.

{
  "code": "InvalidResourceState",
  "description": "Bank already verified.",
  "message": "Bank already verified."
}

(Vladimir) #19

The micro-deposits will complete to the bank account after 1-2 business days. I believe if you attempt to verify the bank account that has been verified then we’ll respond with a 403 Forbidden.

Ok, but it isn’t clear for me, how these identical accounts will be saved in Dwolla in case, when user:

  1. adds an funding source by entering routing, account numbers etc (now he has 1 funding source with ID let’s say “A” and status “unverified”)
  2. requests a micro-deposit verification for that account
  3. after a while, he tries to start an IAV and adding the same bank account

Now a question is: Will he have a two different funding sources (first: id=“A” status=“unverified”; second: id=“B” status=“verified”), or a status of funding source added in step 1 will be updated to “verified” immediately after IAV completion?


(Spencer Hunter) #20

@en_austin, IAV performs two functions: adding a bank account and verifying that bank account. If the user attempts to add the same bank account via IAV after they have already added through entering in their account/routing number then they should be met with a message within the IAV flow.

In this instance, you’ll want to remove the funding source for the user before sending them through the IAV flow to add and verify their bank account. (two accounts with the same account number, routing number, and type cannot be saved in Dwolla)