# IdentityVerification

Pending action IdentityVerification is always triggered only by Intergiro on production environment, however to test the integration you can simulate this use-case on staging environment for Individuals in statuses onboarding_data_provided, activated, blocked by performing the following recommended steps:

  1. POST /individual - create an Individual;
  2. POST /individuals/:id/onboard - start the onboarding process for created Individual;
  3. Depending on the use-case you would like to test you can just simulate onboarding data provision OR additionally simulate Individual status change:
    1. POST /simulations/onboarding/kyc - provide onboarding data to test pending action for the Individual in status onboarding_data_provided;
    2. POST /simulations/onboarding/status - use this request in combination with /onboarding/kyc to simulate onboarding decision and to test pending action for the Individual in status activated or blocked
  4. POST /simulations/individuals/:id/identity_verification - simulate creation of pending action as if it is triggered from Intergiro side;
  5. GET /events - retrieve pending_action_id from received PendingActionCreated event;
  6. GET /pending_actions/:id - fetch consent_id from pending action;
  7. POST /consents/id: - fetch redirect_url and pass the steps on UI

TIP

In case you try to simulate creation of IdentityVerification for the Individual in status pending_activation or onboarding_requested 3d API will return 422 error with the following body:

{
    "error": {
        "code": "request_blocked",
        "message": "The individual should have one of the following statuses: onboarding_data_provided, activated, blocked"
    }
}

# ProofOfAddressVerification

Pending action ProofOfAddressVerification is always triggered only by Intergiro on production environment, however to test the integration you can simulate this use-case on staging environment for Individuals in statuses onboarding_data_provided, activated, blocked by performing the following recommended steps:

  1. POST /individual - create an Individual;
  2. POST /individuals/:id/onboard - start the onboarding process for created Individual;
  3. Depending on the use-case you would like to test you can just simulate onboarding data provision OR additionally simulate Individual status change:
    1. POST /simulations/onboarding/kyc - provide onboarding data to test pending action for the Individual in status onboarding_data_provided;
    2. POST /simulations/onboarding/status - use this request in combination with /onboarding/kyc to simulate onboarding decision and to test pending action for the Individual in status activated or blocked
  4. POST /simulations/individuals/:id/proof_of_address_verification - simulate creation of pending action as if it is triggered from Intergiro side;
  5. GET /events - retrieve pending_action_id from received PendingActionCreated event;
  6. GET /pending_actions/:id - fetch consent_id from pending action;
  7. POST /consents/id: - fetch redirect_url and pass the steps on UI

TIP

In case you try to simulate creation of ProofOfAddressVerification for the Individual in status pending_activation or onboarding_requested 3d API will return 422 error with the following body:

{
    "error": {
        "code": "request_blocked",
        "message": "The individual should have one of the following statuses: onboarding_data_provided, activated, blocked"
    }
}

# AuthenticateCardOperation

Pending action AuthenticateCardOperation is always triggered only by Intergiro on production environment, however to test the integration you can simulate this use-case on staging environment for Individuals in status activated and for the card in status activated by performing the following recommended steps:

  1. POST /simulations/three_ds_authentication - simulate creation of pending action as if it is triggered from Intergiro side;
  2. GET events - retrieve pending_action_id from received PendingActionCreated event;
  3. GET /pending_actions/:id - fetch consent_id from pending action;
  4. POST v3/consents/id: - fetch redirect_url and pass the steps on UI.