以下是用例：
有一个Web服务 S ，它通过REST API获取大量用户输入，并使用该输入生成一些通过API返回的答案。作为具体但虚构的例子，您可以将输入视为用户的出生信息，输出是用户的星座运势。
S 只是一个带有API的计算引擎;它不提供用户界面。人类用户的演示界面由合作伙伴网站 P i 提供，每个网站都有自己的外观和感知，以及与用户的财务安排。每个 P i 代表其中一位用户支付 S 间接为该用户提供的服务费用， S 不会返回特定使用实例的答案，直到该实例的费用已经支付为止。
现在，根据PayPal API文档的适量阅读量，我觉得：
P i 可以使用payouts API为每次使用 S 发送付款，包括sender_item_id值，用于标识所支付的特定使用实例;以及
S 可以使用Instant Payment Notification API接收付款通知和相应的sender_item_id值，然后将其用作确认可以发布该使用实例的答案。
所以问题是：我是否走在正确的轨道上？我是否有必要深入研究这两个API作为实现上述用例的合理方法？或者我应该关注哪些更合适的东西？
如果我我在正确的轨道上，那么从属问题是： S 如何“声明”付款项目？在支付API文档中有一个声明，即支付的状态可能是UNCLAIMED（“支付项目无人认领。如果未在30天内提出申请，则会将资金返还给发件人”）。由于IPN是（只是？）一个通知服务，我是否需要使用一些不同的API来实际申请付款？
更新：关于声明付款的下属问题的可能答案可能是“如果收件人的电子邮件地址已经过验证，则无需公开支付请求付款“。
我将此猜想建立在RECEIVER_UNCONFIRMED错误消息的documentation上，该消息将其含义描述为：
收件人的电子邮件未经证实。对此帐户的任何付款均显示为
UNCLAIMED，直到确认收件人的帐户为止。
如果接收方的帐户已经确认，那么这种情况的双重似乎是，对该帐户的付款不会显示为UNCLAIMED。
有人可以确认吗？