x402: كيف تدفع وكلاء الذكاء الاصطناعي عبر HTTP

ظل رمز الحالة HTTP 402 لعقود في مواصفات الويب بملاحظة شبه اعتذارية واحدة: "الدفع مطلوب — محجوز للاستخدام المستقبلي". وقد وصل ذلك المستقبل في عام 2026. فبروتوكول x402، الذي طوّرته Coinbase وتشرف عليه الآن مؤسسة x402، يمنح أخيرًا الرمز 402 وظيفة فعلية — إذ يتيح للبرمجيات أن تدفع مقابل الموارد بالطريقة نفسها التي تطلبها بها: عبر HTTP، خلال ثوانٍ، ودون تدخّل بشري.

تكمن أهمية ذلك في أن أنظمة الدفع التي بنيناها للبشر تنهار تمامًا أمام الوكلاء المستقلين. فوكيل الذكاء الاصطناعي لا يستطيع تعبئة نموذج بطاقة ائتمان، أو النقر على رسالة تأكيد، أو التفاوض على عقد مؤسسي. إنه يحتاج إلى وسيلة لاكتشاف السعر ودفعه ثم المضي قُدمًا — كل ذلك داخل دورة طلب واستجابة واحدة. وهذا تحديدًا ما يقدّمه x402.

لماذا تفشل المدفوعات التقليدية مع الوكلاء

تأمّل كيف يستدعي الكود الذي تكتبه واجهة API مدفوعة اليوم. لقد سجّل أحدهم حسابًا، وأنشأ مفتاح API، وأرفق بطاقة ائتمان، وضبط اشتراكًا شهريًا. كل خطوة من هذه الخطوات تفترض أن إنسانًا قام بالإعداد مسبقًا.

تخيّل الآن وكيلًا مستقلًا يحتاج إلى استدعاء أربعين واجهة API لم يرها من قبل لإنجاز مهمة بحثية. إنّ تسجيل الحسابات والمفاتيح لها جميعًا مسبقًا أمر مستحيل. يحتاج الوكيل إلى مدفوعات لحظية: يكتشف خدمة، ويدفع بضع سنتات مقابل ما يستهلكه بالضبط، دون أن يُنشئ علاقة دائمة. فالاشتراكات ومفاتيح API هي التجريد الخاطئ للآلات.

يعيد x402 صياغة الدفع بوصفه خاصية من خصائص طلب HTTP نفسه، لا نظام فوترة منفصلًا مُلحقًا من الجانب.

كيف تعمل دورة x402

الآلية أنيقة لأنها تعيد استخدام نمط الطلب والاستجابة الذي يعرفه كل مطوّر. وإليك الدورة كاملة:

يطلب العميل (وكيل أو تطبيق) موردًا محميًا.
يردّ الخادم بالحالة 402 Payment Required مع ترويسة PAYMENT-REQUIRED تصف الشبكات والرموز المقبولة والسعر.
يختار العميل أحد متطلبات الدفع ويبني حمولة دفع موقّعة.
يعيد العميل الطلب، مرفقًا هذه المرة ترويسة PAYMENT-SIGNATURE.
يتحقق الخادم من الدفع، إمّا محليًا أو عبر مُيسّر.
عند النجاح، يعيد الخادم الحالة 200 OK مع المورد وترويسة PAYMENT-RESPONSE تؤكّد التسوية.

تستغرق الدورة بأكملها ثوانٍ وتُسوّى على السلسلة. لا تسجيل دخول، ولا بطاقة محفوظة، ولا علاقة سابقة بين المشتري والبائع. ويُبلَّغ السعر في الاستجابة نفسها التي ترفض الطلب غير المدفوع، فيستطيع الوكيل قراءته واتخاذ القرار والدفع باستقلالية.

المُيسّر: البلوكشين بلا صداع

الجزء الذي يخيف معظم مطوّري الواجهة الخلفية هو عبارة "تُسوّى على السلسلة". لا أحد يريد تشغيل عُقد RPC، أو إدارة الغاز، أو تتبّع تأكيدات الكتل لمجرد تحصيل عُشر سنت. وهنا يأتي دور المُيسّر.

المُيسّر خدمة تتولّى مهمتين عبر نقاط نهاية بسيطة: تتحقق /verify من أن حمولة الدفع صالحة، وتقدّم /settle المعاملة إلى البلوكشين وتنتظر التأكيد. أما خادمك فيُجري مكالمتي HTTP فقط. وتشغّل منصة Coinbase للمطوّرين مُيسّرًا مُستضافًا يعالج المدفوعات على شبكات Base وPolygon وArbitrum وWorld وSolana، مع طبقة مجانية تبلغ 1000 معاملة شهريًا ورسم يقارب عُشر السنت لكل معاملة بعد ذلك.

بعبارة أخرى، لا يلمس تطبيقك أبدًا مفتاحًا خاصًا أو نقطة نهاية RPC. إنه يتحدث بلغة HTTP العادية إلى المُيسّر، والمُيسّر يتحدث بلغة البلوكشين.

البيع: تحويل نقطة نهاية إلى جدار دفع

في جانب الخادم، يأتي x402 على هيئة وسيط برمجي (middleware) لأطر العمل التي يستخدمها المطوّرون أصلًا — Express وNext.js وHono لعمّال Cloudflare وFastAPI للغة بايثون، إضافة إلى حِزم Go وRust. وإليك شكل التكامل مع Express:

import { paymentMiddleware } from "@x402/express";
 
app.use(
  paymentMiddleware({
    "GET /weather": {
      accepts: [
        {
          scheme: "exact",
          price: "$0.01",
          network: "eip155:8453", // Base mainnet, CAIP-2 format
          payTo: "0xYourWalletAddress",
        },
      ],
      description: "Real-time weather data",
      mimeType: "application/json",
    },
  }),
);

هذه الكتلة الواحدة تحوّل GET /weather إلى نقطة نهاية محميّة بجدار دفع بسعر سنت واحد لكل استدعاء. تتلقّى الطلبات غير المدفوعة تلقائيًا حالة 402 مع شروط الدفع؛ بينما تمرّ الطلبات المدفوعة إلى مُعالجك المعتاد. ويعني scheme: "exact" مبلغًا ثابتًا لكل استدعاء — كما يعرّف البروتوكول مخطط upto للتسعير القائم على الاستخدام.

الشراء: السماح للوكيل بالدفع تلقائيًا

في جانب العميل، يغلّف مسار المشتري واجهة fetch القياسية بحيث يصبح الدفع غير مرئي. يُجري الوكيل طلبًا عاديًا؛ فإذا اصطدم بالحالة 402، يقرأ الغلاف المتطلبات، ويوقّع دفعة من محفظة مُهيّأة، ثم يعيد الطلب — كل ذلك دون أن يتفرّع كودك إلى منطق الدفع:

import { wrapFetchWithPayment } from "@x402/fetch";
import { createSigner } from "@x402/evm";
 
const signer = createSigner(privateKey);
const fetchWithPay = wrapFetchWithPayment(fetch, signer);
 
// الوكيل يكتفي بإجراء fetch. يحدث الدفع تلقائيًا عند 402.
const res = await fetchWithPay("https://api.example.com/weather");
const data = await res.json();

هذا هو التفصيل الذي يجعل x402 يبدو متجانسًا مع الوكلاء: الدفع ليس سير عمل منفصلًا، بل هو مجرد إعادة محاولة. فاستدعاء أداة من نموذج لغوي اصطدم بجدار دفع يمكنه تسويته ومواصلة الاستدلال، تمامًا كما يتبع المتصفّح إعادة توجيه بصمت.

العملات المستقرة بوصفها طبقة التسوية

يُسوّي x402 بالعملات المستقرة، وعملة USDC هي الخيار المهيمن في المنظومة مع دعم EURC أيضًا. ويستخدم البروتوكول معيار EIP-3009 للتفويض بلا غاز على USDC وEURC، أي أن الدافع يوقّع تفويضًا بدلًا من بثّ المعاملة ودفع الغاز بنفسه. ويعمل أي رمز ERC-20 عبر Permit2، كما تُدعَم رموز SPL على Solana.

تكتسب العملات المستقرة أهميتها هنا لسبب عملي: يتعامل الوكلاء بمبالغ ضئيلة، غالبًا أجزاء من السنت، عبر الحدود وبسرعة الآلة. فشبكات البطاقات والتحويلات المصرفية لا تستطيع اقتصاديًا تسوية دفعة بسنت واحد، وأوقات تسويتها تُقاس بالأيام. أما المدفوعة الصغيرة بالعملة المستقرة فتُسوّى خلال ثوانٍ برسم بروتوكول يكاد يكون صفرًا، وهو النموذج الوحيد الذي يجعل التسعير لكل طلب قابلًا للتطبيق.

ما الذي يفتحه هذا أمام منطقة الشرق الأوسط وشمال أفريقيا

بالنسبة للمطوّرين والشركات في منطقة الشرق الأوسط وشمال أفريقيا، يتجاوز x402 كونه فضولًا متعلقًا بالعملات المشفّرة. فهو يتخطّى عقبتين راسختين دفعة واحدة. أولًا، يصعب على كثير من مطوّري المنطقة إعداد مدفوعات البطاقات عبر الحدود وحسابات التجار للبيع لجمهور عالمي؛ بينما تقبل نقطة نهاية x402 الدفع من أي مكان منذ اليوم الأول. ثانيًا، يتيح لمزوّدي البرمجيات والبيانات المحليين تحقيق دخل من واجهات API بوحدات دقيقة تُدفع لكل استدعاء — فخدمة طقس تونسية، أو نقطة نهاية لمعالجة اللغة العربية، أو موجز بيانات سوق سعودي، يمكنها أن تحصّل من الوكلاء مباشرة دون بناء قسم فوترة.

ومع بدء الوكلاء المستقلين في أداء عمل اقتصادي حقيقي — حجزًا وبحثًا وشراءً واستدعاءً للأدوات نيابةً عنك — سيحتاجون إلى الدفع مقابل ما يستهلكونه. والبروتوكول الذي يتيح لهم ذلك بسلاسة يتشكّل ليكون x402، تمامًا كما أصبح MCP معيارًا لكيفية استدعاء الوكلاء للأدوات. وإذا كنت تبني واجهات API، فالأمر يستحق نظرة جادة الآن، بينما المعيار في بداياته والتكامل لا يتعدّى بضعة أسطر من الوسيط البرمجي.

كيف تبدأ

أسرع مسار هو تثبيت حزمة SDK المناسبة لإطار عملك وتوجيهها إلى المُيسّر المُستضاف من Coinbase لتتخطّى بنية البلوكشين بالكامل. أنشئ نقطة نهاية مدفوعة واحدة، واختبرها بعميل fetch المُغلَّف على شبكة اختبار مثل Base Sepolia، ثم انتقل إلى الشبكة الرئيسية بمجرد نجاح المسار من طرف إلى طرف. تغطّي الطبقة المجانية أول ألف معاملة لك، وهو ما يكفي ويزيد للتحقّق ممّا إذا كان التسعير لكل استدعاء يناسب منتجك.

أخيرًا، أصبح للويب إجابة أصيلة عن "الدفع مطلوب". وفي اقتصاد الوكلاء، تلك الإجابة هي x402.

هل تبني واجهات API أو وكلاء ذكاء اصطناعي وتريد تحقيق الدخل منها أو استهلاكها بمدفوعات أصيلة للآلات؟ تساعد نقطة الفِرَق في تونس ومنطقة الشرق الأوسط وشمال أفريقيا على تصميم بُنى جاهزة للذكاء الاصطناعي وتكاملات دفع حديثة.