ภัยพิบัติ API 11 ปีของ PayPal: เราสร้างแนวทางแก้ปัญหาอย่างไรในขณะที่พวกเขาเพิกเฉยต่อนักพัฒนา

ที่ Forward Email เราจัดการกับ API ที่มีปัญหาของ PayPal มานานกว่าทศวรรษ สิ่งที่เริ่มต้นจากความหงุดหงิดเล็กๆ น้อยๆ กลายเป็นหายนะครั้งใหญ่ที่บังคับให้เราต้องหาวิธีแก้ไขด้วยตัวเอง บล็อกเทมเพลตฟิชชิ่ง และท้ายที่สุดต้องหยุดการชำระเงิน PayPal ทั้งหมดในระหว่างการย้ายบัญชีที่สำคัญ

นี่คือเรื่องราวของ PayPal 11 ปีที่เพิกเฉยต่อความต้องการพื้นฐานของนักพัฒนา ในขณะที่เราพยายามทุกวิถีทางเพื่อให้แพลตฟอร์มของพวกเขาทำงานได้

ชิ้นส่วนที่หายไป: ไม่มีวิธีแสดงรายการการสมัครสมาชิก

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

ลองคิดดูสักครู่ คุณสามารถสร้างการสมัครสมาชิกได้ ยกเลิกได้ถ้ามี ID แต่คุณไม่สามารถดูรายชื่อการสมัครสมาชิกทั้งหมดที่ใช้งานอยู่ในบัญชีของคุณได้ เหมือนกับการมีฐานข้อมูลที่ไม่มีคำสั่ง SELECT

เราต้องมีสิ่งนี้สำหรับการดำเนินธุรกิจขั้นพื้นฐาน:

• การสนับสนุนลูกค้า (เมื่อมีคนส่งอีเมลสอบถามเกี่ยวกับการสมัครสมาชิก)
• การรายงานทางการเงินและการกระทบยอดบัญชี
• การจัดการการเรียกเก็บเงินอัตโนมัติ
• การปฏิบัติตามกฎระเบียบและการตรวจสอบบัญชี

แต่ PayPal ล่ะ? พวกเขาแค่... ไม่เคยสร้างมันขึ้นมา

2014-2017: ปัญหาเกิดขึ้น

ปัญหารายการสมัครสมาชิกปรากฏขึ้นครั้งแรกในฟอรัมชุมชนของ PayPal เมื่อปี 2017 นักพัฒนาได้ถามคำถามที่ชัดเจนว่า "ฉันจะรับรายการสมัครสมาชิกทั้งหมดของฉันได้อย่างไร"

การตอบสนองของ PayPal คืออะไร? จิ้งหรีด

สมาชิกชุมชนเริ่มรู้สึกหงุดหงิด:

"การละเว้นที่แปลกมากหากผู้ขายไม่สามารถระบุข้อตกลงที่ใช้งานอยู่ทั้งหมดได้ หากรหัสข้อตกลงสูญหาย หมายความว่ามีเพียงผู้ใช้เท่านั้นที่สามารถยกเลิกหรือระงับข้อตกลงได้" - leafspider

"+1. เกือบ 3 ปีแล้ว" - laudukang (หมายถึงปัญหามีมาตั้งแต่ ~2014)

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

2020: เราให้ข้อเสนอแนะอย่างครอบคลุมแก่พวกเขา

ในเดือนตุลาคม 2020 PayPal ได้ติดต่อมาหาเราเพื่อขอฟังความคิดเห็นอย่างเป็นทางการ นี่ไม่ใช่การพูดคุยแบบสบายๆ พวกเขาได้จัดการประชุมทางโทรศัพท์ Microsoft Teams นาน 45 นาที โดยมีผู้บริหาร PayPal 8 ท่าน ได้แก่ Sri Shivananda (CTO), Edwin Aoki, Jim Magats, John Kunze และคนอื่นๆ

รายการข้อเสนอแนะ 27 รายการ

เราเตรียมพร้อมมาเป็นอย่างดี หลังจากพยายามผสานรวมกับ API ของพวกเขานานถึง 6 ชั่วโมง เราก็พบปัญหาเฉพาะเจาะจงถึง 27 ข้อ มาร์ค สจ๊วต จากทีม PayPal Checkout กล่าวว่า:

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

ข้อเสนอแนะนั้นไม่ได้เป็นเชิงทฤษฎี แต่มาจากความพยายามบูรณาการที่แท้จริง:

1. การสร้างโทเค็นการเข้าถึงไม่ทำงาน:

การสร้างโทเค็นการเข้าถึงไม่ทำงาน นอกจากนี้ ควรมีตัวอย่างมากกว่าแค่ cURL

2. ไม่มี UI เว็บสำหรับการสร้างการสมัครสมาชิก:

จะสร้างการสมัครสมาชิกโดยไม่ต้องใช้ cURL ได้ยังไงเนี่ย? ดูเหมือนจะไม่มี UI เว็บสำหรับทำแบบนั้น (เหมือนที่ Stripe มี)

Mark Stuart พบว่าปัญหาโทเค็นการเข้าถึงเป็นเรื่องที่น่ากังวลเป็นพิเศษ:

โดยทั่วไปแล้ว เราจะไม่ได้ยินเกี่ยวกับปัญหาเกี่ยวกับการสร้างโทเค็นการเข้าถึง

ทีมต่างๆ มีส่วนร่วม ทำตามสัญญา

เมื่อเราพบปัญหามากขึ้น PayPal ก็เริ่มเพิ่มทีมเข้ามาพูดคุยเรื่อยๆ Darshan Raju จากทีม UI จัดการการสมัครสมาชิกได้เข้าร่วมและกล่าวว่า:

รับทราบช่องว่าง เราจะติดตามและแก้ไขเรื่องนี้ ขอบคุณอีกครั้งสำหรับคำติชมของคุณ!

เซสชั่นดังกล่าวได้รับการอธิบายว่าเป็นการแสวงหา:

การเดินผ่านประสบการณ์ของคุณอย่างตรงไปตรงมา

ถึง:

ทำให้ PayPal เป็นสิ่งที่ควรจะเป็นสำหรับนักพัฒนา

ผลลัพธ์? ไม่มีอะไรเลย

แม้จะมีการประชุมรับฟังความคิดเห็นอย่างเป็นทางการ รายการที่ครอบคลุม 27 รายการ การมีส่วนร่วมของหลายทีม และคำมั่นสัญญาที่จะ:

ติดตามและที่อยู่

ปัญหาต่างๆ ไม่มีอะไรได้รับการแก้ไขเลย

การลาออกของผู้บริหาร: PayPal สูญเสียความทรงจำของสถาบันทั้งหมดไปได้อย่างไร

นี่คือจุดที่น่าสนใจจริงๆ ทุกคนที่ได้รับฟีดแบ็กจากเราในปี 2020 ต่างก็ออกจาก PayPal แล้ว:

การเปลี่ยนแปลงความเป็นผู้นำ:

• แดน ชูลแมน (ซีอีโอ 9 ปี) → อเล็กซ์ คริส (กันยายน 2566)
• ศรี ศิวานันท์ (CTO ผู้จัดทำข้อเสนอแนะ) → JPMorgan Chase (มกราคม 2567)

ผู้นำทางเทคนิคที่ให้คำมั่นสัญญาแต่สุดท้ายก็จากไป:

• Mark Stuart (คำชมที่สัญญาไว้จะเป็น "ตัวเร่งปฏิกิริยา") → ตอนนี้ที่ Ripple
• Jim Magats (ผู้คร่ำหวอดกับ PayPal มานาน 18 ปี) → ซีอีโอของ MX (2022)
• John Kunze (รองประธานฝ่ายผลิตภัณฑ์ผู้บริโภคระดับโลก) → เกษียณอายุแล้ว (2023)
• Edwin Aoki (หนึ่งในคนสุดท้ายที่ยังเหลืออยู่) → เพิ่งออกเดินทางไป Nasdaq (มกราคม 2025)

PayPal กลายเป็นประตูหมุนเวียนที่ผู้บริหารรวบรวมคำติชมจากนักพัฒนา ให้คำมั่นสัญญา จากนั้นลาออกเพื่อไปทำงานกับบริษัทที่ดีกว่า เช่น JPMorgan, Ripple และบริษัทเทคโนโลยีทางการเงินอื่นๆ

ซึ่งอธิบายได้ว่าเหตุใดการตอบสนองต่อปัญหา GitHub ปี 2025 จึงดูไม่เกี่ยวข้องกับคำติชมของเราในปี 2020 เลย - แท้จริงแล้ว ทุกคนที่ได้รับคำติชมดังกล่าวได้ออกจาก PayPal ไปแล้ว

2025: ผู้นำคนใหม่ ปัญหาเดิม

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

ซีอีโอคนใหม่มีส่วนร่วม

เมื่อวันที่ 30 มิถุนายน 2568 เราได้ส่งต่อเรื่องโดยตรงไปยังอเล็กซ์ คริสส์ ซีอีโอคนใหม่ของ PayPal ซึ่งเขาตอบกลับมาสั้นๆ ว่า

สวัสดีนิค – ขอบคุณที่ติดต่อมาและรับฟังความคิดเห็นนะคะ มิเชลล์ (ส่งสำเนาถึง) คอยช่วยเหลือและประสานงานกับทีมงานของเธออย่างเต็มที่ ขอบคุณ -A

คำตอบของ Michelle Gill

มิเชลล์ กิลล์ รองประธานบริหารและผู้จัดการทั่วไปฝ่ายธุรกิจขนาดเล็กและบริการทางการเงิน ตอบกลับว่า:

ขอบคุณมากนิค ย้ายอเล็กซ์ไปที่ bcc ค่ะ เราได้ตรวจสอบเรื่องนี้ตั้งแต่โพสต์ก่อนหน้าของคุณแล้ว เราจะโทรหาคุณก่อนสิ้นสัปดาห์นี้ค่ะ คุณช่วยส่งข้อมูลติดต่อของคุณมาให้ฉันหน่อยได้ไหม เพื่อให้เพื่อนร่วมงานของฉันติดต่อได้ มิเชล

คำตอบของเรา: ไม่มีการประชุมอีกต่อไป

เราปฏิเสธการประชุมอีกครั้งโดยอธิบายถึงความหงุดหงิดของเรา:

ขอบคุณครับ แต่ผมรู้สึกว่าการโทรไปคุยไปคงไม่ช่วยอะไรหรอกครับ นี่คือเหตุผล... ผมเคยโทรไปคุยไปคุยมาแล้วแต่ก็ไม่มีอะไรเกิดขึ้นเลย เสียเวลาคุยกับทีมงานและผู้บริหารไปตั้ง 2 ชั่วโมงกว่าๆ แต่ก็ไม่มีอะไรเกิดขึ้นเลย... ส่งอีเมลไปๆ มาๆ เยอะแยะไปหมด แต่ก็ไม่มีอะไรเกิดขึ้นเลย ฟีดแบ็กก็หายไปไหนหมด ผมลองมาหลายปีแล้ว มีคนรับฟัง แต่สุดท้ายก็หายไปไหนไม่หาย

การตอบสนองของ Marty Brodbeck ต่อวิศวกรรมที่มากเกินไป

จากนั้น Marty Brodbeck ซึ่งเป็นหัวหน้าฝ่ายวิศวกรรมผู้บริโภคที่ PayPal ได้ติดต่อมาว่า:

สวัสดีนิค ผมมาร์ตี้ บรอดเบ็ค ผมเป็นหัวหน้าฝ่ายวิศวกรรมผู้บริโภคทั้งหมดที่ PayPal และกำลังขับเคลื่อนการพัฒนา API ของบริษัท คุณและผมสามารถพูดคุยกันถึงปัญหาที่คุณเผชิญอยู่และวิธีที่เราจะช่วยเหลือคุณได้ที่นี่

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

ขอบคุณ Nick เรากำลังอยู่ในขั้นตอนการสร้าง API การสมัครสมาชิกรายเดียวที่มี SDK เต็มรูปแบบ (รองรับการจัดการข้อผิดพลาดแบบเต็มรูปแบบ การติดตามการสมัครสมาชิกตามเหตุการณ์ เวลาการทำงานที่มั่นคง) โดยที่การเรียกเก็บเงินยังแยกออกไปเป็น API แยกต่างหากสำหรับผู้ค้าแทนที่จะต้องประสานงานกันระหว่างจุดสิ้นสุดหลายจุดเพื่อรับการตอบกลับเพียงครั้งเดียว

นี่เป็นแนวทางที่ผิดอย่างสิ้นเชิง เราไม่ต้องการสถาปัตยกรรมที่ซับซ้อนหลายเดือน เราต้องการจุดสิ้นสุด REST ง่ายๆ เพียงจุดเดียวที่แสดงรายการการสมัครใช้งาน ซึ่งควรมีมาตั้งแต่ปี 2014

GET /v1/billing/subscriptions
Authorization: Bearer {access_token}

ความขัดแย้ง "CRUD ง่ายๆ"

เมื่อเราชี้ให้เห็นว่านี่คือฟังก์ชัน CRUD ขั้นพื้นฐานที่ควรมีอยู่ตั้งแต่ปี 2014 คำตอบของ Marty ก็บอกอะไรบางอย่างได้ดังนี้:

การดำเนินการ Crud แบบง่าย ๆ เป็นส่วนหนึ่งของ API หลัก เพื่อนของฉัน ดังนั้นมันจึงไม่ต้องใช้เวลาพัฒนาหลายเดือน

SDK ของ PayPal TypeScript ซึ่งปัจจุบันรองรับเพียงสามจุดสิ้นสุดเท่านั้นหลังจากการพัฒนาหลายเดือน พร้อมทั้งไทม์ไลน์ในอดีต แสดงให้เห็นชัดเจนว่าโปรเจ็กต์ดังกล่าวต้องใช้เวลามากกว่าสองสามเดือนจึงจะเสร็จสมบูรณ์

คำตอบนี้แสดงให้เห็นว่าเขาไม่เข้าใจ API ของตัวเอง ถ้า "การดำเนินการ CRUD แบบง่ายๆ เป็นส่วนหนึ่งของ API หลัก" แล้วจุดสิ้นสุดของรายการสมัครสมาชิกอยู่ที่ไหน? เราตอบว่า:

ถ้า 'การดำเนินการ CRUD แบบง่ายเป็นส่วนหนึ่งของ API หลัก' แล้วจุดสิ้นสุดของรายการสมัครสมาชิกอยู่ที่ไหน? นักพัฒนาได้เรียกร้อง 'การดำเนินการ CRUD แบบง่าย' นี้มาตั้งแต่ปี 2014 เป็นเวลา 11 ปีแล้ว ผู้ให้บริการชำระเงินรายอื่นๆ ต่างก็มีฟังก์ชันพื้นฐานนี้มาตั้งแต่วันแรก

การตัดการเชื่อมต่อจะชัดเจน

การแลกเปลี่ยนในปี 2025 กับ Alex Chriss, Michelle Gill และ Marty Brodbeck แสดงให้เห็นถึงความผิดปกติขององค์กรแบบเดียวกัน:

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

รูปแบบนี้จะอธิบายว่าทำไมทีมงาน PayPal ในปี 2025 จึงดูไม่เกี่ยวข้องกับคำติชมมากมายที่ได้รับในปี 2020 เลย เนื่องจากผู้ที่ได้รับคำติชมเหล่านั้นหายไปแล้ว และผู้นำคนใหม่ก็ทำผิดซ้ำแบบเดิม

รายงานข้อบกพร่องหลายปีที่พวกเขาเพิกเฉย

เราไม่ได้แค่บ่นเกี่ยวกับฟีเจอร์ที่ขาดหายไปเท่านั้น แต่เราได้รายงานข้อบกพร่องอย่างต่อเนื่องและพยายามช่วยปรับปรุง นี่คือไทม์ไลน์ที่ครอบคลุมของปัญหาที่เราบันทึกไว้:

2016: ข้อร้องเรียน UI/UX ในระยะเริ่มต้น

ย้อนกลับไปในปี 2016 เราได้ติดต่อผู้บริหารของ PayPal ซึ่งรวมถึง Dan Schulman เกี่ยวกับปัญหาอินเทอร์เฟซและปัญหาการใช้งาน เรื่องนี้เกิดขึ้นเมื่อ 9 ปีที่แล้ว และปัญหา UI/UX เดิมๆ ยังคงมีอยู่จนถึงทุกวันนี้

2021: รายงานข้อบกพร่องของอีเมลธุรกิจ

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

Mark Stuart ยอมรับถึงปัญหาดังกล่าว:

ขอบคุณนิค! ย้ายไปใช้ BCC แล้วนะ @Prasy ทีมของคุณรับผิดชอบอีเมลฉบับนี้หรือเปล่า หรือรู้จักใครบ้าง? ข้อความ "Niftylettuce, LLC เราจะไม่เรียกเก็บเงินจากคุณอีกต่อไป" ทำให้ผมเชื่อว่าน่าจะมีความสับสนระหว่างชื่ออีเมลและเนื้อหาของอีเมล

ผลลัพธ์: พวกเขาแก้ไขปัญหานี้ได้จริง! Mark Stuart ยืนยันแล้ว:

เพิ่งได้รับแจ้งจากทีมแจ้งเตือนว่าเทมเพลตอีเมลได้รับการแก้ไขและเปิดใช้งานแล้ว ขอบคุณที่ติดต่อมารายงานนะคะ ขอบคุณค่ะ!

นี่แสดงให้เห็นว่าพวกเขาสามารถแก้ไขสิ่งต่างๆ ได้เมื่อพวกเขาต้องการ - แต่พวกเขาเลือกที่จะไม่ทำกับปัญหาส่วนใหญ่

2021: ข้อเสนอแนะในการปรับปรุง UI

ในเดือนกุมภาพันธ์ 2021 เราได้ให้ข้อเสนอแนะโดยละเอียดเกี่ยวกับ UI ของแดชบอร์ด โดยเฉพาะส่วน "กิจกรรมล่าสุดของ PayPal"

ผมคิดว่าแดชบอร์ดที่ paypal.com โดยเฉพาะ "กิจกรรมล่าสุดของ PayPal" ควรได้รับการปรับปรุง ผมไม่คิดว่าคุณควรแสดงบรรทัดสถานะ "สร้างแล้ว" ของการชำระเงินแบบต่อเนื่อง $0 เพราะมันจะเพิ่มบรรทัดพิเศษเข้ามาอีกเยอะ และคุณไม่สามารถดูได้ง่ายๆ ว่ารายได้ในแต่ละวันหรือสองสามวันที่ผ่านมานั้นเท่าไหร่

Mark Stuart ส่งต่อไปยังทีมผลิตภัณฑ์เพื่อผู้บริโภค:

ขอบคุณ! ฉันไม่แน่ใจว่าทีมไหนรับผิดชอบกิจกรรม แต่ฉันส่งต่อให้หัวหน้าฝ่ายสินค้าอุปโภคบริโภคแล้วเพื่อหาทีมที่ถูกต้อง การชำระเงินแบบซ้ำ $0.00 ดูเหมือนจะเป็นบั๊ก น่าจะต้องกรองออก

ผลลัพธ์: ไม่ได้รับการแก้ไข UI ยังคงแสดงรายการ $0 ที่ไม่มีประโยชน์เหล่านี้

2021: ความล้มเหลวของสภาพแวดล้อม Sandbox

ในเดือนพฤศจิกายน 2021 เราได้รายงานปัญหาสำคัญกับสภาพแวดล้อมแซนด์บ็อกซ์ของ PayPal:

• คีย์ API ของ Sandbox secret ถูกเปลี่ยนแปลงและปิดใช้งานแบบสุ่ม
• บัญชีทดสอบ Sandbox ทั้งหมดถูกลบโดยไม่แจ้งให้ทราบล่วงหน้า
• ข้อความแสดงข้อผิดพลาดเมื่อพยายามดูรายละเอียดบัญชี Sandbox
• การโหลดล้มเหลวเป็นระยะ

ด้วยเหตุผลบางประการ คีย์ API ของแซนด์บ็อกซ์ลับของฉันจึงถูกเปลี่ยนและถูกปิดใช้งาน นอกจากนี้ บัญชีทดสอบแซนด์บ็อกซ์เก่าทั้งหมดของฉันก็ถูกลบไปด้วย

บางครั้งมันก็โหลดได้ บางครั้งมันก็โหลดไม่ได้ นี่มันน่าหงุดหงิดจริงๆ

ผลลัพธ์: ไม่มีการตอบสนอง ไม่มีการแก้ไข นักพัฒนายังคงประสบปัญหาความน่าเชื่อถือของแซนด์บ็อกซ์

2021: ระบบรายงานเสียหายอย่างสมบูรณ์

ในเดือนพฤษภาคม 2021 เราได้รายงานว่าระบบดาวน์โหลดรายงานธุรกรรมของ PayPal เสียหายโดยสิ้นเชิง:

ดูเหมือนว่าการรายงานการดาวน์โหลดจะใช้ไม่ได้ในตอนนี้ และก็ใช้ไม่ได้มาทั้งวันแล้วด้วย และน่าจะมีการแจ้งเตือนทางอีเมลด้วยถ้าทำไม่สำเร็จ

เรายังได้ชี้ให้เห็นถึงภัยพิบัติในการจัดการเซสชัน:

และถ้าคุณไม่ได้ใช้งาน PayPal ขณะล็อกอินอยู่ประมาณ 5 นาที คุณจะออกจากระบบ ดังนั้นเมื่อคุณรีเฟรชปุ่มข้างๆ รายงานที่คุณต้องการตรวจสอบสถานะอีกครั้ง (หลังจากที่รอมานาน) การต้องล็อกอินใหม่อีกครั้งจึงเป็นเรื่องยุ่งยาก

Mark Stuart ยอมรับปัญหาการหมดเวลาเซสชัน:

ฉันจำได้ว่าคุณเคยรายงานว่าในอดีตเมื่อเซสชันของคุณหมดอายุบ่อยครั้งและรบกวนกระแสการพัฒนาของคุณขณะที่คุณสลับไปมาระหว่าง IDE และ developer.paypal.com หรือแดชบอร์ดผู้ค้าของคุณ จากนั้นคุณกลับมาและออกจากระบบอีกครั้ง

ผลลัพธ์: เซสชันหมดเวลายังคงเป็น 60 วินาที ระบบรายงานยังคงล้มเหลวเป็นประจำ

2022: ฟีเจอร์หลักของ API หายไป (อีกครั้ง)

ในเดือนมกราคม 2022 เราได้ยกระดับปัญหารายการสมัครสมาชิกอีกครั้ง คราวนี้มีรายละเอียดเพิ่มเติมเกี่ยวกับข้อผิดพลาดในเอกสารประกอบ:

ไม่มี GET ซึ่งแสดงรายการการสมัครรับข้อมูลทั้งหมด (ก่อนหน้านี้เรียกว่าข้อตกลงการเรียกเก็บเงิน)

เราพบว่าเอกสารอย่างเป็นทางการของพวกเขาไม่ถูกต้องเลย:

เอกสาร API ก็ไม่ถูกต้องเลย เราคิดว่าน่าจะแก้ปัญหาได้ด้วยการดาวน์โหลดรายการ ID การสมัครสมาชิกแบบฮาร์ดโค้ด แต่มันไม่ได้ผลเลย!

จากเอกสารอย่างเป็นทางการที่นี่... ระบุว่าคุณสามารถทำสิ่งนี้ได้... ประเด็นสำคัญคือ ไม่มีช่อง "Subscription ID" ที่ให้ติ๊กไว้เลย

Christina Monti จาก PayPal ตอบกลับ:

ขออภัยสำหรับความหงุดหงิดที่เกิดจากขั้นตอนเหล่านี้ไม่ถูกต้อง เราจะแก้ไขในสัปดาห์นี้

ศรีศิวานันท์ (CTO) กล่าวขอบคุณเรา:

ขอบคุณสำหรับความช่วยเหลืออย่างต่อเนื่องที่ทำให้เราดีขึ้น ขอบคุณมาก

ผลลัพธ์: เอกสารประกอบไม่ได้รับการแก้ไขเลย ไม่มีการสร้างจุดสิ้นสุดรายการสมัครสมาชิก

ฝันร้ายแห่งประสบการณ์นักพัฒนา

การทำงานกับ API ของ PayPal เปรียบเสมือนการย้อนเวลากลับไปเมื่อ 10 ปีก่อน ต่อไปนี้คือปัญหาทางเทคนิคที่เราได้บันทึกไว้:

อินเทอร์เฟซผู้ใช้ที่เสียหาย

แดชบอร์ดนักพัฒนาของ PayPal นี่มันหายนะชัดๆ นี่คือสิ่งที่เราต้องจัดการทุกวัน:

ปัญหา SDK

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

การละเมิดนโยบายความปลอดภัยเนื้อหา

SDK ของพวกเขาต้องใช้ unsafe-inline และ unsafe-eval ใน CSP ของคุณ ซึ่งบังคับให้คุณต้องประนีประนอมความปลอดภัยของไซต์ของคุณ

ความวุ่นวายในเอกสาร

มาร์ค สจ๊วร์ต เองก็ยอมรับว่า:

เห็นด้วยว่ามี API รุ่นเก่าและใหม่ ๆ มากมายเหลือเกิน ยากที่จะหาสิ่งที่ต้องการจริงๆ (แม้แต่พวกเราที่ทำงานที่นี่)

ช่องโหว่ด้านความปลอดภัย

การนำ 2FA มาใช้ของ PayPal เป็นแบบย้อนกลับ แม้จะเปิดใช้งานแอป TOTP ไว้แล้ว แต่ระบบก็ยังบังคับให้ยืนยันตัวตนด้วย SMS ซึ่งทำให้บัญชีเสี่ยงต่อการถูกโจมตีด้วยการสลับซิม หากคุณเปิดใช้งาน TOTP ไว้ ระบบควรใช้เฉพาะการยืนยันตัวตนนี้เท่านั้น ทางเลือกสำรองควรเป็นอีเมล ไม่ใช่ SMS

ภัยพิบัติการจัดการเซสชัน

แดชบอร์ดนักพัฒนาจะออกจากระบบหลังจากไม่ได้ใช้งาน 60 วินาที ลองทำอะไรที่มีประโยชน์ดูสิ แล้วคุณก็จะเจอปัญหาแบบนี้อยู่เรื่อย: ล็อกอิน → แคปต์ชา → 2FA → ออกจากระบบ → ทำซ้ำ ใช้ VPN เหรอ? โชคดีนะ

กรกฎาคม 2568: ฟางเส้นสุดท้าย

หลังจากประสบปัญหาเดิมๆ มานาน 11 ปี จุดเปลี่ยนสำคัญก็มาถึงระหว่างการย้ายบัญชีตามปกติ เราจำเป็นต้องเปลี่ยนไปใช้บัญชี PayPal ใหม่เพื่อให้ตรงกับชื่อบริษัท "Forward Email LLC" ของเรา เพื่อระบบบัญชีที่สะอาดขึ้น

สิ่งที่ควรจะเป็นเรื่องง่าย กลับกลายเป็นหายนะโดยสิ้นเชิง:

• การทดสอบเบื้องต้นแสดงให้เห็นว่าทุกอย่างทำงานได้อย่างถูกต้อง
• หลายชั่วโมงต่อมา PayPal ได้ระงับการชำระเงินค่าสมัครสมาชิกทั้งหมดอย่างกะทันหันโดยไม่แจ้งให้ทราบล่วงหน้า
• ลูกค้าไม่สามารถชำระเงินได้ ทำให้เกิดความสับสนและเป็นภาระในการสนับสนุน
• ฝ่ายสนับสนุนของ PayPal ให้คำตอบที่ขัดแย้งกัน โดยอ้างว่าบัญชีได้รับการยืนยันแล้ว
• เราถูกบังคับให้หยุดการชำระเงินผ่าน PayPal อย่างสมบูรณ์

ทำไมเราจึงไม่สามารถยกเลิก PayPal ได้

แม้จะมีปัญหาทั้งหมดนี้ แต่เราไม่สามารถเลิกใช้ PayPal ได้อย่างสมบูรณ์ เนื่องจากลูกค้าบางรายมีตัวเลือกการชำระเงินผ่าน PayPal เท่านั้น ดังที่ลูกค้ารายหนึ่งกล่าวไว้ใน หน้าสถานะ ของเรา:

PayPal เป็นตัวเลือกเดียวสำหรับการชำระเงินของฉัน

เราติดอยู่กับการรองรับแพลตฟอร์มที่เสียหายเนื่องจาก PayPal ได้สร้างการผูกขาดการชำระเงินให้กับผู้ใช้บางราย

แนวทางแก้ไขปัญหาชุมชน

เนื่องจาก PayPal ไม่มีฟังก์ชันพื้นฐานสำหรับรายการสมัครสมาชิก ชุมชนนักพัฒนาจึงได้พัฒนาวิธีแก้ปัญหาชั่วคราว เราได้สร้างสคริปต์ที่ช่วยจัดการการสมัครสมาชิก PayPal: set-active-pypl-subscription-ids.js

สคริปต์นี้อ้างอิง แก่นแท้ของชุมชน ซึ่งนักพัฒนาซอฟต์แวร์แชร์โซลูชัน จริงๆ แล้วผู้ใช้คือ ขอบคุณเรา ที่ให้สิ่งที่ PayPal ควรสร้างไว้เมื่อหลายปีก่อน

กำลังบล็อกเทมเพลต PayPal เนื่องจากฟิชชิ่ง

ปัญหาเหล่านี้ไม่ได้จำกัดอยู่แค่ API เท่านั้น เทมเพลตอีเมลของ PayPal ออกแบบมาได้แย่มากจนเราต้องติดตั้งระบบกรองเฉพาะในบริการอีเมลของเรา เพราะไม่สามารถแยกแยะการฟิชชิ่งออกจากกันได้

ปัญหาที่แท้จริง: เทมเพลตของ PayPal ดูเหมือนการหลอกลวง

เราได้รับรายงานเกี่ยวกับอีเมล PayPal ที่ดูเหมือนฟิชชิงเป็นประจำ นี่คือตัวอย่างจริงจากรายงานการละเมิดของเรา:

เรื่อง: [Sandbox] TEST - New invoice from PaypalBilling434567 sandbox #A4D369E8-0001

อีเมลนี้ถูกส่งต่อไปยัง abuse@microsoft.com เนื่องจากดูเหมือนว่าจะเป็นความพยายามฟิชชิง ปัญหาคืออะไร? จริงๆ แล้วอีเมลนี้มาจากสภาพแวดล้อมแซนด์บ็อกซ์ของ PayPal แต่การออกแบบเทมเพลตของพวกเขาแย่มากจนทำให้ระบบตรวจจับฟิชชิงทำงาน

การใช้งานของเรา

คุณสามารถดูการกรองเฉพาะ PayPal ของเราที่นำไปใช้งานใน รหัสการกรองอีเมล ได้:

// check for paypal scam (very strict until PayPal resolves phishing on their end)
// (seems to only come from "outlook.com" and "paypal.com" hosts)
//
// X-Email-Type-Id = RT000238
// PPC001017
// RT000542 = gift message hack
// RT002947 = paypal invoice spam
// <https://www.bleepingcomputer.com/news/security/beware-paypal-new-address-fraud/>
//
if (
  session.originalFromAddressRootDomain === 'paypal.com' &&
  headers.hasHeader('x-email-type-id') &&
  ['PPC001017', 'RT000238', 'RT000542', 'RT002947'].includes(
    headers.getFirst('x-email-type-id')
  )
) {
  const err = new SMTPError(
    'Due to ongoing PayPal invoice spam, you must manually send an invoice link'
  );
  err.isCodeBug = true; // alert admins for inspection
  throw err;
}

เหตุใดเราจึงต้องบล็อก PayPal

เราดำเนินการนี้เนื่องจาก PayPal ปฏิเสธที่จะแก้ไขปัญหาสแปม/ฟิชชิ่ง/การฉ้อโกงจำนวนมาก แม้ว่าเราจะรายงานไปยังทีมดูแลการละเมิดของพวกเขาหลายครั้งแล้วก็ตาม ประเภทอีเมลที่เราบล็อกมีดังนี้:

• RT000238 - การแจ้งเตือนใบแจ้งหนี้ที่น่าสงสัย
• PPC001017 - การยืนยันการชำระเงินที่มีปัญหา
• RT000542 - ความพยายามแฮ็กข้อความของขวัญ

ขนาดของปัญหา

บันทึกการกรองสแปมของเราแสดงให้เห็นถึงปริมาณสแปมใบแจ้งหนี้ PayPal จำนวนมากที่เราประมวลผลทุกวัน ตัวอย่างของหัวข้อที่ถูกบล็อก ได้แก่:

• "ใบแจ้งหนี้จากทีมเรียกเก็บเงิน PayPal: ค่าใช้จ่ายนี้จะถูกหักจากบัญชีของคุณโดยอัตโนมัติ โปรดติดต่อเราทันทีที่ [โทรศัพท์]"
• "ใบแจ้งหนี้จาก [ชื่อบริษัท] ([รหัสคำสั่งซื้อ])"
• มีหลายรูปแบบพร้อมหมายเลขโทรศัพท์และรหัสคำสั่งซื้อปลอมที่แตกต่างกัน

อีเมลเหล่านี้มักมาจากโฮสต์ outlook.com แต่ดูเหมือนว่าจะมาจากระบบที่ถูกต้องตามกฎหมายของ PayPal ซึ่งทำให้อีเมลเหล่านี้เป็นอันตรายอย่างยิ่ง อีเมลเหล่านี้ผ่านการตรวจสอบสิทธิ์ SPF, DKIM และ DMARC เนื่องจากส่งผ่านโครงสร้างพื้นฐานจริงของ PayPal

บันทึกทางเทคนิคของเราแสดงให้เห็นว่าอีเมลขยะเหล่านี้มีส่วนหัว PayPal ที่ถูกต้องตามกฎหมาย:

• X-Email-Type-Id: RT000238 (ID เดียวกับที่เราบล็อก)
• From: "service@paypal.com" <service@paypal.com>
• ลายเซ็น DKIM ที่ถูกต้องจาก paypal.com
• บันทึก SPF ที่ถูกต้องซึ่งแสดงเซิร์ฟเวอร์อีเมลของ PayPal

สิ่งนี้สร้างสถานการณ์ที่เป็นไปไม่ได้: อีเมล PayPal ที่ถูกกฎหมายและสแปมต่างก็มีลักษณะทางเทคนิคที่เหมือนกัน

ความขัดแย้ง

PayPal บริษัทที่ควรเป็นผู้นำในการต่อสู้กับการฉ้อโกงทางการเงิน กลับมีเทมเพลตอีเมลที่ออกแบบมาไม่ดีนักจนทำให้ระบบป้องกันฟิชชิ่งทำงานผิดปกติ เราถูกบังคับให้บล็อกอีเมล PayPal ที่ถูกต้องตามกฎหมาย เพราะอีเมลเหล่านี้แยกแยะไม่ออกจากการหลอกลวง

สิ่งนี้ได้รับการบันทึกไว้ในงานวิจัยด้านความปลอดภัย: ระวังการฉ้อโกงที่อยู่ใหม่ของ PayPal - แสดงให้เห็นว่าระบบของ PayPal ถูกใช้ประโยชน์เพื่อการฉ้อโกงอย่างไร

ผลกระทบในโลกแห่งความเป็นจริง: การหลอกลวง PayPal แบบใหม่

ปัญหาไม่ได้จำกัดอยู่แค่การออกแบบเทมเพลตที่ไม่ดีเท่านั้น ระบบใบแจ้งหนี้ของ PayPal ถูกนำไปใช้ประโยชน์ได้ง่ายมาก จนมิจฉาชีพมักใช้ประโยชน์จากระบบนี้เพื่อส่งใบแจ้งหนี้ปลอมที่ดูเหมือนถูกต้องตามกฎหมาย นักวิจัยด้านความปลอดภัย Gavin Anderegg ได้บันทึกเหตุการณ์ กลโกง PayPal แบบใหม่ ที่มิจฉาชีพส่งใบแจ้งหนี้ PayPal จริงที่ผ่านการตรวจสอบสิทธิ์ทั้งหมด:

"เมื่อตรวจสอบแหล่งที่มา อีเมลนั้นดูเหมือนมาจาก PayPal จริงๆ (ผ่าน SPF, DKIM และ DMARC ทั้งหมด) ปุ่มยังเชื่อมโยงกับสิ่งที่ดูเหมือน URL ของ PayPal ที่ถูกต้อง... ฉันใช้เวลาสักครู่จึงรู้ว่าเป็นอีเมลที่ถูกต้อง ฉันเพิ่งได้รับ 'ใบแจ้งหนี้' แบบสุ่มจากมิจฉาชีพ"

นักวิจัยตั้งข้อสังเกตว่า:

"ดูเหมือนว่าฟีเจอร์อำนวยความสะดวกนี้ PayPal ควรพิจารณาปิดตัวลงด้วย ผมคิดทันทีว่านี่เป็นกลโกงรูปแบบหนึ่ง และสนใจแค่รายละเอียดทางเทคนิคเท่านั้น ดูเหมือนจะทำได้ง่ายเกินไป และผมกังวลว่าคนอื่นอาจตกเป็นเหยื่อ"

สิ่งนี้แสดงให้เห็นปัญหาได้อย่างสมบูรณ์แบบ: ระบบที่ถูกกฎหมายของ PayPal เองได้รับการออกแบบมาไม่ดีนัก ทำให้สามารถฉ้อโกงได้ ขณะเดียวกันก็ทำให้การสื่อสารที่ถูกกฎหมายดูน่าสงสัย

ยิ่งไปกว่านั้น เรื่องนี้ยังส่งผลกระทบต่อความสามารถในการส่งมอบสินค้าของเราผ่าน Yahoo ส่งผลให้ลูกค้าร้องเรียนและต้องใช้เวลานานในการทดสอบและตรวจสอบรูปแบบอย่างพิถีพิถัน

กระบวนการ KYC ย้อนหลังของ PayPal

หนึ่งในสิ่งที่น่าหงุดหงิดที่สุดของแพลตฟอร์ม PayPal คือแนวทางที่ล้าหลังในการปฏิบัติตามกฎระเบียบและกระบวนการรู้จักลูกค้า (KYC) PayPal แตกต่างจากผู้ให้บริการชำระเงินรายอื่นๆ ตรงที่อนุญาตให้นักพัฒนาผสานรวม API และเริ่มรับชำระเงินในขั้นตอนการผลิตก่อนที่จะดำเนินการตรวจสอบความถูกต้องอย่างถูกต้อง

วิธีการทำงาน

ผู้ประมวลผลการชำระเงินที่ถูกกฎหมายทุกคนปฏิบัติตามลำดับตรรกะนี้:

1. ทำการยืนยัน KYC ให้เสร็จสมบูรณ์ก่อน
2. อนุมัติบัญชีผู้ขาย
3. ให้สิทธิ์การเข้าถึง API การผลิต
4. อนุญาตให้รับชำระเงิน

วิธีนี้จะช่วยปกป้องทั้งผู้ประมวลผลการชำระเงินและผู้ค้าโดยรับรองการปฏิบัติตามก่อนที่จะมีการเปลี่ยนเงินใดๆ

PayPal ทำงานอย่างไรจริงๆ

กระบวนการของ PayPal เป็นการย้อนกลับอย่างสิ้นเชิง:

1. ให้สิทธิ์เข้าถึง API การผลิตทันที
2. อนุญาตให้รับชำระเงินได้หลายชั่วโมงหรือหลายวัน
3. ระงับการชำระเงินกะทันหันโดยไม่แจ้งให้ทราบล่วงหน้า
4. ขอเอกสาร KYC หลังจากที่ลูกค้าได้รับผลกระทบแล้ว
5. ไม่ต้องแจ้งให้ร้านค้าทราบ
6. แจ้งให้ลูกค้าทราบถึงปัญหาและรายงาน

ผลกระทบต่อโลกแห่งความเป็นจริง

กระบวนการย้อนกลับนี้ก่อให้เกิดภัยพิบัติต่อธุรกิจ:

• ลูกค้าไม่สามารถทำรายการสั่งซื้อให้เสร็จสมบูรณ์ ในช่วงที่มียอดขายสูงสุด
• ไม่มีการแจ้งเตือนล่วงหน้า ว่าจำเป็นต้องมีการตรวจสอบ
• ไม่มีการแจ้งเตือนทางอีเมล เมื่อการชำระเงินถูกระงับ
• ร้านค้าได้รับแจ้งปัญหาจากลูกค้าที่สับสน
• สูญเสียรายได้ ในช่วงเวลาสำคัญทางธุรกิจ
• ความเสียหายต่อความไว้วางใจของลูกค้า เมื่อการชำระเงินล้มเหลวอย่างไม่ทราบสาเหตุ

ภัยพิบัติการย้ายบัญชีในเดือนกรกฎาคม 2025

สถานการณ์นี้เกิดขึ้นจริงระหว่างการย้ายบัญชีตามปกติของเราในเดือนกรกฎาคม 2568 ในตอนแรก PayPal อนุญาตให้ชำระเงินได้ แต่จู่ๆ ก็ถูกบล็อกโดยไม่มีการแจ้งเตือนใดๆ เราเพิ่งพบปัญหาเมื่อลูกค้าเริ่มรายงานว่าไม่สามารถชำระเงินได้

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

เหตุใดสิ่งนี้จึงสำคัญ

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

กระบวนการย้อนกลับนี้เป็นอาการแสดงของปัญหาองค์กรที่กว้างขวางกว่าของ PayPal: พวกเขาให้ความสำคัญกับกระบวนการภายในมากกว่าประสบการณ์ของผู้ค้าและลูกค้า ซึ่งนำไปสู่หายนะด้านการดำเนินงานที่ทำให้ธุรกิจต่างๆ ห่างหายจากแพลตฟอร์มของตน

วิธีที่ผู้ประมวลผลการชำระเงินรายอื่นทำอย่างถูกต้อง

ฟังก์ชันการสมัครสมาชิกที่ PayPal ปฏิเสธที่จะนำมาใช้นั้น ถือเป็นมาตรฐานในอุตสาหกรรมมานานกว่าทศวรรษแล้ว ต่อไปนี้คือวิธีที่ผู้ให้บริการชำระเงินรายอื่นจัดการกับข้อกำหนดพื้นฐานนี้:

แถบ

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

พาย

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

คอยน์เบสคอมเมิร์ซ

แม้แต่ผู้ประมวลผลการชำระเงินด้วยสกุลเงินดิจิทัลเช่น Coinbase Commerce ก็ยังให้การจัดการการสมัครสมาชิกที่ดีกว่า PayPal

สี่เหลี่ยม

API ของ Square มีรายการสมัครสมาชิกเป็นฟีเจอร์พื้นฐาน ไม่ใช่สิ่งที่คิดขึ้นภายหลัง

มาตรฐานอุตสาหกรรม

ผู้ประมวลผลการชำระเงินสมัยใหม่ทุกรายให้บริการ:

• แสดงรายการการสมัครรับข้อมูลทั้งหมด
• กรองตามสถานะ วันที่ และลูกค้า
• การแบ่งหน้าสำหรับชุดข้อมูลขนาดใหญ่
• การแจ้งเตือน Webhook สำหรับการเปลี่ยนแปลงการสมัครรับข้อมูล
• เอกสารประกอบที่ครอบคลุมพร้อมตัวอย่างการใช้งาน

โปรเซสเซอร์อื่น ๆ ให้บริการอะไรเมื่อเทียบกับ PayPal

Stripe - รายการสมัครสมาชิกทั้งหมด:

GET https://api.stripe.com/v1/subscriptions
Authorization: Bearer sk_test_...

Response:
{
  "object": "list",
  "data": [
    {
      "id": "sub_1MowQVLkdIwHu7ixeRlqHVzs",
      "object": "subscription",
      "status": "active",
      "customer": "cus_Na6dX7aXxi11N4",
      "current_period_start": 1679609767,
      "current_period_end": 1682288167
    }
  ],
  "has_more": false
}

Stripe - กรองตามลูกค้า:

GET https://api.stripe.com/v1/subscriptions?customer=cus_Na6dX7aXxi11N4

ลาย - กรองตามสถานะ:

GET https://api.stripe.com/v1/subscriptions?status=active

PayPal - สิ่งที่คุณจะได้รับจริง:

GET https://api.paypal.com/v1/billing/subscriptions/{id}
Authorization: Bearer access_token

# You can ONLY get ONE subscription if you already know the ID
# There is NO endpoint to list all subscriptions
# There is NO way to search or filter
# You must track all subscription IDs yourself

จุดสิ้นสุดที่ PayPal ใช้ได้:

• POST /v1/billing/subscriptions - สร้างการสมัครสมาชิก
• GET /v1/billing/subscriptions/{id} - รับการสมัครสมาชิกหนึ่งรายการ (หากคุณทราบรหัส)
• PATCH /v1/billing/subscriptions/{id} - อัปเดตการสมัครสมาชิก
• POST /v1/billing/subscriptions/{id}/cancel - ยกเลิกการสมัครสมาชิก
• POST /v1/billing/subscriptions/{id}/suspend - ระงับการสมัครสมาชิก

สิ่งที่ขาดหายไปจาก PayPal:

• ❌ ไม่มี GET /v1/billing/subscriptions (แสดงรายการทั้งหมด)
• ❌ ไม่มีฟังก์ชันการค้นหา
• ❌ ไม่มีการกรองตามสถานะ ลูกค้า และวันที่
• ❌ ไม่รองรับการแบ่งหน้า

PayPal เป็นผู้ประมวลผลการชำระเงินรายใหญ่รายเดียวที่บังคับให้นักพัฒนาติดตาม ID การสมัครสมาชิกในฐานข้อมูลของตนเองด้วยตนเอง

การปกปิดอย่างเป็นระบบของ PayPal: การปิดปาก 6 ล้านเสียง

PayPal ดำเนินการตามแนวทางการจัดการกับคำวิจารณ์ได้อย่างสมบูรณ์แบบ โดยล่าสุดพวกเขาได้ปิดฟอรัมชุมชนทั้งหมด ส่งผลให้สมาชิกกว่า 6 ล้านคนเงียบเสียง และลบโพสต์ที่บันทึกความล้มเหลวของพวกเขาไปหลายแสนข้อความ

การลบครั้งใหญ่

ชุมชน PayPal ดั้งเดิมที่ paypal-community.com มีสมาชิก 6,003,558 คน และมีโพสต์ รายงานข้อบกพร่อง ข้อร้องเรียน และการพูดคุยเกี่ยวกับความล้มเหลวของ API ของ PayPal หลายแสนรายการ สิ่งเหล่านี้ถือเป็นหลักฐานที่ยืนยันถึงปัญหาเชิงระบบของ PayPal มานานกว่าทศวรรษ

เมื่อวันที่ 30 มิถุนายน 2025 PayPal ได้ปิดฟอรัมทั้งหมดอย่างเงียบๆ ลิงก์ paypal-community.com ทั้งหมดแสดงข้อผิดพลาด 404 นี่ไม่ใช่การย้ายหรืออัปเกรด

การช่วยเหลือจากบุคคลที่สาม

โชคดีที่บริการบุคคลที่สามที่ ppl.lithium.com ได้เก็บรักษาเนื้อหาบางส่วนไว้ ทำให้เราสามารถเข้าถึงการสนทนาที่ PayPal พยายามซ่อนไว้ได้ อย่างไรก็ตาม การเก็บรักษาโดยบุคคลที่สามนี้ยังไม่สมบูรณ์และอาจหายไปได้ทุกเมื่อ

รูปแบบการซ่อนหลักฐานแบบนี้ไม่ใช่เรื่องใหม่สำหรับ PayPal พวกเขามีประวัติที่บันทึกไว้ดังนี้:

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

การปิดฟอรัมถือเป็นความพยายามที่หน้าด้านที่สุดในการปกปิดความล้มเหลวอย่างเป็นระบบของตนจากการตรวจสอบของสาธารณะ

ภัยพิบัติการดักจับแมลงที่กินเวลานานถึง 11 ปี: 1,899 ดอลลาร์สหรัฐฯ และยังคงเพิ่มขึ้นเรื่อยๆ

ในขณะที่ PayPal กำลังยุ่งอยู่กับการจัดเซสชันรับฟังความคิดเห็นและให้คำมั่นสัญญา ระบบประมวลผลการชำระเงินหลักของพวกเขากลับมีปัญหาพื้นฐานมานานกว่า 11 ปี หลักฐานที่พิสูจน์ได้นั้นร้ายแรงมาก

ส่งต่ออีเมล ขาดทุน $1,899

ในระบบการผลิตของเรา เราค้นพบการชำระเงินผ่าน PayPal 108 รายการ รวมมูลค่า $1,899 ที่สูญหายไปเนื่องจากความล้มเหลวในการจับภาพของ PayPal การชำระเงินเหล่านี้แสดงให้เห็นถึงรูปแบบที่สอดคล้องกัน:

• ได้รับเว็บฮุก CHECKOUT.ORDER.APPROVED
• API ของ PayPal แสดงผลข้อผิดพลาด 404
• ไม่สามารถเข้าถึงคำสั่งซื้อผ่าน API ของ PayPal ได้

ไม่สามารถระบุได้ว่าลูกค้าถูกเรียกเก็บเงินหรือไม่ เนื่องจาก PayPal ซ่อนบันทึกการดีบักอย่างสมบูรณ์หลังจากผ่านไป 14 วัน และลบข้อมูลทั้งหมดจากแดชบอร์ดสำหรับ ID คำสั่งซื้อที่ไม่ได้บันทึกไว้

นี่เป็นเพียงธุรกิจเดียว ความเสียหายรวมของผู้ค้าหลายพันรายในช่วง 11 ปีที่ผ่านมา น่าจะมีมูลค่ารวมหลายล้านดอลลาร์

เราจะกล่าวอีกครั้งว่า การสูญเสียรวมของผู้ค้าหลายพันรายในช่วงเวลา 11 ปีขึ้นไป น่าจะมีมูลค่ารวมหลายล้านดอลลาร์

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

รายงานต้นฉบับปี 2013: ความประมาทเลินเล่อมากกว่า 11 ปี

รายงานที่ได้รับการบันทึกไว้เร็วที่สุดของปัญหาที่แน่นอนนี้ปรากฏอยู่ใน Stack Overflow ในเดือนพฤศจิกายน 2013 (เก็บถาวรแล้ว):

"ยังคงได้รับข้อผิดพลาด 404 กับ Rest API เมื่อทำการจับภาพ"

ข้อผิดพลาดที่รายงานในปี 2013 นั้น เหมือนกัน กับข้อผิดพลาดที่ Forward Email พบในปี 2024:

{
  "name": "INVALID_RESOURCE_ID",
  "message": "The requested resource ID was not found",
  "information_link": "https://developer.paypal.com/webapps/developer/docs/api/#INVALID_RESOURCE_ID",
  "debug_id": "e56bae98dcc26"
}

การตอบสนองของชุมชนในปี 2013 บ่งบอกว่า:

"ขณะนี้มีรายงานปัญหาเกี่ยวกับ REST API PayPal กำลังดำเนินการแก้ไขอยู่"

กว่า 11 ปีต่อมา พวกเขายังคง "ดำเนินการในเรื่องนั้น" ต่อไป

การรับเข้าปี 2016: PayPal ทำลาย SDK ของตัวเอง

ในปี 2016 คลังข้อมูล GitHub ของ PayPal ได้บันทึก ความล้มเหลวในการจับภาพขนาดใหญ่ ที่ส่งผลกระทบต่อ PHP SDK อย่างเป็นทางการของพวกเขา ซึ่งขนาดนั้นน่าตกใจมาก:

"ตั้งแต่วันที่ 20 กันยายน 2016 ความพยายามบันทึกข้อมูลของ PayPal ทั้งหมดล้มเหลวด้วยข้อผิดพลาด 'INVALID_RESOURCE_ID - ไม่พบ ID ทรัพยากรที่ร้องขอ' ไม่มีการเปลี่ยนแปลงใดๆ เกิดขึ้นกับการรวม API ระหว่างวันที่ 19 กันยายน ถึง 20 กันยายน ความพยายามบันทึกข้อมูล 100% นับตั้งแต่วันที่ 20 กันยายน ส่งคืนข้อผิดพลาดนี้"

พ่อค้ารายหนึ่งรายงานว่า:

"ฉันมี ความพยายามจับภาพที่ล้มเหลวมากกว่า 1,400 ครั้งในช่วง 24 ชั่วโมงที่ผ่านมา โดยทั้งหมดมีการตอบสนองข้อผิดพลาด INVALID_RESOURCE_ID"

การตอบสนองเบื้องต้นของ PayPal คือการตำหนิผู้ขายและแนะนำให้ติดต่อฝ่ายสนับสนุนด้านเทคนิค หลังจากถูกกดดันอย่างหนัก พวกเขาจึงยอมรับผิด:

"ฉันได้รับการอัปเดตจากนักพัฒนาผลิตภัณฑ์ของเรา พวกเขาสังเกตเห็นว่าในส่วนหัวที่ถูกส่งมา PayPal-Request-ID ถูกส่งมาด้วยอักขระ 42 ตัว แต่ ดูเหมือนว่ามีการเปลี่ยนแปลงล่าสุดเกิดขึ้นโดยจำกัด ID นี้ให้เหลือเพียง 38 ตัวอักษรเท่านั้น"

การยอมรับนี้เผยให้เห็นถึงความประมาทเลินเล่ออย่างเป็นระบบของ PayPal:

1. พวกเขาทำการเปลี่ยนแปลงที่ไม่ได้รับอนุญาต
2. พวกเขาทำลาย SDK อย่างเป็นทางการของตัวเอง
3. พวกเขาโทษผู้ขายก่อน
4. พวกเขายอมรับผิดภายใต้แรงกดดันเท่านั้น

แม้ว่าจะ "แก้ไข" ปัญหาแล้ว แต่พ่อค้าก็ยังคงรายงานว่า:

"อัปเกรด SDK เป็น v1.7.4 แล้ว ปัญหายังคงเกิดขึ้น"

การยกระดับในปี 2024: ยังคงล้มเหลว

รายงานล่าสุดจากชุมชน PayPal ที่ได้รับการอนุรักษ์ไว้แสดงให้เห็นว่าปัญหาได้แย่ลงกว่าเดิม การอภิปรายเดือนกันยายน 2567 (เก็บถาวรแล้ว) ระบุปัญหาเดียวกันนี้:

"ปัญหานี้เพิ่งเริ่มปรากฏให้เห็นเมื่อประมาณ 2 สัปดาห์ที่แล้ว และไม่ส่งผลกระทบต่อคำสั่งซื้อทั้งหมด ปัญหาที่พบบ่อยกว่ามากคือ 404 เมื่อจับภาพ"

พ่อค้าอธิบายรูปแบบเดียวกันของการส่งต่ออีเมลที่พบ:

"หลังจากพยายามจับภาพคำสั่งซื้อ PayPal กลับแสดงข้อผิดพลาด 404 เมื่อดึงข้อมูลรายละเอียดของคำสั่งซื้อ: {'id': 'ID', 'intent': 'CAPTURE', 'status': 'COMPLETED', ..., 'final_capture': true, ...} นี่เป็นข้อมูลที่ไม่มีร่องรอยของการจับภาพที่ประสบความสำเร็จจากฝั่งของเรา"

ภัยพิบัติด้านความน่าเชื่อถือของ Webhook

การสนทนาชุมชนที่เก็บรักษาไว้ อีกกรณีหนึ่งเผยให้เห็นว่าระบบเว็บฮุกของ PayPal นั้นไม่น่าเชื่อถือโดยพื้นฐาน:

"ตามทฤษฎีแล้ว ควรมีเหตุการณ์สองเหตุการณ์ (CHECKOUT.ORDER.APROVED และ PAYMENT.CAPTURE.COMPLETED) จากเหตุการณ์ Webhook อันที่จริงแล้ว เหตุการณ์ทั้งสองนี้แทบจะไม่ได้รับทันที PAYMENT.CAPTURE.COMPLETED ไม่สามารถรับได้ในเวลาส่วนใหญ่ หรืออาจได้รับภายในไม่กี่ชั่วโมง"

สำหรับการชำระเงินค่าสมัครสมาชิก:

"'การชำระเงิน.การขาย.เสร็จสมบูรณ์' ไม่ได้รับบางครั้งหรือจนกระทั่งผ่านไปไม่กี่ชั่วโมง"

คำถามของผู้ค้าเผยให้เห็นถึงปัญหาความน่าเชื่อถือเชิงลึกของ PayPal:

1. "ทำไมถึงเป็นแบบนี้?" - ระบบเว็บฮุกของ PayPal มีปัญหาร้ายแรง
2. "หากสถานะคำสั่งซื้อคือ 'เสร็จสมบูรณ์' ฉันถือว่าได้รับเงินแล้วใช่ไหม?" - ร้านค้าไม่สามารถเชื่อถือการตอบกลับ API ของ PayPal ได้
3. "ทำไม 'บันทึกเหตุการณ์->เหตุการณ์เว็บฮุก' จึงไม่พบบันทึกใดๆ เลย?" - แม้แต่ระบบบันทึกของ PayPal เองก็ใช้งานไม่ได้

รูปแบบของการละเลยอย่างเป็นระบบ

หลักฐานมีอายุมากกว่า 11 ปีและแสดงให้เห็นรูปแบบที่ชัดเจน:

• 2013: "PayPal กำลังดำเนินการแก้ไข"
• 2016: PayPal ยอมรับว่าการเปลี่ยนแปลงที่ผิดพลาด และได้แก้ไขปัญหาที่ผิดพลาดแล้ว
• 2024: ข้อผิดพลาดแบบเดียวกันนี้ยังคงเกิดขึ้น ส่งผลกระทบต่อ Forward Email และอีกนับไม่ถ้วน

นี่ไม่ใช่จุดบกพร่อง - นี่คือการละเลยอย่างเป็นระบบ PayPal ทราบเกี่ยวกับความล้มเหลวในการประมวลผลการชำระเงินที่สำคัญเหล่านี้มานานกว่าทศวรรษแล้วและได้ดำเนินการดังต่อไปนี้อย่างต่อเนื่อง:

1. กล่าวหาร้านค้าว่าเป็นต้นเหตุของบั๊กของ PayPal
2. ทำการเปลี่ยนแปลงที่ทำให้เกิดปัญหาโดยไม่ได้บันทึกไว้
3. แก้ไขอย่างไม่เพียงพอและไม่ได้ผล
4. เพิกเฉยต่อผลกระทบทางการเงินต่อธุรกิจ
5. ปกปิดหลักฐานโดยการปิดฟอรัมชุมชน

ข้อกำหนดที่ไม่มีเอกสาร

เอกสารอย่างเป็นทางการของ PayPal ไม่ได้ระบุว่าผู้ค้าต้องใช้ตรรกะการลองใหม่ (retry logic) สำหรับการดำเนินการบันทึกข้อมูล เอกสารระบุว่าผู้ค้าควร "บันทึกข้อมูลทันทีหลังจากได้รับการอนุมัติ" แต่ไม่ได้ระบุว่า API ของพวกเขาส่งข้อผิดพลาด 404 แบบสุ่ม ซึ่งต้องใช้กลไกการลองใหม่ที่ซับซ้อน

สิ่งนี้บังคับให้พ่อค้าทุกคนต้อง:

• ใช้ตรรกะการลองซ้ำแบบ Exponential Backoff
• จัดการการจัดส่ง Webhook ที่ไม่สอดคล้องกัน
• สร้างระบบการจัดการสถานะที่ซับซ้อน
• ตรวจสอบการบันทึกข้อมูลที่ล้มเหลวด้วยตนเอง

ผู้ประมวลผลการชำระเงินรายอื่นทั้งหมดมี API จับภาพที่เชื่อถือได้ซึ่งทำงานได้ตั้งแต่ครั้งแรก

รูปแบบการหลอกลวงที่กว้างขึ้นของ PayPal

ภัยพิบัติจากการจับภาพเป็นเพียงตัวอย่างหนึ่งของแนวทางเชิงระบบของ PayPal ในการหลอกลวงลูกค้าและซ่อนความล้มเหลวของพวกเขา

การดำเนินการของกรมบริการทางการเงินแห่งนิวยอร์ก

ในเดือนมกราคม พ.ศ. 2568 กรมบริการทางการเงินของนิวยอร์กได้ออก การดำเนินการบังคับใช้กฎหมายต่อ PayPal สำหรับการกระทำที่หลอกลวง โดยแสดงให้เห็นว่ารูปแบบการหลอกลวงของ PayPal ขยายออกไปไกลเกินกว่า API ของพวกเขา

การดำเนินการด้านกฎระเบียบนี้แสดงให้เห็นถึงความเต็มใจของ PayPal ที่จะใช้วิธีการหลอกลวงในธุรกิจทั้งหมด ไม่ใช่แค่เครื่องมือสำหรับนักพัฒนาเท่านั้น

คดีน้ำผึ้ง: การเขียนลิงก์พันธมิตรใหม่

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

รูปแบบมีความชัดเจน:

1. API ล้มเหลว: ซ่อนฟังก์ชันการทำงานที่มีปัญหา โทษผู้ขาย
2. การปิดปากชุมชน: ลบหลักฐานปัญหา
3. การละเมิดกฎระเบียบ: มีส่วนร่วมในพฤติกรรมหลอกลวง
4. การขโมยของพันธมิตร: ขโมยค่าคอมมิชชั่นผ่านการจัดการทางเทคนิค

ต้นทุนของความประมาทเลินเล่อของ PayPal

การขาดทุน 1,899 ดอลลาร์จาก Forward Email เป็นเพียงส่วนเล็กน้อยเท่านั้น ลองพิจารณาผลกระทบในวงกว้าง:

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

หากบริการอีเมลขนาดเล็กหนึ่งรายการสูญเสียเงินไปเกือบ 2,000 ดอลลาร์ และปัญหานี้เกิดขึ้นมานานกว่า 11 ปี ส่งผลกระทบต่อผู้ค้าหลายพันราย ความเสียหายทางการเงินรวมทั้งหมดอาจสูงถึง หลายร้อยล้านดอลลาร์

เอกสารโกหก

เอกสารอย่างเป็นทางการของ PayPal มักไม่ได้กล่าวถึงข้อจำกัดและข้อบกพร่องสำคัญที่ผู้ค้าจะพบเจอ ตัวอย่างเช่น:

• Capture API: ไม่ได้ระบุว่าข้อผิดพลาด 404 เป็นเรื่องปกติและต้องใช้ตรรกะการลองใหม่
• ความน่าเชื่อถือของเว็บฮุก: ไม่ได้ระบุว่าเว็บฮุกมักจะล่าช้าเป็นชั่วโมง
• รายการสมัครสมาชิก: เอกสารระบุว่ารายการสามารถทำได้เมื่อไม่มีจุดสิ้นสุด
• การหมดเวลาเซสชัน: ไม่ได้ระบุว่ามีการหมดเวลาที่เข้มงวดถึง 60 วินาที

การละเว้นข้อมูลที่สำคัญอย่างเป็นระบบนี้บังคับให้ผู้ค้าต้องค้นพบข้อจำกัดของ PayPal ผ่านการลองผิดลองถูกในระบบการผลิต ซึ่งมักส่งผลให้เกิดการสูญเสียทางการเงิน

สิ่งนี้หมายถึงอะไรสำหรับนักพัฒนา

ความล้มเหลวอย่างเป็นระบบของ PayPal ในการตอบสนองความต้องการพื้นฐานของนักพัฒนาซอฟต์แวร์ พร้อมกับการรวบรวมคำติชมจำนวนมาก แสดงให้เห็นถึงปัญหาพื้นฐานด้านการจัดการ พวกเขาถือว่าการรวบรวมคำติชมเป็นเพียงการแก้ปัญหาที่แท้จริง

รูปแบบมีความชัดเจน:

1. นักพัฒนารายงานปัญหา
2. PayPal จัดการประชุมรับฟังความคิดเห็นกับผู้บริหาร
3. มีการให้ข้อเสนอแนะอย่างกว้างขวาง
4. ทีมรับทราบข้อบกพร่องและสัญญาว่าจะ "ติดตามและแก้ไข"
5. ไม่มีการดำเนินการใดๆ เลย
6. ผู้บริหารลาออกเพื่อไปทำงานกับบริษัทที่ดีกว่า
7. ทีมใหม่ขอข้อเสนอแนะแบบเดิม
8. วงจรซ้ำซาก

ในขณะเดียวกัน นักพัฒนาถูกบังคับให้สร้างทางแก้ปัญหา ลดการรักษาความปลอดภัย และจัดการกับ UI ที่เสียหายเพียงเพื่อยอมรับการชำระเงิน

หากคุณกำลังสร้างระบบการชำระเงิน ลองเรียนรู้จากประสบการณ์ของเรา: สร้าง แนวทางสามประการ ของคุณด้วยโปรเซสเซอร์หลายตัว แต่อย่าคาดหวังว่า PayPal จะมีฟังก์ชันพื้นฐานที่คุณต้องการ วางแผนสร้างวิธีแก้ปัญหาตั้งแต่วันแรก

โพสต์นี้บันทึกประสบการณ์ 11 ปีของเรากับ API ของ PayPal ที่ Forward Email ตัวอย่างโค้ดและลิงก์ทั้งหมดมาจากระบบที่ใช้งานจริงของเรา เรายังคงรองรับการชำระเงินผ่าน PayPal แม้จะมีปัญหาเหล่านี้ เนื่องจากลูกค้าบางรายไม่มีทางเลือกอื่น