首先得纠正一个点：PayPal Here的文档不适合你的需求——它主要是面向线下收单的硬件/移动应用场景，你应该用PayPal的标准OAuth 2.0商家授权流程来获取商家账户的访问令牌和刷新令牌，这才是正确的基础步骤：

• 第一步：引导商家跳转到PayPal的授权页面，让他们同意你的应用访问其收款相关的权限（比如order:create、order:capture这类核心权限）。商家授权后，PayPal会返回一个授权码（authorization code）。
• 第二步：用这个授权码，搭配你的应用在PayPal开发者平台获取的客户端ID和密钥，调用PayPal的令牌接口，交换得到访问令牌（access token）和刷新令牌（refresh token）。一定要把刷新令牌加密存在你的数据库里，后续可以用它刷新过期的访问令牌。

关于收款环节，你的思路是对的，但有两个关键细节要优化：

• 不建议在前端用Smart Buttons直接生成订单ID，更稳妥的做法是在你的服务端用商家的访问令牌创建订单，再把生成的orderID传给前端的Smart Buttons。这样能避免前端暴露敏感权限，也符合PayPal的安全最佳实践。
• 扣款（也就是订单的捕获操作）必须在服务端完成，用商家的访问令牌调用订单捕获接口，这样能保证交易的安全性，也符合PayPal的API规范。

最后补充几个必注意的点：

• 你得先在PayPal开发者平台创建一个REST应用，拿到专属的客户端ID和密钥，这是所有授权和API调用的基础。
• 授权时要指定正确的权限范围（scopes），如果用最新的Orders API，至少需要https://uri.paypal.com/services/checkout这个范围，或者更细粒度的order:create、order:capture。
• 商家的刷新令牌属于敏感凭证，一定要加密存储，绝对不能明文存在数据库里。

给你捋个完整的流程示例，方便理解：

1. 商家在你的应用里点击「关联PayPal账户」，跳转到你用客户端ID和权限范围构建的PayPal授权URL。
2. 商家登录PayPal并确认授权后，PayPal跳转回你预设的回调URL，带回授权码。
3. 你的服务端用授权码+客户端ID+密钥，调用POST /v1/oauth2/token接口，拿到access_token和refresh_token，把refresh_token加密保存。
4. 当需要帮商家收款时，服务端用商家的access_token调用POST /v2/checkout/orders创建订单，得到orderID。
5. 把orderID传给前端的Smart Buttons，客户点击按钮完成支付授权。
6. 服务端要么监听PayPal的webhook通知，要么主动调用POST /v2/checkout/orders/{orderID}/capture完成扣款，资金直接进入商家的PayPal账户。

内容的提问来源于stack exchange，提问作者j10