Best Practices Using Sources / ソースを使用したベストプラクティス

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

カテゴリー: Stripe  閲覧数:219 配信日:2019-03-13 12:26


docs


Payments > SOURCES > Best Practices
Best Practices Using Sources
ソースを使用したベストプラクティス

単一のAPIを通じてさまざまな支払い方法を受け入れるためのベストプラクティス
・チェックアウトフローを設計するときにSources APIの柔軟性を考慮することで、追加の支払い方法をサポートするために必要な変更を最小限に抑えることができる

カード決済の一般的な流れ


カード決済のための典型的なチェックアウトフロー( 3D Secureを除く)
・カード情報を集めてソースを作成し、そしてすぐにそれをchargeリクエストをするために使用する
・追加の措置を講じる必要はない
・また、カードによる支払いでは同期確認が行われるため、支払いが成功し、資金が保証されているかどうかをすぐに確認できる
・WebHookの使用は不要である

ウェブフックを必要とする用途


他の支払い方法では、ソースがchargeableになり、 chargeリクエストを行うために使用される準備が整う前(例:iDEAL)に、customerに追加のアクションを求める場合がある(例:リダイレクト)
・この遷移は一般に非同期的に発生し、顧客があなたのウェブサイトを離れた後にも発生する可能性がある
・これらの理由から、chargeを作成するためにsourceがchargeableになる時期を判断するには、integrationでWebフックを使用することが不可欠である

次のWebhookイベントがsourceのstatusの変更について通知するために送信される
イベント 説明 提案されたアクション
source.chargeable Sourceオブジェクトは、顧客が支払いを認証および確認した後、chargeableになる Create a Charge.
source.failed 顧客が支払いの認証を拒否したため、Sourceオブジェクトはchargeableになることができなくかった 注文をキャンセルし、オプションで支払いフローに顧客を再参加させる
source.canceled Sourceオブジェクトは有効期限が切れており、請求の作成には使用できない 注文をキャンセルし、オプションで支払いフローに顧客を再参加させる

Source作成


Sourcesを作成するとき
・source.chargeable Webhookを受け取って処理するときに注文を取得できるように、内部注文表現に source IDを記録する必要がある
・効率的な検索のために、このsource属性に基づいて注文オブジェクトに必ずインデックスを付けてくれ

Charge作成


あなたはsourceを chargeするのにsource.chargeableウェブフックに頼るべきである
・Webhookを受信したら、受け取ったソースIDに基づいて内部の注文表現を検索し、注文が支払い待ちになっていることを確認する

chargeリクエストを行う際
・競合状態を回避するために、内部注文IDを idempotency keyとして使用することを強くお勧めする
・さらに、ソースが再利用可能であり、それを再利用したい場合は、課金する前に必ずそれを Customerオブジェクトに関連付けしてくれ
・使い捨ておよび再利用可能なソースの処理方法およびそれらが顧客とどのようにやり取りするかについての詳細は、 使い捨てまたは再利用可能およびソースおよび顧客ガイドを参照してくれ

・ソースの作成と同様に、 charge.succeeded Webhooksを受け取って処理したときに注文を取得できるように、内部の注文表現に charge IDを記録する必要がある

確認ページ


顧客が支払いを承認するために必要なアクションを実行した後(例えば、彼らがリダイレクトを辿った後など)
・注文の状態を示す確認ページを表示する必要がある
・注文を内部的に調査することによってこれを行うことができる

確認ページをさらに合理化したい場合
・ウェブフックの配信待ち時間は保証されていないため、確認ページをさらに合理化したい場合は、クライアントサイドコードで関連するソースのステータスを調べることができる
・ あなたのソースがchargeableになったことを検出したら、source.chargeableウェブフックが到着するのを待たずにそのソースを使ってChargeの作成を開始することができる
・一部の種類のソースは、chargeableとなるまでに数分(または数日)かかる場合がある
・あなたがソースを調査することにした場合、私たちはあなたがある時点でタイムアウトして、彼らの注文が支払い確認を待っていることを顧客に告げること、そして非同期に彼らに支払い確認Eメールを送ることを勧める
・下の表には、各Sourceのステータスに対して推奨される顧客向けメッセージが表示されている

・顧客があなたのページを離れると、クライアントサイドの調査が停止することに注意することも重要である
・これは、あなたがあなたの顧客の注文を見失わないようにするためにsource.chargeableウェブフックに対してもintegrateしなければならないことを意味する

・Stripe.jsを使用している場合は、 stripe.retrieveSource()を使用して独自の調査を実装できる

・下の表には、ソースのステータスに基づいて表示できる、顧客に向けられた可能性のあるメッセージの推奨事項が含まれている
STATUS 顧客向けメッセージング
Source is chargeable あなたの注文は受け取られましたそして支払い確認を待っています。
Source is canceled 支払いが失敗し、注文を処理できませんでした。
Source is failed 支払いが失敗し、注文を処理できませんでした。
Source is still pending after polling for a while あなたの注文は受け取られましたそして支払い確認を待っています。
・Chargeを作成すると(そしてユーザーがまだ確認ページにいる場合)、Chargeのステータスに基づいて次のメッセージを表示できる
STATUS 顧客向けメッセージング
Charge is pending あなたの注文は受け取られましたそして支払い確認を待っています。
Charge is failed 支払いが失敗し、注文を処理できませんでした。
Charge is succeeded お支払いは確認され、注文は完了です。

注文確認


charge.succeeded webhookを受け取った後にのみあなたの注文を確認してくれ(すぐにまたは一定時間後に)
・支払い確認には非同期支払いに何日もかかることがあるため、この段階でお客様にEメールを送信することを強くお勧めする

キャンセルと失敗


あなたはsource.canceledとsource.failed webhooksを聞いて、関係するソースに関連した注文をキャンセルすることを確認するべきである
・あなたが上記のベストプラクティスに従うならば、あなたは以前にchargeableだったsourceのsource.canceledウェブフックを決して受け取るべきではない(あなたのsource.chargeableハンドラはソースがキャンセルされるのを防ぐためにすぐにchargeを作ったはずである)
・chargeable ではなく pendingのままのソースについては、source.canceled Webhookを受け取ることになる
・これは、通常、顧客がチェックアウトフローを早めに行ったことを示している
・顧客が支払いを拒否したとき、または支払いスキームレベルで技術的な失敗が発生したときに、 source.failedフックを受け取ることも可能である

・受け取った chargeに関連する注文を確実にキャンセルするには、 charge.failedフックを確認する必要がある
・これらの各イベントについて、注文が失敗したことを顧客に連絡し、支払いフローに再度参加するように招待することをお勧めする

週間人気ページランキング / 12-1 → 12-7
順位 ページタイトル抜粋 アクセス数
1 Stripe Q50。 Connect 「Standardアカウント」で、自身に連結された子アカウントを、ダッシュボードから削除するには? | QA(Stripe) 9
1 決済用語 9
1 EMVレベル1 / EMVレベル2 / EMVCo とは? 9
2 EMVCo | クレジットカード仕様(仕様) 8
3 Stripe Q16。PaymentIntentの支払いで郵便番号入力を求められる。Radar rules の ZIP code を無効にしているのに | QA(Stripe) 5
4 本番環境利用の申請 | その他エントリー(Stripe) 4
4 LINE LIVE | ライブ配信サービス(課金販売できるプラットフォーム) 4
5 「支払」と「送金」の違い | 違い 3
5 機能一覧表 / Q.アカウント複数作成 / Stripeアカウント登録 3
5 Q63.No signatures found matching the expected signature for payload について | QA(Stripe) 3
5 Stripe Q13。決済成功時に、「請求に紐づけられたメールアドレス」に対して、メール送信したいのですが、 | QA(Stripe) 3
5 Gumroadとは?/ 特徴 / Link 3
6 2 段階認証を削除する / 2 段階認証削除後に受信したメール 2
6 Stripe Q38。Difference between “paymentIntent.status === 'succeeded'” and “payment_intent.succeeded event of Webhook” | QA(Stripe) 2
6 fulfillment / fulfillment とは? / ECサイト運営におけるfulfillmentとは? 2
6 大前提 / source objec /「card object」と「source object」の関係 2
6 Checkout (new) はどこで実行するかにより2種類に分かれる 2
6 ふわっち | ライブ配信サービス(課金販売できるプラットフォーム) 2
6 Periscopeが日本で流行っていない理由は、日本では収益を上げることが出来ないから 2
6 クラウドファンディングのメリット / クラウドファンディングのデメリット 2
2022/12/8 1:01 更新
指定期間人気ページランキング / 2020-5-28 → 2022-12-7
順位 ページタイトル抜粋 アクセス数
1 Stripeアカウントへログインする際、モバイル端末で受信したコード入力を求められる理由は? | その他エントリー(Stripe) 1914
2 Stripe Q13。決済成功時に、「請求に紐づけられたメールアドレス」に対して、メール送信したいのですが、 | QA(Stripe) 886
3 Stripe Q16。PaymentIntentの支払いで郵便番号入力を求められる。Radar rules の ZIP code を無効にしているのに | QA(Stripe) 781
4 Stripe Q50。 Connect 「Standardアカウント」で、自身に連結された子アカウントを、ダッシュボードから削除するには? | QA(Stripe) 721
5 EMVCo | クレジットカード仕様(仕様) 708
6 Stripe Q31。ダッシュボードでの「支払い作成」の見方について | QA(Stripe) 635
7 クレジットカード決済 | 課金 490
8 Stripe Q1。Stripeにおける個人事業主の定義 | QA(Stripe) 469
9 Stripeで"No such token: src"と表示されたら、最初にAPIキーを確認する | Stripe エラー(Stripe) 453
10 決済用語 439
11 「Gumroad」は、決済サービス「PayPal」を利用したオンラインコンテンツ販売サービス | デジタルコンテンツ販売可能なサービス(課金販売できるプラットフォーム) 402
12 Stripe Payments > PREPARING FOR SCA > Payment Intents | documentation(Stripe) 363
13 documentation(Stripe) カテゴリー 333
13 Stripe webhook 配信の問題 | その他エントリー(Stripe) 333
14 ファンティア | クリエイター支援プラットフォーム(課金販売できるプラットフォーム) 332
15 Stripe エラー(Stripe) カテゴリー 328
16 プリペイドカード | カード 325
17 PaymentIntentで支払を実装する場合の選択肢 /「Payment Intents API」使用によるカードの支払確認方法は2種類 / PaymentMethodオブジェクトは歴史的経緯により3種類ある 315
17 Payment Intents Usage Guide / Payment Intents 使用ガイド 315
18 Stripe。Stripeアカウントを持っていない人でもクレジットカード決済が出来る | その他エントリー(Stripe) 313
2022/12/8 1:01 更新