Compatible Protocols

T54 is protocol-agnostic by design. Rather than betting on a single agent-payment standard, X402 Secure and the underlying Trustline risk infrastructure are built to accommodate the major authorization and execution protocols emerging across the agent economy. This page covers the three protocols t54 supports today: x402 for HTTP-native payment execution, Google AP2 for the agent payment mandate model, and Mastercard Verifiable Intent (VI) for cryptographic intent evidence.

The common thread is binding. Each protocol contributes a different piece of an agent payment — an execution surface, a mandate structure, or an intent credential. X402 Secure and Trustline tie those pieces to a single operational question at settlement time: does this payment match the authorized intent, the policy, the counterparty, the risk boundary, and the evidence?

Protocol Overview

Across all three, X402 Secure acts as the risk gateway that binds the protocol's artifacts to a real payment, and Trustline provides the shared underwriting and policy infrastructure that decides whether the payment should proceed.

x402

x402 is the HTTP-native machine-payment protocol that lets an agent pay a resource server or service directly in the flow of a request. It defines payment requirements, the payment payload, and the settlement step, which makes it the primary execution surface for agent-to-service commerce.

For t54, x402 is the core protocol behind X402 Secure, Claw Credit, and the XRPL x402 Facilitator. Trustline sits in front of x402 settlement to evaluate the payment, attach a risk session and trace, and enforce policy before funds move.

Google AP2

Google's Agent Payments Protocol (AP2) organizes agent payments around mandates — typically an intent mandate, a cart mandate, and a payment mandate. This structure matters because an agent payment is rarely a single settlement action; it usually carries a user instruction, a selected offer, and a payment authorization through a multi-party flow.

Trustline can assess AP2-related evidence through AP2-specific validation, while X402 Secure binds those mandate references to the x402 payment or facilitator context. The result is a risk path that respects the AP2 mandate structure while still asking whether the actual payment should proceed.

Mastercard Verifiable Intent

Mastercard's Verifiable Intent (VI) lets an agent or trusted surface present cryptographic evidence that a user or principal authorized a certain class of action. In current design work this can involve layered SD-JWT or key-bound SD-JWT presentations, selective disclosure, issuer policy, holder binding, and content hashes.

A Verifiable Intent presentation becomes operationally useful only when it is bound to the payment context. The amount, asset, destination, merchant, resource, invoice, trace, challenge nonce, and payment payload all need to be consistent with the policy being enforced. That binding is what turns a credential from a general authorization artifact into decision-grade evidence for a specific transaction.

How X402 Secure and Trustline Support These Protocols

The risk question is not simply whether an agent holds a credential or a mandate. The question is whether that artifact authorizes this payment, to this counterparty, for this resource, under this policy, at this time. X402 Secure is designed to answer that binding question before allowing the downstream payment flow to continue, and Trustline supplies the underwriting, policy, and evidence records behind the decision.

This binding model is also where liability becomes clearer. If a payment later fails, is disputed, or is found to be outside the user's mandate, the system needs to reconstruct whether the evidence supported the action at the time of approval. x402 execution, AP2 mandates, and Verifiable Intent credentials are valuable because they make that reconstruction possible; X402 Secure and Trustline make them enforceable in the payment path.

Compatibility Levels

Different integrations can adopt different levels of evidence maturity across these protocols.

This staged model lets developers begin with trace-aware payments and move toward stronger intent and mandate verification as their product matures. For the payment rails and assets these protocols settle over, see Supported Rails.