Data types

Trustap uses 4 data types for gathering identity details:

• string
• date
• phone
• id_number

These will generally correspond to components in JavaScript frontend frameworks like React, Vue and Angular, to Activities in Android, or to Views in iOS. Modularising the data types in this ways allows for consistent rendering and handling for different fields.

In this guide we don't use any framework libraries but instead rely on browser primitives, in order to present a general solution that lends itself to being ported to different environments.

Events

The user flow presented in this guide makes use of a number of events. It can be useful to be aware of these early, because sometimes special provisions need to be made to support different UX activities. For example, when performing an error highlight, it's necessary to be able to retrieve a reference to a component via its name.

• Input change (input field): This event is triggered whenever an input element's value changes, such as from a keypress, pasting data, or deleting a highlighted section.
• Input lose focus (input field): This event is triggered whenever an input element loses focus - for example, when the cursor is present in an input field and then the user clicks outside the field.
• Reset (button): This event is triggered when the reset button for a field is clicked.
• Clear (button): This event is triggered when the clear button for a field is clicked.
• Highlight error (string): This event is triggered when a form submission is attempted, but there's an error with the named input.

Development

The development process for gathering identity details is divided into a number of steps to support incremental development of a functional form for KYC submission. The steps can also be implemented in parallel, but implementing them in sequence can allow for earlier previewing and testing of functionality and correctness.

API Errors

Note that if an invalid value (based on the validation property of a given field) is sent to the API then the API will return a 400 BadRequest error with details of the first invalid field that is found, in which case none of the provided fields will be updated on the API. However, an incorrect value that is otherwise valid (such as a phone number that is formatted correctly, but which isn't registered) will not result in an error. Instead, such values will be stored in the API, and the status of that field will later be updated to reflect its verification. As such, for the best user experience, all validation checks requested by the API should be handled on the frontend, and only values that pass these validation checks should be sent to the API.