Protocols and standards

The five rails a decision can be tagged with, what support means precisely, and what we are not.

Machine payments run over several standards at once, and each carries its own notion of who approved what. Saifuro sits above them: the policy is written once, and the rail a transaction takes is recorded on the decision rather than duplicated into a separate policy per rail.

One policy, written oncex402CoinbasemppStripe, TempoacpStripe, OpenAIap2GooglecardVisa, MastercardThe rail is recorded on the decision, not routed by it.Funds and card credentials do not pass through Saifuro on any of the five.

The five values

protocol is an optional field on an authorization request. It accepts exactly five values, and anything else is 400 invalid_request:

ValueStandardBrought by
x402HTTP-native machine paymentsCoinbase
mppMachine Payments ProtocolStripe and Tempo
acpAgentic Commerce ProtocolStripe and OpenAI
ap2Agent Payments ProtocolGoogle
cardthe card networks' agent programmesVisa, Mastercard

What "support" means here, exactly

It means this and no more: the value is validated, stored on the decision, carried into the log and the exports, and available as a grouping in GET /v1/usage?group_by=protocol. A mandate written for a category applies identically whichever rail is named, which is the point — one policy, five rails, no drift between them.

It does not mean Saifuro moves money on that rail. Funds and card credentials do not pass through Saifuro on any of the five; settlement is executed by your licensed providers, and the boundaries on the introduction apply without exception.

Nor is the field a routing instruction. Setting protocol: "x402" does not cause anything to happen on x402. It records what your integration is doing, so that a month later the log can answer which rail an agent's spending went over.

Why the field is optional

Omitting it costs nothing: the decision is evaluated identically and the field is simply absent. Populate it when you want the breakdown, and populate it consistently, because a half-tagged log produces a grouping that looks like a trend and is an artefact of your instrumentation.

What we are not

Saifuro is not a Visa or Mastercard partner. We are built for their agent programmes and use network tokens issued under them. Neither network lists us as a partner in its own announcements, and we do not describe ourselves as one. This is stated here, next to the names, rather than only in the small print.

Saifuro does not operate a rail or a token of its own, and does not intend to. A control layer that also competed with the rails it evaluates would be answering to two masters.

None of the five standards is settled. Their specifications change on a monthly cadence today. Where a rail's own notion of authorization moves, the field above stays a label and your policy does not have to be rewritten — which is most of the reason for putting the policy above the rails in the first place.

On this page