The Double-Click Test: The Requirement Every AI Agent That Pays Needs

This came from an internal build challenge. Five of us built a donation and volunteer system on Salesforce for a fictional nonprofit, and I was the BA and team lead. Before the demo we wrote 107 test cases and fixed 9 real bugs.

The worst one looked small. On a slow connection, a donor clicks "Donate", nothing seems to happen, so they click again. Each click created a new gift and a new supporter, so every report built on that data would have counted the same donation twice.

A person double-clicks by accident, once. An agent repeats a request on purpose. When a payment call times out, many agents simply try again, because from where they sit the first attempt might have failed. Sometimes it did. Often the payment went through and only the reply got lost.

Without a guard, every retry is another double-click, at machine speed, with nobody watching the screen.

For Indian users this is close. UPI payments inside ChatGPT went into pilot in October 2025 with NPCI and Razorpay, starting with groceries. In September 2026, Reuters reported that NPCI is working on a framework that would let agents make small payments without the user approving each one.

"Given the same request twice, the system creates one record, not two."

It reads like the most boring line in the spec, and it worked. It also forced the two questions that mattered: what makes two requests "the same", and what the donor should see the second time.

Engineers call this idempotency: doing something twice has the same effect as doing it once. Pressing the lift button five times still brings one lift.

The usual way to build it is an idempotency key. The app attaches a unique ID to each request. The server remembers the IDs it has already handled, and when the same ID arrives again it returns the first result instead of doing the work again. Payment APIs such as Stripe accept a key like this on payment requests.

As a BA or PM you do not need to pick the mechanism. You need to write down that it must exist, and what counts as a repeat.

An example for an agent that pays a donation over UPI, written as acceptance criteria:

• Given the agent sends a payment with key K, when the call times out and the agent retries with the same key K, then the donor is charged once and the agent gets the original result.
• Given two payments with different keys but the same payee and amount within 60 seconds, when the second arrives, then the system asks the donor to confirm before paying.
• Given a repeat is blocked, when the donor checks the app, then they see "Already paid ₹500 at 8:30" instead of an error.

• What makes two requests the same? The same key, payee and amount, within what time window?
• When a call times out, does the agent check the payment status before it retries?
• How many retries are allowed, and how far apart?
• What is the limit per payment and per day, and who set it: the user or the product?
• What does the user see when a repeat is blocked, so they do not try again by hand?
• Where is every attempt logged, and who can reverse a duplicate if one gets through?

In that build challenge, finding the rules nobody had written down took more of my time than the screens did. Agents raise the stakes on those rules: an agent follows the spec exactly, and where the spec is silent it repeats the same mistake quickly.

If I were writing the spec for an agent that can pay, the double-click test would go in before any prompt.