Schedule S | Merchant APIs and Authorized-Agent Acceptance
Version 3.0 applies only through valid acceptance of the online MSA or a valid amendment. A private commercial order and provider approvals remain separate.
S.1 Conditional product
These terms apply only to selected and enabled merchant API or agent-initiated acceptance. Publication is not a production-availability statement. They do not enroll Merchant as a cardholder, extend credit, authorize investment management or turn RT into an autonomous payer. Any issued-card or financial-account product remains separately governed.
S.2 Identity, permissions, rules and spending
Before accepting an automated request validate the identity of the requesting integration and the actual payer/merchant authorization, then apply the configured rules, then execute the permitted spending or acceptance action. An agent's text is not consent by itself. Enforce scope, beneficiary, amount/currency, expiry, budget, method, geographic and approval restrictions; preserve evidence of authority and the resulting transaction. Do not let a prompt or tool response override payment or security policy.
S.3 Payment methods
Single-use or scoped card flows and direct USDC payments are different methods with their own providers, permission models, finality, disputes and restrictions. Optional x402-compatible requests do not replace authentication, payer consent, sanctions controls, idempotency or reconciliation. The selected and actually enabled method must be identified; no route may silently substitute a different asset, beneficiary, price or provider.
S.4 Safe operation
Protect credentials and webhooks, validate signatures and state, prevent replay and duplicates, reconcile pending/failed/settled requests and apply rate limits. Revocation stops new actions within the supported architecture; it may not cancel a transaction already authorized or submitted to a network. Human approval is required where configured, legally necessary or needed to resolve an ambiguous consequential request. Keep customer and secret data out of prompts, public metadata and logs unless properly authorized and necessary.
S.5 Responsibility and intervention
Merchant is responsible for its authorized integrations, accurate listings and fulfillment and must cooperate in investigating unauthorized requests. RT may pause unsafe access or revoke credentials under the core Agreement. Liability depends on the actual authorization, causation, applicable method/provider rules and mandatory law; possession of an API key alone does not irrebuttably prove legal authorization. No AI system guarantees error-free fraud or compliance decisions.