贝宝（Paypal）的11年API灾难：我们如何在忽略开发人员的同时建立解决方法
At Forward Email, we've been dealing with PayPal's broken APIs for over a decade. What started as minor frustrations has turned into a complete disaster that forced us to build our own workarounds, block their phishing templates, and ultimately halt all PayPal payments during a critical account migration.
在向前的电子邮件中，我们已经处理了贝宝（Paypal）的API损坏已有十多年了。最初的挫败感已变成了一场完整的灾难，迫使我们建立自己的解决方法，阻止他们的网络钓鱼模板，并最终在关键帐户迁移期间停止所有贝宝付款。
This is the story of 11 years of PayPal ignoring basic developer needs while we tried everything to make their platform work.
这是11年的贝宝（Paypal）的故事，忽略了基本开发人员的需求，而我们尽一切努力使他们的平台工作。
If anyone at PayPal is reading this, please resolve #PP-L-555681076245, #5438494065044876800, and case #15607630 because clearly nobody is paying attention.
如果PayPal的任何人正在阅读此书，请解决＃PP-L-5555681076245，＃5438494065044876800，以及Case＃15607630，因为显然没有人注意。
The Missing Piece: No Way to List Subscriptions
缺少的作品：无法列出订阅
Here's the thing that blows our minds: PayPal has had subscription billing since 2014, but they've never provided a way for merchants to list their own subscriptions.
这是使我们的想法震撼的事情：Paypal自2014年以来就已经进行了订阅帐单，但是他们从未为商人提供列出自己的订阅的方法。
Think about that for a second. You can create subscriptions, you can cancel them if you have the ID, but you can't get a list of all active subscriptions for your account. It's like having a database with no SELECT statement.
考虑一下一秒钟。您可以创建订阅，如果拥有ID，则可以取消它们，但是您无法获得帐户所有活动订阅的列表。这就像没有一个没有选择语句的数据库。
We need this for basic business operations:
我们需要基本业务运营：
Customer support (when someone emails asking about their subscription)
客户支持（当有人发送电子邮件询问其订阅时）
Financial reporting and reconciliation
财务报告与和解
Automated billing management
自动计费管理
Compliance and auditing
合规性和审计
But PayPal? They just... never built it.
但是贝宝呢？他们只是...从来没有建造它。
2014-2017: The Problem Emerges
2014-2017：问题出现
The subscription listing issue first appeared in PayPal's community forums back in 2017. Developers were asking the obvious question:"How do I get a list of all my subscriptions?"
订阅清单问题首先出现在2017年的Paypal社区论坛中。开发人员问一个明显的问题：“我如何获得所有订阅的清单？”
PayPal's response? Crickets.
贝宝的回应？板球。
Community members started getting frustrated:
社区成员开始感到沮丧：
"Very odd omission if a merchant can't list all active Agreements. If the Agreement ID is lost this means only the user can cancel or suspend an agreement." - leafspider
“如果商人无法列出所有主动协议，则非常奇怪的遗漏。如果丢失协议ID，这意味着只有用户可以取消或中止协议。”- 叶子
"+1. It has been almost 3 years." - laudukang (meaning the problem existed since ~2014)
“ +1。已经快3年了。”-Laudukang（这意味着该问题自2014年以来存在）
The original community post from 2017 shows developers begging for this basic functionality. PayPal's response was to archive the repository where people were reporting the issue.
2017年的原始社区帖子显示，开发人员乞求此基本功能。贝宝（Paypal）的回应是归档人们报告该问题的存储库。
2020: We Give Them Extensive Feedback
2020年：我们给他们广泛的反馈
In October 2020, PayPal reached out to us for a formal feedback session. This wasn't some casual chat - they organized a 45-minute Microsoft Teams call with 8 PayPal executives including Sri Shivananda (CTO), Edwin Aoki, Jim Magats, John Kunze, and others.
2020年10月，贝宝（Paypal）与我们联系了正式的反馈会议。这不是休闲聊天 - 他们与8位Paypal高管组织了45分钟的Microsoft团队，包括Sri Shivananda（CTO），Edwin Aoki，Jim Magats，John Kunze等。
The 27-Item Feedback List
27项反馈列表
We came prepared. After 6 hours of trying to integrate with their APIs, we had compiled 27 specific issues. Mark Stuart from the PayPal Checkout team said:
我们做好了准备。经过6个小时的尝试与API集成，我们汇编了27个具体问题。贝宝结帐团队的马克·斯图尔特（Mark Stuart）说：
Hey Nick, thanks for sharing w/ everyone today! I think this will be the catalyst for getting some more support and investment for our team to go and fix these things. It's been difficult to get rich feedback like what you've left us so far.
嘿，尼克，感谢您今天分享大家！我认为这将是为我们的团队提供更多支持和投资来解决这些问题的催化剂。像您到目前为止留下的那样，很难获得丰富的反馈。
The feedback wasn't theoretical - it came from real integration attempts:
反馈不是理论上的 - 它来自真正的集成尝试：
Access token generation not working:
访问令牌一代不起作用：
Access token generation is not working. Also, there should be more than just cURL examples.
访问令牌生成不起作用。另外，不仅应该有卷曲的例子。
No web UI for subscription creation:
没有用于订阅的Web UI：
How the heck can you create subscriptions without having to do it using cURL? There doesn't seem to be a web UI to do this (like Stripe has)
您如何在不用使用卷发的情况下创建订阅而无需进行订阅？似乎没有网络UI可以执行此操作（就像Stripe一样）
Mark Stuart found the access token issue particularly concerning:
马克·斯图尔特（Mark Stuart）发现访问令牌问题特别关注：
We don't typically hear of issues around access token generation.
我们通常不会听到有关访问代币生成的问题。
Teams Got Involved, Promises Were Made
团队参与了诺言
As we discovered more issues, PayPal kept adding more teams to the conversation. Darshan Raju from the Subscriptions management UI team joined and said:
当我们发现更多问题时，PayPal不断在对话中添加更多的团队。订阅管理UI团队的Darshan Raju加入并说：
Acknowledge the gap. We'll track and address this. Thanks again for your feedback!
确认差距。我们将跟踪并解决此问题。再次感谢您的反馈！
The session was described as seeking a:
该会议被描述为寻求：
candid walk through of your experience
坦率地走您的经验
to:
到：
make PayPal what it should be for developers.
使PayPal对开发人员应该是什么。
The Result? Nothing.
结果？没有什么。
Despite the formal feedback session, the extensive 27-item list, multiple team involvement, and promises to:
尽管有正式的反馈会议，但大量的27项列表，多个团队参与，并承诺：
track and address
跟踪和地址
issues, absolutely nothing got fixed.
问题，绝对没有解决。
The Executive Exodus: How PayPal Lost All Institutional Memory
行政逃脱：贝宝如何失去所有机构记忆
Here's where it gets really interesting. Every single person who received our 2020 feedback has left PayPal:
这是真的很有趣的地方。每个收到我们2020年反馈的人都离开了贝宝：
Leadership Changes:
领导力变化：
Technical Leaders Who Made Promises, Then Left:
做出承诺的技术领导者，然后离开：
PayPal has become a revolving door where executives collect developer feedback, make promises, then leave for better companies like JPMorgan, Ripple, and other fintech firms.
贝宝（Paypal）已成为一扇旋转门，高管收集开发商的反馈，做出诺言，然后前往摩根大通，波纹和其他金融科技公司等更好的公司。
This explains why the 2025 GitHub issue response seemed completely disconnected from our 2020 feedback - literally everyone who received that feedback has left PayPal.
这就解释了为什么2025年GitHub问题回应似乎与我们2020年的反馈完全脱节 - 从字面上看，收到该反馈的每个人都离开了PayPal。
2025: New Leadership, Same Problems
2025年：新领导，同样的问题
Fast forward to 2025, and the exact same pattern emerges. After years of no progress, PayPal's new leadership reaches out again.
快进到2025年，并且出现了完全相同的模式。经过多年的进步，PayPal的新领导再次伸出援手。
The New CEO Gets Involved
新首席执行官参与其中
On June 30, 2025, we escalated directly to PayPal's new CEO Alex Chriss. His response was brief:
2025年6月30日，我们直接升级为Paypal的新首席执行官Alex Chriss。他的回答简短：
Hi Nick – Thank you for reaching out and the feedback. Michelle (cc'd) is on point with her team to engage and work through this with you. Thanks -A
嗨，尼克 - 感谢您与您联系和反馈。Michelle（CC'D）与她的团队同时与您互动和合作。谢谢 - A
Michelle Gill's Response
米歇尔·吉尔（Michelle Gill）的回应
Michelle Gill, EVP and General Manager of Small Business and Financial Services, responded:
小型企业和金融服务的执行副总裁兼总经理米歇尔·吉尔（Michelle Gill）回答：
Thanks very much Nick, moving Alex to bcc. We have been looking into this since your earlier post. We will give you a call before the week is out. Can you please send me your contact info so one of my colleagues can reach out. Michelle
非常感谢尼克，将亚历克斯转移到BCC。自您较早的帖子以来，我们一直在研究这一点。我们将在一周结束之前给您打电话。您能给我发送您的联系信息，以便我的一位同事可以伸出援手。米歇尔
Our Response: No More Meetings
我们的回应：不再会议
We declined another meeting, explaining our frustration:
我们拒绝了另一个会议，解释了我们的挫败感：
Thank you. However I don't feel like getting on a call is going to do anything. Here's why... I got on a call in the past and it went absolutely nowhere. I wasted 2+ hours of my time talking to the entire team and leadership and nothing got done... Tons of emails back and forth. Absolutely nothing done. Feedback went nowhere. I tried for years, get listened to, and then it goes nowhere.
谢谢。但是，我不想打个电话会做任何事情。这就是为什么...我过去接过电话，这绝对没有。我浪费了2个小时以上的时间与整个团队交谈和领导力，什么也没做...很多来回的电子邮件。绝对什么也没做。反馈无处可去。我尝试了多年，听了听，然后它一无所获。
Marty Brodbeck's Overengineering Response
马蒂·布罗德贝克（Marty Brodbeck）的过度工程回应
Then Marty Brodbeck, who heads consumer engineering at PayPal, reached out:
然后，在PayPal的消费者工程负责人Marty Brodbeck取得了联系：
Hi Nick, this is Marty Brodbeck. I head up all consumer engineering here at PayPal and have been driving the api development for the company. Can you and I connect on the problem you are facing and how we may help here.
嗨，尼克，这是马蒂·布罗德贝克（Marty Brodbeck）。我在PayPal的所有消费者工程领导，并一直在推动公司的API开发。您和我可以在您面临的问题以及我们如何在这里提供帮助的问题。
When we explained the simple need for a subscription listing endpoint, his response revealed the exact problem:
当我们解释了对订阅清单端点的简单需求时，他的回答揭示了确切的问题：
Thanks Nick, we are in the process of creating a single subscription api with full SDK (supports full error handling, event-based subscription tracking, robust uptime) where billing is also split out as a separate API for merchants to go to rather than having to orchestrate across multiple endpoints to get a single response.
感谢尼克，我们正在创建一个具有完整SDK的单个订阅API（支持完整的错误处理，基于事件的订阅跟踪，健壮的正常运行时间），在该API中，计费也被作为单独的API分开，以便商人可以转到，而不必跨多个端点来获得单个响应。
This is exactly the wrong approach. We don't need months of complex architecture. We need one simple REST endpoint that lists subscriptions - something that should have existed since 2014.
这是错误的方法。我们不需要数月的复杂建筑。我们需要一个列出订阅的简单休息端点，这是自2014年以来应该存在的。
GET /v1/billing/subscriptions Authorization : Bearer {access_token}
get/v1/账单/订阅授权：承载者{access_token}
The"Simple CRUD" Contradiction
“简单的粗糙”矛盾
When we pointed out this was basic CRUD functionality that should have existed since 2014, Marty's response was telling:
当我们指出这是自2014年以来本来应该存在的基本CRUD功能时，Marty的回应说明了：
Simple Crud operations are part of the core API my friend, so it won't take months of development
简单的CRUD操作是我朋友的核心API的一部分，因此不需要几个月的发展
The PayPal TypeScript SDK, which currently supports only three endpoints after months of development, along with its historical timeline, clearly demonstrates that such projects require more than a few months to complete.
PayPal TypeScript SDK目前仅在开发几个月后仅支持三个端点，以及其历史时间表，清楚地表明，此类项目需要超过几个月的时间才能完成。
This response shows he doesn't understand his own API. If"simple CRUD operations are part of the core API," then where is the subscription listing endpoint? We responded:
这一回应表明他不了解自己的API。如果“简单的CRUD操作是核心API的一部分”，那么订阅清单端点在哪里？我们回答：
If 'simple CRUD operations are part of the core API' then where is the subscription listing endpoint? Developers have been asking for this 'simple CRUD operation' since 2014. It's been 11 years. Every other payment processor has had this basic functionality since day one.
如果“简单的CRUD操作是核心API的一部分”，那么订阅清单端点在哪里？自2014年以来，开发人员一直在要求这种“简单的CRUD操作”。已经有11年了。从第一天开始，其他每个付款处理器都具有此基本功能。
The Disconnect Becomes Clear
断开连接变得清晰
The 2025 exchanges with Alex Chriss, Michelle Gill, and Marty Brodbeck show the same organizational dysfunction:
2025年与亚历克斯·克里斯（Alex Chriss），米歇尔·吉尔（Michelle Gill）和马蒂·布罗德贝克（Marty Brodbeck）进行了交流，显示了同样的组织功能障碍：
New leadership has no knowledge of previous feedback sessions They propose the same overengineered solutions They don't understand their own API limitations They want more meetings instead of just fixing the issue
新领导不了解以前的反馈会议，他们提出的是相同的过度工程解决方案，他们不了解自己的API限制，他们想要更多会议，而不仅仅是解决问题
This pattern explains why PayPal teams in 2025 seem completely disconnected from the extensive feedback provided in 2020 - the people who received that feedback are gone, and the new leadership is repeating the same mistakes.
这种模式解释了为什么贝宝团队在2025年似乎与2020年提供的广泛反馈完全脱节 - 收到反馈的人已经消失了，而新的领导层正在重复同样的错误。
Years of Bug Reports They Ignored
他们忽略了多年的错误报告
We didn't just complain about missing features. We actively reported bugs and tried to help them improve. Here's a comprehensive timeline of the issues we documented:
我们不仅抱怨缺少功能。我们积极地报告了错误，并试图帮助他们改善。这是我们记录的问题的全面时间表：
2016: Early UI/UX Complaints
2016：早期UI/UX投诉
Even back in 2016, we were publicly reaching out to PayPal leadership including Dan Schulman about interface problems and usability issues. This was 9 years ago, and the same UI/UX problems persist today.
即使在2016年，我们也公开接触了贝宝（Paypal）领导层，包括丹·舒尔曼（Dan Schulman），讨论界面问题和可用性问题。这是9年前，同样的UI/UX问题今天仍然存在。
2021: Business Email Bug Report
2021：业务电子邮件错误报告
In March 2021, we reported that PayPal's business email system was sending incorrect cancellation notifications. The email template had variables rendered incorrectly, showing confusing messages to customers.
在2021年3月，我们报告说，PayPal的业务电子邮件系统发送了错误的取消通知。电子邮件模板的变量错误地呈现，向客户显示了令人困惑的消息。
Mark Stuart acknowledged the issue:
马克·斯图尔特（Mark Stuart）承认了这个问题：
Thanks Nick! Moving to BCC. @Prasy, is your team responsible for this e-mail or know who is? The"Niftylettuce, LLC, we'll no longer bill you" leads me to believe there's a mix-up in who it's addressed to and the contents of the e-mail.
谢谢尼克！搬到BCC。@prasy，您的团队是对此电子邮件负责的还是知道谁？“ Niftylettuce，LLC，我们将不再向您收费”，这使我相信它的介绍给谁和电子邮件的内容都有混合。
Result: They actually fixed this one! Mark Stuart confirmed:
结果：他们实际上修复了这个！马克·斯图尔特（Mark Stuart）确认：
Just heard from the notifications team that the e-mail template has been fixed and rolled out. Appreciate you reaching out to report it. Thank you!
刚从通知团队那里听说，电子邮件模板已固定并推出。感谢您接触到它。谢谢你！
This shows they CAN fix things when they want to - they just choose not to for most issues.
这表明他们可以在想要的时候修理问题 - 他们只是选择不在大多数问题上。
2021: UI Improvement Suggestions
2021：UI改进建议
In February 2021, we provided detailed feedback on their dashboard UI, specifically the"PayPal Recent Activity" section:
在2021年2月，我们提供了有关其仪表板UI的详细反馈，特别是“ PayPal最近的活动”部分：
I think the dashboard at paypal.com, specifically"PayPal Recent Activity" needs improved. I don't think you should show the $0 Recurring payment"Created" status lines - it just adds a ton of extra lines and you can't easily see at a glance how much income is generating for the day/past few days.
我认为Paypal.com上的仪表板，特别是“ PayPal最近的活动”需求。我认为您不应该显示$ 0的重复付款“创建”状态线 - 它只是增加了很多额外的线路，而且您看一目了然，过去几天的收入会产生多少收入。
Mark Stuart forwarded it to the consumer products team:
马克·斯图尔特（Mark Stuart）将其转发给消费产品团队：
Thanks! I'm not sure what team is responsible for Activity, but I forwarded it to the head of consumer products to find the correct team. A $0.00 recurring payment seems like a bug. Should probably be filtered out.
谢谢！我不确定哪个团队负责活动，但我将其转发给消费产品负责人以找到正确的团队。$ 0.00的重复付款似乎是一个错误。可能应该被过滤掉。
Result: Never fixed. The UI still shows these useless $0 entries.
结果：永不固定。UI仍然显示这些无用的$ 0条目。
2021: Sandbox Environment Failures
2021：沙盒环境故障
In November 2021, we reported critical issues with PayPal's sandbox environment:
在2021年11月，我们报告了Paypal的沙箱环境的关键问题：
Sandbox secret API keys were randomly changed and disabled
沙盒秘密API键随机更改和禁用
All sandbox test accounts were deleted without notice
所有沙盒测试帐户均已删除，恕不另行通知
Error messages when trying to view sandbox account details
尝试查看沙箱帐户详细信息时错误消息
Intermittent loading failures
间歇性加载故障
For some reason my sandbox secret API key was changed and it was Disabled. Also all my old Sandbox test accounts were deleted.
由于某种原因，我的沙盒秘密API密钥已更改，并且被禁用。另外，我所有的旧沙盒测试帐户都已删除。
Sometimes they load and sometimes they don't as well. This is insanely frustrating.
有时它们会加载，有时它们不太好。这是令人沮丧的。
Result: No response, no fix. Developers still face sandbox reliability issues.
结果：没有响应，没有修复。开发人员仍然面临沙盒可靠性问题。
2021: Reports System Completely Broken
2021：报告系统完全破坏了
In May 2021, we reported that PayPal's download system for transaction reports was completely broken:
在2021年5月，我们报告说，PayPal的用于交易报告的下载系统已完全破坏：
Seems like reporting downloads don't work right now and haven't all day. Also should probably get an email notification if it fails.
好像报告下载现在不起作用，而且还没有整天。如果失败，也可能会收到一封电子邮件通知。
We also pointed out the session management disaster:
我们还指出了会议管理灾难：
Also if you're inactive while logged into PayPal for like 5 minutes you get logged out. So when you refresh the button again next to the report you want to check the status of (after you wait forever), it's a pita to have to log back in again.
另外，如果您在登录Paypal时不活动大约5分钟，则可以登录。因此，当您再次刷新报告旁边的按钮时，您想检查（永远等待之后）的状态时，必须重新登录是一个PITA。
Mark Stuart acknowledged the session timeout issue:
马克·斯图尔特（Mark Stuart）确认会议超时问题：
I remember you had reported that in the past w/ your session expiring often and disrupting your development flow while you're switching between your IDE and developer.paypal.com or your merchant dashboard, then you'd come back and be logged out again.
我记得您报告说，过去的会话经常到期，并在IDE和开发人员之间切换时破坏开发流程。
Result: Session timeouts are still 60 seconds. Reports system still fails regularly.
结果：会话超时仍为60秒。报告系统仍然定期失败。
2022: Core API Feature Missing (Again)
2022：核心API功能缺失（再次）
In January 2022, we escalated the subscription listing issue again, this time with even more detail about how their documentation was wrong:
在2022年1月，我们再次升级了订阅列表问题，这次有更多有关其文档如何错误的详细信息：
There is no GET which lists all subscriptions (previously called billing agreements)
没有列出所有订阅（以前称为计费协议）的获取
We discovered their official documentation was completely inaccurate:
我们发现他们的官方文件完全不准确：
The API docs are also totally inaccurate. We thought we could do a workaround by downloading a hard-coded list of subscription ID's. But that doesn't even work!
API文档也完全不准确。我们认为我们可以通过下载硬编码的订阅ID列表来进行解决方法。但这甚至行不通！
From the official docs here... It says you can do this... Here's the kicker- there's no"Subscription ID" field at all anywhere to be found to be checked off.
从这里的官方文档中...它说您可以做到这一点...这是踢脚 - 在任何地方都没有任何“订阅ID”字段可以被检查。
Christina Monti from PayPal responded:
贝宝的克里斯蒂娜·蒙蒂（Christina Monti）回答：
Apologize for the frustrations caused by these steps being wrong, we'll fix that this week.
对于这些步骤是错误的挫败感，我们深表歉意，我们将在本周解决。
Sri Shivananda (CTO) thanked us:
Sri Shivananda（CTO）感谢我们：
Thanks for your continued help in making us better. Much appreciated.
感谢您的持续帮助，使我们变得更好。非常感谢。
Result: Documentation was never fixed. The subscription listing endpoint was never created.
结果：文档从未解决。从未创建订阅清单端点。
The Developer Experience Nightmare
开发人员体验噩梦
Working with PayPal's APIs is like stepping back in time 10 years. Here are the technical issues we've documented:
与PayPal的API合作就像返回10年一样。这是我们记录的技术问题：
Broken User Interface
破损的用户界面
The PayPal developer dashboard is a disaster. Here's what we deal with daily:
贝宝开发人员仪表板是一场灾难。这是我们每天处理的内容：
PayPal's UI is so broken you can't even dismiss notifications Your browser does not support the video tag.
PayPal的UI是如此破坏，甚至无法删除浏览器不支持视频标签的通知。
The developer dashboard literally makes you drag a slider then logs you out after 60 seconds Your browser does not support the video tag.
开发人员仪表板从字面上使您拖动滑块，然后在60秒后将您的浏览器登录，您的浏览器不支持视频标签。
More UI disasters in the PayPal developer interface showing broken workflows Your browser does not support the video tag.
PayPal开发人员界面中的更多UI灾难显示了损坏的工作流，您的浏览器不支持视频标签。
The subscription management interface - the interface is so bad we had to rely on code to generate products and subscription plans
订阅管理接口 - 接口非常糟糕，我们不得不依靠代码来生成产品和订阅计划
A view of the broken subscription interface with missing functionality (you can't easily create products/plans/subscriptions – and there does not seem to be a way at all to delete products nor plans once created in the UI)
缺少功能的损坏订阅接口的视图（您无法轻易创建产品/计划/订阅 - 并且似乎根本没有一种删除产品或曾经在UI中创建的计划的方法）
Typical PayPal error messages - cryptic and unhelpful
典型的PayPal错误消息 - 隐秘和无助
SDK Problems
SDK问题
Can't handle both one-time payments and subscriptions without complex workarounds involving swapping and re-rendering buttons while re-loading the SDK with script tags
在使用脚本标签重新加载SDK时，如果没有复杂的解决方案，就无法处理一次性付款和订阅
JavaScript SDK violates basic conventions (lowercase class names, no instance checking)
JavaScript SDK违反了基本约定（小写类名称，没有实例检查）
Error messages don't indicate which fields are missing
错误消息没有指示缺少哪些字段
Inconsistent data types (requiring string amounts instead of numbers)
不一致的数据类型（需要字符串数量而不是数字）
Content Security Policy Violations
内容安全政策违反行为
Their SDK requires unsafe-inline and unsafe-eval in your CSP, forcing you to compromise your site's security.
他们的SDK需要在CSP中不安全的内线和不安全的信息，从而迫使您损害网站的安全性。
Documentation Chaos
文档混乱
Mark Stuart himself admitted:
马克·斯图尔特本人承认：
Agreed that there's an absurd amount of legacy and new APIs. Really difficult to find what to look for (even for us who work here).
同意有荒谬的遗产和新的API。真的很难找到要寻找的东西（即使对于我们在这里工作的我们）。
Security Vulnerabilities
安全漏洞
PayPal's 2FA implementation is backwards. Even with TOTP apps enabled, they force SMS verification - making accounts vulnerable to SIM swap attacks. If you have TOTP enabled, it should use that exclusively. The fallback should be email, not SMS.
PayPal的2FA实施是向后的。即使启用了TOTP应用程序，它们也强制SMS验证 - 使帐户容易受到SIMS交换攻击。如果您启用了TOTP，则应仅使用它。后备应该是电子邮件，而不是短信。
Session Management Disaster
会话管理灾难
Their developer dashboard logs you out after 60 seconds of inactivity. Try to do anything productive and you're constantly going through: login → captcha → 2FA → logout → repeat. Using a VPN? Good luck.
他们的开发人员仪表板在60秒后会将您记录下来。尝试做任何富有成效的事情，并且您一直在经历：登录→CAPTCHA→2FA→注销→重复。使用VPN？祝你好运。
July 2025: The Final Straw
2025年7月：最后一根稻草
After 11 years of the same issues, the breaking point came during a routine account migration. We needed to transition to a new PayPal account to match our company name"Forward Email LLC" for cleaner accounting.
经过11年的相同问题，破裂点是在常规帐户迁移期间出现的。我们需要过渡到新的PayPal帐户，以匹配我们的公司名称“ Forward Email LLC”，以进行清洁会计。
What should have been simple turned into a complete disaster:
应该简单地变成一场完整的灾难：
Initial testing showed everything worked correctly
初始测试显示一切正常
Hours later, PayPal suddenly blocked all subscription payments without notice
几个小时后，贝宝突然阻止了所有订阅付款，恕不另行通知
Customers couldn't pay, creating confusion and support burden
客户无法付款，造成混乱和支持负担
PayPal support gave contradictory responses claiming accounts were verified
PayPal支持给出了矛盾的答复，要求核实帐户
We were forced to completely halt PayPal payments
我们被迫完全停止贝宝付款
The error customers saw when trying to pay - no explanation, no logs, nothing
客户试图付款时看到的错误 - 没有解释，没有日志，什么也没有
PayPal support claiming everything was fine while payments were completely broken. The final message shows them saying they"restored some features" but still asking for more unspecified information - classic PayPal support theater
贝宝的支持声称一切都很好，而付款完全损坏。最后一条消息显示他们说他们“恢复了某些功能”，但仍要求提供更多未指定的信息 - 经典的PayPal支持剧院
The identity verification process that supposedly"fixed" nothing
据称“修复”一无所有的身份验证过程
Vague message and still no resolution. Zero information, notices, or anything as to what additional information is required. Customer support goes silent.
模糊的消息，仍然没有解决方案。零信息，通知或任何需要什么其他信息的信息。客户支持保持沉默。
Why We Can't Just Drop PayPal
为什么我们不能只是丢下贝宝
Despite all these issues, we can't completely abandon PayPal because some customers only have PayPal as a payment option. As one customer said on our status page:
尽管有所有这些问题，我们仍不能完全放弃PayPal，因为有些客户只有PayPal作为付款方式。正如一位客户在我们的状态页面上所说的那样：
PayPal is my only option for payment
贝宝是我唯一付款的选择
We're stuck supporting a broken platform because PayPal has created a payment monopoly for certain users.
我们坚持支持一个破碎的平台，因为PayPal已为某些用户创建了付款垄断。
The Community Workaround
社区解决方法
Since PayPal won't provide basic subscription listing functionality, the developer community has built workarounds. We created a script that helps manage PayPal subscriptions: set-active-pypl-subscription-ids.js
由于PayPal无法提供基本的订阅清单功能，因此开发人员社区已经建立了解决方法。我们创建了一个有助于管理PayPal订阅的脚本：Set-Active-pypl-subscription-ids.js
This script references a community gist where developers share solutions. Users are actually thanking us for providing what PayPal should have built years ago.
该脚本引用了开发人员共享解决方案的社区要素。实际上，用户感谢我们提供了PayPal几年前应该建造的。
Blocking PayPal Templates Due to Phishing
由于网络钓鱼而阻止贝宝模板
The problems go beyond APIs. PayPal's email templates are so poorly designed that we had to implement specific filtering in our email service because they're indistinguishable from phishing attempts.
问题超出了API。PayPal的电子邮件模板的设计较差，以至于我们必须在电子邮件服务中实施特定的过滤，因为它们与网络钓鱼尝试没有区别。
The Real Problem: PayPal's Templates Look Like Scams
真正的问题：贝宝的模板看起来像骗局
We regularly receive reports of PayPal emails that look exactly like phishing attempts. Here's an actual example from our abuse reports:
我们定期收到贝宝电子邮件的报告，这些电子邮件看起来完全像是网络钓鱼的尝试。这是我们滥用报告中的一个实际示例：
Subject: [Sandbox] TEST - New invoice from PaypalBilling434567 sandbox #A4D369E8-0001
主题：[Sandbox]测试 - Paypalbilling的新发票434567 SANDBOX＃A4D369E8-0001
This email was forwarded to abuse@microsoft.com because it appeared to be a phishing attempt. The problem? It was actually from PayPal's sandbox environment, but their template design is so poor that it triggers phishing detection systems.
将此电子邮件转发到abus@microsoft.com，因为这似乎是一种网络钓鱼尝试。问题？它实际上是来自贝宝（Paypal）的沙箱环境，但是它们的模板设计非常差，以至于触发网络钓鱼检测系统。
Our Implementation
我们的实施
You can see our PayPal-specific filtering implemented in our email filtering code:
您可以看到我们的电子邮件过滤代码中实现的我们的贝宝特定过滤：
if ( session. originalFromAddressRootDomain === 'paypal.com' && headers. hasHeader ( 'x-email-type-id' ) && [ 'PPC001017' , 'RT000238' , 'RT000542' ]. 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 ; throw err; }
if（session。原始fromAddressRootDomain ==='paypal.com'&&headers。hasheader（'x-email-type-id'）&& ['ppc001017'，'rt000238'，'rt000238'，'rt000542']。正在进行的PayPal发票垃圾邮件，您必须手动发送发票链接'）；犯错。iscodebug = true;投掷错误；}
Why We Had to Block PayPal
为什么我们必须阻止贝宝
We implemented this because PayPal refused to fix massive spam/phishing/fraud issues despite our repeated reports to their abuse teams. The specific email types we block include:
我们之所以实施此功能，是因为PayPal拒绝解决大规模的垃圾邮件/网络钓鱼/欺诈问题，尽管我们反复向他们的虐待团队报告。我们阻止的特定电子邮件类型包括：
RT000238 - Suspicious invoice notifications
RT000238-可疑发票通知
- Suspicious invoice notifications PPC001017 - Problematic payment confirmations
- 可疑发票通知PPC001017-有问题的付款确认
- Problematic payment confirmations RT000542 - Gift message hack attempts
- 有问题的付款确认RT000542-礼品消息黑客尝试
The Scale of the Problem
问题的规模
Our spam filtering logs show the massive volume of PayPal invoice spam we process daily. Examples of blocked subjects include:
我们的垃圾邮件过滤日志显示了我们每天处理的大量PayPal发票垃圾邮件。受试者被阻塞的示例包括：
"Invoice from PayPal Billing Team:- This charge will be auto-debited from your account. Please contact us immediately at [PHONE]"
“ PayPal帐单团队的发票： - 此费用将从您的帐户中自动扣押。请立即通过[电话]与我们联系”
"Invoice from [COMPANY NAME] ([ORDER-ID])"
“ [公司名称]（[订单ID]）的发票””
Multiple variations with different phone numbers and fake order IDs
具有不同电话号码和虚假订单ID的多个变体
These emails often come from outlook.com hosts but appear to originate from PayPal's legitimate systems, making them particularly dangerous. The emails pass SPF, DKIM, and DMARC authentication because they're sent through PayPal's actual infrastructure.
这些电子邮件通常来自Outlook.com主机，但似乎源自PayPal的合法系统，使其特别危险。这些电子邮件通过SPF，DKIM和DMARC身份验证，因为它们是通过PayPal的实际基础架构发送的。
Our technical logs show these spam emails contain legitimate PayPal headers:
我们的技术日志显示，这些垃圾邮件电子邮件包含合法的PayPal标题：
X-Email-Type-Id: RT000238 (the same ID we block)
X-Email-type-is：rt000238（如果我们阻止的话相同）
(the same ID we block) From:"service@paypal.com"
（我们封锁的同一ID）来自：“ service@paypal.com”
Valid DKIM signatures from paypal.com
paypal.com的有效DKIM签名
Proper SPF records showing PayPal's mail servers
适当的SPF记录显示PayPal的邮件服务器
This creates an impossible situation: legitimate PayPal emails and spam both have identical technical characteristics.
这会造成不可能的情况：合法的PayPal电子邮件和垃圾邮件都具有相同的技术特征。
The Irony
具有讽刺意味
PayPal, a company that should be leading the fight against financial fraud, has email templates so poorly designed that they trigger anti-phishing systems. We're forced to block legitimate PayPal emails because they're indistinguishable from scams.
PayPal是一家应该领导与财务欺诈斗争的公司，其电子邮件模板的设计较差，以至于触发了反钓鱼系统。我们被迫阻止合法的PayPal电子邮件，因为它们与骗局没有区别。
This is documented in security research: Beware PayPal new address fraud - showing how PayPal's own systems are exploited for fraud.
安全研究中记录了这一点：当心PayPal新地址欺诈 - 显示PayPal自己的系统如何利用欺诈。
Real-World Impact: Novel PayPal Scams
现实世界的影响：新颖的贝宝骗局
The problem extends beyond just poor template design. PayPal's invoice system is so easily exploited that scammers regularly abuse it to send legitimate-looking fraudulent invoices. Security researcher Gavin Anderegg documented A Novel PayPal Scam where scammers send real PayPal invoices that pass all authentication checks:
该问题超出了糟糕的模板设计范围。PayPal的发票系统非常容易被利用，以至于骗子会定期滥用它，以发送合法的欺诈性发票。安全研究员加文·安德雷格（Gavin Anderegg）记录了一个新颖的贝宝骗局，骗子发送了通过所有身份验证检查的真实贝宝发票：
"Inspecting the source, the email looked like it actually came from PayPal (SPF, DKIM, and DMARC all passed). The button also linked to what looked like a legitimate PayPal URL... It took a second to dawn on me that it was a legit email. I had just been sent a random 'invoice' from a scammer."
“检查源后，电子邮件看起来实际上来自PayPal（SPF，DKIM和DMARC都通过了）。该按钮还链接到看起来像合法的PayPal URL ...花了一秒钟的时间，这是我的合法电子邮件。我刚刚从骗子中发送了一个随机的“投票”。”
Screenshot showing multiple fraudulent PayPal invoices flooding an inbox, all appearing legitimate because they actually come from PayPal's systems
屏幕截图显示多个欺诈性的贝宝发票泛滥收件箱，所有这些都显得合理，因为它们实际上来自贝宝的系统
The researcher noted:
研究人员指出：
"It also seems like a convenience feature that PayPal should consider locking down. I immediately assumed this was some form of scam and was only interested in the technical details. It seems far too easy to pull off, and I worry that others might fall for it."
“贝宝（Paypal）应该考虑锁定的便利功能似乎也是一项便利功能。我立即认为这是某种形式的骗局，只对技术细节感兴趣。似乎太容易实现了，我担心其他人可能会为此而堕落。”
This perfectly illustrates the problem: PayPal's own legitimate systems are so poorly designed that they enable fraud while simultaneously making legitimate communications look suspicious.
这完美地说明了这个问题：PayPal自己的合法系统的设计较差，以至于可以使欺诈行为同时使合法的沟通看起来可疑。
To make matters worse, this affected our deliverability with Yahoo resulting in customer complaints and hours of meticulous testing and pattern checking.
更糟糕的是，这影响了我们通过Yahoo的交付性，从而导致客户投诉和细致的测试和模式检查。
PayPal's Backwards KYC Process
贝宝的向后KYC流程
One of the most frustrating aspects of PayPal's platform is their backwards approach to compliance and Know Your Customer (KYC) procedures. Unlike every other payment processor, PayPal allows developers to integrate their APIs and start collecting payments in production before completing proper verification.
PayPal平台最令人沮丧的方面之一是他们的遵守方式并了解您的客户（KYC）程序。与其他所有付款处理器不同，PayPal允许开发人员在完成适当的验证之前将其集成其API并开始在生产中收集付款。
How It Should Work
它应该如何工作
Every legitimate payment processor follows this logical sequence:
每个合法的付款处理器都遵循此逻辑序列：
Complete KYC verification first Approve the merchant account Provide production API access Allow payment collection
完整的KYC验证首先批准商家帐户提供生产API访问允许付款收集
This protects both the payment processor and the merchant by ensuring compliance before any money changes hands.
这可以通过在任何钱易手之前确保合规性来保护付款处理器和商人。
How PayPal Actually Works
贝宝如何运作
PayPal's process is completely backwards:
PayPal的过程完全倒退：
Provide production API access immediately Allow payment collection for hours or days Suddenly block payments without notice Demand KYC documentation after customers are already affected Provide no notification to the merchant Let customers discover the problem and report it
提供生产API访问立即允许数小时或数天的付款突然阻止付款，而无需通知客户已经受到影响后的KYC文档，不向商人提供通知，让客户发现问题并报告该问题
The Real-World Impact
现实世界的影响
This backwards process creates disasters for businesses:
此倒退过程为企业造成灾难：
Customers can't complete purchases during peak sales periods
客户无法在高峰销售期间完成购买
during peak sales periods No advance warning that verification is needed
在高峰销售期间，没有提前警告需要验证
that verification is needed No email notifications when payments are blocked
付款被阻止时无需验证
when payments are blocked Merchants learn about problems from confused customers
当付款被阻止时，商人从困惑的客户那里学习了问题
Revenue loss during critical business periods
关键业务期内的收入损失
during critical business periods Customer trust damage when payments mysteriously fail
在关键的业务时期，当付款神秘失败时，客户信任损失
The July 2025 Account Migration Disaster
2025年7月的帐户迁移灾难
This exact scenario played out during our routine account migration in July 2025. PayPal allowed payments to work initially, then suddenly blocked them without any notification. We only discovered the problem when customers started reporting they couldn't pay.
这种确切的情况在我们的日常帐户迁移期间播放了2025年7月。贝宝允许付款最初工作，然后突然阻止了它们而没有任何通知。我们只有在客户开始报告他们无法付款的时候才发现问题。
When we contacted support, we received contradictory responses about what documentation was needed, with no clear timeline for resolution. This forced us to completely halt PayPal payments, confusing customers who had no other payment options.
当我们联系支持时，我们收到了有关需要哪些文档的矛盾回应，而没有明确的解决时间表。这迫使我们完全停止了贝宝付款，使没有其他付款方式的客户感到困惑。
Why This Matters
为什么这很重要
PayPal's approach to compliance shows a fundamental misunderstanding of how businesses operate. Proper KYC should happen before production integration, not after customers are already trying to pay. The lack of proactive communication when issues arise demonstrates PayPal's disconnect from merchant needs.
贝宝的合规方法表明，对企业的运作方式产生了根本的误解。适当的KYC应在生产整合之前发生，而不是在客户已经试图付款之后。出现问题时缺乏主动沟通表明Paypal与商人需求的脱节。
This backwards process is symptomatic of PayPal's broader organizational problems: they prioritize their internal processes over merchant and customer experience, leading to the kind of operational disasters that drive businesses away from their platform.
这种向后的过程是PayPal更广泛的组织问题的症状：它们优先考虑其内部流程而不是商人和客户体验，从而导致了使企业远离平台的运营灾难。
How Every Other Payment Processor Does It Right
其他每个付款处理器如何正确
The subscription listing functionality that PayPal refuses to implement has been standard in the industry for over a decade. Here's how other payment processors handle this basic requirement:
PayPal拒绝实施的订阅清单功能已在该行业中已经是该行业的标准了十多年。以下是其他付款处理器处理此基本要求的方式：
Stripe
条纹
Stripe has had subscription listing since their API launched. Their documentation clearly shows how to retrieve all subscriptions for a customer or merchant account. This is considered basic CRUD functionality.
自API推出以来，Stripe已列出了订阅清单。他们的文档清楚地显示了如何检索客户或商人帐户的所有订阅。这被认为是基本的CRUD功能。
Paddle
桨
Paddle provides comprehensive subscription management APIs including listing, filtering, and pagination. They understand that merchants need to see their recurring revenue streams.
PADDLE提供全面的订阅管理API，包括上市，过滤和分页。他们了解商人需要看到他们的经常收入来源。
Coinbase Commerce
共同商务
Even cryptocurrency payment processors like Coinbase Commerce provide better subscription management than PayPal.
即使是Coinbase Commerce等加密货币支付处理器，也提供了比PayPal更好的订阅管理。
Square
正方形
Square's API includes subscription listing as a fundamental feature, not an afterthought.
Square的API包括订阅列表作为基本功能，而不是事后的想法。
The Industry Standard
行业标准
Every modern payment processor provides:
每个现代付款处理器提供：
List all subscriptions
列出所有订阅
Filter by status, date, customer
按状态，日期，客户过滤
Pagination for large datasets
大型数据集的分页
Webhook notifications for subscription changes
订阅更改的Webhook通知
Comprehensive documentation with working examples
全面的文档与工作示例
What Other Processors Provide vs PayPal
其他处理器提供的与PayPal提供了什么
Stripe - List All Subscriptions:
条纹 - 列出所有订阅：
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 }
获取https://api.stripe.com/v1/subscriptions授权：bearer sk_test _...响应：{“对象”：“ list”，“ data”：[{“ id”：““ cus_na6dx7axxi11n4”，“ current_period_start”：1679609767，“ current_period_end”：1682288167}]，“ has_more”：false}
Stripe - Filter by Customer:
条纹 - 客户过滤：
GET https://api.stripe.com/v1/subscriptions?customer=cus_Na6dX7aXxi11N4
获取https://api.stripe.com/v1/subscriptions？customer = cus_na6dx7axxi11n4
Stripe - Filter by Status:
条纹 - 按状态过滤：
GET https://api.stripe.com/v1/subscriptions?status=active
获取https://api.stripe.com/v1/subscriptions？status = active
PayPal - What You Actually Get:
贝宝 - 您实际得到的：
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
获取https://api.paypal.com/v1/billing/subscriptions/ {id}授权：bearer access_token＃您只能获得一份订阅
PayPal's Available Endpoints:
PayPal的可用端点：
POST /v1/billing/subscriptions - Create a subscription
发布/V1/计费/订阅 - 创建订阅
- Create a subscription GET /v1/billing/subscriptions/{id} - Get ONE subscription (if you know the ID)
- 创建一个订阅get/v1/billing/sciptriptions/{id} - 获取一个订阅（如果您知道ID）
- Get ONE subscription (if you know the ID) PATCH /v1/billing/subscriptions/{id} - Update a subscription
- 获取一个订阅（如果知道ID）补丁/V1/billing/订阅/{id} - 更新订阅
- Update a subscription POST /v1/billing/subscriptions/{id}/cancel - Cancel subscription
- 更新订阅帖子/v1/账单/订阅/{id}/取消 - 取消订阅
- Cancel subscription POST /v1/billing/subscriptions/{id}/suspend - Suspend subscription
- 取消订阅post/v1/账单/订阅/{id}/暂停 - 暂停订阅
What's Missing from PayPal:
PayPal缺少什么：
❌ No GET /v1/billing/subscriptions (list all)
❌无get/v1/账单/订阅（列出全部）
(list all) ❌ No search functionality
（列出所有）❌没有搜索功能
❌ No filtering by status, customer, date
❌没有按状态，客户，日期进行过滤
❌ No pagination support
❌没有分页支持
PayPal is the only major payment processor that forces developers to manually track subscription IDs in their own databases.
PayPal是唯一迫使开发人员手动跟踪其数据库中订阅ID的主要付款处理器。
What This Means for Developers
这对开发人员意味着什么
PayPal's systematic failure to address basic developer needs while collecting extensive feedback shows a fundamental organizational problem. They treat feedback collection as a substitute for actually fixing issues.
PayPal在收集广泛的反馈的同时，有系统地无法满足基本开发人员需求，这表明了一个根本的组织问题。他们将反馈收集视为实际解决问题的替代品。
The pattern is clear:
模式很清楚：
Developers report issues PayPal organizes feedback sessions with executives Extensive feedback is provided Teams acknowledge gaps and promise to"track and address" Nothing gets implemented Executives leave for better companies New teams ask for the same feedback Cycle repeats
开发人员报告问题贝宝（PayPal）与高管组织的反馈会议提供了广泛的反馈。
Meanwhile, developers are forced to build workarounds, compromise security, and deal with broken UIs just to accept payments.
同时，开发人员被迫建立解决方法，损害安全性并处理破碎的UI，只是为了接受付款。
If you're building a payment system, learn from our experience: build your trifecta approach with multiple processors, but don't expect PayPal to provide the basic functionality you need. Plan to build workarounds from day one.
如果您要构建付款系统，请从我们的经验中学习：使用多个处理器构建您的Trifecta方法，但不要指望PayPal提供所需的基本功能。计划从第一天开始建立解决方法。