Các đại lý AI giờ đây có thể tự thanh toán nhờ x402 và HTTP 402

Đó là tháng 1 năm 1997.

CácIETF(Internet Engineering Task Force) vừa phát hànhRFC 2068chính thức định nghĩaHTTP/1.1Các thông số kỹ thuật được viết bởi các nhà tiên phong webbởi Roy Fielding,Jim Gettys,Jeffrey Mogul,HENRIK FRYSTYKvàTác giả Tim Berners-Lee, các kiến trúc sư đã định hình cách Internet giao tiếp.

Specification giới thiệupersistent connections: trước đây, mỗi yêu cầu HTTP yêu cầu một kết nối TCP mới. kết nối liên tục giải quyết điều này, cho phép nhiều yêu cầu HTTP chảy qua một kết nối TCP duy nhất, kéo dài. không còn thiết lập các kết nối riêng biệt cho mỗi hình ảnh, tệp CSS, hoặc đoạn JavaScript trên một trang web.

Ngoài ra còn cóchunked transfer encoding, một cách mới cho các máy chủ web để phát trực tuyến nội dung mà không biết kích thước đầy đủ trước. không còn một máy chủ cần phải tính toán tổng kích thước của nội dung được tạo động trước, nó bây giờ là tự do để cung cấp dữ liệu dần dần, khi nó được sản xuất.

NhưngRFC 2068 quietly introduces something intriguingMã trạng thái mới:

HTTP 402 Payment Required
This code is reserved for future use.

Điều này cho thấy làm thế nào những người sáng lập của World Wide Web dự đoán làm thế nào tiền cuối cùng sẽ trở thành một phần lớn của Internet.even if they had no clear path on how it would actually play out.

Ngày nay, năm 2025, gần ba thập kỷ và nhiều phiên bản HTTP sau đó (HTTP/2Trong năm 2015,HTTP/3Đến năm 2022,Status Code 402 still sits there with the exact same note: 'reserved for future use.'Mặc dù cuộc cách mạng fintech, sự trỗi dậy của thanh toán trực tuyến, và toàn bộ nền kinh tế được xây dựng trên các giao dịch internet, không ai biết phải làm gì với nó.

Until now.

Tháng trước (tháng 5 năm 2025),CoinbaseGiải phóngx402, một giao thức mã nguồn mở cung cấpHTTP 402công việc thực sự đầu tiên của mình: cho phép người bản xứonchainthanh toán trong các yêu cầu HTTP.

Ngày nay, các nhân viên cần phảiM2M(machine-to-machine) thanh toán trên web với giảmHITLCác can thiệp (con người trong vòng tròn) nhưng các luồng thanh toán truyền thống không hoạt động tốt trong trường hợp này. chúng đòi hỏi nhiều tương tác của con người, chuyển hướng và các bước thủ công mà chỉ đơn giản là không hoạt động khi một đại lý AI cần thực hiện một giao dịch một cách độc lập.

x402Nó đề xuất một luồng thanh toán tự động trên chuỗi được thực hiện tự nhiên trong giao thức HTTP,making them as seamless as any other web request.

Nhưng điều này trông như thế nào trong thực tế?

Kiến trúc và các thành phần củax402

x402được xây dựng xung quanh bốn thành phần cốt lõi:

Thì

a làclienthoạt động như người khởi xướng thanh toán, khám phá những gì được yêu cầu để truy cập và xây dựng tải trọng thanh toán thích hợp. Nói một cách đơn giản, đây là bất cứ điều gì đang làm cho yêu cầu HTTP thành một tài nguyên có tường trả tiền. Nó có thể là một trình duyệt làm cho một yêu cầu cho nội dung cao cấp, một đại lý AI mua API truy cập, hoặc một ứng dụng di động mở khóa các tính năng.

Cácresource serverthực thi các chính sách thanh toán cho các điểm cuối của nó trong khi vẫn tập trung vào logic kinh doanh cốt lõi của nó. Đây là máy chủ web hoặc API lưu trữ nội dung hoặc dịch vụ được mua. Nó duy trì các bảng giá đơn giản mà bản đồ điểm cuối để chi phí, nhưng chuyển giao logic xác minh thanh toán cho người hỗ trợ.

Logic Blockchain được thực hiện trongfacilitatorthành phần: xác minh chữ ký mã hóa, ngăn chặn các cuộc tấn công tái phát thông qua theo dõi nonce, và quản lý thanh toán trên chuỗi thực tế. Nó cho phép cả khách hàng và máy chủ làm việc với thanh toán trên chuỗi mà không hiểu chi tiết triển khai blockchain.

Cóblockchainnằm ở tầng thanh toán cuối cùng, đảm bảo thanh toán không thay đổi và minh bạch. Nó cho phép tiền có thể lập trình thông qua các hợp đồng thông minh và stable-coins,but its complexity is completely hidden from the application layer by the facilitator.

Client:

• Trách nhiệm chính: Bắt đầu thanh toán
• Các tính năng chính:Đăng ký EIP-712, trả lại tự động, phát hiện thanh toán
• Nó làm gì: Gửi yêu cầu, xử lý ví, trả lại với thanh toán

Resource Server:

• Primary Responsibility: Payment enforcement
• Các tính năng chính: Bảng giá, phản hồi HTTP 402, tích hợp middleware
• Nó làm gì: Đặt giá, kiểm tra thanh toán, cung cấp nội dung

Facilitator:

• Trách nhiệm chính: Kiểm tra thanh toán
• Các tính năng chính: Kiểm tra chữ ký, theo dõi nonce, trừu tượng khí
• Nó làm gì: Kiểm tra chữ ký, nói chuyện với blockchain

Blockchain:

• Trách nhiệm chính: Thanh toán
• Các tính năng chính: Chuyển khoản USD, hợp đồng thông minh, hồ sơ không thay đổi
• Nó làm gì: Giải quyết thanh toán trên chuỗi

Nguyên tắc

Kiến trúc này thể hiện một số nguyên tắc cơ bản của kỹ thuật phần mềm.separation of concernsMỗi thành phần có một trách nhiệm duy nhất, được xác định rõ ràng.Resource servers focus purely on business logic, facilitators handle payment complexity, and clients manage user interaction.

Hệ thống đạt đượcloose couplingbằng cách có các thành phần tương tác chỉ thông qua giao diện HTTP và REST chuẩn hóa.A resource server doesn't need to understand how blockchain transactions work, and a client doesn't need to know the server's internal implementationSự cô lập này có nghĩa là bạn có thể trao đổi các thành phần (ví dụ, sử dụng một blockchain khác, thay đổi nhà cung cấp facilitator, hoặc sửa đổi logic máy chủ) mà không ảnh hưởng đến phần còn lại của hệ thống.

Các facilitator thể hiện cácsingle responsibility principlebằng cách cô lập tất cả sự phức tạp của blockchain thành một dịch vụ chuyên biệt. điều này ngăn chặn logic thanh toán rò rỉ vào các ứng dụng kinh doanh và giữ cho các mối quan tâm được tách rời một cách chính xác.

Cuối cùng nhưng không kém phần quan trọng, kiến trúc này saudependency inversionCác thành phần cấp cao phụ thuộc vào trừu tượng thay vì thực hiện cụ thể. máy chủ và khách hàng phụ thuộc vào giao diện HTTP, không phải API blockchain cụ thể. Điều này cho phép cùng một mã ứng dụng để làm việc trên các blockchain khác nhau và các chương trình thanh toán mà không cần sửa đổi.

flow thanh toán

Khi một đại lý AI hoặc người dùng nhấn mộtx402-enabled API, đây là dòng chảy bốn bước xảy ra:

1. Yêu cầu ban đầu: Khách hàng thực hiện một yêu cầu HTTP tiêu chuẩn để truy cập một số tài nguyên
2. Trả lời yêu cầu thanh toán: Nếu không có thanh toán được đính kèm, máy chủ sẽ trả lời bằng HTTP 402 và bao gồm các chi tiết thanh toán
3. Quyền ủy quyền thanh toán: Khách hàng tạo một khoản thanh toán được ký mã hóa và trả lại yêu cầu
4. Xác minh và truy cập: Máy chủ xác nhận thanh toán, phát sóng nó đến blockchain và cấp quyền truy cập

Điều làm cho điều này mạnh mẽ là tất cả mọi thứ xảy ra ở cấp độ giao thức HTTP. Không chuyển hướng đến các bộ xử lý thanh toán của bên thứ ba, khôngOAuthdòng, không tạo tài khoản.Just standard HTTP with extra headers:

• X-PAYMENT chảy từ khách hàng đến máy chủ và chứa khối lượng thanh toán được ký kết. Điều này bao gồm chi tiết thanh toán (số tiền, người nhận, token) cộng với một chữ ký mã hóa chứng minh rằng khách hàng đã ủy quyền thanh toán.
• X-PAYMENT-RESPONSE flows from server to client after successful payment and contains transaction receipt information , providing transparency about what happened on-chain.

Thì

Server-side thực hiện

Kiến trúc Middleware

Việc thực hiện bên máy chủ cốt lõi xoay quanh một bộ lọc thanh toán (AKA middle-ware) chặn các yêu cầu HTTP và thực thi các yêu cầu thanh toán. Khi được tích hợp vào máy chủ web của bạn, middle-ware này kiểm tra các yêu cầu đến với một bảng giá mà bản đồ điểm cuối với chi phí của họ.

Trung bình theo một cây quyết định đơn giản: nếu một yêu cầu đạt đến một điểm cuối được bảo vệ mà không cần thanh toán, nó đáp ứng vớiHTTP 402và các hướng dẫn thanh toán chi tiết. Nếu thanh toán được bao gồm trongX-PAYMENTheader, nó xác minh thanh toán với một dịch vụ facilitator trước khi cho phép yêu cầu tiến hành.

Dưới đây là cấu trúc thiết yếu từ việc thực hiện Java:

public class PaymentFilter implements Filter {
    private final String payTo;
    private final Map<String, BigInteger> priceTable; // path → amount
    private final FacilitatorClient facilitator;

    public void doFilter(ServletRequest request, ServletResponse response, 
                        FilterChain chain) throws IOException, ServletException {
        String path = req.getRequestURI();
        String paymentHeader = req.getHeader("X-PAYMENT");

        if (!priceTable.containsKey(path)) {
            chain.doFilter(request, response);  // Free endpoint
            return;
        }

        if (paymentHeader == null) {
            send402Response(resp, path);  // Request payment
            return;
        }

        // Verify payment, process request, then settle
        VerificationResponse verification = facilitator.verify(paymentHeader, requirements);
        if (verification.valid) {
            chain.doFilter(request, response);
            facilitator.settle(paymentHeader, requirements);
        }
    }
}

The beauty of this approach is that it requires minimal changes to existing applications.Bạn chỉ cần thêm bộ lọc thanh toán vào stack trung bình của bạn và xác định điểm cuối nào yêu cầu thanh toán.

PaymentRequirementsTrả lời

Khi một máy khách chạm vào một điểm cuối được bảo vệ mà không cần thanh toán, máy chủ xây dựng một đối tượng yêu cầu thanh toán chi tiết.USDC), địa chỉ ví nhận, mạng blockchain và thời gian hết hạn để ngăn chặn các cuộc tấn công tái phát.

private void send402Response(HttpServletResponse response, String path) throws IOException {
    response.setStatus(HttpStatus.PAYMENT_REQUIRED);
    response.setContentType("application/json");

    PaymentRequirements requirements = PaymentRequirements.builder()
        .paymentRequirement(List.of(
            PaymentRequirement.builder()
                .kind(new Kind("exact", "base-sepolia"))             // Payment scheme + blockchain network
                .receiver(payTo)                                     // Wallet address to receive payment
                .amount(priceTable.get(path))                        // Cost for this specific endpoint
                .asset("<USDC_TOKEN_CONTRACT>")                      // USDC token contract
                .expiry(Instant.now().plus(Duration.ofMinutes(5)))   // Payment window
                .nonce(UUID.randomUUID().toString())                 // One-time use identifier
                .build()
        ))
        .build();

    response.getWriter().write(Json.MAPPER.writeValueAsString(requirements));
}

Mỗi lĩnh vực trongPaymentRequirementsđược mô tả như sau:

• Loại: Xác định kế hoạch thanh toán (chính xác đối với số tiền cố định) và mạng blockchain mục tiêu (base-sepolia cho Base testnet).
• Người nhận: Địa chỉ ví nơi thanh toán nên được gửi. Đây là ví kinh doanh của bạn sẽ nhận được tiền.
• Số tiền: Chi phí truy cập vào điểm cuối cụ thể này, được lấy từ bảng giá của bạn. Đối với USDC, điều này thường được thể hiện bằng wei (đơn vị nhỏ nhất).
• tài sản: Địa chỉ hợp đồng thông minh của token được sử dụng để thanh toán. ví dụ cho thấy USDC trên Base Sepolia testnet.
• hết hạn: Một dấu hiệu thời gian sau đó yêu cầu thanh toán này trở nên vô hiệu. Điều này ngăn chặn các yêu cầu thanh toán cũ được tái sử dụng và thêm bảo mật chống lại các cuộc tấn công tái phát.
• Nonce: Một ID duy nhất (UUID) đảm bảo mỗi yêu cầu thanh toán chỉ có thể được đáp ứng một lần, ngay cả khi cùng một khách hàng thực hiện nhiều yêu cầu đến cùng một điểm cuối.

Ứng dụng client-side

xử lý thanh toán tự động

Thư viện khách hàng đóng gói các khách hàng HTTP tiêu chuẩn để tự động xử lý các câu trả lời 402.Khi một khách hàng nhận được yêu cầu thanh toán, (1) nó xây dựng tải trọng thanh toán, (2) ký nó với khóa riêng của người dùng, và (3) tái tạo yêu cầu ban đầu với thanh toán đính kèm.

public HttpResponse<String> makeRequest(String url, String method) throws Exception {
    HttpRequest request = HttpRequest.newBuilder()
        .uri(URI.create(url))
        .method(method, HttpRequest.BodyPublishers.noBody())
        .build();

    HttpResponse<String> response = httpClient.send(request, 
        HttpResponse.BodyHandlers.ofString());

    // Handle 402 Payment Required
    if (response.statusCode() == 402) {
        PaymentRequirements requirements = Json.MAPPER.readValue(
            response.body(), PaymentRequirements.class);

        // Create payment payload matching the requirements
        PaymentPayload payment = PaymentPayload.builder()
            .receiver(requirements.getPaymentRequirement().get(0).getReceiver())
            .amount(requirements.getPaymentRequirement().get(0).getAmount())
            .asset(requirements.getPaymentRequirement().get(0).getAsset())
            .nonce(requirements.getPaymentRequirement().get(0).getNonce())
            .expiry(requirements.getPaymentRequirement().get(0).getExpiry())
            .build();

        // Sign using EIP-712 structured data signing
        String signature = signer.sign(payment.toSigningMap());

        // Retry with payment header
        String paymentHeader = encodePaymentHeader(payment, signature);
        HttpRequest paidRequest = HttpRequest.newBuilder()
            .uri(URI.create(url))
            .method(method, HttpRequest.BodyPublishers.noBody())
            .header("X-PAYMENT", paymentHeader)
            .build();

        return httpClient.send(paidRequest, HttpResponse.BodyHandlers.ofString());
    }

    return response;
}

Quá trình ký kết sử dụngEIP-712tiêu chuẩn, tạo ra một đại diện có cấu trúc, có thể đọc được bởi con người của dữ liệu thanh toán trước khi hash và ký nó.

Thanh toán Verification Flow

Facilitator hội nhập

Dịch vụ facilitator là nơi sự phức tạp của blockchain sống, trừu tượng nó xa cả khách hàng và máy chủ.Khi một máy chủ nhận được thanh toán, nó chuyển tải trọng thanh toán cho facilitator để xác minh.

public class HttpFacilitatorClient implements FacilitatorClient {
    private final HttpClient http;
    private final String baseUrl;

    @Override
    public VerificationResponse verify(String paymentHeader, PaymentRequirements requirements) 
        throws Exception {

        // Construct verification request with payment and requirements
        VerifyRequest body = VerifyRequest.builder()
            .paymentHeader(paymentHeader)     // The X-PAYMENT header from client
            .requirements(requirements)       // What the server expects
            .build();

        HttpRequest request = HttpRequest.newBuilder()
            .uri(URI.create(baseUrl + "/verify"))
            .POST(HttpRequest.BodyPublishers.ofString(Json.MAPPER.writeValueAsString(body)))
            .header("Content-Type", "application/json")
            .build();

        String json = http.send(request, HttpResponse.BodyHandlers.ofString()).body();
        return Json.MAPPER.readValue(json, VerificationResponse.class);
    }

    @Override
    public SettlementResponse settle(String paymentHeader, PaymentRequirements requirements) 
        throws Exception {

        // Settlement happens after successful verification
        SettleRequest body = SettleRequest.builder()
            .paymentHeader(paymentHeader)
            .requirements(requirements)
            .build();

        HttpRequest request = HttpRequest.newBuilder()
            .uri(URI.create(baseUrl + "/settle"))
            .POST(HttpRequest.BodyPublishers.ofString(Json.MAPPER.writeValueAsString(body)))
            .header("Content-Type", "application/json")
            .build();

        String json = http.send(request, HttpResponse.BodyHandlers.ofString()).body();
        return Json.MAPPER.readValue(json, SettlementResponse.class);
    }
}

Nhà cung cấp kiểm tra một số điều:

• Chữ ký có hợp lệ không?
• Does the payment amount match the requirements?
• Việc thanh toán này đã được sử dụng trước đây chưa?
• Thanh toán vẫn còn trong cửa sổ hết hạn của nó?

Nếu xác minh được thông qua, người facilitator cũng xử lý thanh toán bằng cách phát sóng giao dịch đến blockchain của sự lựa chọn.FacilitatorClientgiao diện xác định hợp đồng mà bất kỳ khách hàng facilitator nào phải thực hiện:

public interface FacilitatorClient {
    VerificationResponse verify(String paymentHeader, PaymentRequirements requirements);
    SettlementResponse settle(String paymentHeader, PaymentRequirements requirements);
}

Ứng dụng của bạn cần cung cấp một triển khai cụ thể của giao diện này.

Integration Ví dụ

Bây giờ chúng ta đã thấy các thành phần riêng lẻ (lọc thanh toán, tích hợp facilitator, và xử lý khách hàng) hãy xem làm thế nào những mảnh này đến với nhau trong một ứng dụng thực sự.Spring BootMột ví dụ cho thấy toàn bộ dòng chảy.

Đầu tiên, tạo a@PaymentRequiredGhi chú :

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface PaymentRequired {
    String price();
    String currency() default "USDC";
    String network() default "base-sepolia";
}

Sau đó thay đổi cácPaymentFilterđể quét cho các ghi chú này tại startup:

@Component
public class PaymentFilter implements Filter {
    private final Map<String, BigInteger> priceTable;
    private final String payTo;
    private final FacilitatorClient facilitator;

    public PaymentFilter(ApplicationContext context, String payTo, FacilitatorClient facilitator) {
        this.payTo = payTo;
        this.facilitator = facilitator;
        this.priceTable = buildPriceTableFromAnnotations(context);
    }

    private Map<String, BigInteger> buildPriceTableFromAnnotations(ApplicationContext context) {
        Map<String, BigInteger> prices = new HashMap<>();

        // Scan all @RestController beans for @PaymentRequired annotations
        Map<String, Object> controllers = context.getBeansWithAnnotation(RestController.class);

        for (Object controller : controllers.values()) {
            Method[] methods = controller.getClass().getMethods();
            for (Method method : methods) {
                PaymentRequired payment = method.getAnnotation(PaymentRequired.class);
                if (payment != null) {
                    String path = extractPathFromMapping(method);
                    BigInteger amount = new BigInteger(payment.price().replace(".", ""));
                    prices.put(path, amount);
                }
            }
        }
        return prices;
    }
}

Bây giờ bạn có thể ghi chú các phương pháp điều khiển của mình trực tiếp:

@RestController
public class WeatherController {

    @GetMapping("/weather")
    @PaymentRequired(price = "0.001", currency = "USDC", network = "base-sepolia")
    public WeatherData getWeather(@RequestParam String city) {
        // Your existing business logic
        return weatherService.getWeatherForCity(city);
    }

    @GetMapping("/premium-forecast")
    @PaymentRequired(price = "0.01", currency = "USDC", network = "base-sepolia")
    public ExtendedForecast getPremiumForecast(@RequestParam String city) {
        return weatherService.getExtendedForecast(city);
    }
}

@Configuration
public class PaymentConfig {

    @Bean
    public PaymentFilter paymentFilter(ApplicationContext context) {
        return new PaymentFilter(
            context,
            "<WALLET_ADDRESS>", // Your wallet address
            new HttpFacilitatorClient("<FACILITATOR_URL>")
        );
    }

    @Bean
    public FilterRegistrationBean<PaymentFilter> paymentFilterRegistration(PaymentFilter filter) {
        FilterRegistrationBean<PaymentFilter> registration = new FilterRegistrationBean<>();
        registration.setFilter(filter);
        registration.addUrlPatterns("/*");
        registration.setOrder(1);
        return registration;
    }
}

Các@PaymentRequiredghi chú xử lý cấu hình giá một cách tuyên bố, trong khiPaymentFiltertự động phát hiện các ghi chú này tại khởi động và xây dựng bảng giá. logic kinh doanh hiện có của bạn trong các phương pháp điều khiển vẫn hoàn toàn không thay đổi. cấu hình kết nối mọi thứ với nhau bằng cách đăng ký bộ lọc thanh toán và kết nối nó với một dịch vụ facilitator./weathergiá 0.001 USDC và/premium-forecastchi phí 0.01 USDC, với tất cả các thanh toán xử lý xảy ra một cách minh bạch tại lớp HTTP.

Các vấn đề an toàn và sản xuất

x402đơn giản và thanh lịch, nó che giấu sự phức tạp. Đây là một lợi thế và một con. Nó làm cho hội nhập dễ dàng, nhưng nó cũng che giấu một khía cạnh quan trọng:putting AI agents in charge of money creates new attack vectors.

Trong khiEIP-712chữ ký và quản lý nonce xử lý các cuộc tấn công tái phát, điều gì xảy ra khi một đại lý bị xâm phạm? phát hiện gian lận truyền thống dựa trên các mô hình hành vi của con người, nhưngAI agents don't follow human spending habitsMột đại lý bị xâm phạm có thể rút tiền nhanh hơn bất kỳ kẻ lừa đảo nào.

Các thành phần facilitator trở thành một mục tiêu giá trị cao khác vì nó xác minh chữ ký và quản lý nonces. không giống như các bộ xử lý thanh toán truyền thống có thể đảo ngược giao dịch,blockchain settlements are final.

Since x402được dựa trên các giao dịch trên chuỗi, nó thừa hưởng rủi ro hoạt động của các giao dịch blockchain. Phí khí dao động hoang dã, đôi khi làm cho thanh toán vi mô bất tiện về mặt kinh tế. tắc nghẽn mạng có thể trì hoãn các giao dịch. Một đại lý AI được cho là làm gì khi nó cần dữ liệu thời gian thực nhưng thanh toán bị mắc kẹt trong một mempool?

Một khía cạnh quan trọng khác là quy định. tuân thủ khác nhau giữa các khu vực với các quy tắc khác nhau về thanh toán tự động, sử dụng tiền điện tử và lưu giữ dữ liệu. Một đại lý AI thực hiện một khối lượng lớn các giao dịch vi mô xuyên biên giới có thể kích hoạt cảnh báo AML hoặc vi phạm các quy định địa phương mà không ai nhận ra.

Điều gì tiếp theo

Điều gì thú vị vềx402Các đại lý AI cần khả năng thanh toán tự trị, stablecoins cung cấp một lớp tiền có thể lập trình, và cơ sở hạ tầng blockchain đã trưởng thành đủ để xử lý các ứng dụng có thể mở rộng. những mảnh này chưa được sắp xếp trước đó. Internet bây giờ cần một hình thức thanh toán mới, và các luồng truyền thống không được xây dựng cho các đại lý tự trị hoặc thanh toán vi mô.

x402Thay vì tái tạo thanh toán từ đầu, nó mở rộng cơ sở hạ tầng HTTP hiện có. Thay vì yêu cầu tích hợp mới, nó hoạt động với các mô hình tiêu chuẩn mà chúng ta đã hiểu.

Các thách thức an ninh và hoạt động là có thật, nhưng chúng là các vấn đề kỹ thuật với các giải pháp có thể.

Sau gần ba thập kỷ,HTTP 402cuối cùng có thể làm những gì nó được thiết kế cho: làm cho việc trả tiền cho những thứ trên internet đơn giản như yêu cầu chúng.

The foundation is set. Now it's time to build.

cảm ơn Lời bài hát: Erik Reppel bởi Ronnie Caspers bởi Kevin Leffew, Danny Organ, và toàn bộ đội Coinbase để mở nguồn cho giao thức này.

cảm ơn Lời bài hát Erik Reppel và Yuga Cohler Để xem xét Những đóng góp của tôi hai x402.

Tài nguyên và đọc thêm

• Yêu cầu thanh toán HTTP 402 - RFC 2068 - Thông số kỹ thuật HTTP 1997 gốc
• Thông số kỹ thuật giao thức x402 - Tài liệu giao thức chính thức
• x402 GitHub Repository - triển khai mã nguồn mở của Coinbase
• x402 Java Implementation - PR đã giới thiệu thực hiện Java của giao thức
• EIP-712: Ethereum Typed Structured Data Hashing and Signing - Chữ ký tiêu chuẩn được sử dụng trong x402
• Base Network Documentation - Layer 2 blockchain nền tảng được sử dụng trong ví dụ
• Tài liệu USDC - Chi tiết hợp đồng USD Coin Stablecoin
• Spring Boot Filter Documentation - Cài đặt Java middleware
• Java HTTP Client API - Quản lý HTTP ở phía khách hàng
• Machine-to-Machine (M2M) Communication Standards - Hệ thống thông tin liên lạc tự trị
• Autonomous AI Agent Architectures - Nghiên cứu về mô hình thiết kế đại lý AI
• Google Approach to Secure AI Agents - Google đề xuất một khuôn khổ nhân viên AI an toàn, được hướng dẫn bởi con người