Skip to main content

構築するもの

自社サイトに注文を管理ボタンを置きます。サインイン済みの顧客がクリックすると、サーバーが Waffo Pancake にポータルリンクを要求し、ブラウザをリダイレクトします。顧客はメールアドレスや確認コードを入力することなく、サインイン済みの状態でストアのカスタマーポータルに入れます。 ポータルで顧客ができること:
この方法で入った顧客は、ポータルから返金をリクエストできません。返金リクエストは自社のサポート窓口で受け付け、Dashboard または 返金チケットの作成 API で返金してください。

前提条件

  • API Key(Dashboard → API & Development)。開発中はテストキーを使います
  • 顧客に表示するストアの Store ID(STO_xxx)
  • 認証済みチェックアウトで作成され、buyerIdentity を持つ注文
  • 自社のサインイン機能:このフローはサーバーのセッションを信頼するため、顧客は自社サイトで認証済みである必要があります
  • SDK を使う場合:@waffo/pancake-ts 0.26.0 以降、@waffo/pancake-nextjs 0.9.0 以降、または Go SDK v0.17.0 以降
  • ストア設定でストアの Website が登録済みであること。ポータルのセッションが終了すると、ポータルはこのアドレスだけにリンクするショップのサイトに戻るボタンを表示します。ウェブサイトが未登録の場合、ボタンは表示されません

ステップ 1:顧客 ID を決める

ポータルには、指定したストアで buyerIdentity がここで渡す値と一致する注文が表示されます。注文作成時に渡すのと同じ、安定した値を使ってください。
  • 推奨: 社内の顧客 ID —— 安定していて、別の人に再割り当てされない値
  • メールアドレスは避けてください:顧客がメールを変えると過去の注文が見えなくなり、再利用されたアドレスは別の人に注文を見せてしまう恐れがあります
  • 匿名で、または別の ID で行われた注文は表示されません。Waffo Pancake は ID を統合しません。識別子を切り替えた場合、それ以前の注文は古い値のままです
buyerIdentity と storeId は、サーバー自身のサインインセッションから取得してください —— ブラウザが設定できるクエリパラメータ、フォーム項目、ヘッダー、Cookie の値から取ってはいけません。buyerIdentity を操作できる人は、その顧客のポータルを手に入れます。Waffo Pancake はサーバーを信頼し、顧客のメールアドレスを検証しません。

ステップ 2:サーバーでリンクを作成する

API はバックエンドからのみ呼び出してください。API Key をブラウザに渡してはいけません。
  • 環境は API Key に従います。 テストキーならテストデータ、本番キーなら本番データでポータルが開きます。環境パラメータはありません
  • クリックのたびにリンクを作成し、リダイレクトの直前に発行してください。キャッシュ・保存・メール送信はしないでください
  • 302 でリダイレクト し、リダイレクトレスポンスに Cache-Control: no-store と Referrer-Policy: no-referrer を付けてください。トークン付きリンクがキャッシュされたり、referrer として渡されたりするのを防ぎます
SDK ヘルパー createCustomerPortalRedirect は次のオプションを受け取ります: ヘルパーが組み立てるレスポンスにはすべて Cache-Control: no-store と Referrer-Policy: no-referrer が付きます。onError から返すレスポンスは自社の責任なので、同じく両方のヘッダーを付けてください。
loginUrl には自社で管理するパスを設定してください。リクエストパラメータ(returnTo クエリの値など)をそのままコピーして組み立ててはいけません —— ポータルのルートがオープンリダイレクトになります。
SDK を使わない場合は、purpose: "portal" と storeId を付けてセッショントークンの発行を呼び出し、portalUrl + "#token=" + token にリダイレクトします。

ステップ 3:ボタンを追加する

ボタンは Waffo Pancake ではなく自社のルートを指すようにします。ブラウザが API Key を目にすることはなく、リンクは顧客がクリックしたときにだけ作成されます。

セッションの動作

リンクの #token= 部分は bearer 認証情報です。リンクをログ、アナリティクス、エラートラッカー、サポートチケットに書き込まず、メールやチャットでも共有しないでください。

本番前のテスト

1

テスト注文を作成

テスト API Key を使い、テスト顧客の buyerIdentity で認証済みチェックアウトから注文します。
2

ポータルを開く

その顧客として自社サイトにサインインし、注文を管理をクリックします。テスト注文が表示されるはずです。
3

ID の境界を確認

別の顧客でサインインし、最初の顧客の注文が表示されないことを確認します。リクエストに他の顧客の ID を加えてみてください —— ルートはそれを無視しなければなりません。
4

本番に切り替え

本番 API Key でデプロイします。以降、リンクは本番データを開きます。

トラブルシューティング

  1. 注文が同じ buyerIdentity 文字列で作成されているか確認します(大文字小文字を含む完全一致)
  2. 注文が渡した storeId のものか確認します
  3. API Key の環境を確認します:テストキーはテスト注文のみ、本番キーは本番注文のみを表示します
  4. 匿名チェックアウトの注文は buyerIdentity を持たないため、ここには表示されません
セッションが 15 分以上アイドル状態だった場合、または新しいリンクなしで、このブラウザのセッションとは別のストアのポータルを開いた場合、ポータルはショップのサイトから入り直してくださいと表示します。自社サイトの注文を管理から入り直してもらい、新しいリンクを取得してください。
顧客が同じブラウザで再度ポータルに入りました —— 別のタブで自社サイトから入った、別ストアのポータルに入った、またはメールのマジックリンクを使った場合です。最新の入場がそのブラウザのポータルセッションになり、古いタブにはセッションが切り替わりましたと表示され、現在のセッションに移動します。対応は不要です。
ポータルトークンで Customer Portal API を呼び出した際、X-Environment が API Key の環境と異なっています。キーの環境を送ってください。

チェックリスト

  • リンクはサーバーで作成し、API Key はブラウザに届かない
  • buyerIdentity は自社のサインインセッションから取得し、チェックアウト時の値と一致する
  • storeId はリクエストではなくサーバーの設定から取得する
  • ルートは 302、Cache-Control: no-store、Referrer-Policy: no-referrer で応答する
  • ポータルリンクとトークンをログに記録・保存しない
  • 返金リクエストにはポータル外のサポート窓口がある

次のステップ

セッショントークンの発行

purpose: "portal" のリクエストとレスポンスのフィールド。

カスタマーポータル

顧客がポータルで目にする内容。