決済 API を選ぶときの判断軸

決済は「動けばよい」で済まない領域だ。実装の巧拙より、審査・入金サイクル・法令対応といった事業側の条件が採用可否を決めることが多い。技術検証と並行して、事業側の確認を進めるのが実務的な進め方になる。

技術より先に確認すること

  • 審査に通るか — 取扱商材によっては契約できない。開発を進める前に見通しを立てる
  • 入金サイクル — 決済完了と入金は別物で、数日〜1か月の差がある。資金繰りに直結する
  • 手数料の構造 — 決済手段ごとに料率が異なる。想定する決済手段の構成比で試算する
  • 必要な決済手段 — コンビニ決済、銀行振込、キャリア決済といった国内特有の手段が要件に入るか
🔴
カード情報を自社サーバーに通さない構成にしてください

カード番号を自前で受け取ると PCI DSS の適用範囲が一気に広がり、要求される管理水準が跳ね上がります。各社が提供するトークン化の仕組み(フロントで直接トークンを作り、サーバーはトークンだけ受け取る)を使うのが前提です。ここを崩すと、決済機能の実装より監査対応のほうが重くなります。

実装で最も多い誤り

決済の完了をフロントエンドの戻り値で判定してしまう構成は、3D セキュアの認証中に離脱された場合や、非同期の決済手段を使った場合に破綻する。決済の確定は Webhook で受け取るのが正しく、フロントの表示は暫定と扱う。あわせて署名検証と冪等性(同じ通知が二度来ても二重処理しない)は必須になる。

国内サービスと海外サービス

国内サービスは審査・サポート・入金が日本語で完結し、国内の決済手段に強い。海外サービスは多通貨対応とドキュメントの充実で優位に立つ。国内向けサービスなら国内勢、海外展開を見据えるなら海外勢、という分岐が基本になる。