Apple Pay で継続支払いを管理する
Apple Pay 継続取引のオーソリ成功率を向上します。
Checkout と Elements のベストプラクティス
Checkout と Elements は、このガイドで推奨するベストプラクティスを自動的に適用します。
Apple Pay の継続支払いの仕組み
一部のビジネスでは継続支払いを行うために、ユーザーがオンセッションのときに、登録されている Apple Pay の支払い方法を保存して、後からオフセッションになったときに継続支払いを行う必要があります。通常、初回のオンセッションの支払いは顧客が開始した取引 (CIT) と呼ばれ、その後の継続支払いは加盟店が開始した取引 (MIT) と呼ばれます。継続支払い (MIT) の 2 つの例は以下のとおりです。
- ユーザーが固定の頻度で請求を受けるサブスクリプション。
- 請求の頻度が一定ではない、または顧客が頻度を変えられる、継続するオフセッションの支払い。
ユーザーが Apple Pay の支払い画面を操作すると、PAN (元のカード番号) を非公開で保つために、Apple Pay はカードの PAN を処理して、デバイスの OS のバージョンと連携状態に応じて、デバイスのプライマリーアカウント番号 (DPAN) または加盟店トークン (MPAN) を生成します。DPAN は特定の Apple デバイスに関連付けられているため、ユーザーが新しいデバイス (iPhone や iPad など) に切り替えて、同じカードを追加すると、意図せず無効になることがあります。一方、MPAN は、継続支払いのために新たに導入された、より信頼性の高いオプションです。MPAN は、ユーザーがデバイスを切り替えても無効にならず、より明確な可視性とライフサイクル管理機能を提供します。
これ以外の点では、MPAN と DPAN の動作は同じです。
有効期限切れの暗号によってオーソリの失敗が発生する可能性
DPAN (または MPAN) が生成されると、有効期限切れ間近の 1 回限りの使用の暗号も生成されます。Stripe は、暗号の有効期限が切れる前に、できるだけ早く CIT を実行して、DPAN (または MPAN) と暗号の両方を認証ネットワークに送信する必要があります。この有効期限メカニズムにより、Apple Pay ウォレットのセキュリティが強化されますが、CIT を時間内にトリガーできないことが、認証エラーの根本的な原因となることがよくあります。
暗号化を適用する最初の CIT が失敗すると、同じカードを使用する後続の MIT も CIT に内部で関連付けられているため、失敗する可能性があります。このような継続支払いの失敗は、オーソリ成功率の低下につながります。
構築済み API のオーソリを向上させる
API を使用して継続的な Apple Pay 取引を実装するには、以下のようにします。
- DPAN (または MPAN) と暗号を
Card
に保存します。 - 有効期限が切れる前に暗号を使用するために CIT を開始します。0 ドルの検証または支払い取引をオーソリネットワークに送信し、返されたネットワーク取引の記録を保管します。
- 今後のオフセッションの MIT に支払い方法を再利用します。Stripe は、オーソリ成功率を高めるために、元の CIT の DPAN (または MPAN) とネットワーク取引 ID をオーソリネットワークに送信します。
次の推奨事項を基に、作成後すぐに暗号化を適用します。
無料トライアルにサブスクリプションを使用する
顧客が無料トライアルに登録すると、無料トライアル期間が終了するまで請求は行われません。有効期限が切れる前に DPAN (または MPAN) 暗号を使用するには、Stripe の Subscription を使用します。Subscription は、オーソリネットワークで 0 USD の検証を生成する SetupIntent を作成します。これは CIT として機能し、無料トライアルが終了するまで最初の取引を遅らせるのではなく (その時点で暗号の有効期限が切れているため)、暗号を即時に使用します。
また、SetupIntent を作成して、将来の使用に備えて Apple Pay PaymentMethod を直接保存することもできます。SetupIntent の確定によって、同じ CIT の 0 USD の検証が開始され、暗号が使用されます。その後、オーソリ済みの Apple Pay PaymentMethod を使用して、後で Subscription を作成できます。
トークン API 連携の SetupIntent を作成するLegacy
Apple Pay の継続支払いにレガシーの Tokens API と Charges API を使用することはお勧めしません。このドキュメントに記載しているように、暗号の有効期限切れによるオーソリエラーが発生します。Tokens API は、暗号を使用する時間内にオーソリリクエストをトリガーしません。また、Charges API は、クレジットカードの法令遵守に必要な以下の大部分の機能をサポートしていません。
- インドの加盟店
- カード認証に関する銀行のリクエスト
- 強力な顧客認証 (SCA)
これらの理由から、PaymentIntents API と SetupIntents API への移行をお勧めします。
従来の Token を使用して Apple Pay ペイメントトークンを作成してから Charge (支払い) を呼び出してトライアルの終了時にユーザーに請求している場合、以下の手順でオーソリ率を引き上げることができます。
- トークンを作成した直後に支払い方法を作成する。
- 新しい PaymentMethod を使用してすぐに SetupIntent を作成し、0 USD の検証取引を実行します。
これらの 2 つのステップを完了すると、CIT が実行され、有効期限が切れる前に暗号がネットワークに送信されます。Stripe.js を使用している場合には、stripe.confirmCardSetup with token を呼び出すと、これらのステップを組み合わせることができます。
これで、保存された Apple Pay の支払い方法を使用してオフセッションの MIT 支払いを実行できるようになります。PaymentIntent を使用している場合は、off_session=true を設定することで、買い手が支払いの手続き中でないことを表示できるようになります。
オフセッションの支払いを設定する
遅延型のオフセッションの Apple Pay 支払いを設定していて、ホテルの予約など、将来のオフセッションの使用に備えて支払い情報を収集することを目的としている場合は、Apple Pay のサポート対象の支払いタイプのリストをご覧ください。
Apple Pay は、顧客が決済フローに進んでいない場合、DPAN (または MPAN) を使用したusage=off_session の支払いに対応します。ただし、この場合、ネットワークからライアビリティシフトを受けず、平均よりもオーソリ率が下がる可能性があるため、リスクが若干高くなります。
Apple Payの規約は、usage=on_session の支払いに保存された支払い方法を使用することを禁止しています。顧客がフロー内にいる場合は、その取引の新しい暗号を承認および生成してもらう必要があります。
Apple Pay は、オーソリされた支払い額を増やしてからキャプチャーした場合にのみ、増分オーソリをサポートします。
Tokens API 連携の CIT は、以下のいずれかの方法で開始できます。
- 無料トライアルのシナリオで説明されているとおり、SetupIntent を作成して 0 USDの検証を開始し、オフセッション支払いの支払い方法に基づく再利用可能な DPAN (または MPAN) を作成します。
- setup_future_usage=off_session を使用して PaymentIntent を作成します。
これで、保存された支払い方法を使用してオフセッションの MIT 支払いを実行できるようになります。PaymentIntent を使用している場合は、off_session=true を設定することで、買い手が支払いの手続き中でないことを表示できるようになります。