# Redbus - Agent Payment Report - Domain: redbus.com - Category: Transportation & Mobility - Company type: machine_api - Protocols: None detected - Agent integration surfaces: None cataloged - Payer platforms or methods: None cataloged - Vendor roles: None cataloged - Verification level: **not_evaluated** - Score version: `agent-payments-v4` - Reference fixture: No - Last verified: 2026-08-20T19:17:13.68652+00:00 ## Protocol documentation - No payment protocols documented. ## Scores | Dimension | Score | |-----------|-------| | Payment readiness | 0 | | Website experience | — | | Agent experience | — | | Overall score | 0 | | Grade | F | An em dash means the company has not reached the evidence level required for that score. A public protocol claim is not treated as a completed payment. ## Protocol Readiness Suites Each suite separates applicability, public claims, discovery, protocol validation, safety, live execution, delivery, receipts, and recovery. Missing evidence is reported as not evaluated rather than inferred as support or failure. ### x402 V2 agent payment acceptance - Cataloged for this company: No #### Is at least one accepted payment option complete enough for a payer to execute? - Requirement: Core - Status: Fix - Category: x402 V2 static checks - Goal: Is at least one accepted payment option complete enough for a payer to execute? - Observed: The x402 challenge is missing a complete accepted payment option or paid-resource binding. - Problem: The x402 challenge is missing a complete accepted payment option or paid-resource binding. - Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence. - How to implement: Include scheme, network, asset, positive amount, recipient/payTo, and resource binding for at least one accepted option. - Copy prompt: Fix this static agent-payment readiness issue: Is at least one accepted payment option complete enough for a payer to execute?. Target: https://redbus.com/api Problem: The x402 challenge is missing a complete accepted payment option or paid-resource binding. Required change: Include scheme, network, asset, positive amount, recipient/payTo, and resource binding for at least one accepted option. Make the smallest focused implementation change. Add or update tests. Rerun the Agent Payments static scan after the change. #### Is the payment challenge protected from stale public caching? - Requirement: Recommended - Status: Fix - Category: x402 V2 static checks - Goal: Is the payment challenge protected from stale public caching? - Observed: Cache headers were not scored because no x402 challenge was detected. - Problem: No x402 challenge was detected. - Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence. - How to implement: Return Cache-Control: no-store on unpaid x402 challenge responses. - Copy prompt: Fix this static agent-payment readiness issue: Is the payment challenge protected from stale public caching?. Target: https://redbus.com/api Problem: No x402 challenge was detected. Required change: Return Cache-Control: no-store on unpaid x402 challenge responses. Make the smallest focused implementation change. Add or update tests. Rerun the Agent Payments static scan after the change. #### Does the advertised option intersect with a known payer and facilitator capability? - Requirement: Core - Status: Fix - Category: x402 V2 static checks - Goal: Does the advertised option intersect with a known payer and facilitator capability? - Observed: No complete payment option exists to compare with payer capabilities. - Problem: No complete payment option exists to compare with payer capabilities. - Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence. - How to implement: Attach a sandbox payer compatibility matrix and later verify the option with a live sandbox retry. - Copy prompt: Fix this static agent-payment readiness issue: Does the advertised option intersect with a known payer and facilitator capability?. Target: https://redbus.com/api Problem: No complete payment option exists to compare with payer capabilities. Required change: Attach a sandbox payer compatibility matrix and later verify the option with a live sandbox retry. Make the smallest focused implementation change. Add or update tests. Rerun the Agent Payments static scan after the change. #### Is there a concrete paid endpoint or tool the agent can discover? - Requirement: Core - Status: Fix - Category: x402 V2 static checks - Goal: Is there a concrete paid endpoint or tool the agent can discover? - Observed: Found x402/API candidate https://redbus.com/api, but unpaid preflight did not validate a complete x402 payment challenge. - Problem: A URL, OpenAPI operation, or protocol mention is not enough to prove a concrete payable x402 resource. - Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence. - How to implement: Publish a concrete paid endpoint with method, price behavior, scheme, network, asset, and expected result. - Copy prompt: Fix this static agent-payment readiness issue: Is there a concrete paid endpoint or tool the agent can discover?. Target: https://redbus.com/api Problem: A URL, OpenAPI operation, or protocol mention is not enough to prove a concrete payable x402 resource. Required change: Publish a concrete paid endpoint with method, price behavior, scheme, network, asset, and expected result. Make the smallest focused implementation change. Add or update tests. Rerun the Agent Payments static scan after the change. #### Are HTTP, MCP, and A2A x402 claims evaluated separately? - Requirement: Optional - Status: Info - Category: x402 V2 static checks - Goal: Are HTTP, MCP, and A2A x402 claims evaluated separately? - Observed: Transport separation is not scored because no x402 challenge or explicit x402 claim was detected. - Problem: Transport separation is not scored because no x402 challenge or explicit x402 claim was detected. - Why it matters: This protocol should not affect the score unless the company exposes a compatible transaction surface or explicit claim. - How to implement: No change required #### Does an unpaid request return an x402 challenge? - Requirement: Core - Status: Fix - Category: x402 V2 static checks - Goal: Does an unpaid request return an x402 challenge? - Observed: The unpaid response did not include a decodable x402 V2 payment challenge. - Problem: The unpaid response did not include a decodable x402 V2 payment challenge. - Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence. - How to implement: Return HTTP 402 with a decodable x402 V2 PAYMENT-REQUIRED challenge. - Copy prompt: Fix this static agent-payment readiness issue: Does an unpaid request return an x402 challenge?. Target: https://redbus.com/api Problem: The unpaid response did not include a decodable x402 V2 payment challenge. Required change: Return HTTP 402 with a decodable x402 V2 PAYMENT-REQUIRED challenge. Make the smallest focused implementation change. Add or update tests. Rerun the Agent Payments static scan after the change. ### MPP machine payment acceptance - Cataloged for this company: No #### Machine Payments Protocol not applicable - Requirement: Optional - Status: Info - Category: Machine Payments Protocol static checks - Goal: Score this protocol only when it matches the company's transaction surface. - Observed: No paid API/resource, paid MCP tool, MPP claim, or MPP endpoint candidate was detected. - Problem: No paid API/resource, paid MCP tool, MPP claim, or MPP endpoint candidate was detected. - Why it matters: This protocol should not affect the score unless the company exposes a compatible transaction surface or explicit claim. - How to implement: No change required ### UCP agentic checkout readiness - Cataloged for this company: No #### Are declared external UCP service endpoints reachable? - Requirement: Optional - Status: Info - Category: Universal Commerce Protocol static checks - Goal: Are declared external UCP service endpoints reachable? - Observed: No external UCP service endpoint is declared; the registries may be empty or embedded-only. - Problem: No external UCP service endpoint is declared; the registries may be empty or embedded-only. - Why it matters: This protocol should not affect the score unless the company exposes a compatible transaction surface or explicit claim. - How to implement: No change required #### Is the UCP business profile publicly discoverable? - Requirement: Core - Status: Fix - Category: Universal Commerce Protocol static checks - Goal: Is the UCP business profile publicly discoverable? - Observed: Observed HTTP 301 at /.well-known/ucp. - Problem: Observed HTTP 301 at /.well-known/ucp. - Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence. - How to implement: Serve a schema-valid public UCP business profile at /.well-known/ucp without authentication. - Copy prompt: Fix this static agent-payment readiness issue: Is the UCP business profile publicly discoverable?. Target: https://redbus.com/.well-known/ucp Problem: Observed HTTP 301 at /.well-known/ucp. Required change: Serve a schema-valid public UCP business profile at /.well-known/ucp without authentication. Make the smallest focused implementation change. Add or update tests. Rerun the Agent Payments static scan after the change. #### Is checkout capability claimed with enough structure to test later? - Requirement: Core - Status: Fix - Category: Universal Commerce Protocol static checks - Goal: Is checkout capability claimed with enough structure to test later? - Observed: No structurally valid dev.ucp.shopping.checkout capability was declared. - Problem: No structurally valid dev.ucp.shopping.checkout capability was declared. - Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence. - How to implement: Declare dev.ucp.shopping.checkout with version and schema when UCP checkout is supported. - Copy prompt: Fix this static agent-payment readiness issue: Is checkout capability claimed with enough structure to test later?. Target: https://redbus.com Problem: No structurally valid dev.ucp.shopping.checkout capability was declared. Required change: Declare dev.ucp.shopping.checkout with version and schema when UCP checkout is supported. Make the smallest focused implementation change. Add or update tests. Rerun the Agent Payments static scan after the change. #### Does the profile declare payment handlers? - Requirement: Core - Status: Fix - Category: Universal Commerce Protocol static checks - Goal: Does the profile declare payment handlers? - Observed: Invalid UCP payment_handlers registry: payment_handlers registry is missing or is not an object - Problem: Invalid UCP payment_handlers registry: payment_handlers registry is missing or is not an object - Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence. - How to implement: Include the payment_handlers registry. Each declared handler entry requires version and id; config is optional. - Copy prompt: Fix this static agent-payment readiness issue: Does the profile declare payment handlers?. Target: https://redbus.com Problem: Invalid UCP payment_handlers registry: payment_handlers registry is missing or is not an object Required change: Include the payment_handlers registry. Each declared handler entry requires version and id; config is optional. Make the smallest focused implementation change. Add or update tests. Rerun the Agent Payments static scan after the change. #### Are signing keys published for message verification? - Requirement: Optional - Status: Info - Category: Universal Commerce Protocol static checks - Goal: Are signing keys published for message verification? - Observed: No signed-message or webhook capability is claimed, so signing keys are not required. - Problem: No signed-message or webhook capability is claimed, so signing keys are not required. - Why it matters: This protocol should not affect the score unless the company exposes a compatible transaction surface or explicit claim. - How to implement: No change required #### Does the profile follow the UCP business-profile registries? - Requirement: Core - Status: Fix - Category: Universal Commerce Protocol static checks - Goal: Does the profile follow the UCP business-profile registries? - Observed: Invalid UCP business profile structure: ucp.version must use YYYY-MM-DD; services registry is missing or is not an object; payment_handlers registry is missing or is not an object - Problem: Invalid UCP business profile structure: ucp.version must use YYYY-MM-DD; services registry is missing or is not an object; payment_handlers registry is missing or is not an object - Why it matters: Agents may not be able to discover, understand, or safely attempt this payment path from static public evidence. - How to implement: Declare a YYYY-MM-DD ucp.version plus services and payment_handlers registries. Capabilities are optional; declared services, capabilities, and handlers must follow their transport/entity schemas. - Copy prompt: Fix this static agent-payment readiness issue: Does the profile follow the UCP business-profile registries?. Target: https://redbus.com Problem: Invalid UCP business profile structure: ucp.version must use YYYY-MM-DD; services registry is missing or is not an object; payment_handlers registry is missing or is not an object Required change: Declare a YYYY-MM-DD ucp.version plus services and payment_handlers registries. Capabilities are optional; declared services, capabilities, and handlers must follow their transport/entity schemas. Make the smallest focused implementation change. Add or update tests. Rerun the Agent Payments static scan after the change. ### ACP merchant checkout readiness - Cataloged for this company: No #### Agentic Commerce Protocol not applicable - Requirement: Optional - Status: Info - Category: Agentic Commerce Protocol static checks - Goal: Score this protocol only when it matches the company's transaction surface. - Observed: No ACP discovery document, checkout_sessions contract, or Agentic Commerce Protocol claim was detected. - Problem: No ACP discovery document, checkout_sessions contract, or Agentic Commerce Protocol claim was detected. - Why it matters: This protocol should not affect the score unless the company exposes a compatible transaction surface or explicit claim. - How to implement: No change required ### AP2 delegated authorization readiness - Cataloged for this company: No #### Agent Payments Protocol not applicable - Requirement: Optional - Status: Info - Category: Agent Payments Protocol static checks - Goal: Score this protocol only when it matches the company's transaction surface. - Observed: No AP2, signed mandate, or delegated payment authorization claim was detected. - Problem: No AP2, signed mandate, or delegated payment authorization claim was detected. - Why it matters: This protocol should not affect the score unless the company exposes a compatible transaction surface or explicit claim. - How to implement: No change required ### Visa TAP trusted-agent readiness - Cataloged for this company: No #### Visa Trusted Agent Protocol not applicable - Requirement: Optional - Status: Info - Category: Visa Trusted Agent Protocol static checks - Goal: Score this protocol only when it matches the company's transaction surface. - Observed: No target-specific Visa Trusted Agent Protocol claim was detected. Generic Visa acceptance is not TAP support. - Problem: No target-specific Visa Trusted Agent Protocol claim was detected. Generic Visa acceptance is not TAP support. - Why it matters: This protocol should not affect the score unless the company exposes a compatible transaction surface or explicit claim. - How to implement: No change required ### Mastercard Agent Pay acceptance evidence - Cataloged for this company: No #### Mastercard Agent Pay not applicable - Requirement: Optional - Status: Info - Category: Mastercard Agent Pay static checks - Goal: Score this protocol only when it matches the company's transaction surface. - Observed: No target-specific Mastercard Agent Pay claim was detected. Generic Mastercard card acceptance is not Agent Pay support. - Problem: No target-specific Mastercard Agent Pay claim was detected. Generic Mastercard card acceptance is not Agent Pay support. - Why it matters: This protocol should not affect the score unless the company exposes a compatible transaction surface or explicit claim. - How to implement: No change required ### Agent payment website experience #### Agent readiness scan could not complete - Requirement: Core - Status: Review - Category: Discoverability - Goal: Complete the full static evaluation - Observed: ValueError: The target site could not be scanned - Problem: ValueError: The target site could not be scanned - Why it matters: The report is incomplete and should not be treated as verified. - How to implement: Retry the static scan after confirming the public site is reachable. - Copy prompt: Fix the following agent-payment readiness issue: Agent readiness scan could not complete. Target: the public company website Problem: ValueError: The target site could not be scanned Required change: Retry the static scan after confirming the public site is reachable. Make the smallest focused implementation change, preserve existing behavior, and add or update tests where appropriate. Verify the public response and rerun the Agent Payments static scan afterward. ## Frequently Asked Questions ### Who should set up x402? Pick x402 when the thing being sold is a single HTTP-accessible resource: an API response, dataset export, generated report, inference call, paywalled file, crawl result, or metered compute job. The clean implementation is request-scoped: the agent asks for a URL, receives a 402 challenge with payment terms, pays, then retries or continues the same request. Fits: API companies, data providers, AI inference providers, developer infrastructure, paywalled content, search or scraping providers, analytics APIs, and MCP tools whose paid action maps to a URL. It is usually not the first protocol for carts, shipping, variants, returns, or marketplace checkout. ### Who should set up MPP? Pick MPP when you need a machine-payment flow that is broader than one fixed paid URL: a challenge, credential, and receipt flow that can support multiple payment methods, one-time charges, measured sessions, subscriptions, HTTP services, and MCP tools. It is strongest when payer choice, receipts, and recurring or usage-based access matter. Fits: SaaS platforms with public APIs, cloud services, metered data products, AI tools, API marketplaces, and paid MCP tools that may accept cards, stablecoins, Stripe-backed payments, or custom payment methods. It is less useful when the main job is retail product discovery and checkout. ### Where does MCP fit? Use MCP when the agent should operate the product through named tools instead of raw endpoints: create a ticket, run a query, generate a file, start a workflow, reserve inventory, or read private account data. MCP describes the tool interface and context; x402, MPP, or another payment mechanism still needs to describe how the charge is authorized. Fits: developer tools, authenticated SaaS products, observability platforms, CRMs, workflow software, data tools, design or document tools, and internal enterprise platforms. MCP alone should not be counted as payment support; it needs a reproducible paid action behind it. ### Who should set up UCP? Pick UCP when the goal is direct buying from AI surfaces such as Google AI Mode or Gemini while the merchant stays the merchant of record. It is about exposing commerce capabilities, checkout options, payment handlers, and post-purchase state so an agent can move from discovery to purchase without sending the user through a normal browser flow. Fits: retailers with Merchant Center feeds, DTC brands, commerce platforms, marketplaces, and merchants in expanding direct-buying categories such as lodging and food. It is overkill for a simple paid API endpoint with no catalog, checkout, or order lifecycle. ### Who should set up ACP? Pick ACP when the main integration is agentic checkout: product feed or cart discovery, checkout-session create/update/complete, fulfillment choices, delegated payment, delegated authentication, and order or refund webhooks. It is a checkout contract for agents, not a generic API monetization layer. Fits: Stripe-based merchants, ecommerce platforms, marketplaces, product-feed owners, checkout providers, DTC brands, and merchants pursuing ChatGPT or agent-shopping checkout. It is not the first step for API-only companies unless they also sell products or checkout sessions. ### Who should set up AP2? Pick AP2 when the hard part is proving agent authority. The user gives a real-time approval or a delegated mandate, the agent shops or coordinates within those constraints, and the merchant or payment provider needs cryptographic evidence that the final payment matched the approved intent. Fits: travel booking, procurement, marketplace checkout, ticketing, delivery, financial services, high-value retail, and B2B agent workflows where the user may not be present at final purchase time. It is less relevant for fixed-price API calls where the payer approves each request directly. ### Who should set up Visa TAP? Pick Visa Trusted Agent Protocol when the immediate problem is merchant visibility and trusted-agent recognition: distinguishing legitimate shopping agents from generic bots, verifying signed agent requests, and deciding what consumer, intent, and payment information an agent can pass during commerce. Fits: large merchants, bot-mitigation or CDN partners, PSPs, wallets, agent platforms, and commerce teams integrating with Visa Intelligent Commerce. Generic Visa card acceptance is not enough; the implementation needs TAP-style agent identity and signature handling. ### Who should set up Mastercard Agent Pay? Pick Mastercard Agent Pay when Mastercard network tokenization is part of the agentic checkout path. The implementation is about agentic tokens, Mastercard Digital Enablement Service, authentication such as payment passkeys, role registration, and transaction identifiers that let the network, issuer, acquirer, merchant, and agentic-commerce provider understand the transaction. Fits: agentic commerce providers, agentic commerce enablers, token requestors, large merchants, issuers, acquirers, wallets, and checkout providers participating in Mastercard's Agent Pay program. A normal Mastercard card form or generic card-on-file checkout does not qualify. ## Coding-Agent Evaluations | Agent | Status | Score | |-------|--------|-------| | Claude Code | not_run | — | | Codex | not_run | — | ## Services and Endpoints - No endpoint inventory attached. ## External Website Benchmarks - No external website benchmark attached. External scores provide website context and do not contribute to Lightsage's payment-readiness score. ## Evidence - [Sapient backend static agent-payment scan](https://lightsage.com/agent-experience-arena/payments/methodology) - [Lightsage backend static agent-payment scan](https://lightsage.com/agent-experience-arena/payments/methodology) Canonical URL: https://lightsage.com/agent-experience-arena/payments/redbus-com