Quellengeprüfte Recherche: Binance PAY Onchain B402

Verified source facts

1. Binance's September 14 announcement describes On-ramp as a Service, Pay On-chain and Agent Pay with x402 as separate business solution paths. 2. Binance says B402 is intended for AI agents and applications paying for APIs, digital services and online resources on BNB Chain. 3. Binance's product material says integrations are reviewed and availability depends on the business use case, market and supported flow. 4. Coinbase describes x402 as an open HTTP-native payment protocol with signed payloads and facilitator-based verification and settlement.

Comparison at a glance

1. Usage and measurement test: Use case

Stablecoin adoption cannot be inferred from a single gross counter. The use case dimension concerns on-ramp, funding or agent payment. Define the economic job, unit of observation, time window and entities included before counting, then select one production job. Otherwise one routed transaction, exchange rebalance or contract hop may be mistaken for several independent users or payments.

Separate ledger events from economic outcomes. A transfer can be real on-chain yet still represent internal treasury movement, automated arbitrage, bridge routing, collateral management or redemption rather than a purchase. Official sources can frame the categories, but they do not resolve scope expansion. The dataset and classification method therefore belong beside every headline number.

For use case, publish the numerator, denominator and exclusions that support the claim. Make the analyst select one production job, and compare at least one activity metric with one outcome metric relevant to on-ramp, funding or agent payment. Because scope expansion remains unobserved, the conclusion should describe measured behavior rather than declare universal adoption.

2. Usage and measurement test: Eligibility

The eligibility dimension concerns business and regional availability. Define the economic job, unit of observation, time window and entities included before counting, then obtain written confirmation.

Official sources can frame the categories, but they do not resolve future restriction.

For eligibility, publish the numerator, denominator and exclusions that support the claim. Make the analyst obtain written confirmation, and compare at least one activity metric with one outcome metric relevant to business and regional availability. Because future restriction remains unobserved, the conclusion should describe measured behavior rather than declare universal adoption.

3. Usage and measurement test: Assets

The assets dimension concerns supported stablecoins and funding assets. Define the economic job, unit of observation, time window and entities included before counting, then verify live configuration.

Official sources can frame the categories, but they do not resolve asset removal.

For assets, publish the numerator, denominator and exclusions that support the claim. Make the analyst verify live configuration, and compare at least one activity metric with one outcome metric relevant to supported stablecoins and funding assets. Because asset removal remains unobserved, the conclusion should describe measured behavior rather than declare universal adoption.

4. Usage and measurement test: Network

The network dimension concerns BNB Chain and route dependencies. Define the economic job, unit of observation, time window and entities included before counting, then test chain identity.

Official sources can frame the categories, but they do not resolve congestion.

For network, publish the numerator, denominator and exclusions that support the claim. Make the analyst test chain identity, and compare at least one activity metric with one outcome metric relevant to BNB Chain and route dependencies. Because congestion remains unobserved, the conclusion should describe measured behavior rather than declare universal adoption.

5. Usage and measurement test: Wallet

The wallet dimension concerns agent signing and spend control. Define the economic job, unit of observation, time window and entities included before counting, then use bounded permissions.

Official sources can frame the categories, but they do not resolve key compromise.

For wallet, publish the numerator, denominator and exclusions that support the claim. Make the analyst use bounded permissions, and compare at least one activity metric with one outcome metric relevant to agent signing and spend control. Because key compromise remains unobserved, the conclusion should describe measured behavior rather than declare universal adoption.

6. Usage and measurement test: Authorization

The authorization dimension concerns human policy versus autonomous payment. Define the economic job, unit of observation, time window and entities included before counting, then set per-call ceilings.

Official sources can frame the categories, but they do not resolve runaway spend.

For authorization, publish the numerator, denominator and exclusions that support the claim. Make the analyst set per-call ceilings, and compare at least one activity metric with one outcome metric relevant to human policy versus autonomous payment. Because runaway spend remains unobserved, the conclusion should describe measured behavior rather than declare universal adoption.

7. Usage and measurement test: Settlement

The settlement dimension concerns merchant wallet evidence. Define the economic job, unit of observation, time window and entities included before counting, then reconcile transaction receipts.

Official sources can frame the categories, but they do not resolve finality delay.

For settlement, publish the numerator, denominator and exclusions that support the claim. Make the analyst reconcile transaction receipts, and compare at least one activity metric with one outcome metric relevant to merchant wallet evidence. Because finality delay remains unobserved, the conclusion should describe measured behavior rather than declare universal adoption.

8. Usage and measurement test: Compliance

The compliance dimension concerns KYC, KYT and geographic rules. Define the economic job, unit of observation, time window and entities included before counting, then map responsibility.

Official sources can frame the categories, but they do not resolve blocked payer.

For compliance, publish the numerator, denominator and exclusions that support the claim. Make the analyst map responsibility, and compare at least one activity metric with one outcome metric relevant to KYC, KYT and geographic rules. Because blocked payer remains unobserved, the conclusion should describe measured behavior rather than declare universal adoption.

9. Usage and measurement test: Refund

The refund dimension concerns failed service after payment. Define the economic job, unit of observation, time window and entities included before counting, then define contractual recovery.

Official sources can frame the categories, but they do not resolve irreversibility.

For refund, publish the numerator, denominator and exclusions that support the claim. Make the analyst define contractual recovery, and compare at least one activity metric with one outcome metric relevant to failed service after payment. Because irreversibility remains unobserved, the conclusion should describe measured behavior rather than declare universal adoption.

10. Usage and measurement test: Operations

The operations dimension concerns sandbox, monitoring and support. Define the economic job, unit of observation, time window and entities included before counting, then complete staged launch.

Official sources can frame the categories, but they do not resolve provider outage.

For operations, publish the numerator, denominator and exclusions that support the claim. Make the analyst complete staged launch, and compare at least one activity metric with one outcome metric relevant to sandbox, monitoring and support. Because provider outage remains unobserved, the conclusion should describe measured behavior rather than declare universal adoption.

Decision scenarios

Scenario 1: when use case becomes decisive

Consider a reader whose main constraint is on-ramp, funding or agent payment. The correct response is not to infer a universal platform or product winner. It is to select one production job, retain the evidence, and define a stop condition before funds or permissions are committed. If the evidence changes, the decision must be reopened. This produces a repeatable operating rule rather than a one-time opinion.

Scenario 2: when eligibility becomes decisive

Consider a reader whose main constraint is business and regional availability. It is to obtain written confirmation, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 3: when assets becomes decisive

Consider a reader whose main constraint is supported stablecoins and funding assets. It is to verify live configuration, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 4: when network becomes decisive

Consider a reader whose main constraint is BNB Chain and route dependencies. It is to test chain identity, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 5: when wallet becomes decisive

Consider a reader whose main constraint is agent signing and spend control. It is to use bounded permissions, retain the evidence, and define a stop condition before funds or permissions are committed.

Scenario 6: when authorization becomes decisive

Consider a reader whose main constraint is human policy versus autonomous payment. It is to set per-call ceilings, retain the evidence, and define a stop condition before funds or permissions are committed.

Sources and editorial method

• Pay Onchain and Agent Pay with x402 — Binance Announcement
• What is Binance Pay Onchain — Binance Support
• x402 overview — Coinbase Developer Platform