> For the complete index of this site, see [llms.txt](https://alexdewison.com/llms.txt).

# Checking an agent payment request before it reaches the rail

When an AI agent pays on someone's behalf, the payment needs more than an amount and a credential. This demo checks a mock request for five pieces of evidence, loosely based on the questions European local payment schemes say they want to answer for agent payments. It is an illustration, not any scheme's rules. All values are mock.

This is the text version of an interactive demo. The interactive version runs in your browser on mock data: [https://alexdewison.com/labs/agent-payment-checklist/](https://alexdewison.com/labs/agent-payment-checklist/)

## 1. Pick the rail

Card, BLIK, Wero or open banking.

## 2. Choose what evidence the agent sends

- **Human approval**: the shopper confirmed this exact purchase (for example a passkey or bank app prompt)
- **Agent identity**: a verifiable identifier for the agent and who operates it
- **User mandate**: what the user allowed the agent to do, with a spending limit and expiry
- **Dispute owner**: who handles refunds and disputes if the agent got it wrong
- **Merchant identity**: the merchant the agent is paying, as registered with the provider
- **Shared login instead**: the agent uses the customer's own bank or wallet password

Default values in the demo:

- Amount (GBP) 120
- Mandate limit is 250

## 3. Request the agent sends

The demo builds the request from the evidence you choose, then shows the result of the check.

**Why it matters:** if these five things travel as structured fields on one request, the same agent payment can be checked on cards and local methods without a separate integration per scheme. A shared login gives the bank none of them, which is why several large banks now block it.

---

Part of the [interactive payments demos](https://alexdewison.com/insights/demos/) by Alex Dewison. Mock data only.