app-id と secret-key の2つのヘッダーで認証されます。1つのエンドポイント、すなわち v1 のホスト型決済ゲートウェイのリンクについては、同じ認証情報から生成する短命のアクセストークンも追加で必要です。このページでは、認証情報の取得方法と正しい使い方を解説します。
始める前に
認証情報を発行するには、有効な Hello Clever の加盟店アカウントが必要です。連携キーのガイドに従って Payments Account を作成し、app-id と secret-key を取得してください。
リクエストを認証する
すべてのリクエストで、app-id と secret-key をヘッダーとして含めてください。
string
必須
Hello Clever の Merchant Dashboard から発行されるアプリケーションの識別子です。
string
必須
app-id に紐づくシークレットキーです。クライアントサイドのコードで決して露出させないでください。Example request
開発やテストの際は、サンドボックスのベース URL とサンドボックスの認証情報を使ってください。本番稼働の準備が整ってから、本番環境のベース URL と認証情報へ切り替えてください。各 API のバージョンのベース URL は API の概要を参照してください。
例外:v1 決済ゲートウェイのリンク用アクセストークン
POST /v1/payment_gateways/create_payment でホスト型の決済ゲートウェイのリンクを作成する場合、追加で access-token のヘッダーが必要です。app-id と secret-key のヘッダーを付けてアクセストークンのエンドポイントを呼び出すと生成できます。
access-token のヘッダーで渡してください。
expires_in は秒単位です。トークンは 3600 秒(1 時間)有効です。有効期限が切れたら新しいトークンを取得して再試行してください。このトークンが必要なのは決済ゲートウェイのリンクのエンドポイントのみで、その他の v1 のエンドポイントは引き続き app-id と secret-key のヘッダーを直接使用します。決済ゲートウェイのリンクのエンドポイントの詳細は v1 API リファレンスを参照してください。
セキュリティのベストプラクティス
- 認証情報は環境変数またはシークレット管理サービスに保管してください。 ソースコードや、バージョン管理にコミットされる設定ファイルには保存しないでください。
secret-keyを定期的にローテーションしてください。 漏えいが起きた場合の影響範囲を限定できます。- すべての API 呼び出しで HTTPS を使ってください。 認証情報が暗号化された接続で送信されることを確保できます。
- アクセス範囲を分離してください。 環境、通貨、アプリケーションごとに個別の Payments Account(したがって個別の認証情報)を作成してください。
- 想定外の利用をモニタリングしてください。 Merchant Dashboard で確認することで、認証情報の悪用を早期に検出できます。
secret-keyを Webhook Secret Key と混同しないでください。secret-keyは Hello Clever API へ送る自社からのリクエストを認証するものです。Webhook Secret Key は別の認証情報で、Hello Clever がサーバーへ送る受信 Webhook のペイロードに署名するために使います。検証方法は Webhook を参照してください。