支払い中に支払いの詳細を保存する
支払い中に支払いの詳細を保存する方法は次のとおりです。
Payment Intents API を使用して、購入から支払い詳細を保存します。以下のようなユースケースがあります。
- 顧客に EC ストアの注文の請求を行い、以降の購入に備えて情報を保存します。
- 継続支払いの初回の支払いを開始します。
- 頭金を請求し、情報を保存して後から全額を請求できるようにします。
Card-present transactions
Card-present transactions, such as payments through Stripe Terminal, use a different process for saving the payment method. For details, see the Terminal documentation.
法令遵守
顧客の支払いの詳細を保存する際、適用されるすべての法律、規制、ネットワークの規則に準拠する責任はお客様にあります。これらの要件は通常、以降の購入時の決済フローでの顧客の支払い方法を提示する、顧客がお客様のウェブサイトやアプリを使用していないときに請求するなど、将来に備えて顧客の支払い方法を保存する場合に適用されます。支払い方法の保存をどのように計画しているかを示す規約をウェブサイトやアプリに追加し、顧客が許可できるようにします。
支払い方法を保存する場合、規約に記載された特定の用途にのみ使用できます。顧客がオフラインであるときに支払い方法に請求して、以降の購入に備えたオプションとして保存する場合は、この特定の用途について顧客から明示的に同意を収集する必要があります。たとえば、同意を収集するために「今後の使用に備えて支払い方法を保存する」チェックボックスを使用します。
顧客がオフラインのときに請求するには、規約に以下の内容を含める必要があります。
- 指定された取引で顧客の代理として単独の支払いまたは一連の支払いを開始することをお客様に許可するという、顧客からお客様への同意
- 予期される支払い時期と支払い頻度 (たとえば、請求が予定されている分割払いなのか、サブスクリプションの決済なのか、あるいは予定されていないトップアップなのか)。
- 支払い金額の決定方法
- 支払い方法をサブスクリプションサービスに使用する場合は、キャンセルに関するポリシー
これらの規約に関する顧客の書面による同意の記録を必ず保管してください。
Customer の作成サーバ側
将来の支払いに備えてカードを設定するには、カードを Customer (顧客) に関連付ける必要があります。顧客がビジネスでアカウントを作成する際に、Customer オブジェクトを作成します。Customer オブジェクトを使用すると、支払い方法を再利用したり、複数の支払いを追跡したりできます。
作成に成功すると、Customer オブジェクトが返されます。オブジェクトで顧客の id
を調べて、その値を後で取得できるようにデータベースに保存できます。
これらの顧客は、ダッシュボードの顧客ページで見つけることができます。
支払い方法を有効にする
支払い方法の設定を表示して、サポートする支払い方法を有効にします。PaymentIntent を作成するには、少なくとも 1 つは支払い方法を有効にする必要があります。
By default, Stripe enables cards and other prevalent payment methods that can help you reach more customers, but we recommend turning on additional payment methods that are relevant for your business and customers. See Payment method support for product and payment method support, and our pricing page for fees.
PaymentIntent を作成するサーバ側
注
最初に PaymentIntent を作成せずに Payment Element をレンダリングする場合は、インテントを作成する前に支払いの詳細を収集するをご覧ください。
PaymentIntent (支払いインテント) オブジェクトは、顧客から支払いを回収する意図を示し、支払いプロセス全体を通して請求の実施と状態の変化を追跡します。
PaymentIntent を作成する
サーバーで PaymentIntent を作成します。amount、currency、customerを指定します。最新バージョンの API では、automatic_
パラメーターの指定は必須ではありません。この機能はデフォルトで有効になっています。setup_future_usage を有効にします。ダッシュボードで設定した決済手段は、Payment Intent に自動的に追加されます。
ダッシュボードを使用しない場合、または決済手段を手動で指定する場合は、payment_
属性 を使用して決済手段を一覧表示することができます。
注
支払い額は常に、クライアント側ではなく、信頼性の高い環境であるサーバー側で決定してください。このようにすることで、悪意のある顧客が価格を操作できないようにすることができます。
client secret を取得する
PaymentIntent には、client secret が含まれています。これは、支払いプロセスを安全に完了するためにクライアント側で使用されます。client secret をクライアント側に渡す際は、いくつかの方法を使用できます。
支払いの詳細を収集するクライアント側
Payment Element を使用してクライアント側で支払い詳細を収集します。Payment Element は事前構築された UI コンポーネントであり、さまざまな決済手段の詳細の収集をシンプルにします。
Payment Element には、HTTPS 接続を介して支払い情報を Stripe に安全に送信する iframe が含まれています。一部の支払い方法では、支払いを確定するために別のページにリダイレクトする必要があるため、Payment Element を別の iframe 内に配置しないでください。
iframe の使用を選択し、Apple Pay または Google Pay を受け付ける場合、iframe の allow 属性が "payment *"
に設定されている必要があります。
構築済みのシステムを機能させるには、決済ページのアドレスの先頭を https://
ではなく https://
にする必要があります。HTTPS を使用しなくてもシステムをテストできますが、本番環境で決済を受け付ける準備が整ったら、必ず、HTTPS を有効にしてください。
Payment Element によって動的なフォームが表示され、顧客はここで支払い方法を選択できます。支払い方法ごとに、フォームでは、必要な支払いの詳細のすべてを入力するように顧客に自動的に求めます。
デザインをカスタマイズする
Elements
プロバイダーを作成する際に、Appearance (デザイン) オブジェクトを options
に渡すことで、サイトのデザインに合わせて Payment Element をカスタマイズできます。
住所を収集
デフォルトでは、Payment Element は必要な請求先住所情報のみを収集します。(たとえば、デジタル商品およびサービスの税金を計算するなどの目的で) 顧客の詳細な請求先住所または配送先住所を収集するには、Address Element を使用します。
Apple Pay マーチャントトークンをリクエストする
Apple Pay の決済を受け付けるよう自社のシステムを構築している場合、マーチャントトークンを返すように Apple Pay インターフェイスを設定して、加盟店が開始する取引 (MIT) を有効にすることをお勧めします。Payment Element で関連するマーチャントトークンのタイプをリクエストします。
Stripe に支払いを送信するクライアント側
Payment Element からの詳細を指定して stripe.confirmPayment を使用し、支払いを完了します。ユーザーが支払いを完了した後に Stripe がユーザーをリダイレクトする場所を指定するには、この関数に return_url を指定します。ユーザーはまず、銀行のオーソリページなどの中間サイトにリダイレクトされ、その後 return_
にリダイレクトされます。カード支払いでは、支払いが正常に完了するとすぐに return_
にリダイレクトします。
カード決済で支払いの完了後にリダイレクトを行わない場合は、redirect に if_
を設定できます。これで、リダイレクトベースの決済手段で購入する顧客のみがリダイレクトされます。
注
stripe.
の完了には数秒かかる場合があります。この間、フォームを再送信することがないように無効化し、スピナーのような待機中の印を表示します。エラーが発生した場合は、それを顧客に表示し、フォームを再度有効化し、待機中の印を非表示にします。支払いを完了するために顧客による認証などの追加の手順が必要な場合は、Stripe.js がそのプロセスをステップごとに顧客に提示します。
支払いが成功した場合、カードは Customer オブジェクトに保存されます。この内容は、PaymentMethod の customer フィールドに反映されます。この時点で、Customer オブジェクトの ID を独自の内部的な顧客の表記 (設定している場合) に関連付けます。これにより、今後は顧客に再度支払いの詳細を求めずに、保存した PaymentMethod オブジェクトを使用して顧客から支払いを回収できます。
return_
が、Web サイト上の支払いステータスを表示するページと対応していることを確認します。Stripe が顧客を return_
にリダイレクトするときは、以下の URL クエリーパラメーターが指定されます。
パラメーター | 説明 |
---|---|
payment_ | PaymentIntent の一意の識別子。 |
payment_ | PaymentIntent オブジェクトの client secret。 |
注意
顧客のブラウザーセッションを追跡するツールを利用している場合、リファラー除外リストに stripe.
ドメインの追加が必要になる場合があります。リダイレクトを行うと、一部のツールでは新しいセッションが作成され、セッション全体の追跡ができなくなります。
クエリパラメーターのいずれか 1 つを使用して PaymentIntent を取得します。PaymentIntent のステータスを調べて、顧客に表示する内容を決定します。また、return_
を指定するときにカスタムのクエリパラメーターを追加することもできます。このパラメーターはリダイレクトプロセスの間維持されます。
保存された支払い方法に後で請求するサーバ側
警告
bancontact
、ideal
、sofort
は、デフォルトでは 1 回限りの支払い方法です。将来も使用できるように設定すると、再利用可能な支払い方法タイプ sepa_
が生成されます。このため、保存された支払い方法をクエリーで照会するには sepa_
を使用する必要があります。
法令遵守
顧客の支払いの詳細を保存する際、お客様は適用されるすべての法律、規制、ネットワークの規則に準拠する責任があります。将来の購入に備えて顧客に過去の決済手段を提供する際は、必ず、特定の将来の使用に備えて決済手段の詳細を保存することについての同意を顧客から収集した決済手段をリストアップします。顧客に関連付けられた決済手段のうち、将来の購入用の保存済みの決済手段として顧客に提示できるものと提示できないものを区別するには、allow_redisplay パラメーターを使用します。
購入者にオフセッションで請求する準備ができたら、Customer ID と PaymentMethod ID を使用して、PaymentIntent を作成します。請求する決済手段を見つけるには、顧客に関連付けられた決済手段を一覧表示します。この例ではカードが一覧表示されますが、サポートされているすべてのタイプを一覧表示できます。
Customer ID と PaymentMethod ID を取得したら、支払いの金額と通貨を使用して PaymentIntent を作成します。その他のいくつかのパラメーターを設定して、オフセッションの支払いを行います。
- off_session を
true
に設定して、支払いの試行時に購入者が決済フローを実行中でないことと、カード発行会社、銀行、その他の決済機関などのパートナーからの認証リクエストに対応できないことを示します。決済フローの実行時にパートナーが認証をリクエストした場合、Stripe は前回のオンセッション取引の顧客情報を使用して免除をリクエストします。免除の条件を満していない場合は PaymentIntent からエラーが返されることがあります。 - PaymentIntent の confirm プロパティの値を
true
に設定します。これにより、PaymentIntent が作成されると直ちに確定されます。 - payment_method を PaymentMethod の ID に設定し、customer を Customer の ID に設定します。
組み込みをテストする
テスト用の支払いの詳細とテスト用リダイレクトページを使用して、組み込みを確認できます。以下のタブをクリックすると、各支払い方法の詳細を表示できます。
保存された SEPA デビット PaymentMethod への請求をテストする
iDEAL、Bancontact または Sofort を使用して PaymentIntent が確定されると、SEPA ダイレクトデビット の PaymentMethod が生成されます。SEPA ダイレクトデビットは、通知遅延型の決済手段であり、中間の processing
状態に移行してから、数日後に succeeded
または requires_
の状態に移行します。