فرق الهندسة في Stripe و Tempo بيقدموا open protocol جديد علشان الـ Agents تقدر تشتري ساندوتشات فول وطعمية بطريقة سهلة وبدون تدخل بشري. فيا ترى ايه اللي هيحصل لما الـ Agents يبدأ يبقى معاهم محفافظ ؟ وهل يا ترى هنوصل لمرحلة إن ممكن الـ Agents تشتري الحاجات اللي احنا عاوزينها بسهولة وبدون تدخل بشري فعلًا؟
تخيّل إنك مدي الـ coding agent عندك task: "حلّل الـ logs، ولو محتاج dataset مدفوعة اشتريها، وشغّل الـ browser session، واستخدم أفضل model للمهمة دي، وابعتلي النتيجة لما تخلص".
الطبيعي واللي بنشوفه هو إن الـ agent عارف يخطط، وعارف يستدعي الـ APIs، ويستخدم كمان الـ tools، ولكن أول ما بيقابل خدمة مدفوعة، كل ده بيقف: فانت محتاج تعمل account، تختار plan، تدخل card، تعدّي الـ 3DS، وتنسخ الـ API key.
دي مش مشكلة intelligence؛ ولكن دي مشكلة إن الـ payment infrastructure اتبنت للبشر.
في مارس 2026، Stripe وTempo قدّموا Machine Payments Protocol — MPP: open protocol يخلي أي client آلي يطلب resource، يعرف سعره، يقدّم payment credential، وياخد النتيجة والـ receipt جوه نفس HTTP flow.
الفكرة شكلها صغيرة: HTTP 402 Payment Required بدل pricing page. لكن لو نجحت، هي ممكن تغيّر شكل الـ APIs، الـ SaaS، والـ internet economy نفسها.
الخلاصة قبل الدخول في التفاصيل
الـ MPP مش wallet، ومش blockchain، ومش payment processor جديد، ولكن هو لغة تفاوض موحّدة بين machine عايزة تشتري وservice عايزة تبيع.
الـ flow الأساسي:
الـ agent يطلب resource أو ينادي tool.
الـ service ترد بـ 402 ومعاها Challenge: السعر، العملة، والـ payment methods المقبولة.
الـ agent يطبّق spending policy، وممكن يطلب human approval.
الـ agent يبعت Credential تثبت إنه authorizes الدفع.
الـ service تتحقق وتعمل settlement على rail مناسب.
الـ service ترجع الـ resource ومعاه Receipt.
أهم نقطة: الـ protocol منفصلة عن طريقة تحريك الفلوس .. فنفس الـ handshake ممكن يشتغل فوق stablecoins، أو cards وLink عن طريق Shared Payment Tokens — SPTs، ومع methods تانية مستقبلًا.
MPP Protocol
المشكلة اللي MPP بتحاول تحلها فعلًا
الـ agent النهارده يقدر يكتشف tool عن طريق MCP، يفهم الـ schema، ويبعت request صح، ولكن الـ discovery والـ execution مش للدفع. والـ billing التقليدي بيفترض إن فيه إنسان هيعمل onboarding مرة واحدة:
يفتح account.
يوافق على Terms.
يختار subscription tier.
يدخل payment method.
يستلم API key.
يراقب invoice آخر الشهر.
ده منطقي لو كان المشتري شركة أو developer. لكنه سيئ جدًا لو المشتري عبارة عن short-lived agent اتخلق علشان task واحدة، ومحتاج يشتري 3 API calls من 3 vendors مختلفين في خمس دقايق.
المشكلة مش بس friction .. ولكن فيه كمان mismatch في التكلفة:
الـ service ممكن تكون عايزة تبيع request واحدة بـ $0.01 بدل monthly subscription.
الـ agent محتاج يقارن السعر بالـ expected value لحظيًا.
الـ merchant مش عايز يفتح credit لكل agent مجهول ويستنى invoice.
صاحب الـ agent محتاج limits وaudit trail، مش blank cheque.
وهنا الـ MPP بتقرب الدفع من الـ request نفسه، فالسعر ما يبقاش صفحة يقراها إنسان؛ يبقى machine-readable response. والدفع ما يبقاش workflow منفصلة؛ يبقى جزء من الـ protocol.
مصطلحات مهمة — Terminologies
أكتر جزء ممكن يكون مربك في المشهد ده كله هو كمية الـ acronyms:
يعني مثلًا: agent يكتشف restaurant tool عن طريق MCP، يبني order ويحدّث delivery address عن طريق ACP أو UCP، وبعدها يكمّل الدفع عن طريق MPP.
ACP تحديدًا اتعمل كـ open standard بين OpenAI وStripe لرحلات الـ programmatic commerce. الـ merchant يفضل merchant of record، ويفضل متحكم في المنتجات والـ fulfillment وعلاقة العميل. أما Stripe Agentic Commerce Suite فهي product layer بتقلل شغل الـ integration: hosted ACP endpoint، catalog syndication، checkout، payments، fraud tooling، وبعدها order events ترجع للـ merchant stack الموجود أصلًا.
