DEV Community: murray wang

An approval was corrected to Declined: how to test permission revocation

murray wang — Sat, 17 Oct 2026 03:36:01 +0000

Your fixture session received Approved and granted a local permission. A later event says Declined. You need to decide whether that event revokes access, and how to tell a real correction from a replayed or stale callback. This article tests that decision in the synthetic fixture and separates what the fixture does from what your application must design.

The problem: an approval that no longer holds

A seller passed verification, your handler recorded Approved, and the explicit policy allowed a local permission. Later a new Declined event arrives for the same session. If your code treats every terminal status as final, it ignores the correction and access stays open. If it treats every incoming event as fresh, a replayed callback can flip state back and forth. The goal is narrow. A new Declined correction after Approved must set permission_granted from true to false. grant_count must stay at 1, because the history of the grant does not disappear. Duplicate and stale events must change nothing. Whether a real provider ever sends such corrections, and what they mean, depends on that provider's actual contract. The fixture only lets you rehearse the shape.

What the fixture actually implements

The downloadable identity example stores sessions and processed event IDs in SQLite. Its event method accepts only mode synthetic_fixture and source fixture_callback, and only event IDs that start with fixture-. It has no production signature verifier. It checks tenant and subject binding first, then deduplicates on the session and event ID pair. One rule handles corrections. If the stored status is approved and the incoming status is Declined, the fixture records the event and sets status to declined and granted to 0. It leaves the grants counter untouched. Any other event against an approved, declined or expired session returns the current state unchanged. That event is not recorded either. This correction check runs before the deadline check, so a Declined correction after Approved is applied even when it arrives after the deadline. live_permission_changed is always false. No real permission exists.

Hypothetical scenario and expected outputs

This is a hypothetical walkthrough on fixture-session, bound to fixture-tenant and fixture-user, with deadline 60.

Step 1: send event fixture-approved with status Approved and policy true. Expect status approved, deadline 60, permission_granted true, grant_count 1, live_permission_changed false.

Step 2: replay fixture-approved. Expect the identical object. The duplicate is a no-op.

Step 3: send a new event ID, for example fixture-correction, with status Declined. Expect status declined, deadline 60, permission_granted false, grant_count 1, live_permission_changed false.

The tested expired output is a different path: a session that never received an approval. It has status expired, permission_granted false, grant_count 0, next review_or_authorized_provider_refresh and provider_polled false. Do not use it as evidence of revocation.

New correction, duplicate, or stale pending event

Three inputs can look alike and must stay distinct.

A new correction carries an unseen event ID and status Declined against an approved session. It revokes the permission.

A duplicate reuses a processed event ID. It returns stored state, even if its status field now differs.

A stale pending event, such as In Progress or In Review arriving after Approved, must not downgrade or re-grant anything. The fixture returns current state and does not record it.

Two more cases follow the same rule. A late Approved after a Declined correction is also ignored, so permission does not silently reopen. A second Declined after declined changes nothing.

Test each case with distinct event IDs and assert both permission_granted and grant_count.

Proposed design: a caller-owned revocation receipt

The following is a proposed design, not fixture behavior. The fixture flips one flag; real revocation touches listings, payouts or sessions in systems you own. A caller-owned revocation receipt could record:

the session
the correcting event ID
the previous and new status
the grant count at revocation
a timestamp
which downstream actions were requested and confirmed

Write the receipt in the same transaction that clears the permission. Make downstream undo steps idempotent against that receipt. Before trusting a correction, re-fetch the authoritative decision through an authorized provider route. A synthetic Declined is not evidence of a real decline, and synthetic fixture permission is not live business permission.

Failure handling

Several failures need defined behavior.

If a correction fails the binding check, the fixture raises BINDING_MISMATCH. Treat this as an alert, not as a revocation.

Non-synthetic sources raise PRODUCTION_SIGNATURE_VERIFIER_NOT_IMPLEMENTED. Event IDs without the fixture- prefix raise SYNTHETIC_EVENT_REQUIRED. Sending an event for an unknown session raises BINDING_MISMATCH; reading an unknown session with read raises SESSION_NOT_FOUND.

The recover method only expires pending, review or unknown sessions locally. It never polls a provider and never reverses an approval. Do not rely on it to catch a missed correction.

If your downstream revocation partially fails, keep the permission cleared and mark the receipt incomplete for review. Do not restore access.

Acceptance checklist

Approved with policy true yields permission_granted true and grant_count 1.
A replayed approval event ID leaves both fields unchanged.
A new Declined event yields status declined, permission_granted false and grant_count 1.
Stale In Progress or In Review after Approved changes nothing.
A late Approved after the correction does not restore permission.
A correction with the wrong tenant or subject is rejected.
live_permission_changed stays false throughout.
Your own receipt and downstream undo steps are tested separately.
Your correction semantics are confirmed against the real provider contract before any live use.

Run the checked synthetic example

Download and extract https://gridzen.ai/downloads/verification-delivery.zip, enter verification_delivery, then run with Python 3.10+. This local example makes no network calls. Use a fresh database for an independent identity run.

python3 delivery.py identity --db /tmp/gridzen-article-fixture.sqlite

Sources and scope

https://gridzen.ai/guides/approved-seller-permissions/
https://gridzen.ai/guides/current-capabilities/
Based on the checked source snapshot and local fixture; proposed application rules are design advice, not proven production behavior. Written with AI assistance and reviewed independently.

curl https://gridzen.ai/console/api/quickstart/trial \
  -H 'Content-Type: application/json' \
  -d '{"task": "identity_onboarding", "scenario": "success"}'

This is synthetic integration testing, not identity verification or production authorization. Real payments are disabled.

Create a free sandbox account · Integration guide

Written and tested by the GridZen team with AI assistance.

Should an unknown phone result reject a signup?

murray wang — Sat, 17 Oct 2026 03:32:29 +0000

A signup form calls a phone check and gets back something that is neither valid nor invalid. Either the result is unknown or the provider call failed. The tempting shortcut is to reject anything other than a clean pass. This article argues against that shortcut and walks through the four-branch synthetic example to show how to route each outcome. The core distinction is simple. An unknown result is missing evidence, not negative evidence. If you reject on missing evidence, every provider outage becomes a user lockout.

The problem and the decision you own

The decision in front of you is not whether a number is good. It is what your signup flow should do when the check cannot answer. Three outcomes look alike in code but mean different things. A confirmed invalid number is evidence. An unknown result means the check returned no usable signal. A provider failure means the check never completed. Only the first justifies blocking on format grounds. The other two need an explicit path: bounded recovery, manual review, or a possession step through an OTP provider you already run.

Keep in mind what no phone check establishes. Validity and line type are different from possession and identity. The current free production route does not request line type, ownership, reachability or OTP delivery. Its approved controlled pilot covers basic number format and validity only.

What the downloadable example implements

The downloadable example runs offline in Python 3.10 or later. It needs no credentials and makes no network calls. It has four branches: normal, unknown, provider_failure and otp. Every output includes the fields mode, branch, state, valid, line_type, next, otp_sent and live_line_type_available.

Two values never change across branches. The mode field is always synthetic_fixture. The otp_sent field is always false, so the example never sends a code. The live_line_type_available field is always false, which reflects that the free route does not return line type.

The mobile line type you will see in the normal branch is fixture data, not something a live check would return. Any branch name outside the four raises UNSUPPORTED_FIXTURE.

This example is not the same as the anonymous HTTP trial, which covers three scenarios. Do not treat results from one as results from the other.

Worked hypothetical: four signups, four routes

Imagine a hypothetical marketplace that receives four signups in one hour. The fixture's expected outputs map onto them as follows.

The first signup takes the normal branch. The output is state simulated, valid true, line_type mobile and next continue_customer_policy. Your own rules decide what happens next. The check alone does not admit the user.

The second signup takes the unknown branch. The output is state unknown, valid null, line_type null and next review_or_existing_otp. The account is held for review or sent to your existing OTP step. It is not rejected.

The third signup takes the provider_failure branch. The output is also state unknown with valid null and line_type null, but next is bounded_retry_then_review. You retry a limited number of times and then hand the case to review.

The fourth signup takes the otp branch, which models a request to prove possession. The output is state unsupported, valid null, line_type null and next customer_otp_provider. GridZen sends nothing here. That step belongs to your OTP provider.

All four outputs carry otp_sent false.

Proposed application design for failure handling

The following is design guidance for your application, not behavior the fixture implements.

Bound retries with a fixed attempt count and a deadline, so a provider failure cannot loop forever or block the form indefinitely.

Store unknown and failed outcomes as their own state, kept separate from invalid. That way, reviewers and analytics do not mistake an outage for fraud.

When review is the route, decide what the user may do while pending. You might let them browse but block payouts or listings until the case is resolved.

If you route to OTP, call your existing provider and record its result separately from the phone check result.

Do not let a null valid value coerce to false anywhere in your code.

Limits you should state plainly

The fixture produces synthetic outputs only. It proves branch handling in your code, not production success. Its tests cover simulated transitions, bindings, duplicate callbacks, restart and timeouts. They do not demonstrate live accuracy, external adoption or agent superiority.

An OTP recommendation does not send a code and does not establish possession.

Live route availability requires separate confirmation. Production phone checks are limited to the controlled pilot, and self-service live verification is disabled.

Acceptance checklist

Before you ship, confirm each of the following.

Running all four branches reproduces exactly the next values listed above.
Your code treats a null valid value as unknown, never as invalid.
The unknown branch never auto-rejects a signup.
The provider_failure branch retries a bounded number of times, then moves to review.
The otp branch calls only your own OTP provider and records otp_sent as false on the GridZen side.
No logic reads line_type from a live result.
Your code handles UNSUPPORTED_FIXTURE.
The unit tests pass.
Documentation does not claim ownership, reachability or identity from a phone check.

Run the checked synthetic example

python3 delivery.py phone --branch unknown
python3 delivery.py phone --branch provider_failure

Sources and scope

https://gridzen.ai/guides/signup-phone-check/
https://gridzen.ai/guides/current-capabilities/
Based on the checked source snapshot and local fixture; proposed application rules are design advice, not proven production behavior. Written with AI assistance and reviewed independently.

curl https://gridzen.ai/console/api/quickstart/trial \
  -H 'Content-Type: application/json' \
  -d '{"task": "signup_phone", "scenario": "success"}'

This is synthetic integration testing, not identity verification or production authorization. Real payments are disabled.

Create a free sandbox account · Integration guide

Written and tested by the GridZen team with AI assistance.

Recover a delayed verification callback

murray wang — Tue, 13 Oct 2026 07:09:46 +0000

Recover a delayed callback without creating duplicate sessions. The runnable local example stores state in SQLite, enforces a deadline and rejects late permission grants. Its callback channel is explicitly synthetic: it is not a live signature verifier.

What you will build

Run and inspect the three outcomes

for scenario in success reject unavailable; do
  curl -fsS https://gridzen.ai/console/api/quickstart/trial \
    -H 'Content-Type: application/json' \
    -d '{"task":"identity_onboarding","scenario":"'"$scenario"'"}'
done

Expected output (synthetic)

{
  "mode": "synthetic_fixture",
  "source": "local_response_trial",
  "task": "identity_onboarding",
  "scenario": "success",
  "verified": false,
  "real_person_verified": false,
  "billable": false,
  "amount_minor": 0,
  "upstream_calls": 0,
  "result": {
    "status": "Approved",
    "reason": "synthetic_scenario",
    "hosted_url": null
  },
  "business_decision": "caller_owned",
  "next_step": "connect_verified_account_for_persisted_sandbox",
  "production_available_from_this_trial": false
}

Local state machine: restart, duplicates and deadlines

The local script uses only fixture identifiers. Run the code and tests in the linked repository; no account or provider key is required. Production callbacks need their own authorized signature verifier.

git clone https://github.com/immurray/gridzen-developer-kit.git
cd gridzen-developer-kit
python3 examples/verification_delivery/delivery.py identity --db /tmp/gridzen-local-delivery.sqlite3
python3 -m venv .venv
.venv/bin/python -m pip install pytest
.venv/bin/python -m pytest examples/verification_delivery/test_delivery.py -q

Decide what your app does next

Treat success as a fixture branch, not real-person approval. For reject, show a recoverable message or review path. For unavailable, leave the outcome unknown and avoid silently granting permission. In a real integration, bind tenant, account and session; verify the provider notification, re-read authoritative state and apply your business policy before changing permissions.

Limits and production handoff

No documents, phone numbers, credentials or real users are accepted by this trial. Production is a separate owner-approved free pilot. Current phone production provides basic validity only; hosted identity requires current confirmed free allowance and applicable supplier rights. Real payments remain disabled.

Synthetic integration example; no real person verified, no OTP, no production permission and no payment.

Run without signup · Get task guidance · Source and tests

Written and tested by the GridZen team with AI assistance.

Separate verification results from business permissions

murray wang — Tue, 13 Oct 2026 07:00:48 +0000

Turn a verification result into a bounded application decision. Test account binding, explicit policy, duplicate events and rejection handling in a local fixture database. The permission shown in this walkthrough is a demo flag, not a real seller permission.

What you will build

Run and inspect the three outcomes

for scenario in success reject unavailable; do
  curl -fsS https://gridzen.ai/console/api/quickstart/trial \
    -H 'Content-Type: application/json' \
    -d '{"task":"identity_onboarding","scenario":"'"$scenario"'"}'
done

Expected output (synthetic)

{
  "mode": "synthetic_fixture",
  "source": "local_response_trial",
  "task": "identity_onboarding",
  "scenario": "success",
  "verified": false,
  "real_person_verified": false,
  "billable": false,
  "amount_minor": 0,
  "upstream_calls": 0,
  "result": {
    "status": "Approved",
    "reason": "synthetic_scenario",
    "hosted_url": null
  },
  "business_decision": "caller_owned",
  "next_step": "connect_verified_account_for_persisted_sandbox",
  "production_available_from_this_trial": false
}

Local state machine: restart, duplicates and deadlines

git clone https://github.com/immurray/gridzen-developer-kit.git
cd gridzen-developer-kit
python3 examples/verification_delivery/delivery.py identity --db /tmp/gridzen-local-delivery.sqlite3
python3 -m venv .venv
.venv/bin/python -m pip install pytest
.venv/bin/python -m pytest examples/verification_delivery/test_delivery.py -q

Decide what your app does next

Limits and production handoff

curl https://gridzen.ai/console/api/quickstart/trial \
  -H 'Content-Type: application/json' \
  -d '{"task": "identity_onboarding", "scenario": "success"}'

This is synthetic integration testing, not identity verification or production authorization. Real payments are disabled.

Create a free sandbox account · Integration guide

Written and tested by the GridZen team with AI assistance.

Add a phone check without promising ownership

murray wang — Mon, 12 Oct 2026 15:27:41 +0000

Add a pre-registration number check while keeping invalid numbers separate from unavailable results. A format or validity signal cannot prove ownership or SMS reachability. This walkthrough returns no line type and sends no OTP.

What you will build

Run and inspect the three outcomes

for scenario in success reject unavailable; do
  curl -fsS https://gridzen.ai/console/api/quickstart/trial \
    -H 'Content-Type: application/json' \
    -d '{"task":"signup_phone","scenario":"'"$scenario"'"}'
done

Expected output (synthetic)

{
  "mode": "synthetic_fixture",
  "source": "local_response_trial",
  "task": "signup_phone",
  "scenario": "success",
  "verified": false,
  "real_person_verified": false,
  "billable": false,
  "amount_minor": 0,
  "upstream_calls": 0,
  "result": {
    "source": "mock_transport",
    "mode": "simulation",
    "identity_match": "not_checked",
    "ownership": "not_checked",
    "checked_at": 1791873442.459438,
    "status": "completed",
    "number_valid": true
  },
  "business_decision": "caller_owned",
  "next_step": "connect_verified_account_for_persisted_sandbox",
  "production_available_from_this_trial": false
}

Decide what your app does next

Limits and production handoff

Synthetic integration example; no real person verified, no OTP, no production permission and no payment.

Run without signup · Get task guidance · Source and tests

Written and tested by the GridZen team with AI assistance.

Your first identity onboarding sandbox run

murray wang — Mon, 12 Oct 2026 15:27:41 +0000

Build the first identity onboarding result handler before collecting any document. This walkthrough uses an account-free synthetic response; it does not create a hosted provider session. Your application must keep verification decisions separate from seller permissions.

What you will build

Run and inspect the three outcomes

for scenario in success reject unavailable; do
  curl -fsS https://gridzen.ai/console/api/quickstart/trial \
    -H 'Content-Type: application/json' \
    -d '{"task":"identity_onboarding","scenario":"'"$scenario"'"}'
done

Expected output (synthetic)

{
  "mode": "synthetic_fixture",
  "source": "local_response_trial",
  "task": "identity_onboarding",
  "scenario": "success",
  "verified": false,
  "real_person_verified": false,
  "billable": false,
  "amount_minor": 0,
  "upstream_calls": 0,
  "result": {
    "status": "Approved",
    "reason": "synthetic_scenario",
    "hosted_url": null
  },
  "business_decision": "caller_owned",
  "next_step": "connect_verified_account_for_persisted_sandbox",
  "production_available_from_this_trial": false
}

Decide what your app does next

Limits and production handoff

Synthetic integration example; no real person verified, no OTP, no production permission and no payment.

Run without signup · Get task guidance · Source and tests

Written and tested by the GridZen team with AI assistance.