Addressing common misconceptions about the Payment Request API

Even with the PR API, developers still have to send the payment information provided by users to a payment gateway or a payment processor in order to be processed and for the money transfer to happen. Upon user tapping a "PAY" button, instead of a form being POSTed to a server, the website's JavaScript will receive the user's payment information so you can handle it however you want. Typically, you would forward that directly to a payment gateway to obtain a token and then process the payment from your server.

The Payment Request API is designed to handle virtually any kind of payment methods including bank transfers, cryptocurrencies, e-money, points, etc.

If your site is compliant with PCI DSS or PCI SAQ A-EP, you are probably working at a relatively large company and there's not much to worry about to implement the PR API as long as you implement it securely.
If your site is compliant with PCI SAQ A, be careful. With PCI SAQ A, you are not supposed to handle raw credit card information directly. This means using the Payment Request API with "basic-card" as a payment method is outside of PCI SAQ A v3.2 compliance.

ウェブでの新しいお金の払い方 - Web Payments と Payment Request API について

Web Payments はなぜ避けて通れないものになるのか - ウェブでの新しいお金の払い方

PCI DSS は、2015 年に発表されたバージョン 3.2 において、明確に生のクレジットカード情報をブラウザ上で扱うことに関して、従来よりも強い制約を設けました。日本の 「クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画」においても同様です。

今後オンラインマーチャントは、クレジットカード情報を全く扱わない「クレジットカード情報の非保持化」を進めるか、もしくは PCI DSS に対応するか、の選択を迫られます。

トークナイゼーションが画期的なのは、それが渡されたカード情報を守る方法ではなく、そもそもカード情報を渡さないというアプローチを取っている点です。「トークン」と呼ばれる一時的に利用できる文字列をクレジットカード会社に発行してもらい、それをマーチャントに渡すことで、決済を行います。

このトークンはトランザクションに特化して発行されるため他の用途には使えないことに加え、トークン自体から元のカード番号を逆引きできないことから、漏洩したところで被害は最小限に食い止められる、という特徴があります (厳密には様々なバリエーションがあるようですが、ここでは触れません)。

つまり、これを使えば間接的に「クレジットカード情報の非保持化」を実現することができます。