سولانا وغوغل كلاود تطلقان pay.sh لتمكين وكلاء الذكاء الاصطناعي من دفع تكاليف واجهات برمجة التطبيقات

pay.sh مكرسة لسد الفجوة بين الوكلاء الذكاء الاصطناعي وواجهات برمجة التطبيقات المدفوعة.

كتابة: كارين ز، فورسايت نيوز

غالبًا ما يتعثر وكيل يمكنه كتابة الكود، والبحث عن المعلومات، واستخدام الأدوات بنفسه، في أبسط خطوة: الدفع.

ما يرغب pay.sh في تفكيكه هو هذا الجدار. في 5 مايو، أطلقت مؤسسة سولانا بالشراكة مع Google Cloud منتج pay.sh. هذه المنتجات لا تهدف إلى إنشاء محفظة موجهة للمستهلكين، ولا تسعى لإعادة ابتكار زر دفع. بل تستهدف احتياجات أكثر تحديدًا: عندما يحتاج وكيل إلى استدعاء واجهة برمجة تطبيقات الدفع، لا حاجة للتسجيل اليدوي أو استخدام مفاتيح API، بل يمكن الدفع حسب الاستخدام مباشرةً للحصول على حق الاستدعاء.

ببساطة، يهدف pay.sh إلى تقسيم عملية "استدعاء واجهة برمجة التطبيقات" إلى فعل أكثر صداقة للآلة: رؤية السعر، وإرسال طلب، وتأييد الدفع، والحصول على النتيجة.

وفقًا لمعلومات موقع Solana Foundation و pay.sh، فقد شمل النطاق الأولي تكاملًا مع بعض واجهات برمجة تطبيقات Google Cloud، بما في ذلك Gemini و BigQuery و Vertex AI و BigTable و Cloud Run، بالإضافة إلى أكثر من 50 ميسّرًا لواجهات برمجة التطبيقات من المجتمع يقدمون خدمات في مجالات التجارة الإلكترونية والبيانات والاتصالات والبنية التحتية على السلسلة.

من الوصف الرسمي، فإن pay.sh هو طبقة وسيطة للدفع والتنسيق لاستدعاء واجهات برمجة التطبيقات المدفوعة. إنها تغلف أدوات سطر الأوامر وسير العمل الوسيط المعروفة للمطورين، وعندما تُرجع واجهة برمجة التطبيقات الهدف تحديًا من نوع "ادفع أولاً ثم احصل على البيانات"، فإن pay تكتشف بروتوكول الدفع، وتُعد شهادة الدفع، وتطلب التفويض من المحفظة محليًا، ثم تعيد المحاولة بعد إتمام الدفع. بالنسبة للمطورين، فإن طلب curl الذي كان يُظهر خطأً يصبح الآن متبوعًا فقط بـ pay؛ أما بالنسبة للوسيط، فيتلقى مسار أداة يمكنه استخدامه مباشرة للاستفادة من قدرات الدفع.

هناك عدة نقاط مهمة بشكل خاص.

• ما بروتوكول الدفع المستخدم؟ تعتمد pay.sh تقنيًا على معيار الدفع الآلي المفتوح. وتشير الوثائق الرسمية بوضوح إلى أن pay.sh مبنية على بروتوكولي الدفع x402 وMPP.
• طريقة الدفع: تعتمد الدفعات والتسويات الأساسية لـ pay.sh على العملات المستقرة على شبكة Solana. ذكرت مؤسسة Solana أن المستخدمين يمكنهم إجراء إيداعات عبر بطاقة الائتمان أو العملات المستقرة في غضون حوالي 60 ثانية.
• التوقيع: pay.sh لا يسمح للوكيل بالوصول المباشر إلى المفتاح الخاص "مكشوفًا". وفقًا للموقع الرسمي وملف README على GitHub، فإن عملية التفويض المحلية تستخدم قدرات الأمان على مستوى النظام، مثل Keychain وTouch ID على macOS، وWindows Hello، وGNOME Keyring، أو 1Password. بمعنى آخر، يمكن أن يتم تشغيل المطالبات من قبل الوكيل تلقائيًا، لكن عند التوقيع النهائي والموافقة، لا يزال هناك عنصر تحكم مُدار على المستوى الأساسي. هذا التصميم يشبه إعطاء وكيل الذكاء الاصطناعي بطاقة دفع "بحد أقصى مُتحكم فيه وحركات قابلة للمراقبة"، وليس إعطاءه مفتاح خزنة الشركة.

غالبًا ما تكون صفحة قائمة الشركاء هي الأكثر تجاهلًا عند إصدار أي مشروع بنية تحتية.

شركاء البدء ل نقطة النهاية المصدرية لمجتمع pay.sh هم: PayAI و Crossmint و Merit Systems و Corbits و MoonPay و Sponge Wallet و ATXP و Tektonic Company.

تُكمل MoonPay و Crossmint مدخلات التمويل وبنية تحتية المحافظ. تحل الأولى مشكلة التحويل بين العملات الورقية والعملات المستقرة، بينما توفر الثانية محافظًا وعملات مستقرة وتكامل دفع على مستوى المؤسسات. بدون هذه الطبقة، يظل الدفع بالوكيل محصورًا في دائرة صغيرة من المستخدمين الأصليين على السلسلة.

تُعد Sponge Wallet أقرب إلى دور محفظة الوكيل وبوابة الدفع، حيث تُغلف واجهات برمجة التطبيقات الخارجية كواجهات قابلة للدعوة مباشرة وتدفع حسب الاستخدام؛ بينما تركز ATXP على طبقة بروتوكول التداول بالوكالة، والتي تشمل هوية الوكيل، والتعاون في المهام، وتدفق المدفوعات.

بالنسبة لـ Merit Systems و Corbits و PayAI و Tektonic Company، فهي ليست مجرد إضافات دفع، بل更像是 مزودي خدمة وطبقات تجميع للإقتصاد الوكالي، وتساعد مزودي الخدمة على ربط واجهات برمجة التطبيقات والبيانات وقدرات الدفع ضمن هذا النظام. وقد قدمت Merit Systems بالفعل أنواعًا متعددة من واجهات برمجة التطبيقات المتعلقة بالبيانات والوسائط والاتصالات والتحميل، المقومة بعملات مستقرة، في دليل pay.sh.

بعبارة أخرى، لا تهدف pay.sh فقط إلى حل "كيفية الدفع"، بل تسعى إلى ربط سلسلة كاملة من العمليات: "كيف يكتشف الوكلاء الخدمة، وكيف يحصلون على العروض، وكيف يكملون التفويض، وكيف يُ结算ون فورًا"، وهي تعمل كطبقة تنسيق تجمع القدرات الموجودة مسبقًا ولكن الموزعة بين ميسرين وخدمات مختلفة داخل دليل موحد، وتقدم للوكلاء والمطورين نقطة دخول موحدة.

إذا كان Google Cloud يقدم مدخلات API على مستوى المؤسسات ودعم البنية التحتية، فإن شركاء المجتمع يقدمون العمق والعرض الطويل.

في المستقبل، قد يكون المستهلك عبارة عن طبقات متعددة من وكلاء ينفذون المهام نيابة عن البشر. طالما حدث هذا التحول حقًا، سيتعين تغيير طريقة فواتير سوق واجهات برمجة التطبيقات ومنطق توزيعها.