Consumer Splitpay

Copy

• Copy for LLM

  Copy page as Markdown for LLMs
• View as Markdown

  Open this page as Markdown
• Open in ChatGPT

  Get insights from ChatGPT
• Open in Claude

  Get insights from Claude
• Connect to Cursor

  Install MCP server on Cursor
• Connect to VS Code

  Install MCP server on VS Code

Introduction

This guide explains the integration process of Solaris' Splitpay product for retail customers (Consumers) as a standalone solution, including the mandatory information you must collect from your customers and the necessary endpoints and webhooks you must integrate into your solution.

Product specifications

Consumer Splitpay is available for customers in Germany and France with a valid bank account. Check the overview page for more details on the product specifications.

Credit scoring

Solaris uses an automated credit scoring system (Splitpay scorer) to make informed credit decisions on consumer credit line applications. The scorer collects and analyzes different information, such as the customer's self-declared financial information, credit data, transaction history, and outstanding loans to assess their creditworthiness and determine their risk level and credit eligibility.

Based on different credit checks done throughout the application lifecycle, the scorer estimates the probability of default (PD) and then determines whether to offer a credit line and the limit to be granted.

How does the scorer interact with the consumer credit line service?

The consumer credit line service and its related endpoints handle consumer credit line requests and collect the required information about the applicants, such as self-declared financial information, credit records, and account snapshots. Throughout the lifecycle of a consumer credit line application, the scorer provides different responses based on the information provided during each stage of the application.

The scorer performs different credit checks throughout the application lifecycle, such as:

• Initial scoring: In this stage, the scorer evaluates the self-declared information the applicant provided in the credit line application and the credit record obtained from external credit bureaus, such as SCHUFA. Based on this information, the scorer gives decision either to offer a credit line right away or to require a verification step through an account snapshot.
• Verification: The scorer uses the account snapshot to verify the financial information provided in the credit line application. This is the final check, after which the scorer provides the final decision.

System prerequisites

Before integrating Solaris' Consumer Splitpay, implement the following requirements:

1. Technical setup

Set up your environment and get your authentication keys. For step-by-step instructions, check the Technical setup guide.

2. Legal and compliance screens

Build the necessary legal and compliance screens in your sign-up flow to collect your customers' consent. The Legal and compliance screens guide contains step-by-step instructions on how to create these screens and what they must contain.

The following screens are required to onboard B2C customers for lending standalone products:

1. Terms and Conditions
2. Customer information
3. Economic interest

Consent timestamps

You must record the customer's consent on each screen as a UTC timestamp (e.g., 2019-01-01T00:00:00Z) and pass it to Solaris in the following fields:

• Solaris Terms and Conditions: terms_conditions_signed_at
• Data Processing Terms: data_terms_signed_at
• Economic Interest Declaration: own_economic_interest_signed_at

Integration overview

Integrate Solaris' Consumer Splitpay by completing the following steps:

You can find detailed descriptions of these steps and their related endpoints in the following sections.

Sequence diagram

The following sequence diagram gives an overview of the integration flow for the Consumer Splitpay solution:

Webhooks

Solaris recommends subscribing to the following webhook events to better automate your processes. For detailed instructions on implementing Solaris webhooks, check the webhooks documentation.

General Events

• ACCOUNT_SNAPSHOT
• IDENTIFICATION
• PERSON_CHANGED
• PERSON_DELETED
• LOAN

Credit Line Specific Events

1. Application Updates CREDIT_LINE_APPLICATION

This webhook is triggered during the credit line application process in the following scenarios:

Status Triggers

• credit_line_created: Upon the creation of a credit line.
• offered: Upon scorer approval.
• rejected: Upon scorer rejection.
• account_snapshot_verification_succeeded:
  • identification_pending: If used_esigning_provider = BANK.
  • offered: If used_esigning_provider = BANK.
• rejected: Based on account_snapshot_verification_failed.
• esign_failed: Based on signing_failed.
• rejected: Based on esign_completed with screening_finished_with_confirmed_match.
• rejected: Based on samsung_fix_reject.
• expired: When an application expires.
• deleted: On non-customer GDPR deletion.

2. Lifecycle Updates CREDIT_LINE

This webhook is triggered for events occurring after the credit line has been created:

Status Triggers

• open: On mandate_created.
• accepted: On screening_status_changed_to_accepted.
• closed: On credit line revoked.

Block Triggers

• locking_status BLOCK on screening_status_changed_to_potential_match.
• locking_status BLOCK on screening_status_changed_to_declined.
• locking_status BLOCK on id_now_canceled.
• locking_status BLOCK on locking_status_changed: true.

Loan Triggers

• Loan Opened: On credit_line_loan_contract_details_retrieved.
• Loan Repaid: On credit_line_loan_repaid.

Limit Triggers

• Limit Changed: Credit line with updated_data.

Mandatory features

You must integrate all the mandatory features for B2C Splitpay highlighted in the Onboarding requirements guide before going live with your solution.

Step 1: Generate an anonymous installment plan

In this step, you will enable your customers to request an anonymous installment plan before applying for a credit line by integrating the following endpoint in your sign-up flow. Your customers enter the desired amount they want to convert into installments and they receive an initial installment plan, including the monthly installment amount, and applicable interest rates.

POST Create an anonymous credit line installment plan

This endpoint generates an anonymous credit line installment plan for a specific amount, allowing potential customers to receive an initial offer before applying for a credit line.

Request URL

POST /v1/anonymous_credit_line_installment_plans

View full API reference

If the customer decides to apply for a credit line, you need to collect the mandatory information from the customer on your frontend by completing the following steps in this guide.

Step 2: Collect customer data and create person resource

In this step, you have to collect the mandatory data points from the customer in your sign-up flow, including all the timestamps of the customer's consent to the legal and compliance screens.

Afterward, pass all the data points to Solaris by creating a person resource to represent your customer.

API reference

For a complete list of endpoints, properties, and examples related to the person resource, visit the following links:

• Person resource API reference
  • POST Create person
  • GET Retrieve a person
  • PATCH Update person

Related webhook events

• PERSON_CHANGED
• PERSON_DELETED

POST Create person

Create a person resource to represent your customer. You must include the following data points in the request body to satisfy the requirements for German Consumer Loans.

Mandatory fields for retail customers in Germany:

• salutation
• first_name
• last_name
• email
• mobile_number
• birth_date
• birth_city
• birth_country
• nationality
• employment_status
• address:
  • line_1
  • line_2 (optional)
  • postal_code
  • city
  • country
• tax_information:
  • marital_status
• terms_conditions_signed_at
• data_terms_signed_at
• own_economic_interest_signed_at

Request URL

POST /v1/persons

• API Reference: Create person

PATCH update person

This endpoint updates one or more properties on a person resource. You can only update the following properties using this endpoint:

• title
• salutation
• address (line_1, line_2, postal_code, city, state, country)
• contact_address (line_1, line_2, postal_code, city, state, country)
• employment_status
• job_title
• email
• tax_information (tax_assessment, marital_status)
• fatca_relevant
• fatca_crs_confirmed_at
• business_purpose
• industry
• industry_key
• own_economic_interest_signed_at
• aml_confirmed_on (only with today or tomorrow's date)
• expected_monthly_revenue_cents
• vat_number
• website_social_media
• business_trading_name
• nace_code
• business_address_line_1
• business_address_line_2
• business_postal_code
• business_city
• business_country
• annual_income_range
• data_terms_signed_at
• branch
• birth_province
• birth_post_code
• socioprofessional_category
• purpose_of_account_opening
• main_income_source
• work_country
• work_province
• self_declared_as_pep
• international_operativity_expectation
• registration_number

Request URL

PATCH /v1/persons/{id}

Request example

{
  "email": "new.email@example.com",
  "address": {
    "line_1": "New Street",
    "line_2": "1",
    "postal_code": "10119",
    "city": "Berlin",
    "country": "DE"
  }
}

• API Reference: Update person

Step 3: Create credit record

In this step, you must create a consumer credit record and link it to the person resource of the relevant customer.

What is a credit record?

The credit record contains the customer's credit data and history. Creating a credit record is mandatory for Lending integrations, as it is used for credit scoring to determine the customer's creditworthiness and eligibility.

Create a credit record

To create a credit record, you must choose a source in the request body:

1. source: solarisBank (Automated) Solaris retrieves the customer's record directly from SCHUFA. This is the standard recommended process.

2. source: partner (Manual Upload) You collect the credit record manually from SCHUFA or third-party providers and upload it to Solaris.

   • Requirement: You must Base64-encode the file and pass the content in the file field.

Endpoints:

Depending on your customer type, use one of the following endpoints:

Retail Customers

POST /v1/persons/{person_id}/credit_records

• API Reference: Create retail credit record

Freelancers

POST /v1/freelancers/persons/{person_id}/credit_records

• API Reference: Create freelancer credit record

GET Retrieve a credit record

Call this endpoint to check the status and validity of an existing credit record.

Request URL

GET /v1/persons/{person_id}/credit_records/{credit_record_id}

• API Reference: Retrieve credit record

Step 4: Create consumer credit line application

After collecting the mandatory personal information from the customer and creating a person resource, you must collect additional information from the customer related to the credit line application, and pass them to Solaris using the following endpoint:

POST Create consumer credit line application

Call this endpoint to create a consumer credit line application for your customer. You must add the following mandatory properties in the request body, which the credit scorer uses to initiate a series of credit checks:

Mandatory properties:

• requested_credit_limit
• credit_record_id
• employment_since
• living_situation
• living_situation_amount
• existing_credit_repayment_excluding_mortgage
• marriage_status
• moved_in_last_two_years
• net_income_amount
• number_of_dependents
• private_insurance_amount
• recipient_iban
• repayment_day_of_month

The application status changes to initial_scoring_pending after calling this endpoint.

Request URL

POST /v1/persons/{person_id}/credit_line_applications

View full API reference

Scoring results:

This API call triggers the credit scoring system, which initiates the initial scoring based on the self-declared information passed in the payload and the credit record, and rejects applications that don't meet the minimum credit eligibility criteria.

Approved application

• If the application passes the initial scoring and no account snapshot or identification is needed, then the application status goes directly to offered. In this case, proceed to step 6 to generate the relevant contracts for the customer.
• Alternatively, the status can go to account_snapshot_verification_pending if an account snapshot is required. In this case, complete step 5 to create an account snapshot and link it to the application.

Rejected application

If the application is rejected, the application status changes to rejected, and you must abort the customer onboarding process.

GET Retrieve consumer credit line application

This endpoint returns the current status and details of an existing consumer credit line application. For a list of possible values of the application status and their descriptions, check the appendix.

Additionally, subscribe to the webhook event CREDIT_LINE_APPLICATION to receive status updates on the application.

Request URL

GET /v1/persons/{person_id}/credit_line_applications/{credit_line_application_id}

View full API reference

Application status flow

The following diagram describes the status flow of a consumer credit line application:

Step 5: Create account snapshot and link it to the application (Optional)

If the application status changes to account_snapshot_pending, then the final verification step is required to complete the credit scoring process. In this case, you need to create an account snapshot for the customer and link it to their credit line application by calling the following endpoints:

What is an account snapshot?

The account snapshot contains a breakdown of the customer's account information, such as balance, transactions, bookings, and recurrent repayment amounts over a specific period. It is mandatory for Lending integrations, as it is used for credit scoring to verify the customer's financial data.

Create an account snapshot

Call the endpoint below to create a snapshot. You must specify the source field to determine the integration method.

Request URL

POST /v1/persons/{person_id}/account_snapshots

• API Reference: Create snapshot

Method 1: FinTecSystems (FTS)

Use this method to integrate the FTS wizard.

1. Integrate the FTS wizard in your solution (see FTS Documentation).
2. Call the endpoint with source: FIN_TECH_SYSTEMS. Optionally, include the iban.
3. Use the returned wizard_session_key to initialize the FTS wizard.
4. The customer enters their credentials in the wizard.

Request:

{
  "source": "FIN_TECH_SYSTEMS"
}

Response:

{
  "wizard_session_key": "Hm7jUSC7XU2nQjPqJO8dl39eDkdjtOdCtywcmv3x",
  "location": null,
  "id": "8df2a8ba713c43dc9cb481b9cceed487snap",
  "account_id": null
}

Method 2: Finreach

Use this method to integrate the FinX widget.

1. Integrate the FinX widget (see FinX Documentation).
2. Call the endpoint with source: FINREACH.
3. Redirect the customer to the URL provided in the location field.

Request:

{
  "source": "FINREACH"
}

Response:

{
  "wizard_session_key": null,
  "location": "https://ui.solaris-i.prod.finleap.cloud?token=xxxxxx",
  "id": "8df2a8ba713c43dc9cb481b9cceed487snap",
  "account_id": null
}

Method 3: Partner (Manual Upload)

Use this method if you have your own connection to a third-party provider and want to upload the data directly.

• Set source to PARTNER.
• Include the full data structure in snapshot_data.

Request:

{
  "source": "PARTNER",
  "snapshot_data": {
    "account": {
      "bank_name": "",
      "bic": "",
      "country_id": "",
      "description": "",
      "holder": "John Smith",
      "iban": "DE92370601930002130041",
      "joint_account": false
    },
    "balance": {
      "balance": 3720.2,
      "currency": "EUR",
      "date": "2022-02-03",
      "limit": 0
    },
    "date": "2022-02-03",
    "days": 90,
    "turnovers": [
      { … }
    ]
  }
}

Method 4: Solaris (Internal)

Use this method if the customer already has a Solaris account.

• Set source to SOLARISBANK.
• Include the account_id of the Solaris account.

Request:

{
  "source": "SOLARISBANK",
  "account_id": "adc123a45d6d7cf8fbfeed537ba919d5cacc"
}

Response:

{
  "wizard_session_key": null,
  "location": null,
  "id": "0a3f28733f9a4842842aae2804f80eb4snap",
  "account_id": "adc123a45d6d7cf8fbfeed537ba919d5cacc"
}

GET Retrieve account snapshot

Call this endpoint to check the status and validity of an existing snapshot.

Request URL

GET /v1/persons/{person_id}/account_snapshots/{account_snapshot_id}

• API Reference: Retrieve snapshot

PUT Link account snapshot to consumer credit line application

After creating an account snapshot, use this endpoint to link the customer's account snapshot to their existing credit line application.

After linking the account snapshot to the application, the application status changes to account_snapshot_verification_pending, triggering the final verification step in the credit scoring process. After successful snapshot verification, the application status should change to offered and you can proceed with the remaining steps.

If the verification step fails, the status will change to rejected and you must abort the onboarding process.

Request example

// PUT /v1/persons/{person_id}/credit_line_applications/{application_id}/account_snapshot
{
    "account_snapshot_id": "6c8f81a234df4052a9cde197577347b7snap"
}

View full API reference

Step 6: Send SECCI form and credit line contract

Before prompting the customer to sign the final contract of the credit line, you must send the customer the Standard European Consumer Credit Information (SECCI) form. The SECCI form is a standardized credit form that includes the information related to a credit offer, such as creditor details, type of credit, amount, duration, interest rates, credit costs, etc.

In compliance with regulatory requirements, you must first send the customer the SECCI form to review and approve. Afterward, you can send them the final contract which they have to sign during the identification and e-signing process.

Implement the following endpoints to generate the SECCI form and final contract of a credit line:

GET Retrieve the SECCI form of a credit line

Call this endpoint to generate the SECCI form of the credit line as a PDF. You must share this form to the customer before sending the final contract either via email or direct download through your app.

Request URL

GET /v1/persons/{person_id}/credit_line_applications/{application_id}/pre_contract

View full API reference

GET Retrieve final contract

After the customer reviews and approves the credit line's SECCI form, call this endpoint to generate the final contract, which the customer must sign electronically during the identification process.

Request URL

GET /v1/persons/{person_id}/credit_line_applications/{application_id}/contract

View full API reference

Step 7: Complete the customer identification and e-signing process

In the step, you must prompt the customer to complete the identification process, in which the customer will be identified in a video identification session through our provider IDnow. During this session, an identification agent will verify the customer's data against their identification documents, verify their mobile number, and collect the customer's qualified electronic signature (QES) on the credit line contract, SDD mandate, and terms and conditions.

Call the following endpoints once the status of the consumer credit line application changes to esign_pending.

GET Retrieve the signing ID

When the application status changes to esign_pending, it means that the identification and e-signing process has been triggered for the customer. You must call the GET Retrieve consumer credit line application method to get the signing_id, which you will need to retrieve the identification details.

GET Retrieve e-signing and identification details

Once you obtain the signing_id from the previous endpoint, call the following method to get the video identification details, such as IDnow reference and URL.

Request URL

GET /v1/persons/{person_id}/signings/{signing_id}

Response example

The API call returns the identification details, such as the IDnow reference and url, to which you must redirect your customer to complete the identification process and the documents your customer must e-sign. The payload also includes the IDnow status.

{
    "id": "97b07d67783856a08312f38bf7b7ef2ecidt",
    "reference": "TST-NGGWH",
    "url":"[https://go.test.idnow.de/solarisbankesignsandbox/identifications/:id](https://go.test.idnow.de/solarisbankesignsandbox/identifications/:id)",
    "status": "pending",
    "completed_at": null,
    "method": "idnow",
    "proof_of_address_type": null,
    "proof_of_address_issued_at": null,
    "address": null,
    "documents": []
}

View full API reference

GET Retrieve the details of a successful identification

This endpoint returns a completed person identification (i.e., the person identification process was successful). If you use the include_documents filter, this method will also return the documents submitted by the customer during the identification process.

Request URL

GET /v1/persons/{person_id}/identifications/{id}

View full API reference

GET Download a document

This endpoint downloads the file of the document with the id specified in the request URL. Call this endpoint to download the relevant signed documents to share them with the customer.

Request URL

GET /v1/persons/{person_id}/documents/{id}/file

View full API reference

Identification and screening results

In this step, the customer will be identified through our KYC partner IDnow and internally screened by Solaris for risk metrics:

Successful identification

Once the customer completes the identification and e-signing process successfully, the credit line application status changes to esign_complete.

Failed identification

If the identification and e-signing process fails, the credit line application status changes to esign_failed. In this case, the customer can attempt to identify again depending on the reason for failure from IDnow.

Successful screening

Once the application status reaches esign_complete, the screening process will be triggered. If successful, the status will change to credit_line_creation_pending triggering the final steps of the onboarding process, which is the credit line and account creation.

Failed screening

If the screening process fails, the application status will change to rejected, and you must abort the onboarding process.

GET Retrieve the credit line ID

Once the customer completes the video identification and QES processes, Solaris creates the credit line. You can track the credit line creation process by calling the GET consumer credit line application method.

Once the credit line has been created, the application status changes to credit_line_created, and the credit_line_id will be included in the payload and the full credit line details such as the amount and interest rates.

Additionally, Solaris will create an account for the customer, which will be used in the scope of the credit line agreement. The account_id will also be included in the payload.

Step 8: Credit line usage and servicing

This step includes all the relevant endpoints you need to integrate into your solution to use and service credit lines.

Credit line usage

After a customer is granted a credit line, they can use the limit in the form of single installment loans.

For example, if Solaris offers a customer a 5,000 EURO credit line limit, they can choose to use 3,000 EURO to pay back the principal and interests in monthly installments over the course of 24 months. An installment loan for this amount and term will be created and serviced separately, leaving the customer with a remaining credit line limit of 2,000, which they can use in subsequent installment plans.

POST Generate available installment plans

Once a customer is granted a credit line, they can convert previous transactions into installments. You must generate possible installment plans and terms for the given amount and share them with the customer.

This endpoint generates possible installment plans for a given amount. The API call returns an array of possible installment plans for the given amount, including the term, monthly installment amount, and applicable interest rate.

Request example:

POST /v1/persons/{person_id}/credit_lines/{credit_line_id}/available_installment_plans

View full API reference

POST Create a credit line loan

This endpoint creates a loan resource based on an installment plan. The loan is used for bank statements and should shortly describe the purpose of the loan. Additionally, you should assign a reference for the loan and indicate whether a loan for a specific transaction was already created.

The API call returns an object with a unique ID, the loan_id, and the loan status.

For a list of possible values of the credit line loan status and their descriptions, check the appendices section. Additionally, subscribe to the webhook event LOAN to receive status updates about the loan.

Request URL

POST /v1/persons/{person_id}/credit_lines/{credit_line_id}/loans

View full API reference

Credit line servicing

This section includes the different endpoints you need to integrate in your solution for servicing and maintaining credit lines for your customers.

GET Retrieve a credit line

This endpoint returns the details of the credit line, such as the used amount, active loans, available limit, etc.

Request URL

GET /v1/persons/{person_id/}credit_lines/{credit_line_id}

View full API reference

PATCH Update the internal payout account tied to a credit line

This endpoint updates the internal payout account (Solaris account) used for a credit line loan payout.

Request example

PATCH /v1/persons/{person_id}/credit_lines/{credit_line_id}/payout_account

View full API reference

PATCH Update the reference account tied to a credit line

This endpoint updates the reference account (external account) used for a credit line loan payout.

PATCH /v1/persons/{person_id}/credit_lines/{credit_line_id}/reference_account

View full API reference

PUT Revoke a credit line

The customer can revoke an offered credit line within 14 days from the issuance date. The following endpoint revokes a created credit line for a customer.

Request URL

PUT /v1/persons/{person_id}/credit_lines/{credit_line_id}/revoke

View full API reference

Credit line account statements

Due to regulatory requirements, you need to generate annual account statements for credit lines for all of your customers with an active credit line. As long as the credit line remains active, you must share the annual statement with the customer every year as a PDF file, either via email or direct download through your frontend.

Additionally, in case of terminated credit lines, you need to generate a closing account statement and share it with the customer after the termination and account closure process has been completed.

GET Download annual account statement for a credit line

Call this endpoint to download an annual account statement for a credit line.

View full API reference

GET Download closing account statement for a credit line

Call this endpoint to download a closing account statement for a credit line.

View full API reference

Account closure and Credit line termination

If a customer requests to close their account, any associated credit line will be terminated as well. The termination process is managed internally by Solaris and may vary depending on your specific configuration with Solaris. If your customer wishes to terminate an existing credit line independently, please contact your Partner Manager for more information about the process.

For more information about account closure requests, check the related Account Closure guide.

Credit line renewal (France only)

For customers in France, credit lines cannot be offered with an unlimited term. Credit lines are offered for a period of 12 months and must be explicitly renewed by the customer.

The process for credit lines renewals is as follows:

• Solaris will notify you about the credit line renewal via the webhook event CREDIT_LINE.
• You must notify the customer of the renewal request.
• Call the endpoint PATCH Send confirmation to Solaris about customer renewal notification to inform Solaris that you have notified the customer, and include the notification date in the request body.
• In case the customer doesn't want to renew the credit line, call the endpoint POST Cancel credit line renewal to initiate the termination process. Please note that all credit line obligations must be repaid before terminating the credit line and closing the account.
• If the customer doesn't cancel the renewal, the credit line will be automatically renewed.

Loan servicing

This section includes the different endpoints you need to integrate in your solution for servicing and maintaining loans for your customers.

Loan Servicing Endpoints

Implement these endpoints to manage the active loan lifecycle, including retrieving status, schedules, and history.

Key Endpoints:

• GET Retrieve a loan
• GET Index all loans
• GET Retrieve a loan schedule
• GET Retrieve repayment history
• GET Retrieve credit line mandate

GET Retrieve a loan schedule

Call this endpoint to retrieve the latest repayment schedule for a specific loan. The response includes:

• Loan balance: The remaining amount to be paid.
• Loan installments: A list of past and future scheduled payments.

Request URL

GET /v1/loans/{loan_id}/repayment_schedule

• API Reference: Retrieve loan schedule

GET Retrieve repayment history

Call this endpoint to view the history of all payments made towards the loan. The response includes:

• SEPA Direct Debits (SDD): Automatic monthly installments pulled from the reference account.
• SEPA Credit Transfers (SCT): Manual transfers made by the customer for partial or full early repayment (if applicable).

Request URL

GET /v1/loans/{loan_id}/repayment_history

• API Reference: Retrieve repayment history

Next steps

Congratulations! You have successfully integrated Solaris' Consumer Splitpay solution.

Check the following appendices section for additional information on enums and testing data.

For an overview of Solaris' lending products, check the lending products overview page.

Useful resources

Check the following links for additional related guides and API reference documentation:

• Consumer Credit Line API Reference Documentation
• Loan Servicing API Reference documentation
• Person Signings API Reference Documentation
• Video Identification Guide
• SEPA Transfers Overview
• SEPA Direct Debit Transfers

Appendix I: Enums

Consumer credit line application status

These are the possible values for the field status in the consumer credit line application resource.

Consumer credit line status

These are the possible values for the field status in the consumer credit line resource.

Credit line loan status

These are the possible values for the field status in the credit line loan resource.

Document types

The following table includes the possible values for the field document_type and their descriptions.

Idnow status

The following table includes the possible values for the field status for the video identification process carried out by IDnow and the related description of each status.

IDnow provides a reason whenever the identification has a canceled or aborted status. No reason is disclosed for the final failed status.