Skip to main content
Sandbox payloads for the Stateless PhilSys Check Tier 2 endpoint.
When your account is in sandbox mode, these payloads return the outcomes shown below. Any other valid payload is answered as a no-match — HTTP 200 with isValid set to false. Values are case-sensitive. transactionId and createdAt are generated per request, and metadata is echoed back from your request. See Sandbox introduction for the full matching rules. Every request needs faceLivenessSessionId plus exactly one of pcn, pcnFormData, or qrData. Sending two, or none, fails validation.

Verified

Request
Response — HTTP 200
Request
Response — HTTP 200
The ePhilID QR is a colon-delimited string beginning with PH1:. The 16-digit PCN it carries is returned formatted with dashes in PCN.
Request
Response — HTTP 200
The Digital ID QR is a JSON string. Its id is echoed back as digitalId and must be alphanumeric and no more than 7 characters.
Request
Response — HTTP 200
This response carries each name field twice — once normalised (firstName, middleName, lastName, birthDate) and once in the PVC card’s native abbreviated keys (fName, mName, lName, DOB). Read the normalised keys.
Request
Response — HTTP 200
A suffix of "N/A" is returned as null. Send "N/A" when the person has no suffix.
Request
Response — HTTP 200
PCN 9999-0000-9999-0000 accepts any valid UUID as its faceLivenessSessionId, including a session id from a real liveness capture. Use it to test the full capture-then-verify flow end to end.

Rejected

A rejection is a completed verification, not an error: success is true, HTTP status is 200, and no identity fields are emitted. In live mode a rejection is billed.
Request
Response — HTTP 200
Request
Response — HTTP 200
This PCN matches no documented scenario, so it takes the no-match fallback — byte-identical to the documented rejection above apart from transactionId and metadata. Worth firing once to confirm that an unknown PCN never reaches live PhilSys.

Validation failures

All validation failures return HTTP 400 with code set to VALIDATION_FAILED and the same message; only errors differs. Validation runs before any fixture matching, so these behave identically in sandbox and live.
Request
Response — HTTP 400
This is the only 400 that carries a real transactionId and echoes metadata. The request reached the service, so a transaction row was written with status FAILED (6). Every other 400 returns transactionId: null, omits metadata, and writes no row.
These fail before the service is reached. Every one returns HTTP 400 with the same envelope:
Only errors differs. Each row below is a change to the by-PCN request:
trustFlowId and trustValidationId are prohibited on stateless endpoints. Sending either is a validation failure, not a silently ignored field.

Source unavailable

Request
Response — HTTP 500
There is no data key at all. The envelope treats code and data as mutually exclusive, so a coded failure drops data rather than emitting an empty object. Branch on code, not on the presence of data.

Account-level responses

Two further responses are not specific to this endpoint. A missing or invalid Authorization header returns HTTP 401, and an account without the scan_qr plan returns HTTP 403 — both enforced in sandbox exactly as in live. See Sandbox introduction for their envelopes.