FAQ

Does Saifuro see card data?

No. Credentials are tokenized at the edge, so card numbers never reach our systems. Substitution on the settlement path is performed by the VGS proxy, not by Saifuro. Funds do not reach us either: settlement is executed by licensed payment providers.

Can I deploy it myself?

No. Saifuro is a closed product delivered through direct implementation, and integration tooling is issued at onboarding. See getting access.

What happens if Saifuro is unavailable?

Failure mode is set by policy, per class of operation. Critical categories fail closed by default. You can choose to fail open for selected classes, and that choice is stored in the policy and visible in the log.

How is this different from spending limits at my payment provider?

Provider limits attach to an account or a card. If your agents use three providers, you maintain three sets of rules and reconcile them by hand.

A Saifuro mandate attaches to an agent and a principal, applies across providers, and leaves a decision log with the policy version attached to every verdict.

How fast can an agent's authority be revoked?

On the next request. Revoking a mandate needs no change to the agent's code and no action at the provider: the next call comes back deny_revoked.

Who owns the data and the log?

You do. The log is exportable at any time. Agent conversation content is not collected.

What does Saifuro cost?

$1,000 a month for the platform with 500,000 decisions included, $0.10 per 1,000 decisions above that, 0.25% on money your agents pay out capped at $25 a payment, and a graduated rate starting at 0.75% on money you receive through Saifuro. Escrow adds 0.25% on release. Evaluation is free, and nothing is ever deducted from a payment. The full schedule, definitions, and worked examples are on the pricing page.

Which protocols and providers are supported?

Saifuro works through your existing payment providers and does not ship its own rail.

The agentic payment standards are supported directly: x402 and MPP for machine to machine settlement, ACP for agent checkout, AP2 for authorization and proof of intent. One integration covers them, and routing picks the rail per transaction. New protocols are added on our side, so your integration stays where it is.

One provider adapter is running in production today. It is named under NDA on request, and it will be listed here once that provider approves being named. Adapters for the providers you already use are built during implementation. What the rule looks like in practice: VGS handles card tokenization in production and is named on the security page because it approved that.

Card rails run through the Visa and Mastercard agent programs, using network tokens issued under those programs. We are not listed as a partner in either network's own announcements, and we do not describe ourselves as one.

What if one protocol wins and the rest die?

Then the routing part of the product gets less valuable, and we would rather say that than be asked. Several of the standards we support are stewarded by companies that also sell the layer above them, so consolidation is a real possibility. Policy, metering, and the decision log do not depend on how many rails survive; the abstraction over them does.