Skip to main content
Returns the transaction: where it is in its lifecycle and, once analysis has finished, the decision with every reason behind it.

Request

string
required
Bearer {access_token} — see Authentication.
string (UUID)
required
The id returned by Create transaction.

Response

string (UUID)
The transaction id.
string (UUID)
The customer this transaction belongs to.
string
CREATED, INITIATED, COMPLETED, PROCESSING, FINISHED, FAILED or EXPIRED. See How verification works.
string (ISO-8601)
When your backend opened the transaction.
string (ISO-8601) | null
When the SDK started the session on the device.
string (ISO-8601) | null
When the user finished capture.
string (ISO-8601) | null
When analysis started.
string (ISO-8601) | null
When analysis ended.
object | null
The analysis result. null until the transaction reaches FINISHED or FAILED. Full structure in Reading a result.

Example

Response — approved
Response — rejected
Response — still in progress

Polling

Prefer webhooks: they arrive as soon as the decision exists, and polling a transaction that is still INITIATED tells you nothing you did not already know. When you do poll — as a reconciliation job, or as a fallback when a webhook did not arrive — back off rather than hammering:
Analysis normally settles within seconds of the user finishing. A transaction sitting in INITIATED is waiting on the user, not on chmod — it will move to EXPIRED once transaction_ttl_minutes elapses.

Next

Reading a result

Every field inside result_data.

Issue codes

What each rejection reason means.