Designing Approval Gates for Browser-Based Payments and Refunds

Use this checklist to design a human approval gate for browser-based payments and refunds. It focuses on what an operator sees before execution, what a browser agent is allowed to do, and what evidence must be recorded afterward. The central rule is simple: approval applies to one exact, reviewable action—not to a vague instruction or an open-ended session.

The example throughout is hypothetical: a browser workflow proposes refunding a customer’s order. The same controls can be adapted to a payment workflow, but payment creation and refund execution have different consequences and should have separate policies. This is an implementation checklist, not legal or financial advice. Adapt it to your provider, internal controls and applicable obligations.

1. Define the action that needs a gate

• Name each controlled action separately. Define payment creation, payment capture, refund creation, refund amount changes and refund cancellation as distinct actions where the application exposes them. A single label such as “handle payments” is too broad to support meaningful review: it hides what changes, for whom and by how much.

  Write the action in terms of a business outcome and its relevant fields. For a refund, that might mean “create a refund for order 4817, customer C-902, amount USD 42.50, against payment P-183.” Avoid defining the action as “click the refund button.” Buttons move, labels change and the visible control does not fully describe the financial effect.

• Set a boundary between preparation and execution. Decide which steps may occur before approval and which must wait. Looking up an order, assembling a draft and displaying a proposed refund can be preparation. Submitting the final refund is execution. If the workflow has an intermediate confirmation page, specify whether reaching it is safe or already consequential in the actual system.

  Treat this distinction as something to verify, not assume. A control that appears to be a preview may submit a request, reserve funds or create a durable record. If the effect of a step is uncertain, stop the automation before that step until the application behavior has been established by an appropriate owner.

• Write down the disallowed actions. Identify actions the agent must never take under the proposed workflow, such as changing a payment method, issuing a second refund, editing the customer record, or navigating into unrelated accounts. State the restriction in operational terms and include it in the policy and test cases.

  A narrow allowed action is easier to inspect than a broad prohibition. For example, “may prepare a refund proposal for an identified order but may not submit it” has a clearer execution boundary than “be careful with refunds.” The boundary should remain clear even if page content, an instruction or an error message encourages a different action.

• Choose a policy owner and a review cadence. Name the business owner responsible for defining refund eligibility and the technical owner responsible for implementing the browser gate. Set a review point after material changes to the payment interface, refund policy, browser workflow or approval process.

  This is not a request to build a large governance program around each button. It ensures that the person who understands the financial rule and the person who maintains the browser control can resolve mismatches. A stale threshold or outdated field mapping can turn a well-designed preview into a misleading one.

2. Make the preview specific enough to approve

• Show the transaction identity before asking for approval. Include the customer or account identifier, order or invoice reference, payment reference when available, and the destination account context. Do not rely on a customer name alone if names may repeat or be edited.

  The reviewer should be able to distinguish the intended transaction from a nearby record without reopening the workflow and guessing. Prefer stable identifiers that the operator can reconcile with the business system. Mask unnecessary personal information, but do not remove the fields needed to detect a wrong-account or wrong-order proposal.

• Show the amount, currency and action direction prominently. Label a proposal as a payment, capture or refund rather than presenting a bare amount. Display currency next to the number, and show whether the proposed action increases a charge or returns funds. If the amount is partial, show the original amount and proposed amount together when that comparison helps review.

  Formatting should resist common misreads: a decimal point, currency symbol or negative sign should not be the only signal. For example, “Refund USD 42.50 of USD 89.00” communicates more than “42.50.” If the provider or application displays a different amount after submission, the receipt process must flag that discrepancy instead of treating the original preview as proof.

• Include the reason and the source of the proposed values. Present the customer request or internal reason, the source record used to identify the order, and any policy rule that the workflow applied. Separate observed facts from inferred values. “Customer asked for the duplicate charge to be reversed” is not the same as “duplicate charge confirmed.”

  A reviewer needs enough context to challenge the proposal. If an agent inferred an amount from a message, say that it was extracted from a message and make the relevant text available for inspection. If the amount came from an authoritative transaction record, identify that record. Do not quietly turn uncertainty into a confident-looking field.

• Expose uncertainty and missing information instead of filling gaps. Mark an unknown payment reference, ambiguous order match, inconsistent currency or unclear refund reason as unresolved. Define what the workflow does with each condition; a typical safe response is to stop and route the case for manual investigation.

  Avoid a preview that looks complete merely because every field has a value. A guessed identifier is not equivalent to a verified identifier. Set explicit acceptance criteria for the proposal: all required fields are present, their sources are traceable, and the proposed action matches the selected transaction before approval can be requested.

• Keep the preview readable at the point of decision. Put high-consequence fields together and avoid burying the amount or account reference in a long transcript. Show a concise summary first, with supporting details available nearby. The reviewer should not need to reconstruct the proposed action from several screens or interpret the agent’s internal reasoning.

  A practical preview can be a structured card or review page with fields such as action, customer, order, payment, amount, currency, reason, source and expiry. Choose a layout that fits the actual approval channel. If the reviewer sees only a notification, make sure it links to a review surface that displays the same bound proposal rather than a mutable draft.

3. Bind approval to one immutable proposal

• Create a canonical payload before presenting the approval request. Represent the proposed action as structured data with stable field names, such as action type, account identifier, order identifier, payment identifier, amount, currency, reason and a unique proposal identifier. Define which fields are mandatory for each action.

  The payload is the thing being approved. The browser page and human-readable preview are views of it. Keep the representation precise enough to compare later with the execution request. A screenshot or conversational “yes” by itself cannot prove which amount or transaction the reviewer accepted.

• Make edits invalidate the prior approval. If the amount, currency, customer, payment, action type or other material field changes, require a new preview and a new approval. Do not let an operator approve one proposal and then have the workflow silently substitute an updated value before clicking submit.

  Define material fields in advance. A changed spelling in a display-only note may not alter the transaction, while a changed payment identifier plainly does. When uncertain whether a field can change the business effect, treat it as material until the system owner establishes otherwise. The execution path should compare the approved payload with the payload it is about to submit.

• Make approval explicit and attributable. Record an affirmative decision tied to the proposal identifier and the reviewer’s authenticated identity. A general approval of the workflow, a conversation turn that could refer to another item, or an unanswered notification is not approval of this transaction.

  Keep the approval interface unambiguous: identify the action being approved and provide a clear way to reject or defer it. If the decision arrives through a separate system, preserve a reliable association between that decision and the exact proposal. Do not infer consent from inactivity, prior approval of a similar case or a reviewer’s role alone.

• Set and enforce an expiry. Give each pending proposal a defined expiration time. If it expires before execution, require a fresh proposal and review rather than accepting the old decision. The expiry should be short enough to reduce stale-context risk while still allowing the normal reviewer to respond.

  Expiry is useful because account state, customer intent and available balance can change while a request waits. It is not a guarantee that underlying state remains unchanged until the deadline. Recheck relevant transaction facts immediately before execution and stop if the conditions no longer match the approved proposal.

• Prevent duplicate use of an approval. Track whether a proposal has already been submitted or otherwise consumed. A retry, reopened browser tab or repeated click must not turn one approval into a second financial action.

  Define how the workflow behaves after an uncertain submission. It should not blindly repeat the action just because the browser did not display a success message. First inspect the business system for the result and reconcile it with the proposal. If the outcome cannot be established, pause for a person rather than guessing whether the first request took effect.

4. Bound the browser agent’s authority

• Grant only the authority needed for the defined workflow. Separate permission to inspect transaction details from permission to perform a financial action. If the workflow only prepares proposals, it should not have the capability to submit payments or refunds. Where execution is required, constrain it to the specific approved action and account context.

  Think in terms of the consequences the browser session can produce, not just which page it can open. A page-level restriction may still expose several transaction-changing controls. Capability-based design is a useful background for reasoning about this boundary: Securing Agent Tool Use: Capability-Based Permission Models.

• Separate accounts and sessions used for distinct purposes. Use a dedicated operational context for the automation and avoid reusing a person’s broad administrative session. Stored browser authentication state can contain sensitive cookies or headers, so separate accounts and sessions deliberately and protect that state accordingly. Playwright’s authentication guidance notes this sensitivity.

  This checklist does not prescribe a particular identity architecture. The important design question is whether the session can reach unrelated customers, accounts or financial controls if the workflow navigates unexpectedly. Review the actual scope of the authenticated session and account for the data and actions it makes available.

• Limit the agent to the intended customer and transaction context. Resolve the target record before the approval gate and carry its identity through the proposal, review and execution steps. If navigation changes to a different account or record, discard the pending proposal and begin again.

  This is especially important in interfaces with search results, multiple open tabs or records that look alike. The workflow should not depend on a human noticing that the page header changed after approval. Compare the visible transaction context with the approved identifiers immediately before the action.

• Treat page content as input, not as authority to expand the task. A customer note, banner, web page or unexpected dialog may contain instructions that conflict with the defined action. Do not let such content add a recipient, increase an amount, select another payment or bypass review.

  The agent’s authority comes from the workflow boundary and the approved proposal, not from text encountered while browsing. Define a stop condition for unexpected instructions or a changed page state. The agent can report the discrepancy and request human handling without improvising a broader financial action.

• Set a hard ceiling and escalation route for exceptional amounts. If the business sets a maximum amount for automated execution or review, encode it as a policy condition and test values just below, at and above the boundary. State who handles exceptions and ensure that exceeding the limit cannot be resolved by asking the agent to ignore the rule.

  A numeric ceiling is not a universal safe amount; it is a business decision based on the transaction and review model. Some organizations may choose to require human execution for every payment or refund. The implementation should reflect that choice rather than quietly treating a threshold as permission to skip other checks.

5. Use a controlled execution sequence

• Revalidate the proposal immediately before the consequential action. Confirm that the current account, order, payment, amount, currency and action still match the approved payload. Check that approval is explicit, unexpired and unused. If any check fails, return to review or stop.

  This is the last point at which a mismatch can be caught before submission. The revalidation should use the current application state rather than a remembered value from an earlier page. Keep the browser interaction as narrow as possible between this comparison and the consequential control.

• Make one bounded attempt and define how interruptions are handled. Specify the expected sequence from review to submission and the states that can interrupt it: session loss, navigation change, timeout, unexpected confirmation, validation error or a page that no longer identifies the target record.

  For each interruption, define a safe response. A timeout after clicking submit is not proof of failure. A validation message is not permission to alter the payload and try again. The default for an ambiguous financial outcome should be to inspect and reconcile the state before any retry.

• Do not promise exactly-once external effects. Browser automation and an external payment system can fail at different moments, including after the provider has accepted a request but before the browser receives confirmation. Design for duplicate detection and reconciliation rather than claiming that a click happens exactly once.

  If the provider offers a supported mechanism for correlating or de-duplicating requests, validate its behavior for the specific integration before relying on it. This checklist does not assume any particular API, idempotency feature or browser control. Without verified support, the workflow should detect uncertainty and stop for human resolution.

• Keep execution authorization narrower than the review conversation. The reviewer may discuss context, alternatives or corrections, but only the final structured proposal should authorize a transaction. If the reviewer asks to change a material field, generate an updated proposal and collect a fresh decision.

  This avoids confusing a free-form conversation with a reliable instruction to transact. It also creates a clear record when the person’s intent changes: proposal A was rejected or superseded, proposal B was reviewed, and only B proceeded.

The following flow shows the intended control sequence. A changed or expired proposal goes back for review; an uncertain result is reconciled before any retry.

flowchart TD
accTitle: Approval-gated browser transaction flow
accDescr: The workflow prepares a proposal, checks it, obtains approval, revalidates it, submits the approved action, and verifies the resulting business state. Failed checks return for review or stop for reconciliation.
    A["Prepare proposal"] --> B["Validate fields"]
    B --> C["Human reviews"]
    C --> D["Revalidate approval"]
    D --> E["Submit approved action"]
    E --> F["Verify outcome"]
    F --> G["Record receipt"]
    D -. "stale or mismatch" .-> C

6. Verify the business result, not the browser message

• Define what counts as a verified result. Specify the authoritative record or status that demonstrates whether the payment or refund was accepted, pending, failed or otherwise unresolved. A clicked button, closed dialog or success-looking banner is an interaction signal, not sufficient business evidence on its own.

  Decide which record must be checked and how its identity will be matched to the proposal. The verification must distinguish the intended transaction from another transaction on the same account. If the available interface does not expose enough information to confirm the result, route the case for a person to reconcile it.

• Represent pending outcomes accurately. Do not translate a provider’s pending state into “complete” merely because the request was submitted. Refund status and timing vary by provider; check the applicable transaction status and avoid claiming immediate settlement. Stripe’s refund documentation describes provider-specific status and timing.

  The customer-facing message should match the verified state. “Refund request submitted; status pending” is different from “refund completed.” Avoid promising when funds will appear unless the relevant provider information and your own customer policy support that statement.

• Compare the result with the approved payload. Confirm that the resulting record corresponds to the approved customer, payment, amount, currency and action. If the application displays a different amount, a different target or an unexpected status, mark the case as a discrepancy and stop any follow-on action.

  Do not allow a partial match to count as success. A record for the right customer but wrong payment is not a verified outcome. Define which fields must match exactly and which statuses need follow-up, so operational staff do not improvise the meaning of a receipt after an incident.

• Make verification independent of the agent’s self-report. The agent can report what it attempted, but the business result should be checked against the relevant application record or another appropriate source of transaction state. Keep these statements separate in logs and user-facing messages.

  This distinction matters when the browser loses its connection after submission. The agent may have no reliable basis to say whether the provider accepted the action. An independent state check can resolve that uncertainty; where it cannot, the correct result is “unknown, under reconciliation,” not an invented success or failure.

7. Create a useful receipt and handle failure states

• Record the proposal, approval, action and outcome as linked events. A useful receipt connects the proposal identifier to the reviewer decision, execution attempt and verified result. Include timestamps and the identities or system actors involved where available, without collecting unrelated information merely because it is visible.

  The receipt should let an operator answer: what was proposed, what was approved, what was attempted, and what state was later observed? Keep the original proposal and any revised proposal distinguishable. If a correction was made, record the change as a new version rather than overwriting the approved values.

• Capture enough context to investigate a discrepancy. Record stable transaction references, the status observed, the time of verification, and a concise failure category such as approval expired, target mismatch, submission timeout or result unavailable. Follow the organization’s retention and access practices for financial and customer information.

  A receipt is not a transcript dump. Preserve what supports investigation and reconciliation, and avoid copying session secrets, authentication headers or unnecessary personal data into ordinary operational logs. The receipt should be usable by a finance or support operator who was not present during the browser interaction.

• Define the response to each failure class. For example, a pre-submit field mismatch should block execution and return for a corrected proposal; an expired approval should require review again; an uncertain post-submit outcome should trigger reconciliation before a retry; and a verified provider decline should be routed according to the relevant business process.

  These outcomes are not interchangeable. A failed validation before submission is different from a failed transaction after submission. Label the stage at which the failure occurred so that a responder does not accidentally repeat an action whose outcome is still unknown.

• Give uncertain cases a clear owner and queue. State who reviews ambiguous outcomes, how they identify related records and what evidence allows them to close the case. If no one can establish the outcome, keep it open and prevent an automated retry from treating the absence of confirmation as permission.

  This operational detail is easy to omit during implementation. Yet a workflow that correctly stops on uncertainty still needs a path for resolution. Define a practical handoff: the receipt contains the proposal and attempt identifiers, the operator checks the transaction record, and the resolution is recorded before the case can proceed.

• Use the receipt to detect control drift. Review a sample of completed and stopped cases for mismatches between preview fields, approval decisions and resulting records. Look for recurring causes such as ambiguous search results, stale page state, fields omitted from the proposal or users repeatedly overriding the same stop condition.

  The aim is to improve the specific workflow, not to claim that a clean transcript proves a safe outcome. For a separate treatment of evaluating browser-agent end states, see Benchmarking Browser Agents: Check the End State, Not the Transcript. This checklist uses that distinction only to frame transaction verification.

8. Test the gate with representative failures

• Test a valid proposal from preparation through receipt. Use a controlled environment and a transaction scenario that cannot affect real funds. Confirm that the preview shows the required fields, approval binds to the proposal, execution is blocked before approval, and the resulting test state can be reconciled to the receipt.

  Define the expected evidence before the test: proposal identifier, approved values, attempted action, observed final state and recorded status. A test that merely confirms the browser found the button does not establish that the approval boundary or result verification works.

• Change a material field after approval. Modify the amount, payment reference or target account in the test flow after a reviewer approves. Confirm that the old decision is rejected and that a new proposal must be reviewed before execution.

  Include a subtle case, not only a dramatic amount change. A switch to a similar customer record or a different payment with the same amount can expose weak binding. The expected outcome is a stop, a visible explanation and a traceable reason—not a best-effort continuation.

• Exercise expiry, duplicate use and interrupted submission. Test an approval that has expired, a repeated attempt against a consumed proposal and a timeout immediately after the submit action. Verify that expiry blocks the action, duplicate use does not create a second attempt, and the timeout leads to reconciliation rather than automatic resubmission.

  These tests should reflect the real transitions of the browser workflow. If the application cannot be made to simulate a particular provider outcome safely, document that limitation and agree on an appropriate manual validation method. Do not describe an unperformed test as passed.

• Check confusing and incomplete records. Include two similar customer records, a missing payment reference, an amount with a different currency, and an unexpected application message. Confirm that the workflow stops or requests human resolution under the rules you have set.

  This is where the design’s failure policy becomes concrete. For example, an unresolved currency should not be silently inherited from a prior transaction. An unexpected message should not cause the agent to interpret a new instruction as permission to change the refund. Record the expected response for each test case.

• Review changes to the browser workflow before restoring execution. After a page redesign, selector update, account change or modification to the approval interface, repeat the relevant checks before relying on the prior behavior. A control can still appear on screen while its meaning, position or surrounding confirmation steps have changed.

  Keep the review proportionate to the change. A cosmetic adjustment may need a focused preview check; a change to the submission sequence deserves a broader end-to-end review. For background on browser-agent deployment and implementation context, see AI Agents in Production: Browser-Use Agents.

9. Work through a hypothetical refund and a counterexample

• Apply the checklist to one concrete proposal. In this hypothetical example, a customer requests a partial refund for order 4817. The proposed payload identifies customer C-902, payment P-183, refund amount USD 42.50, original payment amount USD 89.00, reason “item returned,” and a proposal identifier. The reviewer can inspect the transaction context and source for the reason before deciding.

  The identifiers and amounts are illustrative, not a PADISO transaction or customer outcome. The point is how the control behaves: it presents the amount and currency, ties approval to those fields, expires the pending decision, checks that the same payment remains selected, and records what status the application reports afterward.

• Keep the decision branch visible. Suppose the reviewer notices that the return record is for a different item and rejects the proposal. The workflow records the rejection and does not submit anything. If the business later confirms the correct item and amount, it creates a revised proposal with a new identifier and requests a fresh decision.

  Suppose instead the reviewer approves the exact proposal, but the browser times out after submission. The system does not click again automatically. It checks the relevant transaction record; if the refund is visible, it records the observed status, and if it cannot determine the result, it sends the case for reconciliation. The next action depends on that evidence.

• Reject the tempting but unsafe shortcut. Consider a counterexample: a reviewer approves “refund the customer” in a chat, the agent selects the first order returned by search, the amount is later adjusted to match a message, and the browser reports a success banner. No exact proposal, transaction-bound approval or independent receipt exists.

  Even if the correct refund happened by chance, this workflow cannot demonstrate what was approved or distinguish a correct result from a wrong-order refund. The repair is not to add a longer prompt telling the agent to be careful. It is to bind a structured proposal, invalidate approval after material edits, verify the resulting business record and preserve a receipt that connects those stages.

A useful review question for the hypothetical is whether an operator who did not watch the browser can reconstruct the authorized action from the receipt. If they can identify the proposal, approval, attempt and observed result—and see any unresolved mismatch—the workflow has a practical evidence trail. If they have only a success message or a transcript, the gate is incomplete.

10. Printable implementation worksheet

Use this worksheet in a design review. Fill it in for one action at a time; do not combine payments and refunds into a single policy unless their fields, authority and execution behavior are genuinely the same.

Action and proposal

• Action name: Write the precise business action, such as create a refund or create a payment.
• Target fields: List the customer/account, order, payment, amount, currency and any other required identifiers.
• Value sources: Record where each field comes from and how uncertainty or disagreement is handled.
• Preparation boundary: Identify the last step permitted before approval and the first consequential execution step.
• Disallowed actions: Name nearby actions the workflow must not perform.

Review and authority

• Preview requirements: Confirm that the reviewer can see action, target, amount, currency, reason, source and unresolved conditions.
• Approval binding: State how the decision is tied to the exact proposal and reviewer.
• Change rule: List which field changes invalidate approval; require a new proposal and decision for each material change.
• Expiry and reuse: Set an expiry and define how the system blocks expired or already-used approvals.
• Execution authority: Specify the account/session scope and whether the browser agent can submit, or only prepare proposals.
• Escalation boundary: Set the amount or condition at which execution stops for additional review, if your policy uses one.

Verification and operations

• Pre-submit check: Identify the exact fields and approval state revalidated immediately before execution.
• Outcome source: Name the business record or status used to determine the result.
• Pending-state language: Specify how pending, failed, unknown and verified outcomes are distinguished in records and customer communications.
• Receipt fields: Include proposal identifier, approved values, reviewer decision, attempt time, observed status and relevant transaction reference.
• Failure owner: Name the person or queue responsible for ambiguous post-submit outcomes and define the no-blind-retry rule.
• Test cases: Include a valid path, changed field, expired approval, duplicate attempt, timeout, ambiguous target and unexpected page state.
• Change review: State which interface, policy or session changes trigger a focused recheck before execution resumes.

Decision summary

Proceed to controlled implementation only when the proposal is readable, approval is bound to it, execution authority is bounded, material changes force a fresh decision, and the result can be checked independently.

Keep the workflow in proposal-only mode if it can prepare a useful preview but cannot yet prove that approval remains attached to the exact action or cannot reliably verify the resulting transaction.

Stop and redesign the gate if the workflow can execute without an attributable approval, can reuse an approval after a material change, or retries an uncertain transaction without checking its state.

Implementation next step

Start with one narrow action and map its fields, approval boundary and receipt before building out a broader browser workflow. If your team needs help translating these controls into an implementation plan, AI workflow automation is a relevant next step. Keep the first design review focused on the exact proposal and the evidence that will prove what happened.

Payment interfaces and browser sessions differ, so validate the actual screens and account scope your workflow will use. For related implementation context on session design, see Browser Agents and SSO: Designing Sessions Without Sharing Passwords. For a separate discussion of browser agents and newer interaction approaches, see Cloudflare Kitesurf and WebMCP: What Changes for Browser Agents?. The approval gate remains the same practical test: can a reviewer see the exact proposed action, can the system execute only that approved action, and can the resulting business state be reconciled afterward?