Thảm họa API kéo dài 11 năm của PayPal: Cách chúng tôi xây dựng các giải pháp thay thế trong khi họ bỏ qua các nhà phát triển

Trình duyệt của bạn không hỗ trợ thẻ video.

Trình duyệt của bạn không hỗ trợ thẻ video.

Sự cố SDK

• Không thể xử lý cả thanh toán một lần và đăng ký mà không cần giải pháp phức tạp liên quan đến việc hoán đổi và hiển thị lại các nút trong khi tải lại SDK bằng thẻ script
• JavaScript SDK vi phạm các quy ước cơ bản (tên lớp viết thường, không kiểm tra phiên bản)
• Thông báo lỗi không cho biết trường nào bị thiếu
• Kiểu dữ liệu không nhất quán (yêu cầu số lượng chuỗi thay vì số)

Vi phạm Chính sách bảo mật nội dung

SDK của họ yêu cầu unsafe-inline và unsafe-eval trong CSP của bạn, buộc bạn phải đánh đổi tính bảo mật của trang web.

Tài liệu hỗn loạn

Bản thân Mark Stuart đã thừa nhận:

Đồng ý là có quá nhiều API cũ và mới. Thật khó để tìm ra thứ cần tìm (ngay cả với những người làm việc ở đây).

Lỗ hổng bảo mật

Việc triển khai 2FA của PayPal khá lạc hậu. Ngay cả khi bật ứng dụng TOTP, chúng vẫn buộc phải xác minh qua SMS - khiến tài khoản dễ bị tấn công hoán đổi SIM. Nếu bạn đã bật TOTP, ứng dụng sẽ chỉ sử dụng phương thức này. Phương án dự phòng nên là email, không phải SMS.

Thảm họa quản lý phiên

Bảng điều khiển dành cho nhà phát triển của họ sẽ đăng xuất bạn sau 60 giây không hoạt động. Thử làm bất cứ điều gì có ích thì bạn liên tục phải trải qua các bước sau: đăng nhập → nhập captcha → xác thực hai bước → đăng xuất → lặp lại. Bạn đang sử dụng VPN? Chúc may mắn.

Tháng 7 năm 2025: Giọt nước tràn ly

Sau 11 năm gặp phải những vấn đề tương tự, điểm đột phá đã đến trong quá trình di chuyển tài khoản định kỳ. Chúng tôi cần chuyển sang một tài khoản PayPal mới để phù hợp với tên công ty "Forward Email LLC" nhằm đảm bảo tính minh bạch trong kế toán.

Những điều tưởng chừng đơn giản lại trở thành một thảm họa hoàn toàn:

• Kiểm tra ban đầu cho thấy mọi thứ hoạt động bình thường
• Vài giờ sau, PayPal đột nhiên chặn tất cả các khoản thanh toán đăng ký mà không báo trước
• Khách hàng không thể thanh toán, gây nhầm lẫn và gánh nặng hỗ trợ
• Bộ phận hỗ trợ của PayPal đưa ra phản hồi trái chiều, khẳng định tài khoản đã được xác minh
• Chúng tôi buộc phải dừng hoàn toàn các khoản thanh toán qua PayPal

Tại sao chúng ta không thể bỏ PayPal

Bất chấp tất cả những vấn đề này, chúng tôi không thể hoàn toàn từ bỏ PayPal vì một số khách hàng chỉ sử dụng PayPal làm phương thức thanh toán. Như một khách hàng đã nói trên trang trạng thái của chúng tôi:

PayPal là lựa chọn thanh toán duy nhất của tôi

Chúng tôi bị mắc kẹt khi hỗ trợ một nền tảng bị lỗi vì PayPal đã tạo ra sự độc quyền thanh toán cho một số người dùng nhất định.

Giải pháp thay thế của cộng đồng

Vì PayPal không cung cấp chức năng liệt kê đăng ký cơ bản, cộng đồng nhà phát triển đã xây dựng các giải pháp thay thế. Chúng tôi đã tạo một tập lệnh giúp quản lý đăng ký PayPal: set-active-pypl-subscription-ids.js

Tập lệnh này tham chiếu đến ý chính của cộng đồng, nơi các nhà phát triển chia sẻ giải pháp. Người dùng thực ra là cảm ơn chúng tôi vì đã cung cấp những gì PayPal đáng lẽ phải xây dựng từ nhiều năm trước.

Đang chặn các mẫu PayPal do lừa đảo

Vấn đề không chỉ nằm ở API. Các mẫu email của PayPal được thiết kế kém đến mức chúng tôi phải triển khai bộ lọc cụ thể trong dịch vụ email của mình vì chúng không thể phân biệt được với các nỗ lực lừa đảo.

Vấn đề thực sự: Các mẫu của PayPal trông giống như lừa đảo

Chúng tôi thường xuyên nhận được báo cáo về các email PayPal trông giống hệt các nỗ lực lừa đảo. Dưới đây là một ví dụ thực tế từ các báo cáo lạm dụng của chúng tôi:

Chủ đề: [Sandbox] TEST - New invoice from PaypalBilling434567 sandbox #A4D369E8-0001

Email này đã được chuyển tiếp đến abuse@microsoft.com vì có vẻ như đây là một nỗ lực lừa đảo. Vấn đề là gì? Thực ra, nó đến từ môi trường sandbox của PayPal, nhưng thiết kế mẫu của họ quá kém đến mức kích hoạt hệ thống phát hiện lừa đảo.

Triển khai của chúng tôi

Bạn có thể thấy bộ lọc dành riêng cho PayPal của chúng tôi được triển khai trong mã lọc email:

// 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;
}

Tại sao chúng tôi phải chặn PayPal

Chúng tôi thực hiện điều này vì PayPal từ chối khắc phục các vấn đề spam/lừa đảo/gian lận nghiêm trọng mặc dù chúng tôi đã nhiều lần báo cáo với nhóm xử lý vi phạm của họ. Các loại email cụ thể mà chúng tôi chặn bao gồm:

• RT000238 - Thông báo hóa đơn đáng ngờ
• PPC001017 - Xác nhận thanh toán có vấn đề
• RT000542 - Nỗ lực hack tin nhắn quà tặng

Mức độ của vấn đề

Nhật ký lọc thư rác của chúng tôi cho thấy khối lượng lớn thư rác hóa đơn PayPal mà chúng tôi xử lý hàng ngày. Ví dụ về các chủ đề bị chặn bao gồm:

• "Hóa đơn từ Nhóm Thanh toán PayPal: Khoản phí này sẽ được tự động trừ vào tài khoản của bạn. Vui lòng liên hệ ngay với chúng tôi theo số [ĐIỆN THOẠI]"
• "Hóa đơn từ [TÊN CÔNG TY] ([MÃ ĐƠN HÀNG])"
• Nhiều biến thể với số điện thoại khác nhau và mã đơn hàng giả

Những email này thường đến từ các máy chủ outlook.com nhưng dường như xuất phát từ các hệ thống hợp pháp của PayPal, khiến chúng đặc biệt nguy hiểm. Các email này vượt qua được xác thực SPF, DKIM và DMARC vì chúng được gửi qua cơ sở hạ tầng thực tế của PayPal.

Nhật ký kỹ thuật của chúng tôi cho thấy những email rác này chứa tiêu đề PayPal hợp pháp:

• X-Email-Type-Id: RT000238 (cùng ID chúng tôi chặn)
• From: "service@paypal.com" <service@paypal.com>
• Chữ ký DKIM hợp lệ từ paypal.com
• Bản ghi SPF phù hợp hiển thị máy chủ thư của PayPal

Điều này tạo ra một tình huống không thể xảy ra: cả email PayPal hợp pháp và thư rác đều có đặc điểm kỹ thuật giống hệt nhau.

Sự trớ trêu

PayPal, một công ty đáng lẽ phải đi đầu trong cuộc chiến chống gian lận tài chính, lại có các mẫu email được thiết kế kém đến mức kích hoạt hệ thống chống lừa đảo. Chúng tôi buộc phải chặn các email PayPal hợp lệ vì chúng không thể phân biệt được với lừa đảo.

Điều này được ghi lại trong nghiên cứu bảo mật: Hãy cẩn thận với lừa đảo địa chỉ mới của PayPal - cho thấy hệ thống của PayPal bị khai thác để gian lận như thế nào.

Tác động thực tế: Các vụ lừa đảo PayPal mới

Vấn đề không chỉ nằm ở thiết kế mẫu kém. Hệ thống hóa đơn của PayPal dễ bị khai thác đến mức kẻ lừa đảo thường xuyên lợi dụng nó để gửi các hóa đơn giả mạo trông có vẻ hợp lệ. Nhà nghiên cứu bảo mật Gavin Anderegg đã ghi nhận trường hợp Một trò lừa đảo mới của PayPal, trong đó kẻ lừa đảo gửi hóa đơn PayPal thật vượt qua mọi bước kiểm tra xác thực:

"Kiểm tra nguồn gốc, email trông giống như được gửi từ PayPal (SPF, DKIM và DMARC đều vượt qua). Nút này cũng liên kết đến một URL trông giống như URL PayPal hợp lệ... Phải mất một giây tôi mới nhận ra đó là email hợp lệ. Tôi vừa nhận được một 'hóa đơn' ngẫu nhiên từ một kẻ lừa đảo."

Nhà nghiên cứu lưu ý:

"Có vẻ như đây cũng là một tính năng tiện lợi mà PayPal nên cân nhắc khóa lại. Tôi ngay lập tức cho rằng đây là một hình thức lừa đảo và chỉ quan tâm đến các chi tiết kỹ thuật. Việc này có vẻ quá dễ dàng, và tôi lo rằng những người khác có thể mắc bẫy."

Điều này minh họa rõ ràng vấn đề: Hệ thống hợp pháp của PayPal được thiết kế rất kém đến mức tạo điều kiện cho gian lận xảy ra đồng thời khiến các giao tiếp hợp pháp trở nên đáng ngờ.

Tệ hơn nữa, điều này ảnh hưởng đến khả năng phân phối của chúng tôi tới Yahoo, khiến khách hàng phàn nàn và mất nhiều giờ thử nghiệm và kiểm tra mẫu tỉ mỉ.

Quy trình KYC ngược của PayPal

Một trong những khía cạnh gây khó chịu nhất của nền tảng PayPal là cách tiếp cận lạc hậu của họ đối với quy trình tuân thủ và quy trình Hiểu biết Khách hàng (KYC). Không giống như mọi bộ xử lý thanh toán khác, PayPal cho phép các nhà phát triển tích hợp API của họ và bắt đầu thu tiền trong quá trình sản xuất trước khi hoàn tất xác minh đúng cách.

Cách thức hoạt động

Mọi bộ xử lý thanh toán hợp pháp đều tuân theo trình tự logic sau:

1. Hoàn tất xác minh KYC trước
2. Phê duyệt tài khoản người bán
3. Cung cấp quyền truy cập API sản xuất
4. Cho phép thu tiền

Điều này bảo vệ cả bên xử lý thanh toán và bên bán bằng cách đảm bảo tuân thủ trước khi giao dịch.

PayPal thực sự hoạt động như thế nào

Quy trình của PayPal hoàn toàn ngược lại:

1. Cung cấp quyền truy cập API sản xuất ngay lập tức
2. Cho phép thu tiền trong nhiều giờ hoặc nhiều ngày
3. Đột ngột chặn thanh toán mà không cần thông báo trước
4. Yêu cầu cung cấp tài liệu KYC sau khi khách hàng đã bị ảnh hưởng
5. Không thông báo cho người bán
6. Cho phép khách hàng tự phát hiện sự cố và báo cáo

Tác động thực tế

Quá trình ngược này gây ra thảm họa cho doanh nghiệp:

• Khách hàng không thể hoàn tất giao dịch mua trong thời gian cao điểm bán hàng
• Không có cảnh báo trước về việc cần xác minh
• Không có thông báo qua email khi thanh toán bị chặn
• Nhà cung cấp biết được sự cố từ khách hàng đang bối rối
• Mất doanh thu trong thời gian kinh doanh quan trọng
• Niềm tin của khách hàng bị tổn hại khi thanh toán không thành công một cách bí ẩn

Thảm họa di chuyển tài khoản tháng 7 năm 2025

Tình huống chính xác này đã xảy ra trong quá trình di chuyển tài khoản định kỳ của chúng tôi vào tháng 7 năm 2025. Ban đầu, PayPal cho phép thanh toán, nhưng sau đó đột nhiên chặn mà không hề thông báo. Chúng tôi chỉ phát hiện ra vấn đề khi khách hàng bắt đầu báo cáo rằng họ không thể thanh toán.

Khi liên hệ với bộ phận hỗ trợ, chúng tôi nhận được những phản hồi trái chiều về các tài liệu cần thiết, không có thời hạn giải quyết rõ ràng. Điều này buộc chúng tôi phải tạm dừng hoàn toàn việc thanh toán qua PayPal, gây hoang mang cho khách hàng vì họ không có lựa chọn thanh toán nào khác.

Tại sao điều này quan trọng

Cách tiếp cận tuân thủ của PayPal cho thấy sự hiểu lầm cơ bản về cách thức hoạt động của doanh nghiệp. KYC đúng cách nên được thực hiện trước khi tích hợp sản xuất, chứ không phải sau khi khách hàng đã cố gắng thanh toán. Việc thiếu giao tiếp chủ động khi phát sinh vấn đề cho thấy PayPal không đáp ứng được nhu cầu của người bán.

Quá trình ngược này là triệu chứng của các vấn đề tổ chức rộng hơn của PayPal: họ ưu tiên các quy trình nội bộ hơn trải nghiệm của người bán và khách hàng, dẫn đến những thảm họa hoạt động khiến doanh nghiệp tránh xa nền tảng của họ.

Cách thức hoạt động đúng đắn của từng bộ xử lý thanh toán khác

Chức năng liệt kê đăng ký mà PayPal từ chối triển khai đã trở thành tiêu chuẩn trong ngành trong hơn một thập kỷ. Sau đây là cách các bộ xử lý thanh toán khác xử lý yêu cầu cơ bản này:

Sọc

Stripe đã có danh sách đăng ký kể từ khi API của họ ra mắt. Tài liệu hướng dẫn của họ trình bày rõ ràng cách lấy tất cả các đăng ký cho tài khoản khách hàng hoặc tài khoản thương gia. Đây được coi là chức năng CRUD cơ bản.

Mái chèo

Paddle cung cấp các API quản lý đăng ký toàn diện, bao gồm danh sách, lọc và phân trang. Họ hiểu rằng các nhà bán hàng cần theo dõi các luồng doanh thu định kỳ của mình.

Coinbase Commerce

Ngay cả các bộ xử lý thanh toán bằng tiền điện tử như Coinbase Commerce cũng cung cấp dịch vụ quản lý đăng ký tốt hơn PayPal.

Hình vuông

API của Square bao gồm danh sách đăng ký như một tính năng cơ bản, không phải là tính năng bổ sung.

Tiêu chuẩn công nghiệp

Mọi bộ xử lý thanh toán hiện đại đều cung cấp:

• Liệt kê tất cả các đăng ký
• Lọc theo trạng thái, ngày tháng, khách hàng
• Phân trang cho các tập dữ liệu lớn
• Thông báo webhook về các thay đổi đăng ký
• Tài liệu toàn diện với các ví dụ thực tế

Các bộ xử lý khác cung cấp gì so với PayPal

Stripe - Liệt kê tất cả các đăng ký:

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 - Lọc theo Khách hàng:

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

Sọc - Lọc theo Trạng thái:

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

PayPal - Những gì bạn thực sự nhận được:

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

Các điểm cuối khả dụng của PayPal:

• POST /v1/billing/subscriptions - Tạo đăng ký
• GET /v1/billing/subscriptions/{id} - Nhận MỘT đăng ký (nếu bạn biết ID)
• PATCH /v1/billing/subscriptions/{id} - Cập nhật đăng ký
• POST /v1/billing/subscriptions/{id}/cancel - Hủy đăng ký
• POST /v1/billing/subscriptions/{id}/suspend - Tạm dừng đăng ký

Những gì còn thiếu trong PayPal:

• ❌ Không có GET /v1/billing/subscriptions (liệt kê tất cả)
• ❌ Không có chức năng tìm kiếm
• ❌ Không lọc theo trạng thái, khách hàng, ngày tháng
• ❌ Không hỗ trợ phân trang

PayPal là bộ xử lý thanh toán lớn duy nhất buộc các nhà phát triển phải theo dõi thủ công ID đăng ký trong cơ sở dữ liệu của riêng họ.

Sự che đậy có hệ thống của PayPal: Làm im lặng 6 triệu tiếng nói

Trong một động thái thể hiện hoàn hảo cách tiếp cận của PayPal trong việc xử lý những lời chỉ trích, gần đây họ đã tắt toàn bộ diễn đàn cộng đồng của mình, khiến hơn 6 triệu thành viên im lặng và xóa hàng trăm nghìn bài đăng ghi lại những thất bại của họ.

Sự xóa sổ vĩ đại

Cộng đồng PayPal ban đầu tại paypal-community.com đã lưu trữ 6.003.558 thành viên và chứa hàng trăm nghìn bài đăng, báo cáo lỗi, khiếu nại và thảo luận về các lỗi API của PayPal. Điều này đại diện cho hơn một thập kỷ bằng chứng được ghi nhận về các vấn đề mang tính hệ thống của PayPal.

Vào ngày 30 tháng 6 năm 2025, PayPal đã lặng lẽ đưa toàn bộ diễn đàn ngoại tuyến. Tất cả các liên kết paypal-community.com hiện trả về lỗi 404. Đây không phải là bản cập nhật hay nâng cấp.

Giải cứu bên thứ ba

May mắn thay, một dịch vụ của bên thứ ba tại ppl.lithium.com đã lưu giữ một số nội dung, cho phép chúng tôi truy cập các cuộc thảo luận mà PayPal đã cố gắng ẩn. Tuy nhiên, việc lưu giữ của bên thứ ba này chưa hoàn chỉnh và có thể biến mất bất cứ lúc nào.

Mô hình che giấu bằng chứng này không phải là mới đối với PayPal. Họ có lịch sử được ghi nhận về:

• Xóa các báo cáo lỗi nghiêm trọng khỏi chế độ xem công khai
• Ngừng cung cấp các công cụ dành cho nhà phát triển mà không báo trước
• Thay đổi API mà không có tài liệu hướng dẫn phù hợp
• Làm im lặng các cuộc thảo luận của cộng đồng về những lỗi của họ

Việc gỡ bỏ diễn đàn này là nỗ lực trắng trợn nhất từ trước đến nay nhằm che giấu những thất bại có hệ thống của họ khỏi sự giám sát của công chúng.

Thảm họa bắt bọ kéo dài 11 năm: 1.899 đô la và vẫn tiếp tục tăng

Trong khi PayPal bận rộn tổ chức các buổi phản hồi và đưa ra lời hứa, hệ thống xử lý thanh toán cốt lõi của họ đã bị hỏng hoàn toàn trong hơn 11 năm. Bằng chứng thật tàn khốc.

Chuyển tiếp email mất 1.899 đô la

Trong hệ thống sản xuất của chúng tôi, chúng tôi đã phát hiện 108 khoản thanh toán PayPal với tổng giá trị $1.899 bị mất do lỗi xử lý của PayPal. Các khoản thanh toán này cho thấy một mô hình nhất quán:

• Đã nhận được CHECKOUT.ORDER.APPROVED webhooks
• API thu thập của PayPal trả về lỗi 404
• Không thể truy cập đơn hàng thông qua API của PayPal

Không thể xác định liệu khách hàng có bị tính phí hay không vì PayPal ẩn hoàn toàn nhật ký gỡ lỗi sau 14 ngày và xóa toàn bộ dữ liệu khỏi bảng điều khiển đối với ID đơn hàng không được ghi lại.

Con số này chỉ đại diện cho một doanh nghiệp. Tổng thiệt hại của hàng nghìn thương gia trong hơn 11 năm qua có thể lên tới hàng triệu đô la.

Chúng tôi xin nhắc lại một lần nữa: tổng số tiền thua lỗ của hàng nghìn thương gia trong hơn 11 năm qua có thể lên tới hàng triệu đô la.

Lý do duy nhất khiến chúng tôi phát hiện ra điều này là vì chúng tôi cực kỳ tỉ mỉ và dựa trên dữ liệu.

Báo cáo gốc năm 2013: Hơn 11 năm bất cẩn

Báo cáo được ghi chép sớm nhất về vấn đề này xuất hiện trên Stack Overflow vào tháng 11 năm 2013 (đã lưu trữ):

"Tiếp tục nhận được Lỗi 404 với Rest API khi thực hiện chụp"

Lỗi được báo cáo vào năm 2013 giống hệt lỗi mà Forward Email gặp phải vào năm 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"
}

Phản ứng của cộng đồng vào năm 2013 cho thấy:

"Hiện tại đang có báo cáo về sự cố liên quan đến REST API. PayPal đang xử lý sự cố này."

Hơn 11 năm sau, họ vẫn đang "xử lý vấn đề đó".

Bản ghi nhớ năm 2016: PayPal phá vỡ SDK của chính họ

Năm 2016, kho lưu trữ GitHub của PayPal đã ghi nhận lỗi thất bại bắt giữ hàng loạt ảnh hưởng đến SDK PHP chính thức của họ. Quy mô của lỗi này thật đáng kinh ngạc:

"Kể từ ngày 20/9/2016, tất cả các nỗ lực thu thập thông tin PayPal đều không thành công với lỗi 'INVALID_RESOURCE_ID - Không tìm thấy ID tài nguyên được yêu cầu.'. Không có thay đổi nào trong quá trình tích hợp API từ ngày 19/9 đến ngày 20/9. 100% các nỗ lực thu thập thông tin kể từ ngày 20/9 đều trả về lỗi này."

Một thương gia đã báo cáo:

"Tôi đã có hơn 1.400 lần chụp không thành công trong 24 giờ qua, tất cả đều có phản hồi lỗi INVALID_RESOURCE_ID."

Phản ứng ban đầu của PayPal là đổ lỗi cho nhà cung cấp và chuyển họ đến bộ phận hỗ trợ kỹ thuật. Chỉ sau khi chịu áp lực lớn, họ mới thừa nhận lỗi:

"Tôi có thông tin cập nhật từ các Nhà phát triển Sản phẩm của chúng tôi. Họ nhận thấy trong các tiêu đề đang được gửi đi, PayPal-Request-ID được gửi đi với 42 ký tự, nhưng có vẻ như một thay đổi gần đây đã diễn ra, giới hạn ID này chỉ còn 38 ký tự."

Lời thừa nhận này cho thấy sự tắc trách có hệ thống của PayPal:

1. Họ đã thực hiện những thay đổi vi phạm không được ghi chép
2. Họ đã phá hỏng SDK chính thức của mình
3. Họ đổ lỗi cho các nhà cung cấp trước
4. Họ chỉ thừa nhận lỗi khi bị áp lực

Ngay cả sau khi "sửa" được vấn đề, các thương gia vẫn báo cáo:

"Đã nâng cấp SDK lên phiên bản 1.7.4 và vấn đề vẫn xảy ra."

Sự leo thang năm 2024: Vẫn chưa hoàn thành

Các báo cáo gần đây từ Cộng đồng PayPal được bảo tồn cho thấy vấn đề thực sự đã trở nên nghiêm trọng hơn. Thảo luận tháng 9 năm 2024 (đã lưu trữ) ghi lại chính xác những vấn đề tương tự:

"Vấn đề này chỉ mới bắt đầu xuất hiện khoảng 2 tuần trước và không ảnh hưởng đến tất cả các đơn hàng. Lỗi phổ biến hơn có vẻ là lỗi 404 khi chụp."

Người bán hàng mô tả cùng một mô hình mà Forward Email đã trải qua:

"Sau khi cố gắng nắm bắt đơn hàng, PayPal trả về lỗi 404. Khi truy xuất Chi tiết đơn hàng: {'id': 'ID', 'intent': 'CAPTURE', 'status': 'COMPLETED', ..., 'final_capture': true, ...} Điều này không cho thấy bất kỳ dấu hiệu nắm bắt thành công nào từ phía chúng tôi."

Thảm họa về độ tin cậy của Webhook

Một thảo luận cộng đồng được bảo tồn khác cho thấy hệ thống webhook của PayPal về cơ bản là không đáng tin cậy:

"Về mặt lý thuyết, sự kiện Webhook phải có hai sự kiện (CHECKOUT.ORDER.APPROVED và PAYMENT.CAPTURE.COMPLETED). Trên thực tế, hai sự kiện này hiếm khi được nhận ngay lập tức, PAYMENT.CAPTURE.COMPLETED hầu như không thể nhận được hoặc sẽ được nhận trong vài giờ."

Đối với thanh toán đăng ký:

"'THANH TOÁN.BÁN HÀNG.ĐÃ HOÀN THÀNH' đôi khi không nhận được hoặc phải mất vài giờ sau mới nhận được."

Câu hỏi của người bán hàng cho thấy mức độ nghiêm trọng của các vấn đề về độ tin cậy của PayPal:

1. "Tại sao điều này lại xảy ra?" - Hệ thống webhook của PayPal bị lỗi cơ bản.
2. "Nếu trạng thái đơn hàng là 'ĐÃ HOÀN THÀNH', tôi có thể coi như đã nhận được tiền không?" - Người bán không thể tin tưởng phản hồi API của PayPal.
3. "Tại sao 'Nhật ký sự kiện->Sự kiện Webhook' không tìm thấy bất kỳ nhật ký nào?" - Ngay cả hệ thống ghi nhật ký của PayPal cũng không hoạt động

Mô hình của sự cẩu thả có hệ thống

Bằng chứng kéo dài hơn 11 năm và cho thấy một mô hình rõ ràng:

• 2013: "PayPal đang xử lý"
• 2016: PayPal thừa nhận lỗi thay đổi, cung cấp bản sửa lỗi
• 2024: Vẫn xảy ra lỗi tương tự, ảnh hưởng đến Forward Email và vô số lỗi khác

Đây không phải là lỗi - đây là sự cẩu thả có hệ thống. PayPal đã biết về những lỗi xử lý thanh toán quan trọng này trong hơn một thập kỷ và luôn:

1. Đổ lỗi cho các nhà cung cấp về lỗi của PayPal
2. Thực hiện các thay đổi không được ghi chép rõ ràng
3. Cung cấp các bản sửa lỗi không đầy đủ và không hiệu quả
4. Bỏ qua tác động tài chính đối với doanh nghiệp
5. Ẩn bằng chứng bằng cách xóa bỏ các diễn đàn cộng đồng

Yêu cầu không có tài liệu

Không có chỗ nào trong tài liệu chính thức của PayPal đề cập đến việc người bán phải triển khai logic thử lại cho các thao tác thu thập. Tài liệu của họ quy định người bán phải "thu thập ngay sau khi phê duyệt", nhưng lại không đề cập đến việc API của họ ngẫu nhiên trả về lỗi 404, đòi hỏi cơ chế thử lại phức tạp.

Điều này buộc mọi thương gia phải:

• Triển khai logic thử lại theo cấp số nhân
• Xử lý việc phân phối webhook không nhất quán
• Xây dựng hệ thống quản lý trạng thái phức tạp
• Theo dõi thủ công các lần chụp không thành công

Mọi bộ xử lý thanh toán khác đều cung cấp API thu thập dữ liệu đáng tin cậy có thể hoạt động ngay lần đầu tiên.

Mô hình lừa đảo rộng hơn của PayPal

Thảm họa bắt lỗi chỉ là một ví dụ về cách tiếp cận có hệ thống của PayPal nhằm lừa dối khách hàng và che giấu những thất bại của họ.

Hành động của Sở Dịch vụ Tài chính New York

Vào tháng 1 năm 2025, Sở Dịch vụ Tài chính New York đã ban hành hành động thực thi chống lại PayPal về các hành vi lừa đảo, chứng minh rằng mô hình lừa đảo của PayPal không chỉ giới hạn ở API của họ.

Hành động quản lý này cho thấy PayPal sẵn sàng thực hiện các hành vi lừa đảo trên toàn bộ doanh nghiệp của họ, không chỉ riêng các công cụ dành cho nhà phát triển.

Vụ kiện Honey: Viết lại các liên kết liên kết

Việc PayPal mua lại Honey đã dẫn đến các vụ kiện cáo buộc Honey viết lại các liên kết liên kết, đánh cắp hoa hồng từ các nhà sáng tạo nội dung và người có sức ảnh hưởng. Đây là một hình thức lừa đảo có hệ thống khác, trong đó PayPal kiếm lời bằng cách chuyển hướng doanh thu đáng lẽ phải thuộc về người khác.

Mô hình này rất rõ ràng:

1. Lỗi API: Ẩn chức năng bị lỗi, đổ lỗi cho nhà bán hàng
2. Làm im lặng cộng đồng: Xóa bằng chứng về sự cố
3. Vi phạm quy định: Thực hiện các hành vi lừa đảo
4. Trộm cắp liên kết: Ăn cắp hoa hồng thông qua thao túng kỹ thuật

Cái giá phải trả cho sự bất cẩn của PayPal

Khoản lỗ 1.899 đô la của Forward Email chỉ là phần nổi của tảng băng chìm. Hãy xem xét tác động rộng hơn:

• Các thương gia cá nhân: Hàng ngàn người mất từ hàng trăm đến hàng ngàn đô la mỗi người
• Khách hàng doanh nghiệp: Có khả năng mất hàng triệu đô la doanh thu
• Thời gian của nhà phát triển: Vô số giờ xây dựng giải pháp khắc phục sự cố API bị lỗi của PayPal
• Niềm tin của khách hàng: Các doanh nghiệp mất khách hàng do lỗi thanh toán của PayPal

Nếu một dịch vụ email nhỏ mất gần 2.000 đô la và vấn đề này đã tồn tại trong hơn 11 năm, ảnh hưởng đến hàng nghìn thương gia, thì tổng thiệt hại tài chính có thể lên tới hàng trăm triệu đô la.

Tài liệu nằm

Tài liệu chính thức của PayPal thường không đề cập đến những hạn chế và lỗi quan trọng mà người bán sẽ gặp phải. Ví dụ:

• API Capture: Không đề cập đến việc lỗi 404 thường gặp và cần logic thử lại
• Độ tin cậy của webhook: Không đề cập đến việc webhook thường bị trễ hàng giờ
• Danh sách đăng ký: Tài liệu cho thấy việc liệt kê có thể thực hiện được khi không có điểm cuối nào tồn tại
• Hết thời gian phiên: Không đề cập đến việc hết thời gian 60 giây

Việc bỏ sót thông tin quan trọng một cách có hệ thống này buộc các thương gia phải khám phá ra những hạn chế của PayPal thông qua quá trình thử nghiệm trong hệ thống sản xuất, thường dẫn đến tổn thất tài chính.

Điều này có ý nghĩa gì đối với nhà phát triển

Việc PayPal không đáp ứng được nhu cầu cơ bản của nhà phát triển một cách có hệ thống trong khi vẫn thu thập phản hồi rộng rãi cho thấy một vấn đề cốt lõi trong tổ chức. Họ coi việc thu thập phản hồi như một giải pháp thay thế cho việc thực sự khắc phục sự cố.

Mô hình này rất rõ ràng:

1. Các nhà phát triển báo cáo vấn đề
2. PayPal tổ chức các buổi phản hồi với ban điều hành
3. Phản hồi được cung cấp rộng rãi
4. Các nhóm thừa nhận những thiếu sót và hứa sẽ "theo dõi và giải quyết"
5. Không có gì được triển khai
6. Các giám đốc điều hành rời đi để tìm kiếm công ty tốt hơn
7. Các nhóm mới yêu cầu phản hồi tương tự
8. Chu kỳ lặp lại

Trong khi đó, các nhà phát triển buộc phải xây dựng các giải pháp thay thế, đánh đổi bảo mật và xử lý giao diện người dùng bị hỏng chỉ để chấp nhận thanh toán.

Nếu bạn đang xây dựng một hệ thống thanh toán, hãy học hỏi từ kinh nghiệm của chúng tôi: xây dựng cách tiếp cận ba bên với nhiều bộ xử lý, nhưng đừng mong đợi PayPal cung cấp các chức năng cơ bản bạn cần. Hãy lên kế hoạch xây dựng các giải pháp thay thế ngay từ ngày đầu.

Bài viết này ghi lại 11 năm kinh nghiệm của chúng tôi với API PayPal tại Forward Email. Tất cả các ví dụ mã và liên kết đều được lấy từ hệ thống sản xuất thực tế của chúng tôi. Chúng tôi vẫn tiếp tục hỗ trợ thanh toán PayPal bất chấp những vấn đề này vì một số khách hàng không có lựa chọn nào khác.