Jan Curn แห่ง Apify เล่าประสบการณ์เชื่อมการจ่ายเงินเข้ากับเครื่องมือที่ AI agent เรียกใช้ ประเด็นของเขาไม่ได้อยู่แค่การส่งคำขอจ่าย แต่รวมถึงเวลาที่ถือว่าเงินเข้าแล้ว งานที่มีต้นทุน และการคิดราคาเมื่อการใช้ทรัพยากรยังไม่จบ
ในคลิปจากช่อง AI Engineer เขาใช้หัวข้อ “x402 isn’t good (yet)” วิจารณ์รอยต่อที่ทีมพบและเสนอแนวทางที่กำลังสำรวจ บทความนี้สรุปประสบการณ์และข้อโต้แย้งขณะนำเสนอ ไม่ได้ตัดสินว่า x402 ทุกรุ่นหรือทุกการติดตั้งยังใช้จริงไม่ได้ ณ วันเผยแพร่บทความนี้
เข้าใจก่อนว่า x402 แก้ปัญหาอะไร
Jan อธิบายลำดับที่ client ขอใช้ API แล้วได้รับ HTTP 402 Payment Required พร้อมข้อมูลการจ่าย ก่อนส่งการอนุมัติผ่าน wallet รายละเอียดในบทความนี้มาจาก flow ที่เขาวิจารณ์ ไม่ใช่การเพิ่มข้อกำหนดจาก protocol ฉบับที่ยังไม่ได้บันทึกมาตรวจ
ผู้พูดให้เหตุผลว่า agent ที่ทำงานยาวอาจต้องซื้อบริการภายนอก และจึงต้องมีทางจัดการงบและการจ่าย นี่เป็นสถานการณ์ที่เขาตั้งขึ้น ไม่ใช่หลักฐานว่า agent ทุกระบบต้องใช้ crypto หรือจ่ายเงินเองเพื่อทำงานได้
Jan แนะนำ Apify ว่าเป็นตลาดเครื่องมือที่เรียกว่า Actors ครอบคลุมข้อมูลจากเว็บไซต์ การค้นหา และงาน automation เขารายงานว่าทีมเชื่อม x402 เพื่อให้เครื่องมือเข้าถึงได้จาก agent แต่คลิปไม่ได้เป็นหลักฐานตรวจจำนวนรายการ ความพร้อมของทุกเครื่องมือ หรือยอดใช้งานจริงอย่างอิสระ
ตัวอย่างสมมติของ VibeSolo คือผู้ช่วยการตลาดที่ได้รับขอบเขตงานให้ซื้อข้อมูลราคาคู่แข่ง หรือผู้ช่วยจัดซื้อที่ขอข้อมูลผู้ขายก่อนเสนอขั้นตอนต่อไป ตัวอย่างนี้ไม่มีวงเงินหรือผลตอบแทนที่คลิปยืนยัน และไม่ได้หมายถึงเปิดสิทธิ์จ่ายจริงให้ AI โดยอัตโนมัติ
แต่คำว่า “จ่ายเอง” ต้องไม่ถูกตีความว่า “ปล่อยให้ใช้เงินได้อิสระ” ธุรกิจควรคิดถึง x402 เป็น รางชำระเงินสำหรับเครื่องจักร ไม่ใช่บัตรเครดิตที่มอบให้ AI ใช้ได้ทุกอย่าง
แยกความต่างระหว่าง AI เชื่อมเครื่องมือ กับ AI ที่ซื้อบริการได้
ช่วงต้น Jan เปรียบเทียบการเชื่อมเครื่องมือผ่าน MCP กับการเพิ่มเส้นทางจ่ายเงินให้เครื่องมือ ประเด็นที่ใช้ในบทความนี้คือการเรียกใช้บริการและการประมวลผลจ่ายเป็นคนละส่วนของ workflow ไม่ใช่การสรุปข้อกำหนด MCP หรือความพร้อมของ host ทุกราย
การเชื่อม tool ได้จึงไม่ได้ยืนยันเองว่าการซื้อบริการสำเร็จแล้ว ต้องดูว่ามีคำขอจ่าย มีการตรวจรายการ และมีการรับผลลัพธ์กลับอย่างไรตามเส้นทางที่ระบบเลือกใช้
ผู้พูดยกหลาย payment protocol จากหลายองค์กรเพื่ออธิบายภาระการติดตามและเชื่อมต่อ บทความนี้ไม่ใช้รายชื่อนั้นเป็นหลักฐานสถานะมาตรฐานหรือความพร้อมเปิดใช้ล่าสุดของแต่ละบริการ
ข้อคิดของ VibeSolo คือเริ่มจากลักษณะงานที่จะเชื่อม เช่น ต้นทุนคงที่หรือแปรผัน เริ่มงานเมื่อใด และรับผลเมื่อใด ก่อนเลือกรูปแบบ payment integration ชื่อ protocol เพียงอย่างเดียวตอบคำถามเหล่านี้ไม่ได้
เลือก use case ที่ต้นทุนต่อครั้งชัดเจนก่อน
Jan มองว่าค่าธรรมเนียมและขั้นตอนของระบบจ่ายเงินสำหรับคนอาจไม่เหมาะกับ request มูลค่าต่ำจำนวนมาก เขาจึงสนใจการจ่ายผ่าน crypto ในบริบทนี้ นี่เป็นเหตุผลเชิงการเชื่อมระบบของผู้พูด ไม่ใช่คำแนะนำลงทุนหรือข้อสรุปค่าธรรมเนียมปัจจุบันของทุกวิธีจ่าย
เขายังตั้งคำถามเรื่องตัวตนและความเชื่อใจเมื่อคู่ธุรกรรมเป็น agent บทความนี้คงคำถามด้านการออกแบบไว้ โดยไม่ได้สรุปสิทธิ์คืนเงิน ข้อพิพาท หรือคำรับรองว่าการใช้ crypto ตัดความเสี่ยงของผู้ขายออกทั้งหมด
หากใช้แนวคิดนี้เลือกงานทดสอบ ข้อเสนอสมมติของ VibeSolo คือกำหนดขอบเขตต่อไปนี้เพื่อให้ดูรอยต่อได้ชัด ไม่ใช่เกณฑ์ที่พิสูจน์แล้วว่าให้ผลทางธุรกิจดีกว่า
- ราคาต่อครั้งต่ำและกำหนดได้ชัด
- ผลลัพธ์ส่งมอบแบบดิจิทัลทันที เช่น รายงานหรือข้อมูล
- ความเสียหายจำกัด หากการจ่ายหรือการส่งมอบล้มเหลว
ตัวอย่างการออกแบบของ VibeSolo คือบริการข้อมูลหนึ่งชุด หรือผลคำนวณที่บอกเงื่อนไขได้ชัด ส่วนงานที่มีผลต่อระบบอื่นหรือมีค่าใช้จ่ายต่อเนื่องต้องระบุขั้นตอนและผู้รับผิดชอบเพิ่ม ตัวอย่างนี้ไม่ใช่บริการที่คลิปทดสอบครบแล้ว
แยกการตรวจลายเซ็นออกจากการ settle
ข้อวิพากษ์หลักของ Jan คือช่วงระหว่างตรวจลายเซ็นอนุมัติจ่ายกับการ settle สำเร็จ ใน flow ที่เขากำลังอธิบายมีลำดับดังนี้
- agent เรียก API ของผู้ให้บริการ
- เซิร์ฟเวอร์ตอบ HTTP 402 พร้อมเงื่อนไขการจ่าย
- agent ลงลายเซ็นเพื่ออนุมัติการจ่ายจาก wallet
- ผู้ให้บริการตรวจสอบลายเซ็นผ่าน facilitator
- ผู้ให้บริการทำงาน แล้วจึงส่งรายการไป settle บน blockchain
Jan ชี้ว่าใน flow ที่เขาประเมิน ก่อนส่งธุรกรรมไป settle ผู้ซื้ออาจสร้างคำขอหลายชุดจากเงินเดียวกันได้ หากผู้ให้บริการเริ่มงานที่มีต้นทุนก่อนรับผล settle ก็อาจทำงานไปแล้วแต่เก็บเงินไม่สำเร็จ นี่เป็นความเสี่ยงที่ผู้พูดอธิบาย ไม่ใช่ผลทดสอบการโจมตีหรือข้อสรุปว่าทุก implementation ปัจจุบันมีช่องโหว่เดียวกัน
ข้อคิดจาก VibeSolo คือสถานะ “ตรวจรายการผ่าน” กับ “settle สำเร็จ” ควรแยกชื่อและความหมายในแบบ workflow ให้ชัด แล้วระบุจุดที่งานซึ่งมีต้นทุนเริ่มทำ รายละเอียดนี้เป็นคำถามด้านระบบ ไม่ใช่คำรับรองทางการเงินหรือการตัดสินว่ารับเงินสมบูรณ์ตามข้อกำหนดของบริการใด
ผู้พูดเปรียบเทียบ API ที่แทบไม่มีต้นทุนส่วนเพิ่มกับงานที่ต้องจ่ายผู้ให้บริการภายนอกหรือใช้ทรัพยากรเป็นเวลานาน เขาเสนอให้พิจารณาลำดับเริ่มงานหลัง settle เป็นทางเลือก แต่ยังต้องดูกรณีที่รับเงินแล้วงานทำไม่สำเร็จด้วย
อย่าปล่อยให้ข้อจำกัด protocol ทำให้ระบบหลักยุ่ง
Jan ยกกรณีที่ flow x402 ต้องตอบ HTTP 402 ขณะที่ขั้นตอนยืนยันสิทธิ์ MCP ที่เขาเปรียบเทียบใช้ HTTP 401 เขามองว่ารอยต่อนี้ทำให้การรวมเส้นทางยากขึ้น บทความนี้ไม่อ้างว่า MCP ทุกการเรียกต้องตอบ 401 หรือยืนยันข้อกำหนด protocol จากเอกสารที่ยังไม่ได้ตรวจ
เขายกการแยก hostname สำหรับ payment gateway เป็นวิธีรับมือที่พบ และวิจารณ์ภาระการดูแล API หลายชุดตามวิธีจ่าย คลิปไม่ได้เป็นผลตรวจการติดตั้งจริงของทุกบริษัทที่เขายกชื่อ
ข้อคิดของ VibeSolo คือแยกส่วนที่จะทดลอง payment integration ออกจากข้อกำหนดของ API เดิมที่ลูกค้าใช้ แล้วประเมินรอยต่อและการดูแลร่วมกัน การเพิ่ม gateway ไม่ได้รับประกันเองว่าการเชื่อมต่อจะง่ายหรือปลอดภัยกว่า
คำถามที่ควรตอบจากข้อวิจารณ์นี้คือ ต้องทำเอกสาร ตั้งค่า และติดตามสถานะกี่เส้นทางเมื่อเพิ่มวิธีจ่ายใหม่ และส่วนใดต้องรักษาความเข้ากันได้กับลูกค้าเดิม
วางแผนราคาแบบใช้งานจริง ไม่ใช่แค่ราคาต่อ API call
Jan อธิบาย scheme ชื่อ Exact เป็นการคิดราคาคงที่ต่อคำขอ และเปรียบเทียบกับ Actors ที่ทำงานตามเวลาและทรัพยากร ไม่ได้หมายความว่ามีราคาต่อ API call หรือข้อจำกัดเดียวกันในทุกระบบที่ใช้ x402
ตามที่ผู้พูดเล่า Actors อาจทำงานไม่กี่วินาทีหรือหลายชั่วโมง ส่วน up to ให้กำหนดยอดสูงสุดที่ server จะเรียกเก็บได้ เขาวิจารณ์ว่าในแบบที่ทีมกำลังพิจารณา เพดานดังกล่าวยังไม่แก้ประเด็นการใช้เงินเดียวกันก่อน settle ข้อสรุปนี้เป็นประสบการณ์และการประเมินของผู้พูด ไม่ใช่การตรวจ protocol รุ่นล่าสุดอย่างอิสระ
Jan รายงานว่าทีมใช้ Exact เรียกเก็บล่วงหน้า แล้วคืนส่วนที่ไม่ใช้หลังงานจบเป็นทางแก้ชั่วคราว เขาชี้ว่าทำให้มีธุรกรรมบน chain สองครั้งและผู้ซื้อต้องเชื่อใจการคืนเงิน คลิปไม่ได้ให้ receipt หรือผลวัดค่าธรรมเนียมและเวลาของการทำงานนี้
สำหรับ batch settlement ผู้พูดอธิบายแนวคิดฝากเงินเข้า escrow แล้วใช้ voucher ลงนามรายการย่อยแบบ off-chain ก่อนรวมยอด settle และปล่อยส่วนที่เหลือ รายละเอียดนี้เป็นคำอธิบายแนวทางที่เขากำลังสำรวจ ไม่ใช่ระบบที่ทีมแสดงผลใช้งานสำเร็จในคลิป
Jan ระบุชัดว่าทีมยังไม่ได้ใช้ batch settlement ในงานที่เล่าและกำลังทำเพื่อรองรับอยู่ จึงยังไม่ควรยกแนวคิดนี้เป็นคำตอบที่พิสูจน์แล้ว หรืออ้างว่าพร้อมใช้ ณ วันเผยแพร่บทความนี้
prepaid token กับ API เดิมของ Apify
Jan นำเสนอ Agent General Interface หรือ AGI ที่เขาระบุชื่อ agi.apify.com เป็นหน้า Markdown สำหรับให้ agent อ่านวิธีซื้อบริการ โดยแยกการเปลี่ยนเส้นทางจ่ายออกจาก API หลัก นี่เป็นคำอธิบายของผู้พูด ยังไม่ได้เปิดหน้าเว็บหรือทดสอบการเชื่อมต่ออย่างอิสระ
ตามคำอธิบายของเขา agent ซื้อ prepaid API token แล้วใช้ token ผ่าน API เดิมหรือ MCP เพื่อเรียกงาน อย่างไรก็ตาม เดโมช่วง 18:44–18:58 ไม่ทำงานตามที่คาดและผู้พูดหยุดการสาธิต จึงไม่ใช่หลักฐานว่าซื้อ token และทำงานสำเร็จครบวงจรในคลิป
ตัวอย่างประยุกต์ของ VibeSolo คือแยกเครดิตสำหรับงานของ agent ออกจากการเรียกบริการ และระบุว่าขั้นตอนใดต้องตรวจเงื่อนไขก่อนใช้เครดิต ตัวอย่างนี้เป็นแบบสำหรับคิดเรื่องสิทธิ์และรอยต่อ ไม่ใช่ผลทดสอบการคุมงบหรือระบบการเงินที่พร้อมติดตั้ง
ข้อวิจารณ์ของ Jan ชวนดูจุดที่การอนุมัติจ่าย การ settle การเริ่มงาน และการคิดราคาตามทรัพยากรมาพบกัน ทีมของเขาเล่าทั้งทางแก้ชั่วคราวและแนวทางที่ยังทำอยู่ การประเมิน payment integration จึงต้องรายงานตามสิ่งที่ตรวจได้จริง แยกคำอธิบายระบบออกจากเดโมที่ยังไม่สำเร็จ
ที่มา: Jan Curn จาก Apify ทางช่อง AI Engineer อัปโหลดวันที่ 1 กันยายน 2026 เวลา 19:00:09 UTC หรือวันที่ 2 กันยายน 2026 เวลา 02:00:09 น. ตามเวลาไทย ตรงกับ 12:00:09 ใน offset -07:00 ของระเบียนต้นทาง สรุปจากคำบรรยายภาษาอังกฤษที่บันทึกไว้ช่วง 00:12–20:21 ซึ่งขาดช่วงต้นและท้าย ไม่ได้ตรวจโค้ด เดโม หรือความพร้อมใช้ของบริการอย่างอิสระ วันอัปโหลดเป็นวันของแหล่งข้อมูล ไม่ใช่วันเผยแพร่บทความนี้
