'Human Present' might throw some people

[tedpower]

Typically in retail, there's a distinction made between 'card present' and 'card not present' checkout. 'Card present' would be when you buy something at the cash register with a physical card; 'card not present' is when you buy something online or by keying in your card number.

So the 'human present' label threw me. When I think 'human present' I think "in-person with a payment instrument" whereas you mean "a person is present in front of an LLM chatbot, but is almost certainly 'remote' / not physically near a brick-and-mortar merchant."

[anjanas]

I guess they want to use familiar terminologies in payments domain. What I understood is - 'Human present' is for scenarios where user has explictly authorized this transaction vs 'Human not present' is where agent took decision based on pre-authorization from user. 'Human not present' is similar to how someone would put a 'limit order' trade. What is presented is a high level idea though. Lots of details have to be worked out

[tedpower]

Ya I think you're right, I eventually figured it out. But fwiw I think a 'pre-auth' or a 'limit order' might be better terminology vs. 'human not present'

[economistgrape]

The terminology around ‘human presence’ is misused.

[Jpzinn654]

Yes, I completely agree. I think something like that would definitely be safer, maybe even a technology where, before the purchase actually goes through, or we would confirm the amount and where it’s being charged. Because if this is left fully autonomous, there’s a big risk of ending up with purchases in fake stores, higher-than-expected prices, or even things you never ordered but it hallucinated. Anyway, these are all still experiments…

[luyiourwong]

I believe the responsibility for secondary confirmation of a transaction should remain on the client side, rather than being handled within AP2 or A2A. AP2 is a protocol layer, and its role should be to enable interoperability and define clear signals—not to enforce or implement user confirmation logic. The actual confirmation flow (whether that’s a second prompt, biometric check, or other safeguard) should be implemented by the client application, which has the right context and user interface to manage trust and risk appropriately.