構築するもの
自社サイトに注文を管理ボタンを置きます。サインイン済みの顧客がクリックすると、サーバーが Waffo Pancake にポータルリンクを要求し、ブラウザをリダイレクトします。顧客はメールアドレスや確認コードを入力することなく、サインイン済みの状態でストアのカスタマーポータルに入れます。 ポータルで顧客ができること:この方法で入った顧客は、ポータルから返金をリクエストできません。返金リクエストは自社のサポート窓口で受け付け、Dashboard または 返金チケットの作成 API で返金してください。
前提条件
- API Key(Dashboard → API & Development)。開発中はテストキーを使います
- 顧客に表示するストアの Store ID(
STO_xxx) - 認証済みチェックアウトで作成され、
buyerIdentityを持つ注文 - 自社のサインイン機能:このフローはサーバーのセッションを信頼するため、顧客は自社サイトで認証済みである必要があります
- SDK を使う場合:
@waffo/pancake-ts0.26.0 以降、@waffo/pancake-nextjs0.9.0 以降、または Go SDK v0.17.0 以降 - ストア設定でストアの Website が登録済みであること。ポータルのセッションが終了すると、ポータルはこのアドレスだけにリンクするショップのサイトに戻るボタンを表示します。ウェブサイトが未登録の場合、ボタンは表示されません
ステップ 1:顧客 ID を決める
ポータルには、指定したストアでbuyerIdentity がここで渡す値と一致する注文が表示されます。注文作成時に渡すのと同じ、安定した値を使ってください。
- 推奨: 社内の顧客 ID —— 安定していて、別の人に再割り当てされない値
- メールアドレスは避けてください:顧客がメールを変えると過去の注文が見えなくなり、再利用されたアドレスは別の人に注文を見せてしまう恐れがあります
- 匿名で、または別の ID で行われた注文は表示されません。Waffo Pancake は ID を統合しません。識別子を切り替えた場合、それ以前の注文は古い値のままです
ステップ 2:サーバーでリンクを作成する
API はバックエンドからのみ呼び出してください。API Key をブラウザに渡してはいけません。- 環境は API Key に従います。 テストキーならテストデータ、本番キーなら本番データでポータルが開きます。環境パラメータはありません
- クリックのたびにリンクを作成し、リダイレクトの直前に発行してください。キャッシュ・保存・メール送信はしないでください
- 302 でリダイレクト し、リダイレクトレスポンスに
Cache-Control: no-storeとReferrer-Policy: no-referrerを付けてください。トークン付きリンクがキャッシュされたり、referrer として渡されたりするのを防ぎます
createCustomerPortalRedirect は次のオプションを受け取ります:
ヘルパーが組み立てるレスポンスにはすべて
Cache-Control: no-store と Referrer-Policy: no-referrer が付きます。onError から返すレスポンスは自社の責任なので、同じく両方のヘッダーを付けてください。
SDK を使わない場合は、purpose: "portal" と storeId を付けてセッショントークンの発行を呼び出し、portalUrl + "#token=" + token にリダイレクトします。
ステップ 3:ボタンを追加する
ボタンは Waffo Pancake ではなく自社のルートを指すようにします。ブラウザが API Key を目にすることはなく、リンクは顧客がクリックしたときにだけ作成されます。セッションの動作
本番前のテスト
1
テスト注文を作成
テスト API Key を使い、テスト顧客の
buyerIdentity で認証済みチェックアウトから注文します。2
ポータルを開く
その顧客として自社サイトにサインインし、注文を管理をクリックします。テスト注文が表示されるはずです。
3
ID の境界を確認
別の顧客でサインインし、最初の顧客の注文が表示されないことを確認します。リクエストに他の顧客の ID を加えてみてください —— ルートはそれを無視しなければなりません。
4
本番に切り替え
本番 API Key でデプロイします。以降、リンクは本番データを開きます。
トラブルシューティング
ポータルは開くが注文が表示されない
ポータルは開くが注文が表示されない
- 注文が同じ
buyerIdentity文字列で作成されているか確認します(大文字小文字を含む完全一致) - 注文が渡した
storeIdのものか確認します - API Key の環境を確認します:テストキーはテスト注文のみ、本番キーは本番注文のみを表示します
- 匿名チェックアウトの注文は
buyerIdentityを持たないため、ここには表示されません
ポータルにセッション終了と表示される
ポータルにセッション終了と表示される
セッションが 15 分以上アイドル状態だった場合、または新しいリンクなしで、このブラウザのセッションとは別のストアのポータルを開いた場合、ポータルはショップのサイトから入り直してくださいと表示します。自社サイトの注文を管理から入り直してもらい、新しいリンクを取得してください。
ポータルにセッションが切り替わったと表示される
ポータルにセッションが切り替わったと表示される
顧客が同じブラウザで再度ポータルに入りました —— 別のタブで自社サイトから入った、別ストアのポータルに入った、またはメールのマジックリンクを使った場合です。最新の入場がそのブラウザのポータルセッションになり、古いタブにはセッションが切り替わりましたと表示され、現在のセッションに移動します。対応は不要です。
Customer Portal API から 403 Environment mismatch が返る
Customer Portal API から 403 Environment mismatch が返る
ポータルトークンで Customer Portal API を呼び出した際、
X-Environment が API Key の環境と異なっています。キーの環境を送ってください。チェックリスト
- リンクはサーバーで作成し、API Key はブラウザに届かない
-
buyerIdentityは自社のサインインセッションから取得し、チェックアウト時の値と一致する -
storeIdはリクエストではなくサーバーの設定から取得する - ルートは 302、
Cache-Control: no-store、Referrer-Policy: no-referrerで応答する - ポータルリンクとトークンをログに記録・保存しない
- 返金リクエストにはポータル外のサポート窓口がある
次のステップ
セッショントークンの発行
purpose: "portal" のリクエストとレスポンスのフィールド。カスタマーポータル
顧客がポータルで目にする内容。