AP2 — תשלומים והרשאות כספיות בין סוכנים

מאת צוות מדיה דיל · 12.08.2026 · Agentic Commerce · 5 דק׳

מדריך טכני ל-AP2: איך מנדטים חתומים קריפטוגרפית מאפשרים לסוכני AI לשלם בשם משתמשים בביטחון, ואיך זה שונה מתשלום כרטיס אשראי רגיל.

מנהל כספים ב-CFO office שומע לראשונה על סוכן AI שמבצע רכישות בשם עובד, ושואל שאלה אחת פשוטה: "אז מה קורה כשמישהו יגיד שהוא לא אישר את זה?" זו בדיוק השאלה שפרוטוקול AP2 (Agent Payments Protocol), שגוגל הובילה בשיתוף עם מאסטרקארד, פייפאל, קוינבייס ועשרות שחקנים נוספים בענף הפיננסי, בא לענות עליה. AP2 לא מנסה לפתור "איך סוכן משלם" ברמה הטכנית הפשוטה — זה כבר פתור באמצעות כרטיס אשראי שמור או ארנק דיגיטלי. הוא פותר בעיה קשה בהרבה: איך יוצרים שרשרת הוכחה בלתי ניתנת להכחשה, שמראה בדיוק מה המשתמש אישר, מתי, ובאילו גבולות — עוד לפני שהתשלום בכלל יצא לדרך.

מנדטים: הרעיון המרכזי מאחורי AP2

הבסיס הרעיוני של AP2 הוא ה-Mandate — אישור חתום קריפטוגרפית שהמשתמש נותן לסוכן, ושמתעד במפורש את גבולות הפעולה המותרת. יש שני סוגים עיקריים: Intent Mandate, שמתעד את הכוונה הכללית ("תמצא לי טיסה לברלין בשבוע הבא, עד 1200 שקל"), ו-Cart Mandate, שמתעד את האישור הספציפי לעסקה בפועל אחרי שהסוכן כבר מצא הצעה קונקרטית ("טיסת אל-על, 1,150 שקל, יציאה ביום שלישי"). ההפרדה הזו קריטית כי היא משקפת את המרחק הזמני והלוגי בין "מה רציתי" ל"מה בפועל נקנה" — בדיוק הפער שבו רוב המחלוקות בתשלומים מתרחשות. במאמר הרחב יותר על מנדטים ואימות כוונה נכנסים לעומק המנגנון הזה ולאיך בונים אותו נכון.

איך זה שונה מתשלום כרטיס אשראי רגיל

בעולם התשלומים המסורתי, ההוכחה לכך שעסקה אושרה היא בעיקרה עקיפה: הקלדת CVV, קוד SMS, או Touch ID על מכשיר. כל אלה מוכיחים "מישהו עם גישה למכשיר אישר" אבל לא מוכיחים בדיוק *מה* הוא אישר ובאילו תנאים. ב-AP2, כל Mandate נושא תוכן מובנה וחתום — לא רק "כן", אלא "כן, לרכישה הזו בדיוק, עד לסכום הזה, בחלון הזמן הזה". זה משנה מהותית את מודל הסיכון עבור ספקי סליקה ועסקים: חנות שמקבלת עסקה מגובה Cart Mandate תקף יכולה להראות בבירור לחברת האשראי בדיוק מה אושר, מה שמפחית משמעותית charge-backs מוצדקים-לכאורה. עבור עסקים שכבר בנו תשתית סליקה מורכבת, ראו מדריך אינטגרציית שערי תשלום — התוספת הנדרשת היא שכבת אימות מנדטים לפני העברת הבקשה לשער התשלום עצמו, לא שינוי בשער התשלום.

Human Present מול Human Not Present

AP2 מבחין בין שני מצבי הפעלה שונים מהותית. במצב Human Present, המשתמש נמצא בזמן אמת ומאשר את הרכישה הסופית לפני שהיא יוצאת לדרך — הסוכן עושה את כל העבודה של חיפוש והשוואה, אבל לחיצת האישור האחרונה עדיין אנושית. במצב Human Not Present, הסוכן פועל באופן עצמאי לגמרי בתוך הגבולות שהוגדרו מראש ב-Intent Mandate, בלי אישור נקודתי לכל עסקה — למשל "תחדש את מנוי התוכנה הזה כל חודש כל עוד המחיר לא עולה מעל X". המצב השני הוא המסוכן והשימושי יותר בו-זמנית, ולכן הוא זה שדורש את התשתית הקריפטוגרפית המלאה של המנדטים: בלי הוכחה חתומה מראש, שום ספק תשלום שפוי לא יאשר עסקאות חוזרות בלי נוכחות אנושית.

הקשר ל-x402 ותשלומי סוכן-לסוכן

AP2 מתחבר גם לעולם מתפתח נוסף: תשלומים ישירים בין סוכנים, בלי בן אדם בשום שלב, למשל כשסוכן רכש קורא ל-API בתשלום של סוכן שני כדי לקבל נתון או שירות. פרוטוקולים כמו x402 (מבוססי סטייבלקוין, שמאפשרים לשרת להחזיר קוד תשובה 402 "Payment Required" עם הוראות תשלום מיידיות) מתלבשים טבעית על גבי מודל המנדטים של AP2. עבור עסקים שכבר בנו מודל חיוב לפי שימוש בפועל, המתואר ב-מדריך חיוב מבוסס שימוש, זה בעצם אותו רעיון — תשלום זעיר ומדויק לפי צריכה — רק שהצד המשלם הוא קוד ולא כרטיס אשראי אנושי, ותדירות העסקאות יכולה להגיע לאלפי מיקרו-תשלומים ביום במקום חיוב חודשי בודד.

מה זה דורש מצוות ההנדסה

הטמעת AP2 בפועל דורשת שלושה רכיבים חדשים בארכיטקטורה: מנגנון להנפקת וניהול מנדטים (כולל תפוגה ואפשרות ביטול מיידי על ידי המשתמש), שכבת אימות שמאמתת חתימה לפני כל עסקה, ולוג בלתי ניתן לשינוי (append-only) של כל מנדט שהונפק ושומש, לצורכי ביקורת עתידית. הטעות הנפוצה ביותר היא לטפל במנדט כמו טוקן OAuth רגיל — משהו ששומרים בבסיס נתונים ובודקים תוקף. מנדט הוא בעצם מסמך משפטי-קריפטוגרפי, וצריך להתייחס אליו כך: כל שינוי בתנאים דורש מנדט חדש, לא עדכון של הישן, וכל מחלוקת עתידית תיפתר לפי מה שהמנדט המקורי בפועל אמר, לא לפי מה שהצוות זוכר שהתכוון.

{
  "mandate_type": "cart_mandate",
  "user_id": "usr_88231",
  "agent_id": "assistant.example.ai",
  "items": [{"sku": "flight_TLV_BER_0912", "price": 115000, "currency": "ILS"}],
  "expires_at": "2026-08-13T10:00:00Z",
  "signature": "ed25519:8f2a...c91"
}

שדה ה-expires_at לא סתם פרט טכני — הוא ליבת מנגנון ההגנה מפני שימוש לרעה במנדט ישן. מנדט שלא פג תוקף לעולם הוא סיכון פתוח: אם מפתח המפתח הפרטי של הסוכן דלף, כל מנדט שעדיין בתוקף הופך לכרטיס פתוח לביצוע עסקאות. המלצה מעשית היא לקבוע ברירת מחדל שמרנית לתוקף — דקות עד שעות עבור Cart Mandate בודד, ולא יותר מחודש עבור Intent Mandate מתמשך — ולתת למשתמש ממשק ברור לביטול מיידי של כל מנדט פעיל, בדיוק כפי שנותנים היום ממשק לביטול הרשאות אפליקציה מחוברת.

מה זה אומר עבור עסקי B2B ומנויים

לעסקים שמוכרים מנויים או שירותים חוזרים, AP2 פותח אפשרות חדשה: לתת לסוכן רכש של הלקוח (ראו מדריך רכש אוטונומי) לנהל את מחזור החיים של המנוי באופן עצמאי — לחדש, לשדרג, ואפילו לבטל אם התנאים משתנים לרעה, הכל בגבולות שהוגדרו מראש בארגון הלקוח. זה הופך את יחסי הספק-לקוח לדינמיים הרבה יותר: במקום חוזה שנתי קשיח, המנדט יכול לכלול תנאים מותנים ("חדש אוטומטית כל עוד המחיר לא עולה מעל 8% משנה שעברה, אחרת החזר לאישור אנושי"). עסקים שכבר מנהלים מודלים גמישים של חיוב, כמתואר ב-מדריך חיוב מבוסס מנוי, צריכים להתחיל לחשוב על תמיכה במנדטים כתכונת מוצר לכל דבר, לא רק כדרישה טכנית מהצד השני. ספק שיציע ממשק מנדטים ברור וגמיש ימצא את עצמו נבחר באופן שיטתי על ידי סוכני רכש ארגוניים על פני מתחרה שדורש עדיין שיחת טלפון וחתימת PDF לכל שינוי תנאים — לא כי המוצר טוב יותר, אלא כי הוא היחיד שהמכונה בכלל יכולה לתפעל בלי מגע יד אדם.

סיכום

AP2 לא בא להחליף את תשתיות התשלום הקיימות אלא להוסיף להן שכבת הוכחת כוונה שהייתה חסרה כל עוד רק בני אדם ביצעו רכישות. עבור עסקים, הבחירה איננה אם להתעלם מהמגמה — כי ברגע שסוכני רכש צרכניים וארגוניים יתחילו לדרוש תמיכה במנדטים כתנאי סף, ספקים בלי תמיכה כזו פשוט ייפלו מרשימת האפשרויות. הצעד המעשי הראשון הוא למפות אילו סוגי עסקאות אצלכם מתאימות למצב Human Not Present בתוך גבולות ברורים, ולתכנן משם את שכבת המנדטים בהדרגה, ולא לנסות לבנות הכל בבת אחת.

תגיות: AP2 · Agent Payments Protocol · Mandates · Agentic Commerce · Payments · x402

← חזרה לבלוג · צור קשר