- インテグレーションガイドライン
- サポートされている機能(セキュリティ)
- Credential on File、カード所有者および加盟店が開始する取引
Credential on File、カード所有者および加盟店が開始する取引
このページでは、カード所有者が開始する取引と加盟店が開始する取引を処理するカードスキーム標準に準拠するために、これらの取引をゲートウェイに送信する方法を説明します。
支払者から支払詳細を収集し、保存し、その後支払者の今後の支払いを処理するために使用すると、インテグレーションがあったことになります。この場合、今後の使用に向けて支払詳細を保存し、使用する予定の初回取引でゲートウェイに情報を提供します。保存した支払詳細を使用して、支払者が開始 (カード所有者が開始する取引) または支払者との支払契約の結果として、加盟店であるユーザーが開始 (加盟店が開始する取引) した後続の支払いを実行する時には、ゲートウェイにこの情報を提供する必要があります。
これは、保存した支払詳細 (Credential on File (COF) 要件とも呼ばれます) を使用して、カード所有者が開始する取引と加盟店が開始する取引を処理するために、カードスキーム標準に準拠することを目的としています。保存した支払詳細、カード所有者が開始する取引、加盟店が開始する取引を識別するためにゲートウェイに情報を送信することにより、以下ができるようになります。
- イシュアー (カード発行会社) に対する取引リスクレベルの可視性を向上
- 承認率と販売完了数を向上
- 支払者の操作を改善
ゲートウェイは、保存した支払詳細を使用して行う以下の支払いについて、<<webServicesIntegration>> v54 以降でサポートしています。
3DS での Credential on file
3DS でのカード所有者が開始する支払いを使用できます。詳細情報については、以下の特定の詳細をお読みください。
カード所有者が開始する支払いの実行
カード所有者が開始する取引とは、支払者のアクティブな参加によって実行される取引です。たとえば、電子商取引、メールオーダーまたは電話注文取引。
取引が支払者によって開始されたことを示すため、transaction.source
を INTERNET
/MOTO
/MAIL_ORDER
/TELEPHONE_ORDER
/VOICE_RESPONSE
/CALL_CENTER
に設定する必要があります。このガイド全体を通して、カード所有者が開始する取引の例示としてインターネットでの支払い (transaction.source
=INTERNET
) を使用しています。ですが、別の許可されている値に変更できます。
カード所有者が開始する取引は、1 回限りの支払いになる場合があります。これは通常、支払者から提供された支払詳細を保存しないものをいいます。しかし、今後の使用に向けた支払詳細の保存 (通常は顧客登録または口座作成プロセスの一環として) について、支払者との間で契約を締結し、保存した支払詳細を使用してカード所有者が開始する後続の取引を実行することができます。
支払者のインタラクション中に、支払者がその支払いの詳細を今後のために保存することに同意した場合、初回取引の以下のフィールドに情報を入力する必要があります。
sourceOfFunds.type
=CARD
またはSCHEME_TOKEN
sourceOfFunds.provided.card.*
フィールドまたはsourceOfFunds.token
transaction.source
=INTERNET, and
sourceOfFunds.provided.card.storedOnFile
:TO_BE_STORED.
支払者 (ユーザーではなく) が開始した後続の支払いで、支払者の保存された支払詳細が使用されている場合、以下を入力する必要があります。
sourceOfFunds.type
=CARD
またはSCHEME_TOKEN
sourceOfFunds.provided.card.*
フィールドまたはsourceOfFunds.token
transaction.source
=INTERNET, and
sourceOfFunds.provided.card.storedOnFile
:STORED.
支払詳細が保存されている、保存されていない、保存する予定かをゲートウェイで示す方法については、「よくある質問」を参照してください。
加盟店が開始する支払いの実行
加盟店が開始する取引とは、保存した支払詳細を使用して、支払者のアクティブな参加なしで実行される取引です。加盟店が開始する取引は、以下を提供する時に実行される場合があります。
- 事前に定義されたスケジュール (雑誌の購読やジムの会員費に対する後続の登録型決済) を使用して、支払者に課金する必要がある商品またはサービス
- 1 回の購入に対して、支払者が複数回の分割払いで支払うとき
- オンデマンドサービスについて、支払者に課金するサービス (使用できる金額が定義したしきい値を下回った場合に、口座にチャージ)。
この場合、これらのサービスについて支払者との間で契約を締結する必要があります。この目的において、ユーザーが支払者の支払詳細を保存し、支払者のアクティブな参加なく、保存した支払詳細を使用して後続の支払いを開始できるよう、支払者は同意する必要があります。
契約詳細
ユーザーが加盟店が開始する支払いを後で送信できる旨の契約を支払者との間で締結すると、一連の初回取引 (カード所有者が開始する取引) の中に以下の契約詳細を提供する必要があります。
agreement.id
:これは、支払者との支払契約を識別するために、ユーザーで生成された一意の値です。一連の支払いをリンク付けするため、後続の加盟店が開始する取引でそれを送信する必要があります。これは、カード所有者が開始する先行の取引を、加盟店が開始する後続の支払いにリンク付けするための識別子として契約 ID を使用するという、カードスキーム義務を遵守するために必要となるものです。agreement.type
:支払者との商業契約が締結されているかを示します。支払者との間で契約を締結した場合にのみ (カード所有者が開始する取引など)、入力する必要があります。
取引ソース
ユーザーが支払いを送信すると、一連の最初の取引 (カード所有者が開始する取引) と一連の加盟店が開始する後続の支払いとを区別します。これは、transaction.source
フィールドを使用して行うことができます。初回取引については、transaction.source
=INTERNET
または別の許可された値に設定することで、取引が支払者によって開始されたことを示す必要があります。一連の後続の支払いでは、transaction.source
=MERCHANT
に設定することで、取引がユーザーによって開始されたことを示す必要があります。Your payment service provider は加盟店アクワイアラーリンクで「MERCHANT」を許可可能取引ソースとして有効にしている必要があります。
カード所有者が開始する取引、または一連の加盟店が開始する後続の支払いをユーザーが送信すると、ユーザーはゲートウェイに対して、支払詳細が保存されている、保存されていない、保存する予定かを示す必要があります。詳細については、「よくある質問」を参照してください。
登録型決済
登録型決済とは、支払者がユーザーに対し、登録型決済または請求書の支払いを合意した間隔 (たとえば、週次や月次) で処理することを承認する契約です。
支払者が今後の使用に向けその支払詳細の保存に同意し、支払者のアクティブな参加なく後続の登録型決済の開始を承認する旨の支払契約が支払者との間で締結されている場合、ゲートウェイへの処理用に登録型決済を送信できます。
これをできるようにするには、一連の初回取引の以下のフィールドに情報を提供する必要があります。
sourceOfFunds.type
=CARD
またはSCHEME_TOKEN
sourceOfFunds.provided.card.*
フィールドまたはsourceOfFunds.token
transaction.source
=INTERNET, and
sourceOfFunds.provided.card.storedOnFile
=TO_BE_STORED
agreement.id
agreement.type
=RECURRING
ユーザーが開始した一連の後続の支払いについて、以下を提供する必要があります。
sourceOfFunds.type
=CARD
またはSCHEME_TOKEN
sourceOfFunds.provided.card.*
フィールドまたはsourceOfFunds.token
transaction.source
=MERCHANT
sourceOfFunds.provided.card.storedOnFile
=STORED, and
agreement.id
:初回取引で提供されたものと同じ agreement.id。これで一連の支払いをゲートウェイにリンク付けできるようになります。
支払者の認証
以下の表は、カード所有者が開始した支払いに 3DS 認証を処理するためのさまざまなシナリオまたは使用事例を示します。3DS 認証に関する詳細については、『3DS インテグレーションガイド』を参照してください。
外部認証取引については、『認証ガイドライン』を参照してください。
バージョン 61 のリクエストから WS API AUTHENTICATE_PAYER を使用する場合、以下のフィールドが登録型取引を成功させるために必要です。
- agreement.id
- agreement.type=RECURRING
- agreement.numberOfPayments
- agreement.amountVariability
- agreement.expiryDate
- agreement.paymentFrequency
- agreement.minimumDaysBetweenPayments
バージョン 57-60 のリクエストから WS API AUTHENTICATE_PAYER を使用する場合、以下のフィールドが登録型取引を成功させるために必要です。
- agreement.id
- agreement.type=RECURRING
- agreement.expiryDate
- agreement.recurring.daysBetweenPayments
使用事例 | インテグレーションの手順 |
---|---|
初期費用を含む支払者との登録型取引を確立し、新しい一連の登録型取引を開始します。 |
|
初回に支払いが発生しない場合に、一連の登録型決済を確立する サービスに申し込んだ時点では支払義務がない支払者との、一連の登録型決済を確立する場合。 例: お客様の契約時に支払いが不要な月額制のサービス。 |
『認証ガイドライン』を参照し、以下の手順で指定されたこれらの追加パラメータを使用して、登録型決済用の 3DS を統合します。 手順 1 と 2 は、カード所有者のセッション中に完了する必要があります。手順 3 は、支払処理の準備ができたときに使用する必要があります。
カード所有者のセッション中に、手順 1 と 2 を完了します。支払処理の準備ができたら、手順 3 を使用します。 手順 1:認証開始
手順 2:支払者の認証
手順 3:検証操作を実行し、以下のいずれかのオプションを選択します。
または
|
支払契約を成立させずにカードを追加する サインアップ時に支払契約を締結せずに、支払者がプロファイルやアカウントを作成する際にカードの詳細を追加できるオプションを提供したい場合。 追加されたカードは、将来的に使用することができます。 |
『認証ガイドライン』を参照し、以下の手順で指定されたこれらの追加パラメータを使用して、3DS を統合します。 手順 1:認証開始
手順 2:支払者の認証
|
加盟店が開始する分割払いの実行
分割払いとは、支払者が 1 回の購入の支払いについて、合意した間隔で複数回の支払いに分割して処理することを承認する契約です。たとえば、1 回の購入に対して、6 回の月次分割払いで支払う場合などです。
支払者が今後の使用に向けその支払詳細の保存に同意し、支払者のアクティブな参加なく後続の分割払いの開始を承認する旨の支払契約が支払者との間で締結されている場合、ゲートウェイへの処理用に分割払いを送信できます。
これをできるようにするには、一連の初回取引の以下のフィールドに情報を提供する必要があります。
sourceOfFunds.type
=CARD
またはSCHEME_TOKEN
sourceOfFunds.provided.card.*
フィールドまたはsourceOfFunds.token
transaction.source
=INTERNET
sourceOfFunds.provided.card.storedOnFile
=TO_BE_STORED
agreement.id, and
agreement.type
=INSTALLMENT
ユーザーが開始した一連の後続の分割払いについて、以下を提供する必要があります。
sourceOfFunds.type
=CARD
またはSCHEME_TOKEN
sourceOfFunds.provided.card.*
フィールドまたはsourceOfFunds.token
transaction.source
=MERCHANT
sourceOfFunds.provided.card.storedOnFile
=STORED
agreement.id
:初回取引で提供されたものと同じ agreement.id。これで一連の支払いをゲートウェイにリンク付けできるようになります。
加盟店が開始する臨時払いの実行
臨時払いとは、支払者が加盟店に対し、合意した購入の支払いについて、必要に応じて (臨時的に) 自動的に資金を控除してこれに充てることを承認する契約です。たとえば、口座残高がしきい値を下回った場合に、自動的にチャージします。
支払者が今後の使用に向けその支払詳細の保存に同意し、支払者のアクティブな参加なく後続の臨時払いの開始を承認する旨の支払契約が支払者との間で締結されている場合、ゲートウェイへの処理用に臨時払いを送信できます。
これをできるようにするには、一連の初回取引の以下のフィールドに情報を提供する必要があります。
sourceOfFunds.type
=CARD
またはSCHEME_TOKEN
sourceOfFunds.provided.card.*
フィールドまたはsourceOfFunds.token
transaction.source
=INTERNET
sourceOfFunds.provided.card.storedOnFile
=TO_BE_STORED
agreement.id, and
agreement.type
=UNSCHEDULED
ユーザーが開始した一連の後続の臨時払いについて、以下を提供する必要があります。
sourceOfFunds.type
=CARD
またはSCHEME_TOKEN
sourceOfFunds.provided.card.*
フィールドまたはsourceOfFunds.token
transaction.source
=MERCHANT
sourceOfFunds.provided.card.storedOnFile
=STORED, and
agreement.id
:初回取引で提供されたものと同じ agreement.id。これで一連の支払いをゲートウェイにリンク付けできるようになります。
よくある質問
支払詳細が保存されている、保存されていない、保存する予定かをゲートウェイに示すにはどうしたらよいですか。
カード所有者が開始する取引と加盟店が開始する取引を処理するカードスキーム標準に準拠するため、sourceOfFunds.provided.card.storedOnFile
フィールドを使用して、支払詳細が保存されている、保存されていない、保存する予定かをゲートウェイに示す必要があります。
初回取引 (カード所有者が開始する取引):
- 1 回限りの支払い (支払詳細を保存しない) の場合、
sourceOfFunds.provided.card.storedOnFile
フィールドを省略できます。 - 今後の使用に向けて支払詳細を保存する支払いの場合、
sourceOfFunds.provided.card.storedOnFile
=TO_BE_STORED
に設定します。これにより、ユーザーが支払者の支払詳細を保存することについて、支払者が合意したことをゲートウェイに示します。以下の値を設定する必要があります。
- 支払詳細をどこに保存したかにかかわらず、—ユーザー自身のアプリケーション (ユーザーが PCI 準拠であることが求められます)、ゲートウェイトークン化、またはカードスキームトークン。
- 支払詳細の保存が、ゲートウェイに取引を送信する前または後であるかは問いません。
後続の支払いについては、支払者の保存した支払詳細を使用したカード所有者が開始する取引、または保存した支払詳細を使用した加盟店が開始する取引のいずれかについて、sourceOfFunds.provided.card.storedOnFile
=STORED
に設定します。
ゲートウェイトークン化により、ゲートウェイがユーザーの代わりにデフォルト値を設定します。
- トークン化が有効ではない場合、ゲートウェイは
sourceOfFunds.provided.card.storedOnFile
=NOT_STORED
を設定します - カードの詳細をトークン化する際、ゲートウェイは
sourceOfFunds.provided.card.storedOnFile
を取引リクエストでユーザーが指定した値と同じに設定します。顧客が開始する取引でTO_BE_STORED
またはNOT_STORED
を指定することができます。 - ゲートウェイトークンを使用して後続の取引を実行する場合、ゲートウェイは
sourceOfFunds.provided.card.storedOnFile
=STORED
を設定します
Stored on File API リファレンス [REST][NVP]
契約 ID がない場合、どうすればよいですか。
支払者との契約で固有の識別子がない場合、以下を行うことができます。
- ゲートウェイのインタラクションを目的として、契約 ID を生成します。その後、契約 ID を保存して、すべての一連の支払い時 (カード所有者が開始する取引も含みます) に契約 ID をゲートウェイに送信する必要があります。
- 一連の最初の支払いに対して、(システムに既に保存されている) 既存の識別子、たとえば注文 ID を使用します。
支払契約の締結時に支払いを送金する必要がありますか。
支払者との間で支払契約を締結する時は、支払者に支払いを要求する訳ではありません。たとえば、雑誌の購読において、最初の支払いが 30 日以内に予定されている場合、契約の詳細と併せて Verify リクエストを送信する必要があります。
agreement.id
agreement.type
Verify 取引は、一連の処理の中で最初のカード所有者が開始する取引になります。後続の支払いについて、agreement.id
を使用して一連の支払いをリンク付けします。
支払者が 3DS 認証を使用して MPGS で認証されている場合、元の取引で使用された authentication.transactionId
を指定できます。
外部で認証された取引については、「認証 API を使用した 3DS インテグレーションの実装」ページを参照して、セクションオプション > 事前認証済みの支払リクエストの送信に移動します。
契約の PAN が変更した場合、どうすればよいですか。
契約に対する支払い詳細情報は、変更になる場合があります。たとえば、以下の場合です。
- 支払者がカードを紛失し、新しいカードが発行された場合
- 支払者が銀行を変更した場合
- カードには十分な資金がなく、支払者が別の支払詳細を提供した場合
カード詳細が変更した場合 (失効カードやカードスキームトークンの再発行の場合を除く)、同じ契約 ID を使用してカード所有者が開始する取引を実行する必要があります。これにより、新しいカード番号で加盟店が開始する取引を実行する前に、支払詳細やゲートウェイトークンが更新されます。ビジネスモデルに応じて、新しい契約の作成を選択することができます。
スキームトークンを使用している場合、スキームトークンに保存しているカード番号は自動的にスキームによって更新されます。