メインコンテンツへスキップ

SDK

Webでの利用については、以下の理由からUnico SDKの使用を推奨します。

  • より高いセキュリティ;
  • お客様のフローとの統合された体験;
  • SDKを使用した場合のより高いコンバージョン率;
  • より簡単な実装。
警告

本ドキュメントで定められた基準に準拠しない連携を使用すると、システムの機能に予期しない障害が発生する可能性があり、これはカード非提示認証による対応やサポートの対象外となります。

例:webview内でUnicoをiFrameで実装する、HTMLタグを通じてiFrameを実装するなど。

一般的なガイドライン​

貴社の業務パフォーマンスを最適化し、コンバージョン率を向上させ、よりスムーズなユーザー体験を提供するために、アプリケーションにUnico SDKをフルスクリーンモードで実装することが必須です。

はじめに​

カード非提示認証 SDKを通じてカード非提示認証を利用するには、最初のステップとして、ユーザージャーニー体験を表示するホストとして使用されるドメインを登録する必要があります。

危険

この設定を行うために、連携プロジェクトの担当者またはUnicoサポートチームに通知してください。

SDKの使用を開始するには、まずUnico Web SDKのインストールから始めます。

npm install idpay-b2b-sdk
ヒント

Unico SDKパッケージをインストールする際は、バージョンを指定せずにデプロイし、依存関係管理ツールが常にマイナーバージョンおよびパッチを最新版に更新するようにしてください。

過去のバージョンを確認するには、npmjs.com/package/idpay-b2b-sdkにアクセスしてください。

利用可能なメソッド​

init(options)​

このメソッドを使用すると、取引IDに関係なくSDKを初期化でき、エンドユーザーの体験をよりスムーズにすることができます。これは、取引IDとトークンが利用可能になった時点で、アプリケーションがこのメソッドを通じて既に事前読み込みされているためです。このメソッドがアプリケーションによって直接呼び出されない場合、SDKが初めて開かれる際にエンドユーザーは長い読み込み時間を経験することになります。

パラメータ:

  • options — 設定プロパティを含むオブジェクトを受け取ります。
    • type — 初期化されるフローのタイプです。現在、IFRAMEタイプを提供しています。新規のアプリケーションについては、IFRAMEタイプの使用を推奨します。これにより、チェックアウト画面を離れる必要がなくなり、体験を事前に読み込んでおけるため、エンドユーザーの体験が大幅にスムーズになり、摩擦が軽減されます。
import { IDPaySDK } from "idpay-b2b-sdk";

IDPaySDK.init({
  type: 'IFRAME',
  env: 'uat' // テスト環境の場合のみ必要です。
});

open({ transactionId, token, onFinish? })​

このメソッドは、初期化関数で事前に選択されたフロータイプに応じてカード非提示認証体験を開きます。REDIRECTフローの場合、この関数はカード非提示認証キャプチャフローのルートへの単純なリダイレクトを実行します。IFRAMEフローの場合、この関数は事前に読み込まれたiframeを表示し、お客様のページとカード非提示認証体験との間のメッセージングフローを開始します。

パラメータ:

  • options — 設定プロパティを含むオブジェクトを受け取ります。
    • transactionId — 作成された取引のIDを受け取ります。このIDは、取引の詳細を取得しフローを正しく完了させるために重要です(APIを通じた取引作成時に取得できます)。
    • token — 作成された取引のトークンを受け取ります。このトークンは、取引を認証し、認可されたドメインのみがそれを使用できるようにするために重要です(APIを通じた取引作成時に取得できます)。
    • onFinish(transaction, type)(任意) — カード非提示認証キャプチャフローの終了時に実行されるコールバック関数を受け取ります。この関数には2つの引数が渡されます:取引オブジェクト({ captureConcluded, concluded, id })と、レスポンスタイプです — フローが正常に完了した場合はFINISH、エラーによってフローが中断された場合はERRORとなります。フロー中にエラーが発生した場合、取引ステータスは変更されず、設定されていてもWebhook経由のコールバックはトリガーされません。
const transactionId = '9bc22bac-1e64-49a5-94d6-9e4f8ec9a1bf';
const token = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c';

const transaction = {
  id: '9bc22bac-1e64-49a5-94d6-9e4f8ec9a1bf',
  concluded: true,
  captureConcluded: true
};

const onFinish = (transaction, type) => {
  console.log('response', transaction, type);
}

IDPaySDK.open({
  transactionId,
  token,
  onFinish
});

// 以下のメソッドを使用して、明示的にSDKを閉じることもできます
IDPaySDK.close();

セキュリティ​

ニーズと課題を慎重に分析した結果、Content Security Policy(CSP)を実装する代わりに、認証トークンを用いたiFrameベースのソリューションを採用することにしました。この決定は、セキュリティおよびお客様の要求に応えるために必要な柔軟性に関するいくつかの考慮事項によるものです。

CSPに関する背景と課題​

**Content Security Policy(CSP)**は、**クロスサイトスクリプティング(XSS)**やコードインジェクションなど、さまざまな種類の攻撃からWebアプリケーションを保護する強力なツールです。しかし、CSPポリシーを設定する際には、信頼できるドメインの厳密なリストを定義する必要があります。このアプローチは、ドメインが固定的かつ予測可能である場合にはうまく機能します。しかし、動的で可変的なドメインを頻繁に使用するお客様にとって、この厳格な設定は大きな課題となります。

動的ドメインに伴う脆弱性​

動的ドメインは、CSPを使用する際に重大なセキュリティリスクをもたらします。クライアントのドメインが頻繁に変更されたり、動的に作成されたりする場合、これらの新しいドメインを含めるためにCSPポリシーを常に更新する必要があります。これはメンテナンスの負荷を増加させるだけでなく、CSPポリシーが適用されるドメインを露出させることにもなります。CSPポリシーに追加された各ドメインは、適切に管理されなければ潜在的な脆弱性のポイントとなります。

iFrameと認証トークンによる解決策​

これらのリスクを軽減し、お客様が求める柔軟性に応えるため、認証トークンと組み合わせたiFrameを使用することにしました。このソリューションは、追加のセキュリティレイヤーを提供し、広範かつ動的なドメインのリストを公開・管理する必要性をなくします。

仕組み​

  • 安全な認証: 各iframeは、取引ごとに一意の認証トークンとともに読み込まれ、認可されたユーザーのみがコンテンツにアクセスできるようにします。このトークンはリアルタイムで検証され、追加のセキュリティレイヤーと制御を提供します。
  • コンテンツの分離: iFrameの使用により、コンテンツを別のコンテキストで分離でき、異なるオリジン間の干渉のリスクを低減し、潜在的な攻撃を軽減します。
  • 動的ドメインへの柔軟性: 静的なCSPポリシーに依存しないことで、私たちのソリューションはセキュリティポリシーの継続的な更新を必要とせずに、お客様の動的なドメインに容易に対応します。
最終更新 に