integrate-hosted-fields

Payroc Hosted Fields 統合

対象範囲：CNP（カード非対面）Hosted Fields — 1 回限りの販売取引、トークン化（支払い詳細の保存）、継続課金。

バージョンの確認（最初に実行してください）

何かを告知したり、フローを開始したりする前に、このスキルが最新であることを確認してください。

1. 上記のフロントマターにある metadata.version フィールドから、このスキルのバージョンを読み取ります。
2. 公開されているコピーを取得し、その metadata.version を読み取ります。 https://raw.githubusercontent.com/payroc/skills/main/plugins/payroc/transaction/skills/integrate-hosted-fields/SKILL.md
3. 2 つのバージョンをセマンティックバージョンとして比較します。

   • このバージョン >= 公開版 → 何も伝えずに続行します。（未リリースの新しいバージョンを開発者が実行しているのは想定内であり、問題ありません。）

   • このバージョン < 公開版 → 開発者に次のように伝えます。

     ⚠️ このスキルの新しいバージョン（v<published>）が公開されています — 現在実行中のバージョンは v<current> です。最良の結果を得るため、アップグレードをおすすめします。

     現在のバージョンで続行するか、停止して先にアップグレードするかを尋ね、回答に従います。

   • 取得できなかった場合（オフライン、ネットワークエラー、404）→ バージョンを確認できなかったことを簡潔に伝えて続行します。

---

初回の呼び出し時に、開発者に次のように案内します。

Payroc Hosted Fields 統合 認証情報の設定から UAT テスト取引の成功までご案内します。 ここでは、Payroc の Hosted Fields を使用したカード非対面決済を扱います。Payroc がホストするカード入力ウィジェットを、独自のチェックアウトページに直接埋め込む方式です。

Hosted Fields の仕組み（3 つの要素）：

1. サーバーが Payroc の API を呼び出してセッショントークンを生成します。これにより、JS ライブラリが安全なカードフィールドを表示できるようになります。
2. Payroc の JS ライブラリが iFrame のカード入力フィールドをページに挿入します。顧客がサイトを離れることはありません。
3. 送信時に、ライブラリがカード詳細をトークン化して使い捨てトークンを返します。サーバーはそのトークンを使用して Payroc の決済 API を呼び出し、請求を処理します。

Hosted Fields と Hosted Payment Pages の違い： 顧客が支払いのために一時的にサイトを離れ、Payroc がホストするページにリダイレクトされるフローが必要な場合は、Hosted Payment Pages をご利用ください。これは別の製品であり、このスキルでは扱いません。

[MCP 接続確認ツールが利用可能な場合は、ここで実行し、続行する前に結果を提示してください。]

---

クイックリファレンス

# Identity service (Bearer token)
POST https://identity.uat.payroc.com/authorize
x-api-key: <api-key>

# Session token
POST https://api.uat.payroc.com/v1/processing-terminals/{processingTerminalId}/hosted-fields-sessions
Authorization:   Bearer <token>
Idempotency-Key: <uuid-v4>
Content-Type:    application/json

# Payments API
POST https://api.uat.payroc.com/v1/payments
Authorization:   Bearer <token>
Idempotency-Key: <uuid-v4>
Content-Type:    application/json

---

参照資料

すべての情報源は、以下のローカルファイル references/ にあります。このスキルは、リアルタイムの検索結果や記憶ではなく、これらの情報源に基づいて動作します。これらはこのスキルにとって信頼できるローカルスナップショットであり、元の URL と最終同期日は references/_sources.md に記録されています。情報源には、異なる種類の質問をそれぞれ担当する、互いに補完的な 3 種類があります。質問に合わない情報源を使うことは、既知の失敗パターンです。

• API スキーマリファレンス（references/api-schema.md）— Payroc API に送信される値と構造の信頼できる情報源です。 フィールド名、列挙値、必須フィールド、リクエストおよびレスポンスのスキーマが記載されています。Payroc API のフィールド名や受け付ける値を確認する場合は、必ず参照してください。OpenAPI 仕様から厳選した抜粋です。
• 解説ガイド（references/<page>.md）— 実装方法の信頼できる情報源です。 呼び出しの順序、最初から最後までのフロー、JS ライブラリの役割が記載されています。統合をどのように組み立てるかを学ぶには、こちらを使ってください。正確な SDK の構造について曖昧な記述がある場合もあります。その場合は 3 つ目の情報源を参照してください。
• SDK JS ファイル（references/hosted-fields-sdk.js）— SDK の設定構造、受け付ける子キー、公開 API メソッドの一覧に関する信頼できる情報源です。 このローカルスナップショットは、<script> タグに指定するものと同じ JS です。SDK は fields.card などに含まれる固定リストのキーを反復処理し、それ以外のキーは何も通知せず無視します。また、hostedFields インスタンスには固定リストのメソッドが公開されています。解説ガイドでは配置場所や名前が曖昧な場合があります（以前の実行時のフィードバックでも裏付けられている、ドキュメントポータルの既知の問題です）。SDK のソースは曖昧ではありません。プロパティ名、受け付ける子キー、メソッド名を確認する場合は、テキストとして読んでください。

「リクエストボディはどのように構成すればよいですか？」という質問には、スキーマリファレンスを参照してください。「これらの呼び出しはどの順番で行えばよいですか？」という質問には、ガイドを参照してください。「new Payroc.hostedFields({...}) で実際に受け付けられるものは何ですか？」または「cardForm.<method> は存在しますか？」という質問には、SDK のソースを参照してください。

情報源	ローカルファイル
API スキーマリファレンス（列挙値、必須フィールド、リクエスト／レスポンスのスキーマ）	references/api-schema.md
エラーレスポンス形式（RFC 7807 エンベロープ + Payroc の errors[] + 正規のエラータイプカタログ）	references/error-response-format.md
ステップ 1 — セッションを認証する	references/authenticate-your-session.md
ステップ 2 — 決済フォームを作成する	references/create-a-payment-form.md
ステップ 3 — 売上処理を実行する	references/run-a-sale.md
拡張 — フィールドのスタイルを設定する	references/style-your-fields.md
拡張 — カスタムフィールドを追加する	references/add-your-own-fields.md
拡張 — セッションを終了する	references/close-a-session.md
拡張 — 顧客の決済情報を保存する	references/save-a-customers-payment-details.md
拡張 — 顧客の決済情報を更新する	references/update-a-customers-payment-details.md
拡張 — 継続課金	references/recurring-billing.md
3-D Secure — 概要	references/3-d-secure.md
3-D Secure — 3DS を使って売上処理を実行する（実装フロー）	references/run-a-sale-with-3-d-secure.md
SDK JS ファイル（SDK の設定構造と公開 API メソッド名の信頼できる情報源 — テキストとして参照）	references/hosted-fields-sdk.js — <script> で読み込むものと同じ JS

ローカルスナップショットの元の URL と最終同期日は references/_sources.md に記載されています。古い情報と思われる場合は、そこから再生成してください。

---

基本原則

1. 質問する前に調査する — まずコードベースを読みます。見つかった情報を活用して、明らかな質問は省き、的を絞った質問をします。
2. 実装する前に質問する — インテークの質問をして、開発者の回答を待ってから実装コードを書きます。回答を「仮定」してコードを同時に提示しながら質問しても、このゲートを通過したことにはなりません。インテークは意思決定の場であり、前置きではありません。
3. 次に進む前に検証する — 開発者が現在のステップのチェックポイントが UAT で合格したと確認するまで、次のステップに進まないでください。
4. ローカルのリファレンスを読み、推測しない — 質問に合ったものを選ぶ。 ソースには 2 種類ではなく、3 種類あります。質問に合わないソースを使うと、記憶違いの値が入り込む原因になります。
   • スキーマ、フィールド名、列挙値、必須フィールド → references/api-schema.md。 API に送信されるあらゆる項目が対象です。よく目にする名前は次のとおりです：paymentRequest、payment（レスポンス）、transactionResult、card、secureTokenSummary、schemas-credentialOnFile、standingInstructions、firstTxnReferenceData、hostedFieldsCreateSessionRequest、HostedFieldsCreateSessionRequestScenario、StandingInstructionsSequence、StandingInstructionsProcessingModel。スキーマリファレンスで名前を検索するほうが、形状を確認するために説明ドキュメントを読み込むよりも速く済みます。
   • アプローチ、手順、ライブラリの組み込み → 説明ガイド（references/<page>.md）。「どの呼び出しを最初に行うか」「JS ライブラリをどう組み込むか」は、ガイドに関する質問であり、スキーマに関する質問ではありません。
   • SDK の設定形状、受け付ける子キー、公開 API メソッド名 → SDK の JS ファイル本体（references/hosted-fields-sdk.js）。このローカルスナップショットは、<script> で読み込むものと同じ JS です。SDK は fields.card[key] を固定の反復リストと照合して検証し、認識できないキーは黙って無視します。また、hostedFields インスタンスに固定のメソッド群を公開します。説明ドキュメントでは正確な配置やメソッド名が曖昧に記載されていることがありますが、SDK のソースは曖昧ではありません。プロパティ名、fields.card 内で受け付ける子キー、または cardForm のメソッドを確認する必要があるときは、JS をテキストとして読んでください。
   • リクエストとレスポンスのスキーマは異なります — 両方を読む。 レスポンスがリクエストと同じ形だと仮定しないでください。Hosted Fields のレスポンスでは paymentMethod ではなく card が使われます。また、cardSchemeReferenceId はカードではなく transactionResult にあります。リクエスト名からレスポンスを推測するのは、よくある落とし穴です。
   • JS ライブラリの CDN URL、SRI ハッシュ、libVersion は 4 部構成のバージョン文字列です。 バージョンを記憶から出力しないでください。references/create-a-payment-form.md（および references/hosted-fields-sdk.js のスナップショット）から読み取り、4 部構成の完全な文字列を使います（例：UAT では 1.7.0.261457、本番環境では 1.7.0.261471）。UAT と本番環境では、公開されるバージョンが異なる場合があります。
5. 値ごとに、読んでから出力する。 列挙値（例：channel、scenario、paymentMethod.type、transactionResult.status、standingInstructions.sequence、processingModel、secCode、accountType）、SDK の設定プロパティまたは受け付ける子キー、あるいは cardForm のメソッド呼び出しを出力する前に、関連するローカルリファレンスを読んでください。このスキルの失敗パターンに関する注意書き（ステップ 3、ステップ 4、エラー分類、アンチパターン）を信頼できる情報源として扱わないでください。これらは症状から間違いを見分けるためのものであり、リファレンスを読む手間を省くためのものではありません。列挙値は記憶に頼らず、references/api-schema.md から読み取ってください。もっともらしい英語風の列挙値（例：channel に "internet" を使う、成功ステータスを "approved" だけとする）は、この失敗でもっともよくある形です。
6. 認証情報をハードコードしない — API キーとターミナル ID は、ソースコードではなく、環境変数またはシークレットマネージャーから取得する必要があります。
7. 先に診断する — ステップが失敗したら、いったん停止し、エラー分類に沿って原因を調べてから続行してください。
8. セッショントークンはセッションごとに発行する — チェックアウトセッションごとに、新しいセッショントークンを生成してください。10 分間の有効期限は意図されたものであり、ユーザー間またはリクエスト間でキャッシュしてはいけません。

---

初期確認

まず、コードベースを調べてください。 以下を確認します。

• サーバー側の言語とフレームワーク
• 既存のチェックアウト、注文、決済関連のルートやハンドラー
• 既存の HTTP クライアント基盤（HttpClient、fetch、axios、RestClient など）
• Hosted Fields の部分的な実装（セッショントークンの呼び出し、Payroc JS ライブラリへの参照など）
• 環境変数や設定の管理方法
• 拡張できそうな PaymentService などがあるか

見つかった情報を使って、開発者自身が使っている用語で質問し、すでに推測できることは尋ねないようにします。

そのうえで、必要な情報を確認します。最低限、以下を確認してください。

質問 1 — インテグレーションの種類：

	Hosted Fields	Hosted Payment Pages
顧客体験	ページから移動せず、Payroc のカードウィジェットがフォームに埋め込まれます	Payroc のホスト型ページで決済するため、一時的にサイトを離れます
決済の実行	サーバーがワンタイムトークンを使って Payroc 決済 API を呼び出します	フォームの POST 時に自動で実行され、Payroc が顧客を元のサイトにリダイレクトします
このスキル	✓ ここで扱います	別のスキルが必要です — ここでは扱いません

• Hosted Fields → 続行します
• Hosted Payment Pages → 違いを説明し、ここで終了するか別の方法に案内するかを提案します

質問 2 — トランザクションの種類：

• 売上（即時キャプチャ） → 標準フローで続行します
• 決済情報の保存（トークン化） → tokenization シナリオが必要であることを伝え、後で使うためにカード情報を保管したいか確認します
• 両方 → まず売上を実装し、その後、拡張としてトークン化を追加します
• 継続課金 → 前提条件としてトークン化が必要であることを伝えます（初回の請求時にカードを保存し、以降の請求で再利用する必要があります）。継続課金の指示を実装したいか確認します。ステップ 4 に進んだら、references/recurring-billing.md も読んでください。

質問 3 — 決済方法：

Hosted Fields はカード、ACH、PAD に対応していますが、1 ページにつき 1 種類のみです。開発者が必要としているものを確認してください。不明な場合は、カードをデフォルトにします。

質問 4 — 3-D セキュア / SCA：

これはカードのフローでのみ質問します。ACH と PAD は 3DS の対象外です。

• 3DS は不要 → 標準のカードフローで続行します
• 必要 — 英国 / EU の顧客、PSD2 SCA、または加盟店がライアビリティシフトを希望 → 以下の追加前提条件を伝えます（端末で 3DS を利用するには Payroc サポートによる有効化が必要で、Webhook URL の登録も必要です）。インテグレーションには submissionSuccess と決済の間に MPI 呼び出しが追加され、決済リクエストボディに threeDSecure ブロックが必要になります。3DS のコードを書く前に references/run-a-sale-with-3-d-secure.md を読んでください。
• 不明 → 顧客が英国または EEA にいる場合は、「必要」をデフォルトにします。PSD2 SCA の下では、アクワイアラーは認証されていないトランザクションをソフトディクラインします。

---

続行する前に、開発者からの回答を待ってください。 4 つの質問すべてについて明確な確認を得るまで、実装コードを書いたり、例を示したり、前提条件に進んだりしないでください。回答によって作業範囲が完全に決まります。HPP を対象とする開発者は異なる手順をたどり、ACH ではカードとは異なるフォーム設定が必要で、3DS ではコードのエンドツーエンドテストを始める前に Payroc サポートへの依頼が必要な前提条件が追加されます。

前提条件

これらは、UAT で統合を実行してテストするために必要なものであり、コードを書くためのものではありません。開発者がすでに用意している場合は問題ありません。まだの場合も作業を止めず、各値を環境変数から読み取るようにコードを実装して、開発を続けてください。開発者はテストの前に変数を設定できます。

1. API キー — Payroc の ID サービスから Bearer トークンを取得するために使用します。HPP ターミナルシークレットとは異なり、Payroc Integrations チームが発行する有効期間の長い API 認証情報です。
2. 処理端末 ID — Payroc Integrations チームが発行する UAT 端末 ID です。UAT は Payroc のテスト環境であり、セルフサービスでの登録はできません。
3. UAT アクセスの確認 — Hosted Fields の基本的な売上処理フローでは、Self-Care Portal の設定は不要です（HPP と異なり、登録するレシート URL はありません）。

不足しているものがあれば、警告はしても作業は止めないでください。 コードベースを調べて既存の環境変数の命名規則があればそれに合わせ、なければ PAYROC_API_KEY や PAYROC_TERMINAL_ID のような名前を提案してください。認証情報をこれらの変数から読み取るコードを書いてから、未対応の項目と入手方法を開発者に伝えてください。

• API キー／UAT アクセス → Payroc Integrations チームに連絡し、テスト前に変数を設定します。その間も開発を続けられます。
• 開発者が既存の HPP 統合用に Payroc の認証情報をすでに持っている場合、同じ API キーと処理端末 ID を Hosted Fields でも使用できます。ここでは API キーを使って Bearer トークンを生成します。新しい認証情報を申請する必要はないことを明確に伝えてください。既存の環境変数に付けた名前をそのまま使用できます。

開発者が質問 4（3DS／SCA）に「はい」と回答した場合： 3DS のエンドツーエンドテストを行う前に手配を開始しておく必要がある前提条件を、さらに 2 つ追加してください。

4. 3DS が有効化された端末 — Payroc サポートが処理端末の 3DS を有効にします。これが完了するまで、MPI エンドポイント（/merchant/mpi）は応答しません。
5. Payroc サポートへの Webhook URL の登録 — Payroc は、加盟店が指定した URL に MPI の結果（mpiReference、result、status、eci）を POST します。この URL は Payroc のネットワークから到達可能である必要があり、3DS の売上処理を完了する前にサポートへ登録しておかなければなりません。

どちらも人手での対応が必要なため、すぐに [email protected] にメールして、両方の手配を開始するよう開発者に伝えてください。コードの開発はこれらに依存しないため、並行して進められます。ただし、両方が整うまでは、UAT で 3DS 取引をエンドツーエンドで完了できません。

確認ポイント

認証情報が確認できているか、または開発者が不足しているものとその入手方法、コードが読み取る環境変数を把握したうえで、作業を進めることを選択しています。（3DS の場合：端末の有効化と Webhook の登録を依頼するメールを [email protected] に送信しましたか？開発と並行して進められます。）不足している項目を明示しないままにしてはいけませんが、それを理由に作業を止めてもいけません。

---

ステップ 1 — 認証：Bearer トークンを取得する

参照：references/authenticate-your-session.md（Hosted Fields のセッショントークンフロー — ステップ 1 および 2） 参照：references/identity-call.md（Bearer トークン交換の正式なリファレンス — エンドポイント URL、ヘッダー名、レスポンス形式）

ID エンドポイント URL、x-api-key ヘッダー名、またはレスポンスのフィールド名を推測してはいけません。references/identity-call.md を読み、記載されている内容だけを出力してください。

何かを書く前に、各ページを読んでください。ローカルのリファレンスを確認し、以下を特定して使用してください。

• ID サービスのエンドポイント（テスト用と本番用）
• 必須ヘッダーとその形式
• アクセストークンを含むレスポンスフィールド
• トークンの有効期限と、有効期限が切れたときの対応

API キーを使って ID サービスに POST リクエストを送り、アクセストークンを返すサーバー側の関数を実装してください。これはサーバー側で実行する必要があります。API キーをブラウザーに送信してはいけません。

確認ポイント

リクエストは access_token を含む 200 を返しますか？返さない場合は、続行する前に API キーの値とエンドポイント URL を確認してください。

---

ステップ 2 — セッショントークンを作成する

参照：references/authenticate-your-session.md（同じページで両方の認証呼び出しについて説明しています）

セッショントークンは、特定のチェックアウトセッション用のフィールドを JS ライブラリが描画することを許可します。リファレンスを読み、次の点を確認してください。

• セッショントークンのエンドポイント（テスト環境と本番環境）
• 必須のリクエストボディのフィールド：libVersion、scenario、および Idempotency-Key ヘッダー
• libVersion の値 — 記憶に頼ってハードコードしないでください。まずステップ 3 で references/create-a-payment-form.md を読み、現在の値を確認してから戻って使用してください
• libVersion は4 部構成の文字列です（例：UAT では 1.7.0.261457、本番環境では 1.7.0.261471）。同じ 4 部構成のバージョンが、create-a-payment-form のページに出力される CDN URL にも含まれています。両者は一致している必要があります。3 部構成に切り詰めたり、記憶に頼って別のバージョンに置き換えたりしないでください。references/api-schema.md の hostedFieldsCreateSessionRequest.libVersion の説明にも、現在の本番バージョンが記載されています。
• libVersion は環境ごとに異なります。 UAT と本番環境では、異なる 4 部構成のバージョンが公開される場合があります。「どこでも同じ値を使う」というのは、環境内では正しいですが、環境をまたいで適用されるわけではありません。本番環境に切り替える際は、本番用の create-a-payment-form.md から libVersion、CDN URL、SRI ハッシュをまとめて読み直してください。UAT のバージョンを本番環境に持ち込まないでください。
• 有効な scenario の値は、references/api-schema.md の HostedFieldsCreateSessionRequestScenario enum から選びます（販売または販売とトークン化には payment、保存のみには tokenization）。カードに実際に請求する場合は、同じ呼び出しで保存も行う場合であっても、必ず payment を使用してください。
• セッションの有効期限（作成から 10 分）
• セッショントークンが含まれるレスポンスフィールド

オンデマンドでセッショントークンを生成し、フロントエンドに返すサーバーサイドのエンドポイントを実装してください。このエンドポイントでは、次の処理を行ってください。

• 新しい Bearer トークンを生成する（または、有効期限が近くないものを再利用する）
• libVersion、scenario: "payment"、および一意の Idempotency-Key を指定して、セッショントークンのエンドポイントに POST する
• token の値をクライアントに返す

重要： チェックアウトページが読み込まれるたびに、新しいセッショントークンを生成してください。ユーザー間やページ遷移間でセッショントークンをキャッシュしたり再利用したりしないでください。有効期間は 10 分と短く、古いトークンを使うとフォームの初期化に気づかないまま失敗します。

チェックポイント

呼び出しは token フィールドを含む 200 を返しますか？返さない場合は、Bearer トークンが有効であることと、パス内の端末 ID が正しいことを確認してください。

---

ステップ 3 — JS ライブラリを読み込み、フォームを初期化する

参照先：references/create-a-payment-form.md

何かを書く前にページを読んでください。ローカルの参照資料で以下を確認し、使用してください。

• JS ライブラリの CDN URL — 記憶に頼ってバージョンをハードコードせず、参照資料から読み取ってください
• 現在のバージョンの SRI ハッシュ（integrity 属性）
• ステップ 2 のリクエスト本文で必要な libVersion の値
• フィールド設定オプションと、それぞれの target セレクター
• initialize() の呼び出し方法と、その戻り値
• submissionSuccess イベントのペイロード — 特に token フィールドとその有効期限

フロントエンドの連携を実装します。

1. ページの <head>（または @section Scripts ブロック）に、CDN URL と SRI ハッシュを指定した <script> タグを追加します。

   スクリプトの順序： 初期化コードを実行する前に Payroc SDK を読み込む必要があります。テンプレートエンジンやフレームワークを使い、本文コンテンツと遅延スクリプト用セクション（フッター、スクリプトバンドル、レイアウトのパーシャルなど）が分かれている場合は、SDK の <script> タグと初期化ブロックの両方を同じ遅延セクションに配置し、SDK のタグを先に置いてください。初期化コードを本文に置き、SDK のタグを遅延読み込みにすると、エラーが発生しないまま処理に失敗します。Payroc は未定義となり、エラーも発生しません。

2. 決済フォームにコンテナー要素を追加します。各フィールド（cardholderName、cardNumber、expiryDate、cvv）用に、CSS クラスまたは ID セレクターを指定した <div> 要素と、送信先を追加します。

3. セッショントークン、mode: "payment" オプション、およびコンテナーのセレクターを指定したフィールド設定を使って、ホスト型フィールドオブジェクトを初期化します。

4. .initialize() を呼び出します。

5. submissionSuccess を監視します。このイベントは、ライブラリによるカードの検証とトークン化が完了したときに発生します。イベントのペイロードには、サーバーで必要となる単回使用トークンが含まれます。

6. error を監視し、type: "config"、"init"、"field"、"submission" の各カテゴリのエラーをログに記録するか、表示します。

new Payroc.hostedFields(...) の設定を出力する前に、SDK のソースを読む

説明資料の create-a-payment-form.md は読み始める資料として適していますが、ドキュメントポータルには少なくとも 1 つの SDK の構造に関する疑問点が曖昧に記載されています（以前の実行では cardForm.submitFields() と cardForm.submit() のどちらかだろうと推測していましたが、どちらも存在しません）。<script> に記述する SDK の JS は読みやすい JS ファイルであり、ローカルにスナップショットされています。設定を出力する前に references/hosted-fields-sdk.js を読み、grep してください。

1. 読むもの。 ローカルのスナップショット references/hosted-fields-sdk.js。これは <script> で読み込むものと同じ JS です（ヘッダーに UAT／prod の CDN URL と 4 部構成の libVersion が記録されています）。トレーニングデータの記憶をもとに SDK の内容を言い換えず、実際のファイルを読んでください。
2. 確認する内容。
   • SDK が fields.card 内で反復処理するキーの一覧（および fields.ach／fields.pad 内の同等のコンテナー）。この一覧にないものはすべて、何も通知されずに無視されます。fields.card の反復処理を検索し、受け付けられるキーを確認してください。
   • hostedFields インスタンスが公開するメソッドの一覧。つまり、どの cardForm.* 呼び出しが有効かを確認します。コンストラクターと、プロトタイプ／Object.assign／クラス本体を検索してください。
3. 確認してから出力する。 すべてのコンテナーのターゲットを、受け付けられるキーの一覧に含めてください。各メソッド呼び出しは、公開されているインターフェイスに対してのみ接続してください。存在すると想定したメソッドが一覧にない場合は、別の名前を推測して試さないでください。その処理は SDK が内部で担います。

既知の SDK 形状に関する失敗パターン

このスキルで、以前のモデルが犯した間違いです。症状を見分けられるように記載しています。修正方法は常に「SDK のソースを読み、現在受け付けられる内容を出力する」ことであり、「以下の値を使う」ことではありません。

• 症状： 設定の最上位に送信先プロパティ（例：submitButton: { target: '#pay' }）があるにもかかわらず、SDK が "A submit button is required for payment forms" という error を発生させます。過去の誤り： 送信先を設定オブジェクトの最上位に置いていましたが、SDK は fields.card の内側からしか読み取りません。確認方法： references/hosted-fields-sdk.js で fields.card[...] を反復処理する箇所を検索し、送信キーを実際にどこから取得しているかを特定します。
• 症状： 手動のクリックハンドラーで、実行時に TypeError: cardForm.submitFields is not a function（.submit() や .validate() でも同様）が発生します。過去の誤り： SDK がプログラムから送信を実行する機能を公開していると思い込み、payButton.addEventListener('click', () => cardForm.submitFields()) を設定していました。確認方法： references/hosted-fields-sdk.js でインスタンスが公開するメソッドを検索します。使用したメソッドが存在しない場合、SDK 自身が送信要素（iframe）を描画してクリック処理も管理しています。手動のハンドラーを削除してください。
• 症状： フィールドのコンテナーはページレベルの CSS による枠線や背景付きで表示されますが、操作できません。iframe は挿入されず、error イベントも発生しません。これはエラー分類で説明済みの、スクリプト読み込み順序の問題です。形状に関する症状をすべて一か所で確認できるよう、ここでも相互参照しています。

迷った場合は、SDK の JavaScript はテキストです。references/hosted-fields-sdk.js を読んでください。

チェックポイント

カード入力フィールドはページに表示されていますか？ テストカード情報を送信したとき、ペイロードにトークンを含む submissionSuccess が発生しますか？ そうでない場合は、ブラウザーのコンソールで error イベントを確認してください。

---

ステップ 3b — 3-D Secure（質問 4 の回答が「はい」の場合のみ）

参照先：references/run-a-sale-with-3-d-secure.md

何かを書く前に、このページを読んでください。3DS の経路では、サーバー呼び出しが 1 回追加され、決済リクエストに 1 つのブロックが追加されます。

1. submissionSuccess が発生した後（ステップ 3）、サーバーは単回使用トークン、金額、通貨、orderId、メールアドレス、processingTerminalId、および任意の cardholderChallenge（チャレンジを強制する場合は REQUIRED、発行会社の判断に任せる場合は OPTIONAL）を使って、GET /merchant/mpi（テスト環境：payments.uat.payroc.com、本番環境：payments.payroc.com）を呼び出します。
2. Payroc が 3DS チャレンジを実行し、その結果を [email protected] に登録した webhook URL に送信します。ペイロードには mpiReference、result、status、eci が含まれます。
3. webhook は mpiReference を orderId（または同様の識別子）に紐付けて保存し、ステップ 4 で取得できるようにします。
4. ステップ 4 の決済リクエストに threeDSecure ブロックを追加します：{ "serviceProvider": "gateway", "mpiReference": "<from webhook>" }。これにより、認証情報がライアビリティシフトのためにアクワイアラーへ引き継がれます。

PSD2／英国 SCA の免除（TRA、少額決済、MIT）： 公開ドキュメントでは、これらについて詳しく説明されていません。開発者が免除の明示的な処理を必要とする場合は、推測せずに Payroc Integrations チームにエスカレーションしてください。

チェックポイント

MPI GET は 200 を返しますか？ webhook は mpiReference を含む結果を受け取りますか？ どちらも発生しない場合、端末で 3DS がまだ有効になっていない可能性が高いため、先に進む前に Payroc サポートに確認してください。

---

ステップ 4 — 決済を実行する

参照先：references/run-a-sale.md

何かを書く前に、このページを読んでください。ローカルのリファレンスで、以下を確認してください。

• 決済 API のエンドポイント（テスト環境と本番環境）
• 必須ヘッダー：Content-Type、Authorization: Bearer <token>、Idempotency-Key
• リクエスト本文の必須最小項目：channel、processingTerminalId、order（orderId、最小通貨単位での金額、通貨）、paymentMethod
• 単回使用トークン用の paymentMethod 構造：type: "singleUseToken"、token: <submissionSuccess から取得した値>
• 成功時の HTTP ステータス、および決済が処理されたことの確認方法

references/api-schema.mdからすべての列挙値を読み取ってください。英語としてもっともらしい値を推測してはいけません。 リクエストボディ内の列挙型文字列（channel、paymentMethod.type、standingInstructions.sequence、processingModel、secCode、accountType、通貨、国）は、すべてローカルのスキーマリファレンスに記載された値を使用する必要があります。過去に発生した既知の失敗： ブラウザー内のチェックアウトで妥当に聞こえるという理由で、モデルがchannel: "internet"を出力しました。その結果、Payrocはエラー詳細に列挙値の一覧を含むHTTP 400を返しました。ここで正しい値を暗記するのではなく、ボディを組み立てる際にreferences/api-schema.mdからpaymentRequest.channel（または設定しようとしているフィールド）を読み取ってください。もっともらしい類似値（internet、online、ecommerce、card-not-present）が、この種の失敗でもっともよく見られます。

submissionSuccessハンドラーから、単一使用トークンをサーバーに送信します。次に、サーバーは以下を行います。

1. 有効なBearerトークンを生成する（または再利用する）
2. 単一使用トークンを含む決済リクエストボディを組み立てる
3. 3DSを使用した場合（ステップ3bを実行した場合）： threeDSecure: { serviceProvider: "gateway", mpiReference: "<your MPI webhookから取得した値>" }を決済リクエストボディに追加する
4. 新しいIdempotency-Keyを付けて、決済APIにPOSTする
5. HTTPステータスを確認する。201は、Payrocがリクエストを処理したことを意味し、発行会社が承認したことを意味するわけではありません。承認／拒否の結果はレスポンスボディ（transactionResult.statusとtransactionResult.responseCode）にあります。HTTPコードではなく、レスポンスボディに基づいて分岐してください。

成功時の分岐は、記憶している一部の値ではなく、列挙値全体に基づいて作成してください。 成功チェックを書く際に、references/api-schema.mdのtransactionResult.status列挙値を読み取ってください。銀行による承認に対応するすべての値を特定し、その値の集合に基づいて分岐してください。過去に発生した既知の失敗： モデルがstatus == "approved"だけで分岐したため、APIがresponseCode: "A"／responseMessage: "APPROVAL"とともに"ready"（承認済み＋キャプチャ待ち）を返した際、実際の承認を失敗として気づかないまま記録しました。解決策は「readyも受け入れる」ことではありません。根本的な誤りは、列挙値について不完全な記憶に基づいてチェックを作成したことです。列挙値を読んでください。

フレームワークに関する注意 — AJAXハンドラーのアンチフォージェリ／CSRF。 submissionSuccessから単一使用トークンを受け取るエンドポイントは、従来のHTMLフォーム送信ではなく、fetch／XHRによるPOSTです。ほとんどのサーバーフレームワークでは、デフォルトでPOSTに対してCSRF／アンチフォージェリ対策が有効になっています。次の2つの方法があります。優先順に、（1）トークンを渡す — レンダリングされたページからフレームワークのCSRFトークンを読み取り、submissionSuccessコールバックからリクエストヘッダーとして送信します。（2）このハンドラーのみ無効にする — デモや社内専用ツールでは許容されますが、本番環境では使用しないでください。

フレームワーク別の設定：

• ASP.NET Core／Razor Pages。 [IgnoreAntiforgeryToken]はPageModelのクラスレベルで適用する必要があります。単一のハンドラーメソッドに適用すると、ビルド時にMVC1001が発生します。アンチフォージェリを有効にするには、フォーム内に@Html.AntiForgeryToken()をレンダリングし、生成された__RequestVerificationTokenの値をRequestVerificationTokenヘッダーとして送信します。
• Django。 csrftoken Cookieの値をX-CSRFTokenリクエストヘッダーとして送信するか、ビューに@csrf_exemptデコレーターを付けます。
• Rails。 csrf-tokenメタタグの値をX-CSRF-Tokenヘッダーとして送信するか、コントローラーのアクションでskip_before_action :verify_authenticity_tokenを指定します。
• Express + csurf。 csurfの設定に従い、トークンをcsrf-token（またはX-CSRF-Token）ヘッダーとして送信します。
• Laravel。 XSRF-TOKEN Cookieの値をX-XSRF-TOKENヘッダーとして送信する（Laravelのデフォルトの動作）か、ルートをVerifyCsrfToken::$exceptに追加します。

単一使用トークンは、一度しか使用できません。 正当な拒否以外の理由で決済API呼び出しが失敗した場合、開発者は新しいセッショントークンを生成し、フォームを再初期化してから、お客様が再試行できるようにする必要があります。単一使用トークンは再送信できません。

チェックポイント

テストカードを使用した場合、payments API は UAT で HTTP 201 を返しますか？返さない場合は、以下のエラー分類を使用してください。

---

ローカルテスト戦略

Payroc からのブラウザーリダイレクトもサーバー側の Webhook もないため、すべての手順（セッショントークンの生成、フォームのレンダリング、決済 API の呼び出し）は localhost で動作します。フロー全体は開発者のブラウザーセッション内で実行されます。

---

エラー分類

症状	考えられる原因	対処方法
フォームフィールドが表示されず、submissionSuccess が一度も発火しない	セッショントークンの有効期限が切れている（生成から10分超過）、または initialize() が呼び出されていない	ページ読み込み時にセッショントークンを再生成します。type: "init" または type: "config" の error イベントがないか確認します
type: "config" の error イベントが発生する	コンストラクターでセッショントークンが指定されていないか、無効	セッショントークンが new Payroc.hostedFields({sessionToken: ...}) に正しく渡されていることを確認します
決済 API が 401 を返す	Bearer トークンの有効期限切れ、または API キーが誤っている	Bearer トークンを再取得し、ID サービスで使用する x-api-key の値を確認します
決済 API が 409 を返す	冪等性キーが再利用されている	決済リクエストごとに新しい UUID v4 を生成します。冪等性キーは決して再利用しないでください
決済 API が 400/422 を返す	単回使用トークンがすでに使用済み、または有効期限切れ（30分の有効期間を超過、または使用済み）	トークンは一度だけ使用できます。顧客はカード情報を再入力する必要があります。新しいセッショントークンを生成し、フォームを再初期化します
CDN スクリプトの読み込みに失敗する	CDN URL が古い、または正しくない	references/create-a-payment-form.md から現在の URL と SRI ハッシュを確認します
libVersion の不一致エラーが発生する	セッショントークンのリクエストに指定した libVersion が、読み込まれた JS ライブラリのバージョンと一致しない	references/create-a-payment-form.md で両方の値を確認し、一致していることを確かめます
フィールドコンテナーは表示される（CSS でスタイル設定された枠線や背景は表示される）が操作できない。iframe が挿入されず、コンソールエラーもない	Payroc SDK スクリプトが読み込まれる前に初期化コードが実行されている。new Payroc.hostedFields(...) は ReferenceError: Payroc is not defined をスローします。cardForm が作成されないため、.on('error', ...) ハンドラーも設定されず、エラーが通知されないままになります	初期化コードの実行前に SDK の <script> タグがレンダリングされ、実行されるようにします。スクリプトの実行を遅延するレイアウトでは、SDK タグと初期化ブロックの両方を同じ遅延実行セクションに置き、SDK タグを先に配置します
SDK の初期化が始まり（iframe の読み込みが始まり）、すぐに "CVV wrapper is required for card forms. If you do not have a wrapper, please provide false." が発火する	cvv フィールド設定に wrapperTarget プロパティがない、またはキー名が誤っている（wrapper を wrapperTarget の代わりに使用している）	cvv フィールド設定に wrapperTarget: false を追加します。ラッパー要素がある場合は、false の代わりにその CSS セレクター文字列を渡します。注：wrapper: false（誤ったキー）は無視されます。プロパティ名は wrapperTarget である必要があります
決済が拒否される（201 以外のステータス、またはレスポンス内の拒否フラグ）	テストカードが UAT で有効ではない	Payroc UAT テストカードを使用し、レスポンスボディ内の transactionResult.status と transactionResult.responseCode を確認します
HTTP 201 が返されたのに、顧客からカードが拒否されたと言われる	HTTP 201 を承認と混同している	201 は Payroc がリクエストを受け付けて処理したことを意味し、カード発行会社が承認したことを意味しません。承認／拒否の結果は transactionResult.status（列挙値には declined が含まれます）と transactionResult.responseCode（例：A=承認、D=拒否、R=照会、C=CVV エラー）に含まれます。201 ではなくボディの内容に基づいて分岐してください
CSP によって Payroc CDN ホストがブロックされ、スクリプトが読み込まれず、error イベントも発火しない	Content Security Policy に Payroc CDN ホストが設定されていない	Payroc CDN ホスト（<script> の src のホスト。正確な UAT および本番用ホストは references/hosted-fields-sdk.js のスナップショットヘッダーを参照）を、（JS ファイル用の）script-src と、ライブラリが挿入する iFrame 用の frame-src／child-src の両方に追加します。また、トークン化の XHR 用に connect-src も追加します。本番稼働時には UAT ホストを本番用ホストに切り替えることを忘れないでください
MPI エンドポイントが 404 または認証エラーを返す	端末で 3DS が有効になっていない、または Webhook URL が登録されていない	[email protected] にメールを送り、端末で 3DS を有効にして Webhook URL を登録してもらいます。両方が完了するまで、MPI／3DS の呼び出しは成功しません
Payments API が、エラー詳細で "channel"（またはその他の列挙型フィールド）を指定し、許可された値の一覧を含む HTTP 400 を返す	列挙型にない値が出力された（過去の失敗例：channel: "internet"、"online"、"ecommerce"）。スキーマの参照先を確認せず、もっともらしい類似値を生成してしまった	references/api-schema.md で paymentRequest.channel（または該当フィールド）を確認し、一覧に記載された値のいずれかを出力します。英語としてもっともらしいかどうかで列挙値を推測しないでください
設定の最上位に送信先プロパティがあるにもかかわらず、SDK が error と "A submit button is required for payment forms" を発火する	プロパティが最上位にあり、SDK は送信関連のキーを fields.card 内からしか読み取らないため、反復処理対象外のキーはすべて無視される	references/hosted-fields-sdk.js を読み、fields.card[...] を反復処理している箇所を grep します。SDK が実際に読み取る位置に送信先を配置します。送信に関する形の最上位キーはスキーマに含まれていません
手動のクリックハンドラーで実行時に TypeError: cardForm.<method> is not a function が発生する（過去の失敗例：submitFields、submit、validate）	そのメソッドは SDK のパブリック API に存在しない。送信先が fields.card 内に設定されると、SDK はそれを iframe としてレンダリングし、クリックを制御する	references/hosted-fields-sdk.js を読み、hostedFields インスタンスで公開されているメソッドを確認します。使用したいメソッドが一覧にない場合、SDK が送信処理を内部で行っています。別の名前を推測するのではなく、手動ハンドラーを削除します
アプリでは決済失敗と記録されたが、実際には銀行が承認していた。レスポンスには responseCode: "A"／responseMessage: "APPROVAL" と表示される	サーバー側の成功判定が、記憶していた transactionResult.status の一部の値だけで分岐していた（過去の失敗例："approved" のみを受け入れ、承認済みで売上確定待ちの "ready" を失敗として誤処理した）	references/api-schema.md で transactionResult.status の列挙値を確認します。銀行の承認と組み合わさる値の全種類に基づいて分岐してください。列挙値についての不完全な記憶をもとに成功判定を作らないでください

---

検証チェックリスト

• API キーとターミナル ID は環境変数から取得しており、ソースコードには記述されていない
• Bearer トークンはサーバー側で生成され、ブラウザーに公開されていない
• セッショントークンはチェックアウトページの読み込みごとに生成され、セッションをまたいでキャッシュされていない
• JS ライブラリの CDN URL と SRI ハッシュは references/create-a-payment-form.md から読み取っており、記憶に頼ってハードコードされていない
• セッショントークンのリクエスト内の libVersion は、CDN URL 内のバージョンと一致している
• 決済 API の呼び出し前に、トークンを伴って submissionSuccess が発火することを確認している
• 冪等性キーは、決済リクエストごとに新しい UUID v4 である
• テストカードを使って、UAT で HTTP 201 を確認している
• 単回使用トークンはログに記録されず、API 呼び出しの直後以降は保存されない
• リクエストボディ内のすべての列挙値（channel、paymentMethod.type、standingInstructions.* など）は、記憶に頼らず references/api-schema.md から読み取っている
• SDK の設定キーと cardForm.* メソッドの呼び出しは、references/hosted-fields-sdk.js をテキストとして読み、照合している
• transactionResult.status に対するサーバー側の成功分岐では、references/api-schema.md の列挙値に含まれるすべての承認値（例："ready"）を処理しており、記憶している値ひとつだけを対象にしていない

---

アンチパターン

JS ライブラリのバージョンや CDN URL をハードコードする — バージョンはリリースごとに変わるため、ハードコードした URL はバージョンが上がると、気付かないうちに動作しなくなります。

ページの読み込みをまたいでセッショントークンをキャッシュする — 有効期限が 10 分のため、キャッシュしたトークンはチェックアウトに時間がかかると有効期限が切れてしまいます。チェックアウトページの読み込みごとに新しいトークンを生成してください。

冪等性キーを再利用する — 異なる決済リクエストに同じキーを 2 回送信すると 409 が発生します。リクエストごとに新しい UUID v4 を生成してください。

submissionSuccess の前に決済 API を呼び出す — 単回使用トークンは、ライブラリが submissionSuccess を発火した後にのみ存在します。トークンをポーリングしたり、合成したトークンを作成したりすると失敗します。

Bearer トークンをクライアントに公開する — Bearer トークンは API へのアクセス権を与えるため、サーバー側だけで管理してください。クライアントに返されるセッショントークンは、スコープが限定され、短時間で有効期限が切れるよう設計されています。

同じ単回使用トークンで再試行する — トークンは一度しか使用できません。再試行が必要な場合は、ユーザーが新しいセッショントークンを使ってフォームのフローを最初からやり直す必要があります。

SDK スクリプトがまだ読み込まれていない場所に初期化コードを配置する — 多くのサーバーサイドテンプレートエンジンやフロントエンドフレームワークでは、ページ本文のコンテンツと遅延スクリプトブロックが分離され、本文の後にスクリプトがレンダリングされます。初期化コードが本文に置かれ、SDK の <script> タグが遅延セクションに置かれると、Payroc がまだ未定義の状態で初期化が実行されます。cardForm が作成されず、.on('error', ...) ハンドラーも設定されないため、このエラーは表面化しません。SDK の <script> タグと初期化ブロックは同じ遅延位置または本文末尾の位置にまとめ、SDK タグを先に配置してください。

CVV の設定で wrapperTarget: false ではなく wrapper: false を使う — 正しいプロパティ名は wrapperTarget です。誤った名前の wrapper を使っても SDK は無視するため、設定の検証エラーは解消されず、SDK 自体のエラーメッセージからキー名の不一致を知ることもできません。必ず wrapperTarget を使い、wrapper は使わないでください。ラッパー要素がない場合、値はブール値の false です。ラッパー要素がある場合、値はその CSS セレクター文字列です。

// Correct
cvv: { target: '.card-cvv', wrapperTarget: false },

// Wrong — silently ignored, config error persists
cvv: { target: '.card-cvv', wrapper: false },

スキーマのリファレンスを読まずに列挙値を指定する。 channel、paymentMethod.type、standingInstructions.sequence、processingModel、secCode、accountType、transactionResult.status はすべて列挙型です。過去には、ブラウザー内チェックアウトに適しているように聞こえるものの列挙値には含まれていない channel: "internet" を指定したり、成功判定を "approved" のみにして "ready" を見落としたりする問題がありました。このスキルでは正規の値を列挙できません。正規の値は references/api-schema.md に記載されています。リクエストボディを作成する前と、レスポンスの分岐を実装する前に、スキーマのリファレンスを読んでください。 プロパティ名とメソッド名について、説明文形式のSDKドキュメントを信頼すること。 説明文形式の create-a-payment-form.md は、少なくとも1つのSDKの形式に関する質問で曖昧だと記録されています（以前の実行では、submitFields() と submit() のどちらかという含みがありました）。new Payroc.hostedFields({...}) が受け取る内容と、cardForm に存在するメソッドについて明確な情報源は、references/hosted-fields-sdk.js のみです。設定や cardForm.* 呼び出しを出力する前に、テキストとして読んでください。

cardForm のメソッドを呼び出す手動のクリックハンドラーを追加すること。 これまでの失敗例では、cardForm.submitFields()、cardForm.submit()、cardForm.validate() が誤って使われていましたが、SDK が公開しているメソッドにこれらはありません。fields.card 内で送信先を設定すると、SDK はそれを iframe としてレンダリングし、クリックを処理します。判断を誤ったことを示す目に見える兆候は、TypeError: cardForm.<method> is not a function です。実際に存在するメソッドを確認するには、references/hosted-fields-sdk.js を読んでください。使おうとしているメソッドがその中にない場合は、別のメソッド名を推測せず、手動ハンドラーを削除してください。

列挙型についての不完全な認識に基づいて、成功判定を作成すること。 実際の実行では status: "ready" と responseCode: "A" / responseMessage: "APPROVAL" が返されました。銀行は承認していましたが、判定が status == "approved" だったため、アプリは失敗を記録しました。修正のために "ready" をハードコードされたリストに追加するのではありません。根本的な誤りは、スキーマのリファレンスではなく記憶を頼りに列挙型を判断したことです。references/api-schema.md で transactionResult.status を確認し、銀行の承認と組み合わされる値をすべて特定して、その全種類を処理してください。

---

完了

HTTP 201 が確認され、すべてのチェックリスト項目に合格したら：

連携が完了しました。 以下を実装しました。

• Bearer トークン — API キーを使用してPayrocのIDサービスからサーバー側で取得します。すべてのPayroc API呼び出しを認証します。
• セッショントークン — チェックアウトセッションごとに生成される、スコープが限定された短期間有効なトークンです。JSライブラリによるカード入力欄の表示を認証します。
• Hosted Fieldsフォーム — PayrocのJSライブラリがページ内にiFrameのカード入力欄を表示します。カードデータがサーバーに送信されることはありません。
• 単回使用トークン — フォーム送信時にライブラリがクライアント側で生成し、決済を実行するためにサーバーへ渡します。
• 決済API呼び出し — サーバーからPayrocのpayments APIに単回使用トークンをPOSTします。HTTP 201によって決済が確認されます。
• UATで検証済み — テストカードを使用したエンドツーエンドの取引が確認されています。

本番稼働の前に： UATエンドポイントのURLを本番URL（ID、セッショントークン、payments API）に切り替え、認証情報を本番ターミナルに設定してください。本番用のcreate-a-payment-form.mdページから、libVersion、CDN URL、SRIハッシュを再度読み込んでください。これらの値は環境ごとに異なるため、UAT用の値は本番環境では使用できません。

まだ実装されていない項目に応じて、次のステップを案内してください。

• トークン化 — 顧客のカード情報をセキュアトークンとして保存し、今後の決済に使用します。セッショントークンリクエストでscenario: "tokenization"を指定し、secure-tokens APIを使用します。
• 継続課金 — 初回決済で継続的な支払い指示を設定し、保存済みトークンを後続の加盟店起点取引で再利用します。references/recurring-billing.mdをお読みください。
• 顧客の保存済みカードを更新する — 顧客のカードの有効期限が切れた場合や変更された場合、新しいトークンを作成せずに、保存済みsecureTokenに紐づくカード情報を更新できます。このフローではscenario: "payment"ではなくscenario: "tokenization"を使用し、取引を伴いません。決済もゼロ金額のオーソリも不要です。実装前にreferences/update-a-customers-payment-details.mdをお読みください。
• 3-D Secure — 開発者が初回の要件確認で3DSを省略したものの、後から必要になった場合（例：アクワイアラーが英国の取引をソフトディクラインする場合）は、上記のステップ3bを参照してください。
• スタイリング — styles設定オプションを使ってCSSでHosted Fieldsの外観をカスタマイズします。
• カスタムフィールド — onPreSubmitのバリデーションを使用して、カード入力欄とともに追加データを収集します。
• セッション終了時のクリーンアップ — 顧客がチェックアウト途中でキャンセルした場合やページを離れた場合は、Hosted Fieldsのインスタンスでdestroy()を呼び出し、iFrameを破棄します。これはセッショントークンの10分間の自動有効期限とは別の処理で、クライアント側のリソースを解放します。正確なAPIについてはreferences/close-a-session.mdをお読みください。
• Hosted Payment Pages — 開発者が後からリダイレクト方式のフローを必要とする場合（例：別ページでのACH決済）は、HPPのスキルを使用します。