iDEAL | Wero の決済中に銀行口座の詳細を保存する
iDEAL | Wero での決済から顧客の IBAN 銀行口座の詳細を保存する方法をご紹介します。
注意
支払い中に支払いの詳細を保存するためのガイドに従うことをお勧めします。すでに Elements との連携が完了している場合は、Payment Element 移行ガイドをご覧ください。
iDEAL | Wero (旧 iDEAL) はオランダで普及している 1 回限りの 決済手段であり、顧客は決済の 認証 を求められます。顧客は iDEAL | Wero で決済します。WebView にリダイレクトされ、決済をオーソリすると、アプリに戻されます。そこで、決済が成功したか失敗したかに関する即時の通知が届きます。
iDEAL | Wero を使用して、顧客の IBAN 銀行口座の詳細を SEPA ダイレクトデビットPaymentMethod に保存することもできます。その後、SEPA ダイレクトデビット PaymentMethod を使用して決済を受け付けるか、サブスクリプションを設定できます。これにより、顧客は IBAN を再度入力する必要がなくなるため、手間が軽減されます。また、検証済みの名前と検証済みの IBAN も届きます。
注意
iDEAL | Wero を使用して SEPA ダイレクトデビット決済を設定するには、ダッシュボードで SEPA ダイレクトデビットを有効にする必要があります。また、iDEAL 利用規約と SEPA ダイレクトデビット利用規約に準拠する必要があります。
iDEAL | Wero での決済の受け付けは、決済を追跡するための PaymentIntent オブジェクトの作成、決済手段の詳細と同意書の承認の収集、および決済を処理するための Stripe への送信で構成されます。Stripe は PaymentIntent を使用して、決済が完了するまでの決済の状態をすべてトラックおよび処理します。最初の iDEAL | Wero PaymentIntent から収集された SEPA ダイレクトデビット PaymentMethod の ID を使用して、以降の決済を作成します。
Customer を作成するサーバー側
お客様のビジネスで顧客がアカウントを作成する際に、Customer を作成し、それを、そのアカウントを表す独自の内部表記と関連付けます。このようにすると、保存されている支払い方法の詳細を後で取得して使用することができます。
PaymentIntent を作成するサーバー側
サーバーで PaymentIntent を作成し、徴収する金額、eur 通貨、顧客 ID、および今後の使用設定の引数として off_ を指定します。最小決済金額はなく、iDEAL | Wero は他の通貨に対応しません。既存の Payment Intents API の組み込みがある場合は、決済手段タイプのリストに ideal を追加してください。
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 *" と等しく設定する必要があります。
構築済みのシステムを機能させるには、決済ページのアドレスの先頭を http:// ではなく https:// にする必要があります。HTTPS を使用しなくてもシステムをテストできますが、本番環境で決済を受け付ける準備が整ったら、必ず、HTTPS を有効にしてください。
Stripe に支払いを送信するクライアント側
Payment Element からの詳細を指定して stripe.confirmPayment を使用し、支払いを完了します。ユーザーが支払いを完了した後に Stripe がユーザーをリダイレクトする場所を指定するには、この関数に return_url を指定します。ユーザーはまず、銀行のオーソリページなどの中間サイトにリダイレクトされ、その後 return_ にリダイレクトされます。カード支払いでは、支払いが正常に完了するとすぐに return_ にリダイレクトします。
メモ
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_ を指定するときにカスタムのクエリパラメーターを追加することもできます。このパラメーターはリダイレクトプロセスの間維持されます。
後日 SEPA ダイレクトデビット PaymentMethod に請求する
顧客に再度請求する必要がある場合は、新しい PaymentIntent を作成します。以前の PaymentIntent を取得し、 payment_ 内に generated_ ID がある latest_ フィールドを展開して、SEPA ダイレクトデビットの決済手段の ID を見つけます。
SEPA ダイレクトデビットの決済手段 ID は、レスポンス内の payment_method_details にある generated_ ID になります。
{ "latest_charge": { "payment_method_details": { "ideal": { "bank": "ing", "bic": "INGBNL2A", "iban_last4": "****", "generated_sepa_debit": "pm_1GrddXGf98efjktuBIi3ag7aJQ", "verified_name": "JENNY ROSEN" }, "type": "ideal" }, }, "payment_method_options": { "ideal": {}
SEPA ダイレクトデビットと顧客 ID を使用して PaymentIntent を作成します。
構築したシステムをテストする
テスト API キーを使用して PaymentIntent を確定します。確定すると、決済を承認または失敗させるオプションのあるテストページにリダイレクトされます。
- Authorize test payment (テスト支払いをオーソリする) をクリックして、支払い成功のケースをテストします。PaymentIntent が
requires_からaction succeededに変わります。 - Fail test payment (テスト支払いを失敗させる) をクリックして、認証失敗のケースをテストします。PaymentIntent が
requires_からaction requires_に変わります。payment_ method
SEPA ダイレクトデビット組み込みのテスト
オプション支払い後のイベントを処理する
支払いが完了すると、Stripe は payment_intent.succeeded イベントを送信します。ダッシュボード、カスタム Webhook、またはパートナーソリューションを使用してこれらのイベントを受信し、また、顧客への注文確認メールの送信、データベースでの売上の記録、配送ワークフローの開始などのアクションを実行します。
クライアントからのコールバックを待つのではなく、これらのイベントをリッスンします。クライアント側では、コールバックが実行される前に顧客がブラウザーのウィンドウを閉じたり、アプリを終了したりする可能性があります。また、悪意を持つクライアントがレスポンスを不正操作する恐れもあります。非同期型のイベントをリッスンするよう構築済みのシステムを設定することで、これ以降はより多くの決済手段を簡単に受け付けられるようになります。サポートされているすべての決済手段の違いをご確認ください。
イベントを受信し、ビジネスアクションを実行する
ビジネスアクションを受信して実行するためのいくつかのオプションがあります。
手動
Stripe ダッシュボードは、すべての Stripe での支払いの確認、メール領収書の送信、入金処理、または失敗した支払いの再試行に使用できます。
カスタムコード
Webhook ハンドラを作成してイベントをリッスンし、非同期型のカスタムの支払いフローを作成します。Stripe CLI を使用して、ローカルで Webhook 組み込みのテストとデバッグを行います。
事前構築のアプリ
オートメーションやマーケティングとセールスなどの一般的なビジネスイベントを、パートナーアプリケーションとの連携によって処理します。
オプションiDEAL | Wero リダイレクトの手動処理
iDEAL | Wero のリダイレクトと決済を confirmIdealPayment で処理するには、Stripe.js を使用することをお勧めします。ただし、サーバーで決済を完了し、顧客を手動でリダイレクトすることもできます。
- 決済手段の詳細を収集したら、stripe.createPaymentMethod を呼び出して PaymentMethod を作成します。
const paymentMethod = await stripe.createPaymentMethod({ type: 'ideal', billing_details: { name: accountholderName.value, }, }); - サーバーで PaymentIntent と PaymentMethod ID を確認し、支払い完了後に顧客をリダイレクトする return_url を指定します。
PaymentIntentのステータスがrequires_であり、action next_がaction redirect_であることを確認します。to_ url { "next_action": { "type": "redirect_to_url", "redirect_to_url": { "url": "https://hooks.stripe.com/...", "return_url": "https://example.com/checkout/complete" } }, "charges": { "data": [ { "payment_method_details": { "ideal": { "bank": "ing", "bic": "INGBNL2A", next_プロパティに指定されている URL に顧客をリダイレクトします。これで、顧客は認証して支払いを完了できます。action 顧客は支払いを完了すると、const action = intent.next_action; if (action && action.type === 'redirect_to_url') { window.location = action.redirect_to_url.url; }return_にリダイレクトされます。この URL には、クエリパラメーターurl payment_およびintent payment_が含まれています。上記のように独自のクエリパラメーターを追加することもできます。intent_ client_ secret