Personal Verified Customer
Learn how to create a Verified personal Customer that can send and receive funds.
Overview
This guide will walk through the identity verification process for personal verified Customers within the Dwolla API.
A personal verified Customer represents an individual that intends to send or receive funds on your platform. In any transaction, at least one party—either the sender or the receiver—must complete the identity verification process as outlined in this guide.
Create a personal verified Customer
To create a personal verified Customer, use the create a Customer endpoint. A personal verified Customer is determined by setting the value of the type request parameter to personal and including additional fields required for identifying the individual.
Events
As a developer, you can expect these events to be triggered when a personal verified Customer is successfully created and systematically verified:
customer_createdcustomer_verified
Request parameters - personal verified Customer
Once you submit this request, Dwolla will perform some initial validation to check for formatting issues such as an invalid date of birth, invalid email format, etc. If successful, the response will be an HTTP 201/Created with the URL of the new Customer resource contained in the Location header.
Request and response
Check the status of the personal verified Customer
The successful creation of a Customer doesn’t necessarily mean the Customer is verified and eligible to send or receive funds. When a Customer has been successfully verified by Dwolla, their status will be set to verified.
Let’s check to see if the Customer was successfully verified or not. We are going to use the location of the Customer resource that was just created, which is in new_customer.
Congrats! Our Customer was successfully verified!
However, if the Customer was unable to be verified on the initial flow, they will be given a verification status of either retry, kba, document, or suspended. Continue reading for instructions on handling various Customer verification statuses and guidelines for providing additional information to verify these Customers.
Handling verification statuses
After successfully creating a personal identity-verified Customer, they will immediately be given a status. There are various reasons a Customer status can be something other than verified; you will want to account for this after the Customer is created.
A Customer’s verification status is determined by an identity verification score based on the data submitted; this score is returned from Dwolla’s identity vendor. Therefore, it is important that the user enters accurate and complete identifying data, and that you exercise best practices in input field validation to ensure the best possible success rate. As an example, the retry status can occur when an individual mis-keys or uses incorrect identifying information upon Customer creation (i.e. submitting a date of birth that differs from the user’s actual date of birth).
It is recommended to have an active webhook subscription to listen for Customer verification related events. Reference the table below for Customer verification statuses and the related events.
Verification statuses
| Customer status | Event | Description |
|---|---|---|
| verified | customer_verified | The identifying information submitted was sufficient in verifying the Customer account. |
| retry | customer_reverification_needed | The initial identity verification attempt failed because the information provided did not satisfy Dwolla’s verification check. You can make one additional attempt by changing some or all the attributes of the existing Customer with a POST request. All fields are required on the retry attempt. If the additional attempt fails, the resulting status will be either document or suspended. |
| kba | customer_kba_verification_needed | The retry identity verification attempt failed due to insufficient scores on the submitted data. The end user will have a single kba attempt to answer a set of “out of wallet” questions about themselves for identity verification. Note: KBA is a premium feature. Please contact Sales or your account manager for more information on enabling KBA functionality. |
| document | customer_verification_document_needed | Dwolla requires additional documentation to identify the Customer in the document status. Once a document is uploaded it will be reviewed for verification. |
| suspended | customer_suspended | The Customer is suspended and may neither send nor receive funds. Contact Account Management for more information. |
Testing verification statuses in Sandbox
Dwolla’s environment allows you to submit verified, retry, kba, document, or suspended as the value of the firstName parameter to create a new verified Customer with their respective status. To simulate transitioning a verified Customer with a retry status to verified, you’ll need to call the Update a Customer endpoint and submit full identifying information with an updated firstName value and full SSN. To simulate transitioning a verified Customer with a document status to verified in the Sandbox, you’ll need to upload a test document as outlined in the Testing in the Sandbox resource article.
Handling status - retry
A retry status occurs when a Customer’s identity scores are too low during the initial verification attempt. Dwolla will require the full 9-digits of the individual’s SSN on the retry attempt in order to give our identity vendor more information in an attempt to receive a sufficient score to approve the Customer account. The Customer will have one more opportunity to correct any mistakes.
You need to gather new information if the Customer is placed
into the retry status; simply passing the same information will
result in the same insufficient scores. All fields that were required in the
initial Customer creation attempt will be required in the retry attempt, along
with the full 9-digit SSN.
Check the Customer’s status again. The Customer will either be in the verified, kba, document, or suspended state of verification.
Handling status - kba
This section outlines a premium feature for the Dwolla API. Please contact Sales or your account manager for more information on enabling KBA functionality.
Initiating the KBA session
The first step in the KBA flow is to make a request to the Dwolla API to generate a unique KBA ID which is used to represent the KBA session.
Example request and response
Retrieve KBA Question set
Once the KBA ID is created, your application will have a single attempt to retrieve and answer the question set returned from the Dwolla API. Upon a successful request to retrieve the question set, your end user will have two minutes to complete the submission of their selected answers.
Example request and response
Answer KBA Questions
Questions and answers will have their own unique identifiers. Questions and answers are submitted via an answers array that contains a list of four JSON objects that include key-value pairs for specifying a questionId and answerId.
Example request and response
KBA Success
If your Customer is able to correctly answer at least three of the four (total) KBA questions, your Customer will be moved into verified status. You will receive the customer_kba_verification_passed and to indicate that your Customer has passed the KBA attempt and has been successfully verified.
KBA Failure
A Customer that is unable to answer at least three questions correctly will be moved into document status. You will receive the customer_kba_verification_failed and customer_verification_document_needed webhooks to indicate that your Customer has failed the KBA attempt and must upload a photo Id in order to become verified.
Handling status - document
If the Customer has a status of document, the Customer will need to upload additional pieces of information in order to verify the account. Use the create a document endpoint when uploading a colored camera captured image of the identifying document. The document(s) will then be reviewed by Dwolla; this review may take up to 1-2 business days to approve or reject.
You can provide the following best practices to the Customer in order to reduce the chances of a document being rejected:
- Only images of the front of an ID
- All 4 Edges of the document should be visible
- A dark/high contrast background should be used
- At least 90% of the image should be the document
- Should be at least 300dpi
- Capture image from directly above the document
- Make sure that the image is properly aligned, not rotated, tilted or skewed
- No flash to reduce glare
- No black and white documents
- No expired IDs
Document types
A colored camera captured image of the Customer’s identifying document can be specified as documentType: passport, license (state issued driver’s license), or idCard (other U.S. government-issued photo id card).
Note: Military IDs are not accepted
When a Customer is placed in the document verification status, Dwolla will return a link in the API response after retrieving a Customer which will be used by an application to determine if documentation is needed.
| Link name | Description |
|---|---|
| verify-with-document | Identifies if documents are needed only for an individual |
Example response
Uploading a document
To upload a color photo of the document, you’ll initiate a multipart form-data POST request from your backend server to https://api.dwolla.com/customers/{id}/documents. The file must be either a .jpg, .jpeg, or .png. Files must be no larger than 10MB in size.
You’ll also get a webhook with a customer_verification_document_uploaded event to let you know the document was successfully uploaded.
Document review process
Once created, the document will be reviewed by Dwolla. When the document has been reviewed, which may take anywhere from a few seconds up to 1-2 business days if manual verification is required to approve or reject, we’ll create either a customer_verification_document_approved or customer_verification_document_failed event.
If the document was sufficient, the Customer may be verified in this process. If not, we may need additional documentation. Note: Reference the determining verification documents needed section for more information on determining if additional documents are needed after an approved or failed event is triggered.
If the document was found to be fraudulent or doesn’t match the identity of the Customer, the Customer will be suspended.
Document failure
A document can fail if, for example, the Customer uploaded the wrong type of document or the .jpg or .png file supplied was not readable (i.e. blurry, not well lit, not in color, or cuts off a portion of the identifying image). If you receive a customer_verification_document_failed webhook, you’ll need to upload another document. To retrieve the failure reason for the document upload, you’ll retrieve the document by its ID. Contained in the response will be a failureReason field which corresponds to one or more of the following values. In case of a failure due to multiple reasons, an additional allFailureReasons array of reasons and descriptions is also returned :
| Failure reason | Description |
|---|---|
ForeignPassportNotAllowed | The passport’s country of origin was not the United States of America |
ScanNotReadable | Image blurry, too dark, or obscured by glare |
ScanNotUploaded | Scan not uploaded |
ScanIdExpired | ID is expired |
ScanIdTypeNotSupported | ID may be a military ID, firearm license, or other unsupported ID type |
ScanIdUnrecognized | ID is not recognized |
ScanNameMismatch | Name mismatch |
ScanDobMismatch | Date of birth mismatch |
ScanFailedOther | ID may be fraudulent or a generic example ID image |
Request and response
Handling status: suspended
If the Customer is suspended, there’s no further action you can take to correct this using the API. You’ll need to contact support@dwolla.com or your account manager for assistance.