Customer approval and business review are different state transitions

A customer saying "yes" and a business reviewer approving an operation answer different questions. Treating them as one approval state makes it hard to tell who authorized the next step, what remains pending, and which actor may move the workflow forward.

What the documented QA run observed

In a documented QA run of our gateway, the owner-review fixture moved through a recorded sequence: proposed, then after user confirmation in_progress with awaiting business review, then team approval, and finally succeeded with test:true.

The exercise was performed in Test mode. It showed a customer confirmation followed by a separate business-review transition, rather than a single confirmation immediately authorizing completion.

That distinction is important in the evidence. The fixture's success does not demonstrate that an arbitrary reviewer could approve it. No unauthorized-reviewer test was performed, and the run should not be described as one. The observed claim is only that this owner-review path recorded the listed states and reached a simulated success after team approval.

Model the workflow as separate decisions

Customer approval usually answers: "Does the customer authorize these presented terms for this action?" Business review answers: "Has the organization completed its required internal review under its own policy?"

Those decisions can have different actors, permissions, evidence, and expiration rules. A useful state model therefore keeps the transitions explicit.

A customer confirmation can move a proposed operation to an internal-review queue. A permitted reviewer can move that queue item to approved. Only an authorized execution path should move an approved operation to succeeded.

OWASP's Transaction Authorization Cheat Sheet similarly emphasizes clear transaction state transitions and checking authorization at the point where the business action is actually executed.

Practical design and test advice

Store separate audit facts for customer approval and business approval:

• actor type
• identity reference
• approved revision
• policy decision
• timestamp
• resulting state

Define which roles may perform each transition and reject attempts from roles that do not qualify.

Test the happy path, a customer approval without business approval, a business approval before customer approval, a stale approval, and a terminal-state repeat. Also test that the UI does not offer a review control when an operation is already terminal if the product does not support that transition.

For documentation, a sanitized text sequence is clearer than a screenshot or raw export:

proposed → customer confirmed → awaiting business review → team approved → succeeded (test)

It says what was observed without implying that every reviewer or every production workflow has the same authority.

Limits of this observation

The exercise used an isolated sandbox and did not move real money, refund a real order, or perform a live commerce write. It did not test an unauthorized reviewer, concurrent approvals, restarts, reconciliation, or a production authorization transaction.

The state sequence is evidence for this recorded owner-review fixture - not proof that business-review enforcement is complete across all roles and integrations.

Disclosure: Generated using AI from recorded Allowfy QA observations and linked technical references; sandbox results, not a production implementation claim.