3. Provide identification data

POST /api/v1/checkout/:uuid/identification

Endpoint to provide all the customer identification data and the selected product setup.
Example of request payload:

{
  "given_names": "John",
  "surnames": "Doe",
  "dob_day": "13",
  "dob_month": "04",
  "dob_year": "1970",
  "mobile_phone": "674253441",
  "nin": "46923652H",
  "address": "",
  "postal_code": "",
  "city": "",
  "sequra_privacy_policy_accepted": true,
  "credit_agreement": {
    "product": "pp3",
    "instalment_count": 3
  }
}

Selected credit_agreement (if needed) should be identified with product and instalment_count fields.

If the identification contain errors, the response will be a HTTP 200 with a errors json:

{
  "action": "show_identification_form",
  "errors": {
    "address": "invalid",
    "city": "invalid",
    "postal_code": "invalid",
    "surnames": "invalid"
  }
}

Currently, there is only one type of error: invalid. The frontend must show a different error message depending on the field. For example, "invalid" surnames error message could be "2 surnames required".

When all the fields are correct, it will respond with HTTP 200 and the next action to take:

{
  "action": "wait_for_screening"
}

Possible actions:

Action	Description
`show_identification_form`	There are errors in the identification data. A field `errors` is present with the list of fields having an error.
`require_payment`	Payment is required.
`require_validate_otp`	An OTP (SMS) has been sent and it is required that the shopper introduces the code. The identification must be submitted again with the provided `validation_code` attribute (5 digits).
`show_on_hold`	The order is on hold and needs to be manually reviewed.
`wait_for_screening`	The order is in screening process. Polling at wait endpoint will return the result. `expires_in` attribute will be present to show to the users how much they should wait. Polling at wait endpoint will eventually resolve it.
`wait_for_confirmation`	The order is in confirmation process. Polling at wait endpoint will eventually resolve it.
`show_error`	Something happened. `errors` attribute will be present with a list of error messages.
`reject`	The order has been rejected.
`finish`	The order is already confirmed, checkout can be finished.

Special metadata on some actions

{
  "action": "wait_for_screening",
  "expires_in_seconds": 120,
  "polling_url": "..."
}

{
  "action": "wait_for_confirmation",
  "polling_url": "..."
}

{
  "action": "show_error",
  "messages": [
    "error message 1",
    "error message 2"
  ]
}

{
  "action": "finish",
  "return_url": "..."
}

{
  "action": "require_payment",
  "iframe_url": "...",
  "reusable_cards": [
    {
      "iframe_url": "...",
      "expiry_month_year": "12/23",
      "last_four": "9777",
      "masked_pan": "471677******9777"
  ],
  "amount": { "value": 100, "string": "1,00 €" }
}

Rendering the Card Form

When receiving the require_payment action, the iframe_urlparam will include an url to the card form.

To render the card form, load the Mufasa JS SDK Javascript library and follow the library documentation to render the iframe and listen to the iframe callbacks.

You can use the test card as described in the seQura API Docs to perform a successful payment.