PayPalのAPIには、前から使われいてるClassic APIと２年ぐらい前にリリースされた新しいREST APIがあり、REST APIへの機能の移行が徐々に進んでいますが、REST APIの便利な仕様としてHTEOAS Linkがあります。

HATEAOSの説明（Wikipedia）
https://en.wikipedia.org/wiki/HATEOAS

PayPalのHATEOAS Link
https://developer.paypal.com/docs/api/#hateoas-links

HATEOAS, an abbreviation for Hypermedia as the Engine of Application State

ということですが、簡単に言ってしまうとURL（URI）をつかって、APIのデータを表現する方法です。

よく使われるパターンは、

APIが一度に100件しか返さなくて次の100件を取得したい場合に,
https://xxxx.com/search?name=aaa&page=2
みたいなクエリを投げると思いますが、今までは、この「page=2」のクエリ仕様をDeveloperがドキュメントなどを調べて知っておく必要がありました。
これを初めのレスポンス、
https://xxxx.com/search?name=aaa
内に
{next_link : "https://xxxx.com/search?name=aaa&page=2"}
といったように、「次のページを取得するためのURL」というフィールドとして返すことで、
開発者はそのフィールドの値をGETすれば次のデータを取得することができます。

これにより、情報参照の手間が省けるとともに、仮に「page=2」の部分が「offset=101」に仕様変更になったとしても、プログラムの改修をしなくて済むというメリットがあります。

もうひとつのケースとしては、

従業員データを返すAPIなどで、検索結果には

[{emp_id : "001"}, {emp_id : "002"}, {emp_id : "003"}]

というIDが返ってきて、それを詳細データ参照API

https://xxxx.com/detail?id=001

を使ってデータを参照するというケースがあると思いますが、

[{emp_id : "001", rel : "https://xxxx.com/detail?id=001"}, {emp_id : "002", rel : "https://xxxx.com/detail?id=002"}, {emp_id : "003", rel : "https://xxxx.com/detail?id=003"}]

といった参照用のURIを示すことで、データ参照の実装がやりやすくなります。

単発のAPIコールだけでなくて、幾つかのAPIを複合的にコールすることが多いサービスには有効なアプローチかと思います。

決済は、ユーザーアクションや運用に応じた様々なフロー設計が必要なので、このアプローチにはマッチしていると言えます。

PayPalのHATEOASLinkにおいては、支払い関連のAPIで次にコールすべきAPIのエンドポイントや返された支払いデータの詳細を取得するAPIのエンドポイントを、メソッド（POST/GET）とともに指定しています。
(以下はデベロッパーサイトでの例）

"links": [ { "href": "https://api.sandbox.paypal.com/v1/payments/sale/4RR959492F879224U", "rel": "self", "method": "GET" }, { "href": "https://api.sandbox.paypal.com/v1/payments/sale/4RR959492F879224U/refund", "rel": "refund", "method": "POST" }, { "href": "https://api.sandbox.paypal.com/v1/payments/payment/PAY-17S8410768582940NKEE66EQ", "rel": "parent_payment", "method": "GET" } ]

ちなみに、PayPalはこの投稿でも述べたように、APIの標準化にも積極的で、HATEOASで検索すると上記のデベロッパーサイトのページが上位にHITしたり、広く参考にされていたりします。