Skip to main content

Get users' consent

You need end-user consent to process a transaction. If it's not given, you cannot progress through the workflow. Consent is always transaction-scoped, meaning each new transaction will require a new user consent.

Structure​

Consent is defined as the following structure:

{
  "userId": "unique-value-representing-end-user",
  "givenOn": "2025-01-02 03:04:05.678",
  "ipAddress": "192.168.1.1",    // automatically collected & anonymized
  "userAgent": "Mozilla/5.0...", // automatically collected
  "note": "notes, comments",
  "isProcessingStoringAllowed": true,
  "isTrainingAllowed": true
}
  • userId is a required field. This value should uniquely represent the end user within the system.
  • givenOn is an optional field describing when the consent was collected. If it's not provided, the current timestamp is assigned.
  • ipAddress, userAgent: Automatically assigned by the platform.
  • note is a text field available to customers to further explain the consent if needed.
  • isProcessingStoringAllowed must be set to true to proceed with the transaction. This value represents that the account owner has collected this end-user's consent for their data to be processed and stored by Microblink. Their consent is required for us to be able to complete the verification.
  • isTrainingAllowed is optional and will not block the transaction if not given. However, when set to true, transaction-level data may be used to further improve the platform. This value represents that the account owner has collected this end-user's consent for their data to used by Microblink for the improvement of the fraud detection capabilities in our own products.

You can submit user consent via multiple channels.

At the start of transaction​

When a new transaction is started, you can immediately provide the consent for it.

{
  "workflowId": "8cL5xg63gbzLSjvUWYBm9Hnv", 
  "platform": "browser", 
  "sdkVersion": "1.3.0",
  "consent": {
    "userId": "my-user-55d02c8f-28c9-4ae1-aec8-6cdaf78101be",
    "isProcessingStoringAllowed": true,
    "isTrainingAllowed": true
  }
}

In this case, the consent is provided by the app on the user's device. The SDK code in the app contacts your proxy and simultaneously starts a transaction and provides consent.

As a separate API call​

If transaction was already created without a consent, you can submit the consent payload separately:

{
  "userId": "my-user-55d02c8f-28c9-4ae1-aec8-6cdaf78101be",
  "isProcessingStoringAllowed": true,
  "isTrainingAllowed": true
}

In this case, the app (SDK) doesn't go through the proxy and doesn't contact the Agent API. Instead, it provides consent directly to the Edge API:

https://api.us-east.platform.microblink.com/edge/api/v1/transaction/<transaction_id>/consent

Verification links allow deferred transaction creation. As this process automatically creates the transaction when the link is opened, you can send the consent at that point.

curl --url https://api.us-east.platform.microblink.com/agent/api/v1/verification-link \
     --oauth2-bearer '<access_token>' \
     --json '{ 
               ...,
               "consent": {
                 "userId": "my-user-55d02c8f-28c9-4ae1-aec8-6cdaf78101be",
                 "isProcessingStoringAllowed": true,
                 "isTrainingAllowed": true
               }
             }'

Partial submission​

You can also send consent partially: send individual fields in different requests, optionally by using multiple of the methods above. Only the latest values are used on the back end.

However, once isProcessingStoringAllowed is true, it cannot be reverted to false, as the transaction might have already been executed.

Request​

GET /agent/api/v1/transaction/{transaction_id}

For example:

curl --url https://api.us-east.platform.microblink.com/agent/api/v1/transaction/<transaction_id> \
     --oauth2-bearer '<acces_token>'

Response​

{
    "id": "0267bdb133715dc60d70f49703",
    // ... cropped for readability
    "consent": {
      "userId": "unique-value-representing-end-user",
      "givenOn": "2025-01-02 03:04:05.678",
      "note": "free text",
      "ipAddress": "34.66.222.0",
      "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36",
      "isProcessingStoringAllowed": true,
      "isTrainingAllowed": true
    },
    // ...
}

In the IP address field, the last octet is always .0, as platform does not store full IP address at any point.

Privacy notices​

Before collecting consent, provide clear privacy notices that are easily discoverable and use plain language accessible to your target audience.1 Your privacy notice should include:

  • Controller identity
  • Specific processing purpose
  • Data types collected
  • Retention period
  • Third-party sharing details

You can use or adapt the Microblink privacy notices available at:

Obtain explicit opt-in consent through active checkboxes or buttons—never use pre-ticked boxes.2 Enable easy consent withdrawal mechanisms that are as simple as granting consent, ensuring users can change their preferences at any time.

Identity verification transparency​

Clearly explain why identity documents and biometric data are collected. Detail the document scanning, authenticity checks, and liveness detection procedures your end users will experience.

Data retention​

Define clear retention periods based on legal requirements and business needs:3

  • Typically 3-5 years for identity verification data under AML/KYC compliance
  • Immediate deletion of biometric data after verification unless legally required

The platform has customizable data retention with a minimum retention period of 3 months and a default setting of 36 months. Automated deletion permanently removes data when retention periods expire.

Regional compliance​

Store data in appropriate jurisdictions based on customer location. Implement adequate safeguards for cross-border transfers through Standard Contractual Clauses, adequacy decisions, or Data Privacy Framework mechanisms. Adapt retention periods to meet specific regional requirements, including state biometric laws.

Documentation and audit trails​

The platform documents when, how, and for what specific purposes consent was obtained. This includes timestamps, dates, and consent context to create verifiable audit trails for regulatory inspections and end-user rights requests.

Track and respond to data subject rights requests within GDPR's 30-day timeline.

Jurisdiction considerations​

Displaying a privacy notice to the end customer is mandatory in most jurisdictions. Certain jurisdictions also require publication of retention schedules—check if the jurisdiction of your interest has this requirement. Additionally, some regulations require written consent for specific data types (e.g., CPRA requires written consent for biometric data processing).

Footnotes​

  1. (EU/UK) GDPR art. 12-14; (Canada) PIPEDA Principles 2-3; (Brazil) LGPD art. 6-7, 9; (China) PIPL art. 17-21; (California) CPRA §1798.100(b), §1798.110, §1798.121; (Colorado) CPA §6-1-1307, §6-1-1308; (Virginia) CDPA §59.1-574, §59.1-575 ↩

  2. (EU/UK) GDPR art. 4, 6, 7; (Canada) PIPEDA Principle 3; (Brazil) LGPD art. 7-8; (China) PIPL art. 13-17; (California) CPRA §1798.120; (Colorado) CPA §6-1-1306; (Virginia) CDPA §59.1-574, §59.1-575 ↩

  3. (Illinois) BIPA art. 15(a) ↩

Last updated on