コンビニ決済
Payment Intents API と Payment Methods API を使用して、日本でよく使用されるコンビニエンスストアでの支払いを受け付けます。
注意
Stripe は、顧客の通貨、決済手段の制限、その他のパラメーターを評価して、決済手段オプションを自動的に提示します。決済を受け付けるの手順を使用して、Stripe ダッシュボードから決済手段を設定することをお勧めします。
引き続き、Checkout で顧客に提示する決済手段を手動で設定する場合は、このガイドを使用します。それ以外の場合は、ダッシュボードで決済手段を設定できるように、構築済みのシステムを更新してください。
コンビニ決済は 1 回限り使用の支払い方法であり、顧客は支払いを完了するために追加の対応をする必要があります。顧客は日本のコンビニエンスストアで支払いコード、確認番号を提示し、現金で支払います。支払いが完了すると、Stripe から通知が届きます。
支払いを受け付ける
注
このガイドを使用する前に、まず Checkout で決済を受け付けるための実装を構築します。
このガイドでは、Konbini を有効にする方法を紹介し、カード決済を受け付ける場合と、Konbini を使用する場合の違いを説明します。
支払い方法としてコンビニ決済を有効にする
新しい Checkout セッションを作成する際は、以下を行う必要があります。
konbiniをpayment_のリストに追加します。method_ types - すべての
line_がitems jpy通貨を使用していることを確認します。
その他の支払い方法オプション
支払い方法オプションは、支払い方法オプションの konbini キーで指定できます。
| フィールド | 値 | 必須 | デフォルト値 |
|---|---|---|---|
expires_ | 保留中のコンビニ決済の期限切れまでの日数。有効値は 1 ～ 60 日です。有効期限をご覧ください。 | いいえ | 3 |
有効期限
保留中のコンビニ決済は、指定した日付の真夜中 (23:59:59 JST) に期限切れになります。たとえば、expires_ に 2 が設定され、月曜日に PaymentIntent が確定された場合、保留中のコンビニ決済は水曜日の日本時間 (UTC+9) 23:59:59 に期限切れになります。
電話番号
コンビニの決済フォームでは、顧客はオプションで電話番号を入力して確認番号として使用できます。これにより、店内の UI で支払いコードと確認番号の入力が求められるコンビニエンスストアでの支払いプロセスが簡素化されます。両方とも、顧客が決済フォームを提示した後に表示される支払い手順に反映されます。顧客が電話番号を提供しない場合、Stripe はランダムな確認番号を生成します。
電話番号がゼロのみで構成される場合、Stripe はその番号をブロックします。
Stripe がオンラインで提供する取引の詳細ページにリダイレクトする
注
カード支払いと異なり、コンビニ決済では顧客は success_url にリダイレクトされません。
Checkout フォームの送信に成功すると、顧客は hosted_ にリダイレクトされます。顧客はオンラインで提供されるページに記載されている支払い手順書を参照して、支払いを完了する詳しい方法を確認できます。このページはデスクトップとモバイルで見ることができ、印刷も可能です。
Stripe は、コンビニ決済用の取引詳細が正常に作成されると、payment_intent.requires_action イベントを送信します。店舗支払いの詳細を記載したリンクを顧客にメールで送信する必要がある場合は、payment_intent.next_action.konbini_display_details に hosted_ が含まれています。Webhook で PaymentIntent を監視する方法をご確認ください。
Stripe では、ブランディング設定 ページで顧客に表示される UI をカスタマイズすることができます。取引の詳細には、以下のブランド設定を適用できます。
- アイコン: ブランド画像と公開ビジネス名
- アクセントカラー:「番号をコピー」ボタンのカラーとして使用されます
- ブランドカラー: 背景色として使用されます
注文のフルフィルメントを実行する
Konbini は通知遅延型の支払い方法であるため、Webhook などの方法を使用して支払いステータスを監視し、注文のフルフィルメントを履行する必要があります。詳細については、Webhook の設定と注文のフルフィルメントの履行をご覧ください。
支払いのステータスに変化があると、以下のイベントが送信されます。
| イベント名 | 説明 | 次のステップ |
|---|---|---|
顧客が Checkout フォームの送信を完了しました。Stripe がコンビニ決済向けに取引の詳細を生成しています。 顧客がコンビニ決済のための取引詳細を紛失した場合に備え、顧客に | 顧客がコンビニで支払うのを待っています。 | |
| checkout.session.async_payment_succeeded | 顧客がコンビニ決済を完了しました。PaymentIntent が succeeded に移行します。 | 顧客が購入した商品またはサービスのフルフィルメントを実行します。 |
| checkout.session.async_payment_failed | コンビニ決済の有効期限が切れたか、その他の理由で支払いが失敗しました。PaymentIntent のステータスは requires_ に戻ります。 | メールで顧客に連絡して、新たに注文をするようにリクエストします。 |
組み込みをテストする
Checkout の組み込みをテストする際は、支払い方法としてコンビニ決済を選択して、支払うボタンをクリックします。
決済フォームに次の値を指定して、さまざまなシナリオをテストします。特殊な確認番号とメールパターンのいずれかを使用してテストできます。両方を指定した場合、特殊な確認番号の動作が適用されます。
| メールアドレス | 確認番号 | 説明 |
|---|---|---|
|
| 3 分後に成功し、その後 例: hanako@test.com |
|
| 即座に成功し、その後 例: succeed_immediately@test.com |
|
| 即座に有効期限が切れ、その後 支払い方法オプションで 例: expire_immediately@test.com |
|
| 成功することなく、3 分後に有効期限が切れ、その後 支払い方法オプションで 例: expire_with_delay@test.com |
|
| コンビニ決済を成功させずにシミュレーションを実行します。支払い方法オプションで指定されたパラメーターに基づき、 例: fill_never@test.com |
確認番号のエラーをテストするには、以下の値を使用できます。
01234567890は、確認番号の拒否をシミュレートします。00000000000は検証エラーを引き起こします。
Expiration and cancellation
next_action.konbini_display_details の expires_ 値によって指定された期限を過ぎると、顧客はコンビニエンスストアのキオスク端末で、保留中のコンビニ決済の支払いプロセスを「開始」することができなくなります。ただし、期限が切れる前に有効な払込取扱票を発行した場合には、expires_ の後でもレジで支払いを「完了」できます。
このような場合に備え、早期に支払いが失敗しないように、バッファーの時間が設けられています。PaymentIntent のステータスは requires_ に変わります。この時点では、別の支払い方法を指定して PaymentIntent を確定するか、キャンセルできます。
保留中のコンビニ決済は、確定後 next_ で指定された時間までの間に、キャンセルすることもできます。PaymentIntent を更新するか、またはそれを別の支払い方法で確定することでも、暗黙的に既存のコンビニ決済がキャンセルされます。
顧客が現在コンビニエンスストアでコンビニ決済による支払いを行っている場合、キャンセルのリクエストは失敗します。顧客が支払いの試行を放棄した場合や、払込取扱票の期限が切れた後にキャンセルを再度試すことができます。
支払い方法が一時的に利用できなくなる問題は、(明示的および暗黙的な) キャンセルリクエストにも影響することにご注意ください。
注意
保留中の支払いをキャンセルすると、元の決済手順は無効になります。ほぼすべてのユースケースで、顧客にキャンセルについて連絡することをお勧めします。
ステータスが requires_ の PaymentIntent を正常に再確定すると、新しい指示と新しい hosted_ が作成されます。顧客がこれについて通知されていることを確認する必要があります。
返金
Konbini 支払いは、ダッシュボードまたは API で返金できます。
顧客の銀行口座に直接返金するには、顧客が返金先の口座情報を指定する必要があります。Stripe は支払い方法の請求詳細に登録されているメールアドレスを使用して顧客に連絡し、顧客に詳細情報をリクエストします。銀行口座情報を受け取ると、その後返金は自動的に処理されます。
返金のステータスは次のように移行します。
| イベント | 返金のステータス |
|---|---|
| 返金が作成されました | requires_ |
| 顧客が銀行口座の詳細を送信し、Stripe が返金の処理を開始します | pending |
| 返金が顧客の銀行に入金される予定です | succeeded |
| 顧客の銀行が資金を Stripe に戻します | requires_ |
返金は、作成後 45 日間、requires_ です | failed |
返金が requires_ ステータスからキャンセルされました | canceled |
顧客の銀行口座で送金に失敗した場合、資金は Stripe に戻り、返金のステータスは requires_ に変わります。これは、口座保有者の名前が受取人の銀行に登録されている名前と異なるか、指定した銀行口座番号に入力ミスがある場合に発生する可能性があります。この場合、Stripe から顧客に対し、メールで失敗の通知と銀行口座の詳細の再送依頼が行われます。
If your customer doesn’t provide their bank account details within 45 days, the refund’s status transitions to failed and we send the refund.failed event. This means that Stripe can’t process the refund, and you must return the funds to your customer outside of Stripe.
返金の instructions_email フィールドは、返金の送信先のメールアドレスです。返金が顧客からの応答を待機している間、顧客に送信されたメールの詳細も返金の next_action.display_details.email_sent フィールドに示されます。
個々の返金 (一部返金を含む) には手数料が発生する場合があります。詳細については、 Stripe の担当者にお問い合わせください。
返金をテストする
顧客に送信されたメールにリンクが記載された銀行口座情報の収集ページで、以下のテスト用の銀行口座を使用して、テスト環境で返金の動作をテストできます。このテスト用の銀行口座以外の銀行口座情報は受け入れられません。
| 金融番号 | 口座 | 種別 |
|---|---|---|
1100000 | 0001234 | 返金は成功します。 |
|
| 返金は失敗します。 |
返金の有効期限をテストする
API コールを実行して、テスト環境の返金の有効期限をシミュレーションできます。
curl https://api.stripe.com/v1/test_helpers/refunds/{{REFUND_ID}}/expire \ -X POST \ -u:sk_test_4eC39HqLyjWDarjtT1zdp7dc