Approval belongs to a revision, not just an operation ID

A customer approval is meaningful only if the system can show what was approved. An operation ID identifies a workflow, but it does not by itself prove that a later confirmation still matches the terms the customer saw.

What the documented QA run exercised

In a documented QA run of our gateway, a cancellation was represented as a proposed operation in Test mode. The recorded exercise tried a standing-permission confirmation and received 403 user_approval_required. It then tried a confirmation against revision 2 and received 409 terms_changed. The successful path used the correct user approval for revision 1 and returned 200; the response explicitly said that Test mode made no change.

That sequence is useful because it distinguishes three decisions that can otherwise blur together: whether a standing permission is sufficient, whether the submitted revision is current, and whether the customer’s approval is valid for that revision. The observed record does not establish that anyone edited the cancellation terms between revisions. The important fact is narrower: the system rejected the revision-2 confirmation and accepted the customer-approved revision-1 path.

Why the distinction matters

A confirmation endpoint that accepts only an operation ID can accidentally turn “I approved these terms” into “I approve whatever this operation means now.” That is risky when amount, target, timing, policy result, or downstream action can change. A safe design binds approval to a server-held representation of the terms—or to a revision with an equivalent integrity check—and validates that binding again at the final execution gate.

This is the same practical idea behind the OWASP Transaction Authorization Cheat Sheet: show the user what will be signed, invalidate authorization when relevant data changes, and enforce the check at the business execution step. The revision is not a cosmetic counter. It is part of the authorization boundary.

Practical design and test advice

Record the approved revision alongside the principal, resource, action, tenant, policy context, and expiration. On confirmation, reject a missing or stale revision rather than silently selecting the latest one. Test at least these paths: standing permission where an explicit approval is required; an approval for an older revision; the current user-approved revision; and a repeated terminal confirmation. Keep response meanings distinct so clients can tell “approval required” from “terms no longer match.”

A diagnostic sequence can be written as sanitized text, not a raw export: proposed → approval required, revision mismatch → terms changed, approved revision → succeeded (Test mode). That makes the contract reviewable without exposing operation IDs or customer data.

Limits of this observation

This was an isolated mock WooCommerce and gateway exercise in a sandbox, with no real funds and no real commerce write. It did not prove that terms were edited between versions, nor did it test concurrent confirmations, process restarts, database-write races, or a production execution transaction. The successful result demonstrates the recorded QA path, not a universal guarantee for every integration.

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