ทำไมแอปชำระเงินที่สร้างด้วยวิธี Vibe-Coding ถึงถูกปฏิเสธจาก App Store

แอปชำระเงินที่สร้างด้วยวิธี Vibe-coding ถูกปฏิเสธจาก App Store ในอัตราที่สูงกว่าแอปประเภทอื่น ๆ เกือบทั้งหมดในคิวการตรวจสอบ และเหตุผลมักจะไม่เกี่ยวข้องกับคุณภาพของโค้ดเลย แอปที่สร้างด้วยวิธี vibe-coded ซึ่งเป็นแอปที่คุณสร้างขึ้นโดยการอธิบายสิ่งที่คุณต้องการให้ผู้ช่วย AI ฟังแล้วส่งแอปที่มันเขียนขึ้นมาตรวจสอบ อาจดูไม่ต่างจากผลงานของมืออาชีพ แต่การตรวจสอบของ Apple ไม่ได้ให้คะแนนที่ตัวโค้ด มันจะตรวจสอบว่าใครเป็นผู้ส่งแอป กลไกการชำระเงินใดจัดการกับสินค้าประเภทใด สิทธิ์การใช้งานฮาร์ดแวร์ได้รับการอนุมัติแยกต่างหากหรือไม่ และผู้ตรวจสอบสามารถทำธุรกรรมจริงได้หรือไม่ สิ่งเหล่านี้คือสิ่งที่ผู้ช่วย AI ไม่สามารถสร้างขึ้นมาได้

นี่คือกำแพงที่ทุกคนต้องเจอหลังจาก สร้างระบบ POS ที่กำหนดเองด้วยโมเดล AI: โค้ดอาจเสร็จได้ในบ่ายวันเดียว แต่การนำแอปนั้นไปติดตั้งบน iPhone เพื่อใช้งานเป็นแอปชำระเงินจริง ๆ นั้นเป็นกระบวนการปฏิบัติตามข้อกำหนด ไม่ใช่งานเขียนโค้ด

AI ของคุณกำหนดเส้นทางการชำระเงินผ่านระบบที่ผิดหรือเปล่า?

สาเหตุการปฏิเสธที่พบบ่อยที่สุดคือการใช้กลไกการชำระเงินที่ผิดประเภทกับสินค้าที่ขาย และผู้ช่วย AI ก็มักจะทำพลาดในเรื่องนี้ได้ง่ายมาก แนวทางการตรวจสอบแอป (App Review Guidelines) ของ Apple ได้แบ่งเส้นไว้อย่างชัดเจน เนื้อหาและบริการดิจิทัลที่ใช้งานภายในแอปจะต้องใช้ระบบการซื้อภายในแอป (In-App Purchase) ของ Apple ตามแนวทางข้อ 3.1.1 ส่วนสินค้าที่จับต้องได้และบริการในโลกแห่งความเป็นจริง เช่น กาแฟ การตัดผม หรือคำสั่งซื้อที่ต้องจัดส่ง จะต้องทำตรงกันข้ามตามแนวทางข้อ 3.1.5(a) คือห้ามใช้ระบบการซื้อภายในแอปเลย และต้องใช้วิธีการชำระเงินภายนอกแทน

โมเดลการเขียนโค้ดจะสร้างรูปแบบการชำระเงินตามข้อมูลที่มันถูกฝึกฝนมามากที่สุด เช่น โค้ดสำเร็จรูปสำหรับการซื้อภายในแอปจากบทเรียนการสมัครสมาชิก หรือ SDK สำหรับการชำระเงินบนเว็บจากตัวอย่างอีคอมเมิร์ซ โดยไม่ได้ถามเลยว่าคุณกำลังขายอะไร หากคุณสั่งให้มันสร้าง "แอปที่รับชำระเงินได้" คุณจะได้รูปแบบใดรูปแบบหนึ่งจากสองรูปแบบนี้ ซึ่งเลือกโดยสถิติไม่ใช่โดยกฎของ Apple นอกจากนี้ กฎเกณฑ์ยังแตกต่างกันไปตามแต่ละประเทศ: หลังจากการตัดสินคดีของ Epic ในปี 2025 แอปใน App Store ของสหรัฐฯ อาจเชื่อมโยงไปยังตัวเลือกการซื้อภายนอกสำหรับสินค้าดิจิทัลได้ แต่ข้อยกเว้นนั้นใช้ได้เฉพาะในสหรัฐอเมริกาเท่านั้น แอปที่เผยแพร่ทั่วโลกยังคงต้องปฏิบัติตามกฎที่เข้มงวดกว่าในประเทศอื่น ๆ ทั้งหมด

คุณได้รับอนุญาตให้ส่งแอปชำระเงินตั้งแต่แรกหรือไม่?

Apple กำหนดให้แอปที่จัดการเรื่องเงินหรือบริการทางการเงินต้องส่งโดยสถาบันที่ให้บริการเหล่านั้นจริง ๆ พร้อมทั้งมีใบอนุญาตที่จำเป็นในทุกภูมิภาคที่แอปนั้นเปิดใช้งาน — นั่นคือแนวทางข้อ 3.2.1 นักพัฒนาอิสระที่ส่งแอปชำระเงินที่สร้างโดย AI ไม่ใช่สถาบันการเงินที่ได้รับใบอนุญาต และเอเจนซีที่ส่งแอปให้ลูกค้าก็ไม่ใช่เช่นกัน การเปิดให้ใช้งานแอปในประเทศที่ไม่มีใบอนุญาตการโอนเงินจะส่งผลให้ถูกปฏิเสธเช่นเดียวกัน

ผู้ตรวจสอบของ Apple ไม่ได้ประเมินว่าโปรแกรมการปฏิบัติตามข้อกำหนดของคุณดีแค่ไหน แต่พวกเขาจะตรวจสอบว่านิติบุคคลที่ถูกต้องเป็นผู้ส่งแอปหรือไม่ และจะปฏิเสธหากไม่ใช่ ไม่มีคำสั่งใดที่สามารถแก้ไขเรื่องนี้ได้

ทำไม Tap to Pay ถึงต้องมีกระบวนการอนุมัติเฉพาะของตัวเอง?

การรับชำระเงินผ่านบัตรแบบไร้สัมผัสบน iPhone ต้องใช้สิทธิ์การใช้งาน Tap to Pay on iPhone ซึ่งเป็นการยื่นคำขอแยกต่างหากไปยัง Apple โดยไม่ขึ้นกับการตรวจสอบแอป และจะมอบให้กับนิติบุคคลไม่ใช่ตัวโค้ด สิทธิ์การใช้งานสำหรับการพัฒนา (Development Entitlement) มักจะได้รับการอนุมัติในหนึ่งหรือสองวัน ส่วนสิทธิ์การใช้งานสำหรับการเผยแพร่ (Publishing Entitlement) จะต้องผ่านทีมปฏิบัติการของ Apple ซึ่งโดยทั่วไปจะใช้เวลาหนึ่งถึงสองสัปดาห์ และต้องทำงานร่วมกับผู้ให้บริการชำระเงินที่ได้รับการรองรับ ผู้ช่วย AI จะเขียนโค้ด Tap to Pay ให้คุณอย่างเต็มใจโดยไม่ได้พูดถึงเรื่องนี้เลย หากคุณส่งแอปก่อนที่สิทธิ์การใช้งานจะได้รับการอนุมัติ แอปก็จะถูกตีกลับ

การรับชำระเงินแบบเสียบบัตร/แตะบัตรหน้าร้านยังดึงเอาข้อกำหนดที่ Apple ไม่ได้เป็นเจ้าของเข้ามาเกี่ยวข้องด้วย เช่น ฮาร์ดแวร์เครื่องอ่านบัตรที่ได้รับการรับรอง, กฎเกณฑ์ EMV และขอบเขต PCI สำหรับสิ่งใดก็ตามที่สัมผัสกับข้อมูลบัตร สิ่งเหล่านี้ไม่มีทางสร้างออกมาจากโมเดลที่เขียนโค้ด Swift ได้เลย

ผู้ตรวจสอบสามารถทำธุรกรรมจริงได้หรือไม่?

แนวทางข้อ 2.1 เรื่องความสมบูรณ์ของแอป (App Completeness) เป็นตัวการเงียบที่ทำให้แอปชำระเงินถูกปฏิเสธมากกว่ากฎการชำระเงินเสียอีก ผู้ตรวจสอบจะต้องสามารถทดลองใช้งานแอปได้ทั้งหมด รวมถึงขั้นตอนการชำระเงินด้วย แอปชำระเงินมักจะต้องใช้บัญชีร้านค้า การยืนยันตัวตน และบางครั้งก็ต้องใช้บัญชีธนาคาร ซึ่งเป็นสิ่งที่ผู้ตรวจสอบไม่สามารถสมัครใช้งานได้ในระหว่างการตรวจสอบ แอปที่สร้างด้วยวิธี vibe-coded มักจะตกม้าตายตรงนี้ เพราะผู้สร้างมักจะไม่เคยเตรียมบัญชีร้านค้าจริงไว้เลย แอปถูกทดสอบเฉพาะกับข้อมูลจำลองที่ AI สร้างขึ้นมาคู่กันเท่านั้น หากไม่มีบัญชีเดโมที่ใช้งานได้จริงและวิธีการทำธุรกรรมทดสอบ แอปจะถูกปฏิเสธเนื่องจากไม่สมบูรณ์ และการส่งใหม่แต่ละครั้งก็ต้องเสียเวลาในรอบการตรวจสอบอีกครั้ง

แล้วอะไรคือสิ่งที่ใช้งานได้จริง?

ส่วนที่ยากไม่เคยเป็นเรื่องของโค้ด ผู้ช่วย AI สามารถสร้างอินเทอร์เฟซการชำระเงินที่ใช้งานได้ในบ่ายวันเดียว แต่การเผยแพร่บน App Store นั้นเต็มไปด้วยเรื่องของสิทธิ์การใช้งาน ใบอนุญาต และนโยบายการตรวจสอบที่อยู่นอกเหนือขอบเขตที่คำสั่งจะเข้าถึงได้ ตัวเดโมทำงานได้ แต่โครงสร้างพื้นฐานยังไม่มีอยู่จริง

สำหรับร้านค้าที่ขายสินค้าที่จับต้องได้ ข้อสรุปในทางปฏิบัติจะง่ายกว่านั้นมาก: อย่าเข้าไปในคิวนั้นเลย ธุรกิจของคุณต้องการระบบชำระเงินที่ใช้งานได้จริง ไม่ใช่การมีแอปของตัวเองใน App Store — เพราะเรื่องใบอนุญาต การรับรองฮาร์ดแวร์ และภาระในการตรวจสอบแอปนั้นสมเหตุสมผลสำหรับบริษัทที่ทำซอฟต์แวร์ระบบชำระเงินเป็นหลักเท่านั้น ดำเนินการขายหน้าร้านของคุณบนแพลตฟอร์ม POS ที่แบกรับต้นทุนเหล่านั้นไว้ให้แล้ว (Final ถูกสร้างขึ้นมาในรูปแบบนี้อย่างแท้จริง — ชำระเงินผ่าน Final Pay ด้วย ฮาร์ดแวร์เครื่องรูดบัตรที่ได้รับการรับรอง โดยไม่ต้องเผยแพร่แอปของคุณเอง) และนำเงินที่จะต้องเสียไปกับรอบการตรวจสอบแอปไปลงทุนกับสิ่งที่จะช่วยเพิ่มรายได้ดีกว่า เช่น ขั้นตอนการชำระเงินที่รวดเร็วขึ้น และ ค่าธรรมเนียมบัตรที่ถูกลง

กระบวนการตรวจสอบของ Apple มีขึ้นเพื่อเหตุผลที่ดี แอปการเงินที่ทำงานผิดพลาดจะสร้างความเสียหายให้กับผู้คนจริง ๆ เพียงแต่มันไม่ใช่กระบวนการที่ร้านค้าส่วนใหญ่จำเป็นต้องผ่าน ไม่ว่าใครหรืออะไรจะเป็นผู้เขียนแอปนั้นขึ้นมาก็ตาม