この記事はNikkei Advent Calendar 2022の 4 日目の記事です。

NIKKEI COMPASS

NIKKEI COMPASS は 2022 年 11 月末に開始した新サービスです。

もともとは会員制サービスの日経テレコンの内容をベースに、ある程度オープンに検索・閲覧ができるようにしようという事でプロジェクトが始まりました。
これを NIKKEI COMPASS としてリニューアルするにあたり、日経 ID によるログインとサービス内で支払いを行ってワンストップで有料コンテンツの閲覧ができるように機能を追加しました。

日経 ID には既に登録したクレジットカードで決済を行う仕組みが有りましたが、これは新聞購読のように月額費用のサブスクリプションモデルを想定した機能になっていました。
NIKKEI COMPASS では見たいと思ったコンテンツに対して都度支払いを行うという形をとっており、日経 ID が想定するサブスクリプションモデルとは相容れませんでした。
なので代わりに決済プラットフォームの Stripe を用いて都度支払いの機能を実装することになりました。

この記事では NIKKEI COMPASS の支払い機能の実装についてと、Stripe を使うにあたっての Tips を紹介したいと思います。

Stripe Elements を利用した支払い

既に紹介したとおり NIKKEI COMPASS ではコンテンツ 1 つごとに支払いが可能となっています。
Stripe では多様な支払い方法が用意されており、Stripe のサイトで用意された支払いページを用いて支払いをする方法から API のみを利用して全てを独自に実装する方法まで多数のオンライン支払い方法が用意されています。
NIKKEI COMPASS ではサイト内で支払いを完結したいという要件があったので、Stripe Elements を用いることにしました。

Stripe Elements では支払いページに必要なフォーム要素を Stripe が用意したものを用いて構築できるようになっています。
今回は React のコンポーネントを用いましたが、Stripe Elements のコンポーネントに対して自由にクラス名を設定可能なので、サイトのブランディングに沿うようにスタイリングを調整することもできます。

Stripe デフォルトの見た目	見た目を調整したフォーム

ただし Stripe Elements では支払いに必須となる要素しか準備されていません。
具体的にはカード名義人(クレジットカードの表面にある氏名) は支払い時には不要な要素なのでフォームが用意されておらず、自前でフォームの内容をハンドリングする必要がありました。
また、後の支払いの為に保存したクレジットカードをリストで選択するようなコンポーネントも用意されておらず、カードブランドの画像も含めて自前で用意する必要がある点には注意が必要です。
受け付けているクレジットカードのロゴを見つける : Stripe: ヘルプ & サポート

Metadata の活用

Stripe には支払いを司る PaymentIntent や、個別の支払いを表す Charge 、商品を表す Product や顧客を表す Customer など多数のオブジェクト (API リソース) が用意されています。
そしてこれらのほぼ全て (全てのオブジェクトを利用しているわけではないので本当に全てかは不明です) に対して Metadata を設定することができます。
Metadata は個々のオブジェクトに対してサービス特有の情報を Key-Value で持てる仕組みとなっており、これにより簡単な情報変換のためのマスタデータなどを自前で持つ必要がなくなります。
NIKKEI COMPASS では Stripe の Customer に対してサービスのログイン ID を Metadata として持たせたり、購入可能なコンテンツ毎に作成している Product に対して当該コンテンツの情報元名称や再閲覧可能な時間などを Metadata として持つようにしています。

このようにして Metadata を活用することで Stripe と自前の DB で情報が分散するのを防ぎ、情報を集約することでデータの不整合も防ぐことができます。
また、Metadata は API でのリソース検索時に検索クエリに含めることができるので、しっかりと Metadata に持たせる情報を設計することで購入履歴ですら自前の DB に持つ必要もなくなります。

冪等キーの設定と注意点

Stripe のオブジェクトを作成する際には冪等キーを設定することができます。
これはその名の通りキーによる結果の冪等性を保証するもので、例えば支払いをする際に起きたネットワークエラーなどでのリトライを安全に行うために必要です。
オブジェクトを作成するようなリクエストに対しては基本的には冪等キーのオプションを設定すべきなのですが、Stripe の開発環境でのみ利用可能な全データ削除の機能とは相性が悪いことがわかりました。

全データ削除の機能は開発環境でのみ利用可能な機能で、今までに作成された PaymentIntent や Product・Customer などのすべてのデータを削除するというものです。
開発初期などで試行錯誤があるような場面では非常に有用な機能なのですが、全データ削除の前後で同じ冪等キーを使ってオブジェクトを作成すると、全データ削除の前の結果が全データ削除後のリクエストで返ってきてしまうことがわかりました。
支払い情報などはセッション ID を冪等キーに利用すれば重複することが無いのですが、サービスのログイン ID と紐付けて作成している Customer はサービスのログイン ID を冪等キーに使っていたので、全データ削除の後に作成したデータの結果が古いままとなってしまっていました。
これに対しての対応は簡単で、冪等キーにそのまま外部 ID を利用するのをやめて外部 ID に加えて全データ削除のオペレーション毎にインクリメントを行うバージョン番号のようなものを含めることで解決しました。

なにはともあれ

Stripe のドキュメント がとにかく充実していて、とにかくよい開発体験でした。 支払い機能の実装は短い期間で完了する必要があったのですが、Stripe が関連する支払い周りは非常にスムーズに完了することができました。

NIKKEI COMPASS はこれからも購入可能なコンテンツを強化し続ける予定です。
決済に使っているサービスという裏方の話になってしまいましたが、これを機にサービスにも興味が湧いた方はぜひ利用してみてください。