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

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

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

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

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

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

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

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

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

2014-2017: ปัญหาเริ่มปรากฏ

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

คำตอบของ PayPal? ไม่มีอะไรเลย

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

"การละเว้นที่แปลกมากถ้าพ่อค้าไม่สามารถแสดงรายการข้อตกลงที่ใช้งานอยู่ทั้งหมดได้ ถ้า ID ข้อตกลงหายไป นั่นหมายความว่ามีเพียงผู้ใช้เท่านั้นที่สามารถยกเลิกหรือระงับข้อตกลงได้" - 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 ของพวกเขา เราได้รวบรวมปัญหาเฉพาะ 27 รายการ Mark Stuart จากทีม PayPal Checkout กล่าวว่า:

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

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

1. การสร้าง access token ไม่ทำงาน:

การสร้าง access token ไม่ทำงาน นอกจากนี้ควรมีตัวอย่างมากกว่าการใช้แค่ cURL

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

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

Mark Stuart พบว่าปัญหา access token นั้นน่ากังวลเป็นพิเศษ:

ปกติเราไม่ค่อยได้ยินปัญหาเกี่ยวกับการสร้าง access token

ทีมเข้ามามีส่วนร่วม สัญญาถูกให้ไว้

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

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

การประชุมถูกอธิบายว่าเป็นการ:

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

เพื่อ:

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

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

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

ติดตามและแก้ไข

แต่ก็ไม่มีอะไรได้รับการแก้ไขเลย

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

นี่คือจุดที่น่าสนใจจริง ๆ ทุกคนที่ได้รับข้อเสนอแนะของเราในปี 2020 ได้ออกจาก PayPal ทั้งหมด:

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

• Dan Schulman (CEO 9 ปี) → Alex Chriss (กันยายน 2023)

• Sri Shivananda (CTO ที่จัดการข้อเสนอแนะ) → JPMorgan Chase (มกราคม 2024) ผู้นำทางเทคนิคที่ให้คำมั่นสัญญา แล้วจากไป:

• Mark Stuart (สัญญาว่าจะให้ feedback เป็น "catalyst") → ตอนนี้ที่ Ripple

• Jim Magats (อดีตพนักงาน PayPal 18 ปี) → CEO ของ MX (2022)

• John Kunze (รองประธานฝ่ายผลิตภัณฑ์ผู้บริโภคทั่วโลก) → เกษียณแล้ว (2023)

• Edwin Aoki (หนึ่งในคนสุดท้ายที่เหลืออยู่) → เพิ่งลาออกไป Nasdaq (มกราคม 2025)

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

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

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

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

CEO คนใหม่เข้ามามีส่วนร่วม

เมื่อวันที่ 30 มิถุนายน 2025 เราได้ยกระดับเรื่องไปยัง CEO คนใหม่ของ PayPal คือ Alex Chriss การตอบกลับของเขาสั้นๆ ว่า:

สวัสดี Nick – ขอบคุณที่ติดต่อมาและให้ feedback Michelle (cc'd) รับผิดชอบกับทีมของเธอในการมีส่วนร่วมและแก้ไขเรื่องนี้กับคุณ ขอบคุณ -A

การตอบกลับของ Michelle Gill

Michelle Gill, EVP และผู้จัดการทั่วไปฝ่ายธุรกิจขนาดเล็กและบริการทางการเงิน ตอบกลับว่า:

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

การตอบกลับของเรา: ไม่ต้องการประชุมอีกแล้ว

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

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

การตอบกลับที่ซับซ้อนเกินไปของ Marty Brodbeck

จากนั้น Marty Brodbeck หัวหน้าฝ่ายวิศวกรรมผู้บริโภคของ PayPal ติดต่อมา:

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

เมื่อเราอธิบายความต้องการง่ายๆ คือ endpoint สำหรับรายการสมาชิกแบบ subscription การตอบกลับของเขาเผยให้เห็นปัญหาอย่างชัดเจน:

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

นี่คือแนวทางที่ผิดอย่างสิ้นเชิง เราไม่ต้องการสถาปัตยกรรมที่ซับซ้อนเป็นเดือนๆ เราต้องการแค่ REST endpoint ง่ายๆ ที่แสดงรายการ subscription — สิ่งที่ควรมีมาตั้งแต่ปี 2014

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

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

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

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

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

หาก 'การดำเนินการ CRUD ง่ายๆ เป็นส่วนหนึ่งของ API หลัก' แล้ว endpoint สำหรับการแสดงรายการการสมัครสมาชิกอยู่ที่ไหน? นักพัฒนาต่างถามหาการ 'ดำเนินการ 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: รายงานบั๊กอีเมลธุรกิจ

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

Mark Stuart รับทราบปัญหา:

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

ผลลัพธ์: พวกเขาแก้ไขอันนี้จริงๆ! Mark Stuart ยืนยันว่า:

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

นี่แสดงให้เห็นว่าพวกเขาสามารถแก้ไขได้เมื่ออยากทำ — แต่ส่วนใหญ่เลือกที่จะไม่ทำ

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

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

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

Mark Stuart ส่งต่อให้ทีมผลิตภัณฑ์ผู้บริโภค:

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

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

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

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

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

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

บางครั้งโหลดได้ บางครั้งโหลดไม่ได้ด้วย นี่น่าหงุดหงิดมาก

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

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

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

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

เรายังชี้ให้เห็นถึงความหายนะของการจัดการเซสชัน:

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

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

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

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

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

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

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

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

เอกสาร API ก็ไม่ถูกต้องเลย เราคิดว่าเราสามารถแก้ไขโดยการดาวน์โหลดรายการ ID สมาชิกที่กำหนดไว้ล่วงหน้า แต่สิ่งนั้นก็ไม่ทำงานด้วยซ้ำ!

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

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

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

Sri Shivananda (CTO) ขอบคุณเรา:

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

ผลลัพธ์: เอกสารไม่เคยได้รับการแก้ไข จุดเชื่อมต่อรายการสมาชิกไม่เคยถูกสร้างขึ้น

ฝันร้ายของประสบการณ์นักพัฒนา

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

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

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

ปัญหา SDK

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

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

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

ความสับสนในเอกสาร

Mark Stuart เองก็ยอมรับว่า:

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

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

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

ความหายนะในการจัดการเซสชัน

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

กรกฎาคม 2025: จุดแตกหักครั้งสุดท้าย

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

สิ่งที่ควรจะง่ายกลับกลายเป็นหายนะอย่างสมบูรณ์:

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

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

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

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

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

วิธีแก้ไขชุมชน

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

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

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

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

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

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

หัวข้อ: [Sandbox] TEST - New invoice from PaypalBilling434567 sandbox #A4D369E8-0001

อีเมลนี้ถูกส่งต่อไปยัง abuse@microsoft.com เพราะดูเหมือนเป็นความพยายามฟิชชิ่ง ปัญหาคือ? มันมาจากสภาพแวดล้อม sandbox ของ 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 ปฏิเสธที่จะแก้ไขปัญหาสแปม/ฟิชชิ่ง/การฉ้อโกงจำนวนมากแม้เราจะรายงานซ้ำๆ ไปยังทีม abuse ของพวกเขา ประเภทอีเมลเฉพาะที่เราบล็อกได้แก่:

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

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

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

• "Invoice from PayPal Billing Team:- This charge will be auto-debited from your account. Please contact us immediately at [PHONE]"
• "Invoice from [COMPANY NAME] ([ORDER-ID])"
• หลายรูปแบบที่มีหมายเลขโทรศัพท์และรหัสคำสั่งซื้อปลอมแตกต่างกันหลายแบบ อีเมลเหล่านี้มักมาจากโฮสต์ outlook.com แต่ดูเหมือนจะมีต้นทางจากระบบที่ถูกต้องของ PayPal ทำให้มีความอันตรายเป็นพิเศษ อีเมลเหล่านี้ผ่านการตรวจสอบ SPF, DKIM และ DMARC เพราะถูกส่งผ่านโครงสร้างพื้นฐานจริงของ PayPal

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

• X-Email-Type-Id: RT000238 (รหัสเดียวกับที่เราบล็อก)
• 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

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

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

ทำไมเรื่องนี้ถึงสำคัญ

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

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

วิธีที่ผู้ให้บริการชำระเงินรายอื่นทำได้ถูกต้อง

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

Stripe

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

Paddle

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

Coinbase Commerce

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

Square

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

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

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

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

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

# คุณสามารถรับได้เพียงการสมัครสมาชิกเดียวถ้าคุณรู้ ID อยู่แล้ว
# ไม่มี endpoint สำหรับแสดงรายการการสมัครสมาชิกทั้งหมด
# ไม่มีวิธีค้นหาหรือกรอง
# คุณต้องติดตาม ID การสมัครสมาชิกทั้งหมดด้วยตัวเอง

Endpoints ที่ PayPal มีให้:

• POST /v1/billing/subscriptions - สร้างการสมัครสมาชิก

• GET /v1/billing/subscriptions/{id} - รับการสมัครสมาชิกหนึ่งรายการ (ถ้าคุณรู้ 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 กว่า 10 ปี

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

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

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

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

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

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

ภัยพิบัติบั๊กการจับเงิน 11 ปี: $1,899 และยังเพิ่มขึ้น

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

การสูญเสีย $1,899 ของ Forward Email

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

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

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

นี่เป็นเพียงธุรกิจเดียวเท่านั้น การสูญเสียรวมกันของพ่อค้าออนไลน์หลายพันรายในช่วงกว่า 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 เองได้บันทึก ความล้มเหลวในการจับเงินจำนวนมาก ที่ส่งผลกระทบต่อ SDK PHP อย่างเป็นทางการของพวกเขา ขนาดของปัญหานั้นน่าตกใจ:

"ตั้งแต่วันที่ 20/9/2016 ความพยายามจับเงินทั้งหมดของ PayPal ล้มเหลวพร้อมข้อความ 'INVALID_RESOURCE_ID - Requested resource ID was not found.' ไม่มีการเปลี่ยนแปลงใดๆ ระหว่างวันที่ 19/9 และ 20/9 ในการเชื่อมต่อ API 100% ของความพยายามจับเงินตั้งแต่วันที่ 20/9 ส่งกลับข้อผิดพลาดนี้"

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

"ผมมี ความพยายามจับเงินล้มเหลวมากกว่า 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 ที่เก็บรักษาไว้แสดงให้เห็นว่าปัญหานี้แย่ลงกว่าเดิม การสนทนาใน กันยายน 2024 (เก็บถาวร) บันทึกปัญหาเดียวกันอย่างชัดเจน:

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

พ่อค้าอธิบายรูปแบบเดียวกับที่ Forward Email ประสบ:

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

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

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

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

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

"'PAYMENT.SALE.COMPLETED' บางครั้งไม่ได้รับหรือได้รับล่าช้าเป็นชั่วโมง"

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

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

รูปแบบของความประมาทอย่างเป็นระบบ

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

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

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

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

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

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

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

• นำตรรกะการลองใหม่แบบ exponential backoff มาใช้
• จัดการกับการส่ง webhook ที่ไม่สม่ำเสมอ
• สร้างระบบจัดการสถานะที่ซับซ้อน
• ตรวจสอบการจับเงินที่ล้มเหลวด้วยตนเอง

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

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

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

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

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

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

คดีความ Honey: การเขียนลิงก์พันธมิตรใหม่

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

รูปแบบชัดเจน:

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

ต้นทุนจากความประมาทของ PayPal

ความสูญเสีย 1,899 ดอลลาร์ของ Forward Email เป็นเพียงส่วนเล็ก ๆ ของปัญหา ลองพิจารณาผลกระทบที่กว้างขึ้น:

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

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

การโกหกในเอกสารประกอบ

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

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

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

สิ่งที่หมายถึงสำหรับนักพัฒนา

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

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

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

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

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