แผนที่โปรโตคอลการชำระเงินแบบเอเจนต์: ทำไมจึงมีมากมายกระจัดกระจาย

• เพื่อให้ AI agent สามารถดำเนินการซื้อ ชำระเงิน และเคลียร์ยอดได้ด้วยตนเอง จึงเกิดโปรโตคอลการชำระเงินหลายแบบขึ้นพร้อมกันแบบขนาน
• ACP, UCP, AP2, x402 เป็นต้น ต่างก็เกี่ยวข้องกับการชำระเงิน แต่ มุ่งแก้ปัญหาคนละด้าน เช่น คอมเมิร์ซ, B2B, การชำระเงินระหว่าง agent
• เดิมทีอินเทอร์เน็ตถูกออกแบบมาเพื่อ การส่งผ่านข้อมูล จึง ไม่มีชั้นการชำระเงิน อยู่ในตัว และแม้ HTTP status code 402 จะถูกนิยามไว้ตั้งแต่ปี 1997 ก็ไม่เคยถูกใช้งานจริง
• ในธุรกรรมของ agent นั้น ชั้นความน่าเชื่อถือเป็นเงื่อนไขล่วงหน้าก่อนการชำระเงิน โดยมีโปรโตคอลอย่าง ERC-8004 และ Visa TAP มารับบทนี้
• ในฝั่งคอมเมิร์ซ ACP ของ OpenAI·Stripe และ UCP ของ Google·Shopify กลายเป็นสองแกนหลัก และกำลังถูกใช้งานในสภาพแวดล้อมของ ChatGPT และ Gemini ตามลำดับ
• การชำระเงินระหว่าง agent เปิดทางให้เกิด ไมโครเพย์เมนต์ขนาดใหญ่ สำหรับการใช้คอมพิวต์ ข้อมูล และ API พร้อมส่งสัญญาณถึงโครงสร้างการซื้อขายทรัพยากรแบบอัตโนมัติ
• ในอนาคต เศรษฐกิจของ agent มีแนวโน้มจะพัฒนาไปเป็น โครงสร้างแบบสแตกที่โปรโตคอลต่างบทบาทเชื่อมประกอบกันเป็นชั้นๆ มากกว่าจะมีมาตรฐานเดียว

---

ฉากหลังของการแตกแขนงของโปรโตคอลการชำระเงินแบบเอเจนต์

• มีตัวย่อหลากหลายอย่าง เช่น ACP, UCP, A2P, AXTP, x402 ปรากฏขึ้น ทำให้พื้นที่การชำระเงินแบบเอเจนต์ดูสับสน
• เหตุผลที่โปรโตคอลมีจำนวนมากขึ้นคือ ไม่ได้กำลังแก้ปัญหาเดียวกันทั้งหมด
• คอมเมิร์ซ การชำระเงินแบบ B2B และการชำระเงินระหว่าง agent มีเงื่อนไขและข้อจำกัดที่ต่างกัน
• หากมองทั้งหมดเป็นปัญหาเดียว จะยิ่งทำให้เข้าใจโครงสร้างได้ยากขึ้น

โครงสร้างของโปรโตคอลอินเทอร์เน็ตและการไม่มีอยู่ของชั้นการชำระเงิน

• อินเทอร์เน็ตทำงานจากหลายโปรโตคอลร่วมกัน เช่น TCP/IP, DNS, HTTP/S จนเกิดประสบการณ์ใช้งานที่ลื่นไหลเป็นหนึ่งเดียว
  • TCP/IP: ดูแลการระบุที่อยู่ การกำหนดเส้นทาง และการส่งข้อมูลอย่างเชื่อถือได้
  • DNS: แปลงชื่อโดเมนที่มนุษย์อ่านได้ให้เป็น IP address
  • HTTP/S: ใช้สำหรับขอและส่งหน้าเว็บกับสื่อ โดย HTTPS เพิ่มความปลอดภัยผ่านการเข้ารหัส
• อินเทอร์เน็ตไม่ใช่โครงสร้างแบบหยุดนิ่ง แต่เป็น ระบบที่วิวัฒน์ต่อเนื่อง โดยมีโปรโตคอลใหม่อย่าง gRPC, WebSocket ถูกเพิ่มเข้ามาเรื่อยๆ
• HTTP status code 402(Payment Required) ถูกนิยามไว้ตั้งแต่ปี 1997 แต่ไม่เคยถูกใช้งานจริง
• ตั้งแต่แรก อินเทอร์เน็ตถูกออกแบบมาเพื่อ การส่งผ่านข้อมูล และการชำระเงินถูกเชื่อมเข้ามาภายหลังผ่านระบบการเงินภายนอก
  • คำขอที่เริ่มจากเบราว์เซอร์จะถูกส่งต่อไปยังผู้ขาย payment gateway และเครือข่ายการเงินอย่าง Visa·ACH ตามลำดับ
• จึง ไม่มีโปรโตคอลการชำระเงินแบบเดี่ยว ที่ครอบคลุมตั้งแต่ ‘หยิบใส่ตะกร้า’ ไปจนถึง ‘การเคลียร์ยอดการชำระ’ แบบครบวงจร

agent ทำให้เห็นช่องว่างของชั้นการชำระเงิน

• โครงสร้างพื้นฐานเดิมที่ออกแบบโดยมีคีย์บอร์ดและหน้าจอเป็นสมมติฐาน ไม่เหมาะกับ software agent ที่คิดและลงมือทำด้วยความเร็วระดับเครื่อง
• เมื่อ agent ทำการซื้อแทนมนุษย์ ปัญหาใหม่ก็ปรากฏขึ้น
  • ลูกค้าประเภทใหม่: agent ต้องตัดสินใจเองว่าจะเลือกร้านและสินค้าใด ขณะที่ผู้ขายต้องปรับให้เหมาะกับลูกค้าที่ไม่ใช่มนุษย์
    → เกิดแนวคิด Agent Engine Optimization(AEO)
  • ช่องทางการชำระเงินแบบใหม่: อินเทอร์เฟซแชตกลายเป็นช่องทางชำระเงินโดยตรง ทำให้ conversion funnel, A/B test, อีเมลเตือนตะกร้าค้างมีความหมายน้อยลง
  • ความเสี่ยงการฉ้อโกงแบบใหม่: ต้องตรวจสอบทันทีว่า agent ใช้งานโดยผู้ใช้ที่ได้รับอนุญาตและใช้วิธีชำระเงินที่ถูกต้องตามกฎหมายจริงหรือไม่ หรือกำลังนำ credential ที่ถูกขโมยมาใช้โดยอัตโนมัติหรือไม่

ชั้นความน่าเชื่อถือ: ตรวจสอบคู่ธุรกรรม

• แม้ MCP และ A2A จะดูแลการสื่อสารระหว่าง agent แต่ในสเปก ERC-8004 ระบุชัดว่า ไม่ได้จัดการเรื่องการค้นหา agent และความน่าเชื่อถือโดยเนื้อแท้
• ก่อนจะเกิดธุรกรรมระหว่าง agent ต้องมี การตรวจสอบความชอบธรรม ก่อน และผู้ขายต้องอนุญาตเฉพาะ agent ที่เชื่อถือได้ ไม่ใช่บอตที่ยิงเข้ามาแบบไม่จำกัด
• จึงมีสองแนวทางที่เกิดขึ้นเพื่อแก้ปัญหานี้
  • ERC-8004(Trustless Agents): รีจิสทรีบนเชนสำหรับตัวตน ชื่อเสียง และการตรวจสอบ ที่ MetaMask, Google, Coinbase, Ethereum Foundation มีส่วนร่วม และอยู่ในขั้น Draft EIP
    • ข้อมูลการลงทะเบียนของ agent สามารถระบุ MCP endpoint, A2A agent card, ชื่อ ENS, DID ฯลฯ ร่วมกันได้
    • ไม่ได้มาแทนโปรโตคอลการสื่อสารระหว่าง agent เดิม แต่เป็นโครงสร้างที่ช่วยเสริมข้อมูลด้านความน่าเชื่อถือและอัตลักษณ์
  • Visa Trusted Agent Protocol(TAP): โปรโตคอลที่ Visa กำลังพัฒนา เพื่อให้ผู้ขายแยกแยะ agent ที่เชื่อถือได้ออกจากบอตทั่วไปผ่านลายเซ็นที่ตรวจสอบได้
    • พิสูจน์ได้ว่าเป็น Visa trusted agent ที่มีวัตถุประสงค์ด้านคอมเมิร์ซ
    • ยืนยันได้ว่ากำลังทำงานแทนผู้บริโภคคนใดผ่านบัญชี loyalty หรือ device identifier
    • ผู้ขายสามารถตรวจสอบ credential การชำระเงินที่ใช้งานได้จริงร่วมกันได้
• ประเด็นสำคัญ: ความน่าเชื่อถือคือจุดเริ่มต้นของการชำระเงิน และคำถามว่า “จะจ่ายอย่างไร” ต้องมาหลังจาก “ไว้ใจ agent นี้ได้หรือไม่”

โปรโตคอลคอมเมิร์ซ: พื้นที่ที่ขยายตัวเร็วที่สุด

• Agentic commerce คือโครงสร้างที่มอบหมายช่วงเวลาการซื้อทั้งหมดให้ agent ตั้งแต่การค้นหาสินค้า การเลือก ไปจนถึงการชำระเงิน
• เพื่อทำให้สิ่งนี้เป็นมาตรฐาน จึงมีสองโปรโตคอลหลักที่เริ่มโดดเด่น
  • Agentic Commerce Protocol(ACP): โปรโตคอลที่ OpenAI และ Stripe พัฒนาร่วมกัน กำหนดวิธีสร้างตะกร้าสินค้าและสร้าง payment token เพื่อส่งต่อให้ PSP
    • ใช้งานจริงแล้วในสภาพแวดล้อม ChatGPT ร่วมกับ Walmart, Etsy, Instacart
    • เป็น มาตรฐานที่เน้นธุรกรรม ซึ่งกำหนดโครงสร้างตะกร้า การสร้าง payment token และขั้นตอนปิดการชำระเงินไว้อย่างชัดเจน
  • Universal Commerce Protocol(UCP): โปรโตคอลที่ Google และ Shopify เป็นแกนนำ โดยให้ผู้ขายตั้งค่าเซิร์ฟเวอร์ที่จะเปิดให้ agent เข้าถึงด้วยตนเอง
    • มีกำหนดทยอยใช้งานกับ Google Search และ Gemini
    • เป็น framework สำหรับ orchestration ที่ผู้ขายเผยแพร่ capability manifest แล้วให้ agent ค้นพบและเจรจาต่อรอง
    • ทำหน้าที่คล้าย DNS ในโลกคอมเมิร์ซ
• ความต่างเชิงโครงสร้าง: UCP มีภาระในการติดตั้งเริ่มต้นสูงกว่า แต่ให้ความยืดหยุ่นตลอดทั้งกระบวนการ ส่วน ACP เชื่อมกับระบบการชำระเงินเดิมได้ค่อนข้างง่ายกว่า
• หากต้องการให้ถูกพบทั้งใน ChatGPT และ Gemini ก็กลายเป็นสถานการณ์ที่ ต้องรองรับทั้ง ACP และ UCP พร้อมกัน

โปรโตคอลในระดับเครือข่ายการชำระเงิน

• Visa Intelligent Commerce(VIC): โปรโตคอลที่ Visa พัฒนา เพื่อให้ agent สามารถชำระเงินบนเครือข่าย Visa ได้โดยสร้าง security token แบบคล้ายบัตร
  • ปัจจุบันอยู่ในช่วงทดสอบ และมีกำหนดเปิดตัวในครึ่งหลังของปี 2026
• Mastercard Agent Pay(MAP): โปรโตคอลที่ Mastercard พัฒนา เพื่อสร้าง security token ที่ใช้งานได้บนเครือข่าย Mastercard
  • อยู่ในช่วงทดสอบ และมีกำหนดเปิดตัวในครึ่งหลังของปี 2026
• มาตรฐานทั้งสองมีโครงสร้างและจุดมุ่งหมายแทบเหมือนกัน โดยความแตกต่างสำคัญคือ แต่ละแบบทำงานได้เฉพาะบนเครือข่ายการชำระเงินของตนเอง
• token ที่ออกในระดับเครือข่ายช่วยให้การคุ้มครองผู้บริโภค การจัดการ chargeback และการรับมือการฉ้อโกง ยังคงดำเนินไปในรูปแบบเดียวกับการชำระเงินผ่านบัตรเดิม

ข้อกำหนดที่แตกต่างของโฟลว์การชำระเงินแบบ B2B

• แม้คอมเมิร์ซฝั่งผู้บริโภคจะได้รับความสนใจมากกว่า แต่ขนาดธุรกรรมจริงนั้น การชำระเงินแบบ B2B ใหญ่กว่ามาก
  • การจ่ายใบแจ้งหนี้ การจ่ายให้ซัพพลายเออร์ การจ่ายเงินเดือน ล้วนเป็นสัดส่วนหลักของการเคลียร์ยอดระหว่างธุรกิจ
• ลักษณะเฉพาะของโฟลว์การชำระเงิน B2B
  • จำนวนเงินสูง และย้อนกลับได้ยากหลังดำเนินการแล้ว
  • ต้องมีการควบคุมภายใน เช่น การจับคู่ใบแจ้งหนี้ ขั้นตอนการอนุมัติ และ audit trail
  • ใช้ rails อย่าง ACH หรือ wire transfer ที่แม้ช้ากว่าแต่ยืดหยุ่นเชิงโครงสร้างมากกว่า
• ในพื้นที่นี้ agent มัก สื่อสารกับ payment rails โดยตรง มากกว่าจะผ่านชั้นกลาง
• payment rails ที่ถูกใช้งาน
  • Stablecoin(USDC, USDT): ชำระเงินโดยตรงบนเชน และสามารถใส่กฎกับลอจิกลงไปในธุรกรรมได้
    • มีการใช้งานจริงแล้วในบริษัทอย่าง Catena Labs, Payman
  • Traditional rails(ACH, Wire): agent เตรียมข้อมูลการชำระเงินแล้วส่งผ่าน rails การเงินเดิม
• Stablecoin ให้ทั้งความมั่นใจในการสำเร็จของธุรกรรมใกล้เคียงการชำระเงินผ่านบัตรและความสามารถในการ programmable สูง แต่ ยังไม่มีมาตรฐานที่ชัดเจน ซึ่งถูกยอมรับร่วมกันทั้งอุตสาหกรรม

การชำระเงินระหว่าง agent: ศักยภาพสูงสุด

• ทรัพยากรที่มีมูลค่าบนอินเทอร์เน็ตส่วนใหญ่ ยังถูกล็อกไว้หลัง API key และโมเดล subscription
• วิธีเข้าถึงแบบเดิมคือต้องสร้างบัญชี เติมเงินล่วงหน้า และรับคีย์ก่อน จึงค่อยใช้บริการได้
• ในสภาพแวดล้อมที่มี agent หลายพันล้านตัวเขียนโค้ด ซื้อขายกันเอง และใช้ทรัพยากรตามเวลาที่ต้องการ โมเดลนี้ไม่สามารถขยายได้
• ปัจจุบันมีจุดเสียดทานหลักสองอย่าง
  • ปัญหาโทเคนหมด: หาก agent ชนเพดานระหว่างทำงาน มนุษย์ต้องมาเติมเองก่อน จึงจะทำงานต่อได้
  • ปัญหา API key: ทุกครั้งที่ agent ต้องการบริการใหม่ ผู้ใช้ต้องสมัครเอง สร้าง credential แล้วส่งต่อให้ด้วยตนเอง
• ด้วยข้อจำกัดเหล่านี้ agent จึงยังไม่มีอิสระเต็มที่ และยังอยู่ในสถานะคล้าย นักพัฒนาระดับจูเนียร์ที่ยังไม่ได้รับมอบ corporate card หรือ credential สำคัญ

โปรโตคอลแบบ agent-native

• Google Agent to Pay(AP2): เป็นส่วนหนึ่งของ framework A2A โดยกำหนดโครงสร้าง mandate สำหรับให้มนุษย์มอบสิทธิ์การชำระเงินแก่ agent
  • เป็น โปรโตคอลในชั้น abstraction ที่ถูกออกแบบให้ทำงานร่วมกับ x402 และ UCP ได้ จึงไม่ใช่ความสัมพันธ์แบบเลือกอย่างใดอย่างหนึ่ง
  • บนพื้นฐานของ credential ที่ตรวจสอบได้ จะแยก mandate ออกเป็น
    • cart mandate: ขอบเขตที่ agent สามารถซื้อได้
    • intent mandate: วัตถุประสงค์ที่มนุษย์ต้องการจริง
    • payment mandate: credential การชำระเงินที่บันทึกไว้
• HTTP x402: แนวทางที่ Coinbase และ Cloudflare พัฒนาขึ้น โดยจะส่งคืน HTTP 402 เมื่อมีการร้องขอทรัพยากรที่ถูกจำกัดการเข้าถึง และชักนำให้จ่ายด้วย stablecoin
  • กำลังทดสอบบนเครือข่าย Base และในสภาพแวดล้อม Cloudflare
• Agent Transaction Protocol(AXTP): โปรโตคอลที่ Circuit และ Chisel กำลังพัฒนา เพื่อให้ agent สามารถจ่ายค่าการใช้ MCP server หรือสร้างรายได้ตอบแทนจากมันได้
  • ยังอยู่ในระยะเริ่มต้น
• สิ่งนี้เปิดทางสู่ ไมโครเพย์เมนต์ขนาดใหญ่ที่แบ่งย่อยได้ทันที ตามหน่วยคอมพิวต์ ข้อมูล หรือการเรียก API และอาจสร้างปริมาณธุรกรรมใหม่มหาศาลในพื้นที่ที่ก่อนหน้านี้สร้างรายได้ได้ไม่ดี

โครงสร้างโปรโตคอลโดยรวมและแนวโน้ม

• ณ ตอนนี้ ระบบนิเวศการชำระเงินแบบเอเจนต์ยังอยู่ในสภาพ ปะปนและยังไม่เป็นระเบียบ
• สแตกที่มี Google เป็นศูนย์กลางกำลังก่อตัว: มีโครงสร้าง A2A → AP2 → UCP ปรากฏขึ้น ซึ่งครอบคลุมทั้งการชำระเงินด้านคอมเมิร์ซและนอกคอมเมิร์ซ
• แต่ละโปรโตคอลแบ่งบทบาทกันใน ชั้น abstraction ที่ต่างกัน
  • ชั้นการสื่อสารระหว่าง agent: ทำให้วิธีแลกเปลี่ยนข้อความระหว่าง agent เป็นมาตรฐาน (MCP, A2A)
  • ชั้นความน่าเชื่อถือ: ตัดสินตัวตนและความน่าเชื่อถือของ agent พร้อมจัดการ identity·reputation (ERC-8004, Visa TAP)
  • ชั้นการมอบอำนาจ: ตรวจสอบสิทธิ์การชำระเงินและการครอบครอง credential (AP2 mandates, VIC/MAP token)
  • ชั้นโฟลว์ธุรกรรม: จัดการการค้นพบ การเจรจา และ checkout ว่าจะซื้ออะไรและจ่ายอย่างไร (ACP, UCP)
  • ชั้นการยืนยันตัวตน: ตรวจสอบความชอบธรรมของธุรกรรม รักษาความปลอดภัย ป้องกันการฉ้อโกง และจัดการการยกเลิก
  • ชั้น payment rails: ลงมือชำระเงินจริง โดยใช้บัตร ACH หรือ stablecoin

ประเด็นสำคัญที่น่าจับตา

• มาตรฐานในปัจจุบันยังอยู่ใน ระยะก่อรูป ยังไม่สมบูรณ์ และมีการยอมรับในวงจำกัด
  • ในอนาคตก็อาจหายไปได้เหมือน WAP หรือ Betamax
• อย่างไรก็ดี ข้อสมมตินั้นตั้งอยู่บนฐานที่ว่า AI agent เองจะหายไป ซึ่งมีโอกาสต่ำ
• จุดที่ผู้ขาย ผู้ให้บริการชำระเงิน และสถาบันการเงินควรจับตา
  1. อิทธิพลของ Google: มีประวัติในการผลักดันมาตรฐานอินเทอร์เน็ตมาก่อน จึงมีโอกาสที่ A2A·AP2 และสแตกที่เกี่ยวข้องจะอยู่ได้ในระยะยาว
  2. กลยุทธ์คอมเมิร์ซมาก่อน: หากรองรับ ACP และ UCP ก็สามารถถูกพบได้ทั้งในสองสภาพแวดล้อม LLM ฝั่งผู้บริโภคหลักอย่าง ChatGPT และ Gemini
  3. ความสำคัญของโครงสร้างพื้นฐานด้านความน่าเชื่อถือ: ยิ่งทราฟฟิกของ agent เพิ่มขึ้น ปัญหาเรื่องตัวตนและชื่อเสียงก็ยิ่งซับซ้อนขึ้น และ ERC-8004 กับ Visa TAP ต่างก็พุ่งเป้ามาที่จุดนี้
  4. โอกาสใน B2B payments: เป็นพื้นที่ที่มูลค่าธุรกรรมสูงและมาตรฐานยังไม่ลงตัว แม้การยอมรับ stablecoin จะกำลังเดินหน้า แต่ยังไม่มีหลักเกณฑ์ที่ชัดเจน
  5. ศักยภาพของการชำระเงินแบบ agent-native: stablecoin ที่เร็ว ถูก ทำงานได้ตลอดเวลา และ programmable เป็นคำตอบที่มีน้ำหนักมาก โดย x402 เป็นจุดเริ่มต้น แต่ยังไม่ถึงขั้นสุกงอม
• สภาพแวดล้อมการชำระเงินแบบเอเจนต์ในระยะถัดไปมีแนวโน้มจะเกิดจาก การผสมกันของโปรโตคอลหลายแบบและการสืบทอดฟังก์ชันข้ามชั้น
• การเปลี่ยนผ่านไปสู่ซอฟต์แวร์ที่ค้นหาทรัพยากรเอง เจรจาเงื่อนไขเอง และจ่ายค่าตอบแทนเองนั้น ได้เริ่มต้นขึ้นแล้ว ไม่ว่ามาตรฐานใดจะเป็นผู้รอดสุดท้ายก็ตาม