本文へ移動
チェックアウトの導入ウェブショップを設定する

ウェブショップを設定する

Tokenzのウェブショップは、Tokenzがホストするゲーム用のストアです。プレイヤーはそこでアイテムを購入し、Tokenzが決済を受け付け、ゲームサーバーがアイテムを付与します。ショップはダッシュボードで作成でき、ストアフロントを開発する必要はありません。

まずテストモードですべてを設定し、テスト購入をします。その後、1つのチェックリストからライブ公開します。ショップと注文のエンドポイントはテストからコピーでき、商品とプレイヤーIDの確認はライブでもう一度設定します。

始める前に

ダッシュボード右上のスイッチで、テストとライブを切り替えます。テストとライブでは商品、ショップ、Webhookエンドポイントが別々なので、テストで設定してもライブのショップは変わりません。テスト購入にはテストカードを使い、誰にも請求されません。

ゲームサーバーはウェブショップのために2つの役割を担います。

  • **注文を届ける。**Tokenzは支払い済みの注文をサーバーのエンドポイントに送り、サーバーがアイテムを付与します。
  • **プレイヤーIDを確認する。**プレイヤーが支払う前に、Tokenzは入力されたプレイヤーIDが存在するかをサーバーに問い合わせます。これでアイテムが実在するアカウントに届きます。

サーバーがどちらにも対応する前に、ショップを試せます。サーバーがまだない場合をご覧ください。

1. 商品を追加する

テストモードに切り替え、ショップ > 商品を開きます。アイテムを1つずつ作成するか、ファイルからカタログをインポートします。商品をインポートするをご覧ください。

公開した商品がショップで販売されます。下書きはショップに表示されません。

2. ショップを作る

ショップ > ビルダーを開き、ウェブショップを編集を選択します。ショップのアドレスを決め、販売する各言語でロゴ、色、テキストを追加します。エディターの横のプレビューに、プレイヤーに表示されるショップが映ります。

プレイヤーは支払う前にプレイヤーIDを入力します。プレイヤーIDのヘルプに、ゲーム内でIDが表示される場所を1〜2文で書いてください。スクリーンショットがあると伝わりやすくなります。プレイヤーは、プレイヤーID欄のヘルプアイコンからこの説明を開きます。

ショップの準備ができたら、公開を選択します。テストで公開してもショップは一般には公開されず、テスト購入ができる状態になります。

3. 注文の送信を設定する

ショップ > ビルダーで送信を設定を選択します。注文の送信ページで、注文をゲームサーバーに届ける方法を設定します。

  1. 注文の送信先に、注文を受け取るサーバーのHTTPSアドレスを入力し、エンドポイントを保存を選択します。
  2. 署名シークレットをコピーします。Tokenzはエンドポイントを保存したときに一度だけ表示します。サーバーはこれを使って、各注文がTokenzから届いたことを確認します。Webhookエンドポイントを保護するをご覧ください。
  3. テストイベントを送信を選択します。Tokenzが支払い済みのサンプル注文を送ります。サーバーは5秒以内に応答してください。

エンドポイントは、注文、返金、チャージバックのすべてのイベントを受け取ります。支払い済みの注文はorder.succeededイベントとして届き、playerIdにプレイヤー、アイテムにはSKUが入ります。そのプレイヤーにアイテムを付与し、refund.createdで取り消してください。イベントの説明はWebhookにあります。

エンドポイントを別の人が作る場合は、開発者に渡すで設定概要をコピーを選択します。概要にはエンドポイント、受け取るイベント、商品、サンプル注文が含まれます。署名シークレットは含まれないので、別に送ってください。

サーバーがまだない場合

テストモードでは、注文の送信ページにTokenzのテストサーバーを使うが表示されます。テストサーバーはすべてのテスト注文を受け付け、ゲームには何も届けません。テストの検証URLを設定するまでは、テストのプレビューも入力されたプレイヤーIDを確認せずに受け付けます。そのため、サーバーのコードを書く前にテスト購入ができます。サーバーの準備ができたら、そのアドレスを入力してください。

4. プレイヤーIDを確認する

Tokenzは、注文を受け取るエンドポイントとは別に、サーバー上の検証URLでプレイヤーIDを確認します。設定 > 開発者 > ユーザー検証を開くか、注文の送信ページで**「ユーザー検証」を開く**を選択します。テストとライブには、それぞれ専用のURLと署名シークレットがあるため、まずテストモードで設定します。

  1. 検証を設定を選択し、サーバーのHTTPSアドレスを入力して保存します。
  2. 署名シークレットをコピーします。署名シークレットは生成時に一度だけ表示されます。
  3. 実在するプレイヤーIDを入力し、テスト検証を送信を選択して、サーバーが応答することを確認します。

以降、プレイヤーがIDを入力すると、支払いの前に、TokenzはそのIDを含むuser.validationリクエストをこのURLに送ります。ライブのURLがtrueと応答した後は、Tokenzが数分間その応答を再利用し、サーバーを呼ばないことがあります。そのため、アカウントをすぐに止める手段としてこの確認に頼らないでください。応答の再利用を参照してください。テストのURLを設定するまでは、テストのプレビューはどのプレイヤーIDも受け付けるため、サーバーが応答できるようになってから設定してください。

json
{
  "id": "9f8d3c2b-1a4e-4f6d-8b0c-2e5a7d9f1c34",
  "object": "user.validation",
  "createdAt": "2026-07-22T09:15:00Z",
  "test": true,
  "credentials": { "type": "playerId", "playerId": "player-42931" }
}

HTTP 200と、プレイヤーが存在するかどうかを返します。

json
{ "valid": true }
  • プレイヤーが存在してもしなくても200を返してください。Tokenzはそれ以外のステータスを障害とみなし、プレイヤーは購入できません。
  • 3秒以内に応答してください。応答がないとプレイヤーは支払えず、もう一度試すよう案内されます。
  • validだけを返してください。IDを入力した人は誰でも応答を読めるので、プレイヤーについての情報はほかに送らないでください。
  • testがtrueのときは、テスト用のプレイヤーと照合してください。
  • 注文と同じようにTokenz-Signatureヘッダーを検証してください。ただし、検証URLの署名シークレットを使います。

リクエストと応答の詳細は、プレイヤーIDの確認を参照してください。

5. テスト購入をする

ショップ > ビルダーでプレビューを開くを選択します。テストで最後に公開したショップが開きます。テストカードでアイテムを購入し、サーバーがアイテムを付与したことを確認します。ダッシュボードがテストモードのとき、注文は注文にも表示されます。

6. ライブ公開する

ダッシュボードをライブに切り替え、ショップ > ビルダーを開きます。ライブ公開のリストに、ライブでまだ必要なものが、それぞれのボタンとともに表示されます。

必要に応じて横にスクロール
項目すること
契約ページ上部のアカウントを有効化から署名します。ライブの決済が始まる前に、Tokenzが契約を確認します。プロジェクトは組織の契約でカバーされます。
ライブで販売中の商品ライブには専用の商品があります。商品を追加を選択し、ライブでもう一度作成またはインポートします。
ショップテストからコピーを選択すると、ライブの下書きがテストで公開したショップに置き換わります。
注文の送信先テストの注文を自社のサーバーに送っている場合は、ライブでも使うを選択すると、ライブの注文も同じサーバーに送られます。ライブには専用の署名シークレットがあり、一度だけ表示されます。それ以外の場合は設定を選択し、サーバーのアドレスを入力します。
プレイヤーIDの確認ライブには専用の検証URLがあります。設定を選択してライブのユーザー検証を開き、サーバーのアドレスを入力して、ライブの署名シークレットをコピーします。

すべての項目の準備ができると、ウェブショップを有効化が使えるようになります。有効化するとライブのショップが公開され、プレイヤーはそのアドレスからアクセスできます。

お問い合わせ

Tokenzサポートに連絡し、ショップのアドレスをお知らせください。