Skip to main content

KYC Identity Validation Routine

The Enrollment routine is intended for users who do not have a previously successful verification record. In operational terms, the flow should start only after FindByNumberIdSuccess indicates that there is no successful transaction for the customer. Once that condition is met, the platform creates a new validation transaction, attaches the front and back images of the document, closes the transaction, and retrieves the final outcome through the Validation service.

Services

Face Comparison Process-2026-03-24-161224.png


How to Communicate Responses

This routine should be communicated at two different levels. The first level is the HTTP result of each individual service call, which confirms whether the technical request was accepted or rejected. The second level is the business outcome obtained from Validation/{id}, especially through Extras.IdState and Extras.StateName. A successful Close call does not mean that the business process is complete. The final user-facing outcome should only be communicated after the validation result has been retrieved.

Response Received

The most relevant technical values in this routine are Uid, which links the creation request with the image upload requests and the close request, and TransactionId, which identifies the transaction once it has been closed and is later used in the Validation query. The Validation response also provides business-facing fields such as Extras.IdState, Extras.StateName, Images, and Scores, which can be used for auditing, compliance, or downstream orchestration.

Flow Diagram

Face Comparison Process-2026-03-24-161421.png

Service Invocation

The expected sequence begins with FindByNumberIdSuccess. When that service confirms that no successful record exists, the integrator calls Validation/New and stores the returned Uid. The same Uid is then reused in DocumentFrontSide, DocumentBackSide, and Close. Once Close returns the TransactionId, the integrator queries Validation/{TransactionId} until the process reaches a final business state.

Recommendations

The same Uid should be preserved across all intermediate calls. The integration should not assume that the process is complete immediately after Close, because the final operational result is determined by the Validation endpoint. Image quality should be monitored closely, since invalid or malformed base64 payloads are a common cause of capture errors. If the project uses OAuth, the token should be obtained before any protected service call and kept valid for the duration of the session.

Postman Collection

The Postman collection for this routine is available in