How to confirm a returning customer with Myaza Trust
Protect a returning-customer journey with a subject-bound face re-authentication workflow. Compare the current live capture with an eligible enrolment or an authorised reference photo, then let your backend decide whether to continue the login.

Charles Archibong, Co-founder
· 4 min read

Key takeaways
- The intended customer can complete a subject-bound test.
- A different account cannot claim that login result.
- Mismatch, unavailable and Review do not grant access.
- Repeated notifications do not create a second login side effect.
Protect a returning-customer journey with a subject-bound face re-authentication workflow. Compare the current live capture with an eligible enrolment or an authorised reference photo, then let your backend decide whether to continue the login.
Before you begin
An eligible active face enrolment or authorised reference photo
A subject-bound session created for the customer
Camera permission and an available liveness method
Use a team member with permission for this control. Check the organisation and environment before changing a setting. Review the current price before a paid check or ongoing enrolment. Screenshots show an example workspace or the public integration reference; they do not show a real customer or a completed paid check.
Set up and use the capability
Step 1: Choose the customer reference and face source
Use the same stable customer reference your application already holds. Check whether that customer has an eligible active biometric enrolment. If not, use the documented enrolment journey or an authorised reference photo supported by the session API. Do not assume every stored KYC image is automatically a usable biometric enrolment. Obtain the permission required for this reuse of biometric evidence.

Integration reference: Request body
Step 2: Create the Face re-authentication workflow
Open Configuration → Workflows in Sandbox and create a workflow from Face re-authentication. Check that the Scope is biometric authentication rather than Full Verification. Choose the name your team can recognise, then inspect the capture steps. Scope is locked after first publication; use the appropriate scoped copy rather than trying to turn an already published onboarding workflow into a login workflow.

Dashboard example: Create the Face re-authentication workflow
Step 3: Configure presence and the decision
Open Presence Intelligence → Setup and select the available liveness method. Inspect Rules and the workflow’s decision graph for a passed comparison, a mismatch and an unavailable result. A match and a live-person result are separate evidence. Keep any extra contact step deliberate. Scoped authentication attaches the result to the existing customer without changing their KYC status.

Dashboard example: Configure presence and the decision
Step 4: Save and publish the workflow
Wait for Saved in the editor. Select Publish, or Publish changes for an existing workflow. In the publication review, check the target environment, workflow ID, price and readiness warnings. Resolve blocking issues, then confirm Publish version. A saved draft is not the version customers use. New sessions use the new published snapshot; sessions already created retain their original version.

Dashboard example: Save and publish the workflow
Step 5: Create the session for this login on your server
Call POST /api/kyc/sessions with the published workflowId and the intended externalUserId. For an authorised reference-photo path, upload it with type: auth_reference and pass the returned faceReferenceMediaId as documented. A biometric-authentication session needs a named subject or reference; a missing enrolment is refused. Return the resulting session URL only to this applicant, not as a reusable link for other customers.

Integration reference: Request
Step 6: Wait for the authentication outcome before granting access
Store the session and verification reference against the login attempt. Read the current final status on your backend or handle its signed status update. Continue the intended login only when your policy accepts that subject-bound result. Keep pending, review, mismatch and unavailable paths distinct. Myaza records the face-check outcome; it does not automatically sign a person into your application.

Integration reference: Tracking the session
Get more from the capability
Request re-authentication for sensitive actions, such as a new device or an account recovery, when your approved policy requires it.
Bind the intended account on the server. A user-supplied account ID and a completed browser screen cannot replace that binding.
Keep login assurance separate from customer KYC status. Do not create a new onboarding identity for every login.
Test before relying on it
Run the supported Sandbox or simulator scenarios for this product. Where a tool is Production only, check access and scope first, then use only a permitted, deliberately reviewed Production test. A documentation screenshot or a successful page load is not an end-to-end integration test.
The intended customer can complete a subject-bound test.
A different account cannot claim that login result.
Mismatch, unavailable and Review do not grant access.
Repeated notifications do not create a second login side effect.
Troubleshooting
The session says the customer is not enrolled
Check the customer reference, environment and active enrolment. Use the documented reference-photo route where authorised.
An old link shows old settings
Session configuration is frozen at mint time. Create a fresh session after publishing.
The login still completes after a mismatch
Review your backend login gate and correlation. A Myaza finding cannot enforce access without your result handler.
Open the setup and integration references
Read the integration reference
Back to Solutions. Choose the capability you want to activate, then follow its own guide.
Sources

Charles Archibong
Co-founder
Charles Archibong co-founded Myaza Trust. He writes about identity verification, financial technology, and the practical work of building trusted digital services.


