Verification needs more information
request_for_information is a fixable outcome, not a rejection. Read the reasons, supply the fix with a PATCH, and submit again.
What it means
request_for_information is the retryable adverse outcome. The review
looked at the submission and needs something corrected: a blurry document,
a selfie that did not match, a missing proof of address. Nothing is final,
and the customer is not rejected.
The endorsement moves to issues, and
endorsement.request_for_information fires.
What to do
Read the reasons
The round object carries rejection_reasons, and each entry names the
requirement to fix:
"rejection_reasons": [
{"requirement": "selfie", "retryable": true}
]
The endorsement's missing and issues buckets now list the same
items as bare codes. Render your fix-it screen from the buckets: they
are the channel designed for it.
Collect a replacement from your user
Show the affected requirement and collect a new file. Send a genuinely new image: an identical file is deduplicated by content hash and will not trigger a re-review.
PATCH it in
curl -s -X PATCH $BASE/api/customers/cus_... \
-H "Api-Key: $KEY" -H "Idempotency-Key: $(uuidgen)" \
-H "Content-Type: application/json" \
-d '{"documents": [{"purpose": "selfie", "file": "<base64>"}]}'
Submit again
curl -s $BASE/api/customers/cus_.../verifications/submit \
-H "Api-Key: $KEY" -H "Idempotency-Key: $(uuidgen)" \
-H "Content-Type: application/json" -d '{}'
This opens a new round on the same applicant. No new customer, no lost progress: requirements that already passed stay passed.
Good to know
- If the customer was already approved and the ask came from a scoped re-check, they stay approved while it runs. Money keeps flowing.
rejectedis the final state. Resubmission will not be accepted, so route the customer to your support path.- An
amlrequirement is not fixable by documents. It is usually final. - Rehearse the whole loop in sandbox with
"decision": "request_for_information"on the verification simulator.