Migrating to Payment Intents with Automatic Confirmation / 自動確認による Payment Intents への移行

「決済」及び「開発」関連用語集

カテゴリー: documentation  閲覧数:421 配信日:2019-04-09 08:53


docs


Payments > PREPARING FOR SCA > Payment Intents API > Migration Guide > Automatic Confirmation
Migrating to Payment Intents with Automatic Confirmation
自動確認による Payment Intents への移行
・自動確認を使用して、既存のカードとCharges APIのシステムをPayment Intents APIへ移行する方法を学ぶ

従来の Charges API システムとの比較


Elementsを使用してカードでの支払いを受け付ける従来のトークンベースのStripeシステムには、通常次の手順が含まれる
・Elementsを使用してブラウザで顧客の支払い情報を集める
・Stripe.jsで支払い情報をトークン化する
・サーバーにトークンを送信するためのリクエストを実行する
・トークンを使用して、希望する金額と通貨でサーバーに請求を作成する
・支払いが成功したら、顧客の注文を履行する

比較すると、自動確認を使用したPayment Intents API システムには通常、次の手順が含まれる
・希望する金額と通貨でPaymentIntentを(あなたの)サーバー上に作成する
・PaymentIntentのクライアントシークレットをクライアントサイドに送信する
・Elementsを使用してブラウザで顧客の支払い情報を集める
・Stripe.jsまたはモバイルSDKを使用してダイナミック3Dセキュアを実行し、クライアント側で支払いを完了する
・支払いが成功した場合は、サーバーのWebフックを使用して顧客の注文を処理する 

移行のための戦略


あなたの支払いフローを移行するのは大変なことだ
・Payment Intents APIを徐々に採用し、Charges APIと並行して使用するのが安全だ
・そのために、移行を次の手順に分割することをお勧めする
・1.APIのバージョンとクライアントライブラリを更新する
・2.該当する場合は、Charges APIとPayment Intents APIによって作成された請求書の間に一貫した読み取りパスができるように、 請求書から読み取るコードを移行する
・3.Payment Intents APIを使用するために、 Web 、 iOS 、およびAndroid上の既存のCharges APIシステムを移行する
・4.「Customerオブジェクトにカードを保存するシステム」を移行する
・5.アップグレードされたシステムが3D Secure認証を処理することを確認するために、3D Secureテストカードでテスト

APIのバージョンとクライアントライブラリを更新する


Payment Intents APIはすべてのAPIバージョンで機能するが
・最新のAPIバージョンにアップグレードすることをお勧めする

2019-02-11よりも古いAPIバージョンを使用する場合
・コード例を見ながら次の2つの変更点に注意してくれ

requires_source
・require_payment_methodに改名された

requires_source_action
・require_actionに改名された

また、Stripe社のAPIライブラリの何れかを使用している場合
・Payment Intents APIを使用するために最新バージョンのライブラリにアップグレードしてくれ


Webシステムを移行する / Elements


Stripe.js&Elementsを使用して構築されたシステムは、以下のステップで構成されている
・1.サーバー側で支払いを回収するintentを登録する
・2.クライアント側で支払いの詳細を集める
・3.支払いの作成を開始する
・4.サーバー側で顧客の注文を処理する
ステップ 処理内容 BEFORE AFTER
1 サーバー側で支払いを回収するintentを登録する
顧客の支払いを処理するには、まずサーバー上にPaymentIntentを作成し、それをクライアント側からアクセスできるようにする
以前は不可能だった
Stripe::PaymentIntent.create({
 amount: 1099,
 currency: 'jpy',
})
2 クライアント側で支払い詳細を収集する
handleCardPayment関数を使用して、支払い情報を収集し、それをStripeへ直接送信する
const {token} =
 await stripe.createToken(
   cardElement
 );
const {paymentIntent, error} =
 await stripe.handleCardPayment(
   INTENT_SECRET_FROM_STEP_1,
   cardElement
 );
if (error) {
 // Display error.message in your UI.
} else {
 // The payment has succeeded
 // Display a success message
}
3 支払いの作成を開始する
既存のシステムでは、最後のステップはトークン化された支払い情報を使用してサーバーに課金を作成することだ。前の手順で呼び出されたhandleCardPayment関数によって課金の作成が開始されるため、これは不要になった
$charge = \Stripe\Charge::create([
   'source' => '{{FROM_PREVIOUS_STEP}}',
   'amount' => 1099,
   'currency' => 'jpy',
]);
前のステップで完了
4 サーバー側で顧客の注文を処理する
自動確認では、クライアント側での顧客の行動に基づいて料金が非同期で自動的に作成されるため、Webフックを監視して支払いが正常に完了した時期を判断する必要が必要がある。 顧客の支払いが成功した後で注文履行などの手順を実行するには、Webhookのサポートを実装し、payment_intent.succeededイベントを監視する
課金が成功したら、履行してくれ payment_intent.succeeded Webhookイベントを監視し、Webhookハンドラーを実行する

Webシステムを移行する / 支払いリクエストボタン


Stripe.js paymentRequest API
・従来のPaymentRequestシステムで取得されたトークンを使用してそれをPaymentIntentに添付することによって、Payment Intents APIと連携する

PaymentRequestを使用して構築されたシステムは、以下のステップで構成されている
・サーバー側で支払いを回収するintentを登録する
・クライアント側で支払いの詳細を集める
・支払いの作成を開始
・サーバー側で顧客の注文を処理する
ステップ 処理内容 BEFORE AFTER
1 サーバー側で支払いを回収するintentを登録する
顧客の支払いを処理するには、まずサーバーにPaymentIntentを作成し、それをクライアント側からアクセスできるようにする必要がある
Not possible before
Stripe::PaymentIntent.create({
 amount: 1099,
 currency: 'jpy',
})
2 クライアント側で支払い詳細を収集する
PaymentRequestオブジェクトのtokenイベントをリッスンする。これは、支払いプロセスがいつ完了したかを示すために使用できるトークンとコールバック関数を提供する。
このシステムをPayment Intents APIをサポートするように調整するには、サーバーにトークンを送信するのではなく、handleCardPayment関数を使用してトークンIDを渡す。 handleCardPayment関数によって返されたpromiseが解決したら、完了コールバックを呼び出す
paymentRequest.on(
 'token',
 ({token, complete}) => {
   // Send the token to the server
   // Invoke the callback when done
   complete(success);
});
paymentRequest.on(
 'paymentmethod',
 ({paymentMethod, complete}) => {
   // First, confirm the PaymentIntent to
   // see if there are any payment errors.
   const {error: confirmError} =
     await stripe.confirmPaymentIntent(
       INTENT_SECRET_FROM_STEP_1
     );

   if (confirmError) {
     // Complete with 'fail' and show error:
     complete('fail');
   } else {
     // Otherwise, close the Payment Request
     // modal and call handleCardPayment
     // to complete any potential actions
     // required.
     complete('success');
     const {error, paymentIntent} =
       await stripe.handleCardPayment(
         INTENT_SECRET_FROM_STEP_1,
       );

     // Handle payment error, if any.
   }
 }
);
3 支払いの作成を開始する
既存のシステムでは、最後のステップはトークン化された支払い情報を使用してサーバーに課金を作成することだ。前の手順で呼び出されたhandleCardPayment関数によって課金の作成が開始されるため、これは不要になった
$charge = \Stripe\Charge::create([
   'source' => '{{FROM_PREVIOUS_STEP}}',
   'amount' => 1099,
   'currency' => 'jpy',
]);
前のステップで完了
4 顧客の注文を処理する
自動確認では、クライアント側での顧客の行動に基づいて料金が非同期で自動的に作成されるため、Webフックを監視して支払いが正常に完了した時期を判断する必要がある。 顧客の支払いが成功した後で注文履行などの手順を実行するには、Webhookのサポートを実装し、payment_intent.succeededイベントを監視する
課金が成功したら、履行してくれ payment_intent.succeeded Webhookイベントを監視し、Webhookハンドラーを実行する

Webシステムを移行する /  Legacy Checkout


従来のバージョンのCheckoutを使用している場合
・新しいCheckoutへアップグレードする
・これは、Stripeで支払いを受け取る最も早い方法だ
・それを使うと、あなたは一度限りの支払いと購読を受け入れることができる
・サーバーでStripe APIを使用せずにCheckoutを使用することもできる
Checkoutの移行ガイドに従って、既存の統合を移行する

代わりに独自のチェックアウトフローを作成したい場合
・Elementsに切り替えてくれ

Elementsにアップグレードしたと仮定すると
・(上記の)Elements移行ガイドを使用してPayment Intents API統合を構築できる

「顧客オブジェクトにカードを保存するシステム」の移行


ヨーロッパに拠点を置き、強力な顧客認証の準備をしている場合、7月1日以降では
・次回のオフセッション支払いのためにカードを保存するとき、認証を実行して、オフセッション免除の資格を得る必要がある
・このAPIは7月1日までに利用可能になるだろう

チェックアウトフローでカードを保存する


チェックアウトフローでカード情報を収集するPayment Intents APIシステムは、次の手順で構成されている
・1.サーバー側で支払いを回収する intentを登録する
・2.クライアント側で支払い詳細を収集する
・3.支払いの作成を開始する
・4.サーバー側で顧客の注文を処理する
ステップ 処理内容 BEFORE AFTER
1 サーバー側で支払いを回収するintentを登録する
顧客の支払いを処理するには、まずサーバー上にPaymentIntentを作成し、支払い方法を保存する顧客のIDを設定する。 次に、PaymentIntentをクライアント側でアクセス可能にする
以前は不可能だった
Stripe::PaymentIntent.create({
 'customer' => '{{CUSTOMER_ID}}',
 amount: 1099,
 currency: 'jpy',
})
2 クライアント側で支払い詳細を収集する
「支払い情報を収集してStripeへ直接送信するhandleCardPayment関数」と「提供された支払い方法を顧客に添付するsave_payment_method」を使用する
const {token} =
 await stripe.createToken(
   cardElement
 );
const {paymentIntent, error} =
 await stripe.handleCardPayment(
   '{{INTENT_SECRET_FROM_STEP_1}}',
   cardElement,
   {save_payment_method: true},
 );
2 クライアント側で支払い詳細を収集する
既存のシステムでは、支払方法を顧客に添付するには別の手順が必要だ。 handleCardPayment関数が提供された支払い方法を顧客に添付するので、これはもう必要ない
$card = \Stripe\Customer::createSource(
 '{{CUSTOMER_ID}}',
 [
   'source' => '{{TOKEN_OR_SOURCE}}',
 ]
);
handleCardPayment関数で完了した
3 支払いの作成を開始する
既存のシステムでは、最後のステップはトークン化された支払い情報を使用してサーバーに請求を作成することだ。前の手順で呼び出されたhandleCardPayment関数が請求の作成を開始するため、これは不要になった
$charge = \Stripe\Charge::create([
   'source' => '{{FROM_PREVIOUS_STEP}}',
   'customer' => '{{CUSTOMER_ID}}',
   'amount' => 1099,
   'currency' => 'jpy',
]);
前のステップで完了
4 サーバー側で顧客の注文を処理する
自動確認では、クライアント側での顧客の行動に基づいて料金が非同期で自動的に作成されるため、Webフックを監視して支払いが正常に完了した時期を判断する必要が必要がある。 顧客の支払いが成功した後で注文履行などの手順を実行するには、Webhookのサポートを実装し、payment_intent.succeededイベントを監視する
課金が成功したら、履行してくれ payment_intent.succeeded Webhookイベントを監視し、Webhookハンドラーを実行する

チェックアウトフロー外でのカードの保存


チェックアウトフローの外でカードを保存する場合
・既存のシステムとPayment Methods APIのシステムとの間には2つの違いがある

クライアント側
・createTokenまたはcreateSourceの代わりにcreatePaymentMethod関数を使用してくれ

BEFORE
const {token} =
 await stripe.createToken(
 // or stripe.createSource
   cardElement
 );

AFTER
const {paymentMethod} =
 await stripe.createPaymentMethod(
   'card',
   cardElement
 );


サーバー側
・Customers APIの代わりにPayment Methods APIを使用して、Customerオブジェクトに支払い方法を添付する

BEFORE
$card = \Stripe\Customer::createSource(
 '{{CUSTOMER_ID}}',
 [
   'source' => '{{TOKEN_FROM_STEP_1}}',
 ]
);

AFTER
$payment_method = \Stripe\PaymentMethod::retrieve('{{PAYMENT_METHOD_ID}}'))
$payment_method->attach(['customer' => '{{CUSTOMER_ID}}']);


保存したカードで支払う


顧客がチェックアウトフローで支払う「保存済みの支払方法を選択できるようにするシステム」は、次の手順で構成されている
・1.サーバー側で支払いを回収する intentを登録する
・2.クライアント側で顧客の保存した支払い方法から支払い詳細を収集する
・3.支払いの作成を開始する
・4.サーバー側で顧客の注文を処理する
ステップ 処理内容 BEFORE AFTER
1 サーバー側で支払いを回収するintentを登録する
以前に保存した支払い方法で支払いをするときは、CustomerオブジェクトのIDでPaymentIntentを作成する
以前は不可能だった
Stripe::PaymentIntent.create({
 'customer' => '{{CUSTOMER_ID}}',
 amount: 1099,
 currency: 'jpy',
})
2 クライアント側で顧客の保存した支払い方法から支払い詳細を収集する
handleCardPayment関数を使用して、支払い情報を収集し、それをStripeへ直接送信する
顧客の選択した保存済みソースIDをサーバーに送信してくれ
const {paymentIntent, error} =
 await stripe.handleCardPayment(
   INTENT_SECRET_FROM_STEP_1,
   {payment_method: PAYMENT_METHOD_ID}
   // An existing Card or Source ID
   // can also be used
 );
if (error) {
 // Display error.message in your UI.
} else {
 // The payment has succeeded
 // Display a success message
}
3 支払いの作成を開始する
既存のシステムでは、最後のステップはトークン化された支払い情報を使用してサーバーに請求を作成することだ。前の手順で呼び出されたhandleCardPayment関数が請求の作成を開始するため、これは不要になった
$charge = \Stripe\Charge::create([
   'source' => '{{FROM_PREVIOUS_STEP}}',
   'customer' => '{{CUSTOMER_ID}}',
   'amount' => 1099,
   'currency' => 'jpy',
]);
前のステップで完了
4 サーバー側で顧客の注文を処理する
自動確認では、クライアント側での顧客の行動に基づいて料金が非同期で自動的に作成されるため、Webフックを監視して支払いが正常に完了した時期を判断する必要が必要がある。 顧客の支払いが成功した後で注文履行などの手順を実行するには、Webhookのサポートを実装し、payment_intent.succeededイベントを監視する
課金が成功したら、履行してくれ payment_intent.succeeded Webhookイベントを監視し、Webhookハンドラーを実行する

保存した支払い方法にアクセスする


顧客の以前に保存されたCards、Sources、およびPaymentMethodsを表示するには
・customerオブジェクトのsourcesプロパティを読み取る代わりに支払い方法を一覧表示する
・顧客に追加された新しいPaymentMethodsが顧客オブジェクトのsourcesプロパティに重複しないため、これが必要だ

BEFORE
customer->sources

AFTER
\Stripe\PaymentMethod::all(['customer' => '{{CUSTOMER_ID}}', 'type' => 'card']);


週間人気ページランキング / 10-11 → 10-17
順位 ページタイトル抜粋 アクセス数
1 Twitch | ゲーム実況配信サービス(課金販売できるプラットフォーム) 5
2 EMVレベル1 / EMVレベル2 / EMVCo とは? 4
3 pixivFANBOX | クリエイター支援プラットフォーム(課金販売できるプラットフォーム) 3
4 Stripe Q1。Stripeにおける個人事業主の定義 | QA(Stripe) 2
4 普通送金とは? / 処理の流れ 2
4 Stripe Q74.「お客様のビジネスの詳細」とは何ですか? | Stripe 2
5 Stripe Q65.Connect Standard で連結されているStripeアカウントの違いについて | QA(Stripe) 1
5 Stripe Payments > SOURCES / ソース | documentation(Stripe) 1
5 クリエイター支援プラットフォーム(課金販売できるプラットフォーム) カテゴリー 1
5 クリエイター支援プラットフォーム | 課金販売できるプラットフォーム 1
5 Stripeで"No such token: src"と表示されたら、最初にAPIキーを確認する | Stripe エラー(Stripe) 1
5 Stripeのアカウントへログインできなくなった場合の手続きには要注意。新しいアカウントでログインできるようになるまで約 2 か月かかった例も | Stripe 1
5 「払い戻し」と「チャージバック」の違い | 違い 1
5 振込 | 送金 1
5 Saving Payment Methods / 支払い方法を保存する 1
5 Stripe Q18。PHP使用する場合、オブジェクト形式で配列形式でもアクセスできる | QA(Stripe) 1
5 Stripe Q16。PaymentIntentの支払いで郵便番号入力を求められる。Radar rules の ZIP code を無効にしているのに | QA(Stripe) 1
5 PCI DSS  | セキュリティ 1
5 SHOWROOM | ライブ配信サービス(課金販売できるプラットフォーム) 1
5 Stripe Q71.CheckoutSessionで、success_urlに指定したURLでzipダウンロードすると、success_urlへ遷移しない | QA(Stripe) 1
2024/10/18 1:01 更新
指定期間人気ページランキング / 2020-5-28 → 2024-10-17
順位 ページタイトル抜粋 アクセス数
1 Stripeアカウントへログインする際、モバイル端末で受信したコード入力を求められる理由は? | その他エントリー(Stripe) 2019
2 EMVCo | クレジットカード仕様(仕様) 1320
3 Stripe Q13。決済成功時に、「請求に紐づけられたメールアドレス」に対して、メール送信したいのですが、 | QA(Stripe) 969
4 Twitch | ゲーム実況配信サービス(課金販売できるプラットフォーム) 927
5 Stripe Q16。PaymentIntentの支払いで郵便番号入力を求められる。Radar rules の ZIP code を無効にしているのに | QA(Stripe) 924
6 クレジットカード決済 | 課金 909
7 決済用語 876
8 Stripe Q50。 Connect 「Standardアカウント」で、自身に連結された子アカウントを、ダッシュボードから削除するには? | QA(Stripe) 844
9 Stripe Q1。Stripeにおける個人事業主の定義 | QA(Stripe) 798
10 EMVレベル1 / EMVレベル2 / EMVCo とは? 797
11 pixivFANBOX | クリエイター支援プラットフォーム(課金販売できるプラットフォーム) 786
12 Omise | 「支払」機能を有する決済系サービス(決済サービス) 784
13 Stripe Q31。ダッシュボードでの「支払い作成」の見方について | QA(Stripe) 746
14 YouTube | 動画サービス(課金販売できるプラットフォーム) 718
15 プリペイドカード | カード 648
16 EPUB | ファイルフォーマット(電子書籍) 613
17 Stripe Q74.「お客様のビジネスの詳細」とは何ですか? | Stripe 586
18 Stripeで"No such token: src"と表示されたら、最初にAPIキーを確認する | Stripe エラー(Stripe) 573
19 サブスクリプション | 課金 565
20 Stripe エラー(Stripe) カテゴリー 486
2024/10/18 1:01 更新