A customer passes identity verification in the morning. In the afternoon a newer review restricts the account. That evening a retried copy of the morning approval reaches the payment app. Which version of the customer should the app trust?
If the integration writes the last webhook it receives into a Boolean, an old decision can restore access. The provider may be working correctly. The app has confused delivery order with decision order.
Separate a review from what a customer can do
A provider reports the outcome of a review. The product owns the consequences for opening a wallet, initiating a payout or raising a limit. A retryable document issue, a manual hold and a final rejection should lead to different next actions.
Sumsub’s results documentation explains that an applicant can receive more than one final webhook and that retries can reflect an earlier state. Its webhook documentation describes authenticating the raw message with a digest. Signature validation establishes provenance; it does not establish that the result is current.
Preserve a decision history
Verify the signature before treating a message as evidence. Match the applicant to the expected account and workflow; an applicant reference should not cross environments or tenants. Keep enough metadata to identify repeats and compare decisions in the correct scope. When two events cannot safely be ordered, reconcile with the authoritative provider state and defer the sensitive action.
The lab uses synthetic revision numbers. It does not assume a provider exposes that exact primitive. Real integrations need to establish which fields, timestamps and API results distinguish the cases and test that contract in a sandbox.
Check access where it matters
When an account initiates a new payout, check the current feature policy at the server authorization boundary. A green badge cached in the browser should not be enough. Design separately for actions already in flight; a later restriction cannot undo an irreversible transfer.
Keep an operator receipt with the source reference, decision and policy version. Give support a reason it can safely explain without copying identity documents or private notes into logs.
Try Verification Replay Lab
Replay approval, restriction and then the old approval. Compare an app that trusts arrival order with one that validates provenance and keeps the newer decision. Also try a duplicate and an ambiguous update. This is a fictional access policy: it uses synthetic applicants and signature flags, makes no provider calls and does not determine anyone’s eligibility.
What dOrg would build first: connect one verification workflow to one gated feature, with signed event intake, clear resubmission and review states, and a test suite that proves a stale approval cannot reopen access.