"Currently, x402 is still just a 'loli' in the payment track" 😅 I have been experiencing x402 for the past few days, and from an engineer's perspective, there is still a lot of room for improvement. Based on my experience, there are several issues that hinder the comprehensive development of x402. If these cannot be resolved, I believe they can only remain in the conceptual stage and cannot be applied on a large scale. 1. Complexity of Embedded Engineering ⚙️ x402 provides a fetch SDK and some HTTP middleware to implement this payment function. However, the fetch package is actually a special encapsulation. If you need to use it, you can only easily integrate their fetch in your code; otherwise, you will need to manually complete a very complex integration logic. Meanwhile, middleware integration takes priority. Although it already supports mainstream frameworks, it still needs refinement. Of course, this is the smallest issue, and as the ecosystem develops, these problems will ultimately be minor. 2. No Essential Change 🧩 Although the 402 status code sounds impressive, what it returns is actually not important at all. It can return a 402, a 200 with a JSON, or anything else along with a bunch of data. Essentially, it is just an engineering encapsulation that adds a payment process. 3. Unreliable Under High-Frequency Calls ⏱️ In the case of the second point, it raises a question about this so-called high-frequency issue. We know that the current mainstream concept is for AI Agents to call an API to obtain data or other content. However, with the addition of this payment logic, the entire process becomes very lengthy. Low-frequency requests from AI Agents are manageable (since Agent requests are inherently slow...), but once it enters high-frequency requests, the request time for an API can multiply, potentially extending an API request to 3 to 10 times its original duration (official tests show an additional 2 seconds delay per request, but I believe that is optimistic). If I need to obtain a large amount of data, the overall process time can be overwhelming. As the number of requests increases, you also have to wait for on-chain transaction confirmations and RPC delays, making high-frequency APIs basically unfeasible with the current x402 model (though it can be modified later). 4. Extremely Incomplete Process 🔁 As a payment-oriented protocol, I see no rigor in this product as a financial middleware. I have no idea how it handles network fluctuations that affect the actual processing of payments, nor have I seen any binding relationship between API requests and transaction records. The current situation is that you paid, but the payment status is only valid for this one request, and all other context completely disappears. In traditional Web2 scenarios, payments not only have a callback method (redirecting to a merchant-specified page after payment completion) but also periodic retries (if the callback is not executed, it will attempt to retry the callback at intervals of 3 seconds, 5 seconds, 1 minute, etc., until successful to prevent transaction loss). I see none of this in x402. It's like buying something from a small vendor at a street market versus a supermarket. When you buy something at a street market, there’s no invoice, no product information, no quantity, and when you get home and find the items are spoiled, you realize you can't even claim a refund because the vendor has vanished. But when you buy something at a supermarket, at least there’s a physical receipt, monitoring, and if you encounter a generous return policy, you might even enjoy unconditional refunds. As a B2B product, x402 is currently completely unqualified and irresponsible. 5. Almost No Regulatory Process ⚖️ I know many people think that the lack of regulation is a good thing, as decentralization emphasizes no KYC and no regulation. We won't discuss the frequent security incidents caused by new technologies here, but let's talk about a so-called API provider. If, for various reasons, they provide non-compliant data or if a merchant's request fails due to excessive request volume, or a series of requests fail, but you have already paid, how do you handle refunds? I currently see no relevant mechanisms. This means that if one day you are unlucky, and after payment, the network lags, or their service lags, or you refresh the page, congratulations, your payment is invalid. Then, when you look for how to get a refund, after searching for a long time, you find that there is none. No one can take responsibility for this payment action; at most, you can contact the provider, saying you paid but they didn’t provide the service, leading to months of back-and-forth. If you’re unlucky, and the service provider hasn’t implemented sufficient monitoring, they might not even be able to find your request records.

@taowang1 @Cloudflare typed the wrong namecheap