Ga naar hoofdinhoud
LerenWoordenlijstBetalingsmandaat
GLOSSARIUM

Wat is een betalingsmandaat.

DEFINITIE

Een betalingsmandaat is een vooraf goedgekeurde instructie die een agent in staat stelt een specifieke klasse van betalingen uit te voeren zonder verdere goedkeuring. Het mandaat is geparameteriseerd: het kan een maximaal bedrag, een ontvanger of een set van toegestane ontvangers, een frequentievenster en een vervaldatum benoemen. De primitieve Google’s AP2-protocol en verschillende vergelijkbare mandaat-gebaseerde betalingssysteem zijn hierop gebouwd.

WAAROM HET ER TOE DOET

The "approve every payment" model does not scale to agents.

Menselijke betalingspatronen gaan uit van één goedkeuring per transactie: u ziet het totaal bij het afrekenen, u tikt om te bevestigen. Agents die 200 API's in een uur moeten betalen, kunnen niet op deze manier werken. De gebruiker kan niet 200 bevestigingen klikken, en zelfs als ze dat konden, zou de latentie de bruikbaarheid van de agent doden. Een of ander pre-autorisatiemodel is vereist.

Payment mandates formalize the pre-authorization. Instead of "approve every payment" or "approve nothing" (a static spend limit), a mandate says: "approve any payment that matches these parameters, up to this cap, until I revoke it." The user grants the mandate once; the agent executes against it many times. This is the structural primitive that turns the agent into an autonomous economic actor while still keeping the human in control of the boundaries.

HOE HET WERKT

Toekennen, presenteren, afhandelen, intrekken.

  1. Toekennen. De gebruiker (of de afgevaardigde van de gebruiker) creëert een mandaat via de gebruikersinterface van het protocol, waarbij de parameters worden gespecificeerd: maximaal bedrag per betaling, maximaal totaal over een venster, ontvanger allowlist, vervaldatum. Het mandaat wordt ondertekend en opgeslagen door het protocol.
  2. Presenteren. Wanneer de agent een betaling moet doen, presenteert hij het mandaat aan de betalingsverwerker van de ontvanger als bewijs van autorisatie. De verwerker valideert het mandaat, controleert of de betalingsparameters binnen de limieten van het mandaat vallen en accepteert de betaling.
  3. Verreken. De daadwerkelijke verrekening gebeurt op welke rail het mandaat ook specificeert (stablecoin, kaart, ACH). Validatie van het mandaat is gescheiden van de verrekening; één mandaat kan betalingen autoriseren via meerdere verrekenmethoden als het protocol dit toestaat.
  4. Intrekken. De gebruiker kan op elk moment het mandaat intrekken. Volgende presentaties falen in de validatie. Betalingen in behandeling kunnen al dan niet worden voltooid, afhankelijk van de atomiciteitsgaranties van het protocol.

The protocol layer holds the mandate; the agent never holds the user's payment credentials directly. This is the safety property that makes mandate-based systems different from "give the agent your credit card." Compromise the agent and the worst case is the mandate's parameter envelope, not the user's full payment power.

VOORBEELDEN

Drie mandaatstructuren.

VOORBEELD 1

Per-oproep API-toegang mandaat

Een agent krijgt een mandaat om tot $0.10 per oproep uit te geven op elke API in een gedefinieerde toegestane lijst, tot maximaal $50 per dag. De agent roept gedurende de dag API's aan; elke oproep binnen de parameters van het mandaat wordt zonder verdere goedkeuring verrekend. Uitgaven boven $50 in 24 uur worden geblokkeerd op het platformniveau.

VOORBEELD 2

Leverancier-specifiek abonnementsmandaat

Een onderzoeksagent krijgt een mandaat om één specifieke gegevensleverancier tot $200/maand te betalen, gefactureerd in stablecoin. De factuur van de leverancier activeert automatisch de vooraf goedgekeurde betaling van het mandaat. De agent hoeft de factuur nooit aan een mens voor te leggen.

VOORBEELD 3

Eenmalig capped mandaat

Een gebruiker verleent een agent een eenmalig mandaat om tot $500 uit te geven aan hotelboekingen van één vertrouwd boekingsplatform. De agent zoekt, kiest een optie binnen de limiet en boekt. Zodra het mandaat is verbruikt, kan het niet opnieuw worden gebruikt.

Veelgestelde vragen

Drie veelgestelde vragen.

Is een betalingsmandaat hetzelfde als een doorlopende machtiging op een kaart?

Vergelijkbaar in geest, structureel heel anders. Een kaartautorisatie wordt vastgehouden door het kaartnetwerk en geldt tussen een specifieke kaarthouder en een specifieke handelaar. Een betalingsmandaat in de agentic-commerce zin wordt vastgehouden door een betalingsprotocol (bijv. AP2), kan worden geparameteriseerd op basis van bedrag, ontvanger, frequentie en tijdvenster, en wordt afgehandeld in stablecoin of fiat, afhankelijk van de implementatie. Mandaten zijn meer programmeerbaar, meer gedetailleerd en niet gebonden aan kaart-netwerk rails.

Kan een mandaat worden ingetrokken?

Ja. De gebruiker die het mandaat heeft verleend, kan het op elk moment intrekken via de intrekking-primitief van het protocol. Zodra het is ingetrokken, worden er geen nieuwe betalingen meer uitgevoerd. Lopende of in behandeling zijnde betalingen op het moment van intrekking kunnen al dan niet worden voltooid, afhankelijk van het protocol; AP2 specificeert een onmiddellijke stop voor elke betaling die nog niet op de keten is afgewikkeld.

Gebruikt Blockchain0x betalingsmandaten?

Nog niet formeel. We bereiken vergelijkbare resultaten voor agent spending control via de per-agent spend permission (een limiet per periode en een per-transaction cap) die op API-laag wordt afgedwongen. Dit is mandate-equivalent voor de meest voorkomende gevallen (uitgaven begrensd over een tijdsvenster). Volledige mandate-protocol support (revocation primitives, ondertekende mandates die met payment requests meereizen, AP2-compatibele flows) staat op de roadmap naarmate de standaarden samenkomen.
Laatst beoordeeld: 2026-05-15. Gepubliceerd onder CC BY 4.0.

Pre-autorisatie van de uitgaven van je agent.

Per-agent uitgavenbeleid afgedwongen op API-niveau. Gratis om te beginnen.