ACH ダイレクトデビットによる支払いを受け付ける
カスタムの決済フォームを構築するか、Stripe Checkout を使用して、ACH ダイレクトデビットによる決済を受け付けます。
アプリでの ACH ダイレクトデビットによる決済の受け付けは、以下のように構成されます。
- 決済を追跡するためのオブジェクトを作成する
- Stripe Financial Connections によって有効化される即時確認を使用して、支払い方法の情報を収集する
- 決済を処理するために Stripe に送信する
- 顧客の銀行口座を確認する
注
ACH ダイレクトデビットは通知遅延型の支払い方法であるため、決済後すぐには売上が利用可能になりません。通常、決済金額がお客様のアカウントに入金されるまでに 4 営業日かかります。
Stripe では、Payment Intent (支払いインテント) と呼ばれる決済オブジェクトを使用して、決済が完了するまでの状態のすべてを追跡および処理します。
iOS SDK はオープンソースです。詳細なドキュメントが提供されており、iOS 13 以降をサポートするアプリと互換性があります。
注
最新の SDK リリースと過去のバージョンの詳細については、GitHub のリリース ページをご覧ください。新しいリリースの公開時に通知を受け取るには、リポジトリーのリリースを確認してください。
アプリの起動時に Stripe 公開可能キーを使用して SDK を設定します。これにより、アプリが Stripe API にリクエストを送信できるようになります。
Stripe では、顧客の銀行口座を即座に確認できます。口座に関する追加データを取得する場合は、Stripe Financial Connections を使用してデータアクセスを登録します。
Stripe Financial Connections を使用すると、金融口座をビジネスに関連付けることで、顧客が財務データを安全に共有できます。Financial Connections を使用して、トークン化された口座番号と金融番号、残高データ、所有者の詳細、取引データなどの顧客に許可された財務データにアクセスします。
このデータにアクセスすることで、決済を開始する前に残高を確認するなどのアクションを実行し、残高不足による決済の失敗の可能性を減らすことができます。
Financial Connections は、ユーザーがより少ないステップで自身のアカウントを Link に関連付け、Stripe のすべての加盟店に銀行口座の詳細を保存して、素早く再利用できるようにします。
顧客を作成または取得する推奨サーバー側
ユーザーがビジネスでアカウントを作成する際に、Customer オブジェクトを作成するか、このユーザーに関連付けられた既存の Customer を取得します。この Customer オブジェクトの ID を、顧客を表す社内の内部表記と関連付けることで、保存されている支払い方法の詳細を後で取得して使用することができます。Financial Connections のリピートユーザーの最適化を有効にするには、Customer にメールアドレスを含めます。
PaymentIntent を作成するサーバー側クライアント側
PaymentIntent (支払いインテント) は、顧客から支払いを回収する意図を表すオブジェクトで、決済プロセスのライフサイクルの各段階を追跡します。
サーバー側
まず、サーバーで PaymentIntent を作成し、回収する金額と通貨 usd
を指定します。Payment Intents API を使用した実装がすでにある場合は、PaymentIntent の支払い方法タイプのリストに us_
を追加します。オプションで、Customer の ID を指定します。
将来その支払い方法を再利用する場合には、値を off_
に設定して setup_future_usage パラメーターを指定します。
デフォルトでは、銀行口座の支払い情報の収集では、手動の口座番号入力と少額入金の確認のフォールバックオプションを使用し、Financial Connections で顧客のアカウントを即時確認します。Financial Connections を設定し、ACH の実装を最適化するために追加の口座データにアクセスする方法については、Financial Connections に関するドキュメントをご覧ください。たとえば、Financial Connections を使用して、ACH 決済の開始前にアカウントの残高を確認できます。
注
顧客がアカウントを認証した後で、追加データにアクセスを拡張するには、権限を拡張してアカウントを再度関連付ける必要があります。
クライアント側
返される PaymentIntent には client secret が含まれています。これは、PaymentIntent オブジェクト全体を渡すことなく安全に決済を完了するために、クライアント側で使用されます。クライアント側で、サーバーに PaymentIntent をリクエストし、その client secret を保存します。
戻り先 URL を設定するクライアント側
顧客はお客様のアプリから離れて、(Safari やバンキングアプリなどで) 認証する場合があります。ユーザーが認証後にアプリに自動的に戻れるようにするには、カスタム URL スキームを構成し、URL を SDK に転送するようにアプリのデリゲートを設定します。Stripe はユニバーサルリンクには対応していません。
注
Stripe は、指定された戻り先 URL にパラメーターを追加する場合があります。パラメーターが追加された戻り先 URL がコードで拒否されないことを確認してください。
支払い方法の詳細を収集するクライアント側
ACH ダイレクトデビットで決済を成功させるには、顧客の氏名と (オプションで) メールアドレスが必要です。アプリで、必要な請求詳細を顧客から収集します。
- 顧客の氏名 (姓と名)
- 顧客のメールアドレス
STPCollectBankAccountParams
でクラス関数 collectUSBankAccountParams
を使用し、collectBankAccountForPayment
を呼び出すために必要なパラメーターを作成します。ACH ダイレクトデビット PaymentMethod を作成するには、billing_
パラメーターに口座名義人を含める必要があります。
STPBankAccountCollector
のインスタンスを作成して collectBankAccountForPayment
を呼び出し、銀行口座情報を収集し、PaymentMethod を作成し、その PaymentMethod を PaymentIntent に関連付けます。
これにより、銀行口座の詳細の収集と銀行口座の確認を処理するモーダル UI が読み込まれます。処理が完了すると、PaymentMethod が PaymentIntent に自動的に関連付けられます。
同意書承認を収集し、決済を送信するクライアント側
決済を開始する前に、同意書の規約を表示して顧客から承認を得る必要があります。
Nacha の運営規則に準拠するため、決済を開始する前に、同意書の規約を表示して顧客から承認を得る必要があります。同意書の詳細については、こちらの記事をご覧ください。
顧客が同意書の規約を承認する際に、お客様は PaymentIntent を確定する必要があります。顧客がフォームを送信したら、confirmPayment
を使用して、決済を完了します。
注
confirmPayment
が完了するまでには数秒かかる場合があります。この間、フォームが再送信されないように無効化し、待機中のインジケーター (スピナーなど) を表示します。エラーが発生した場合は、それを顧客に表示し、フォームを再度有効化し、待機中のインジケーターを非表示にします。
成功した場合、Stripe から以下のいずれかのステータスで PaymentIntent オブジェクトが返されます。
ステータス | 説明 | 次のステップ |
---|---|---|
requires_ | 銀行口座の確認を完了するには、追加のアクションが必要です。 | ステップ 6: 少額入金で銀行口座を確認する |
processing | 銀行口座が即座に確認されたか、確認が必要ありません。 | ステップ 7: PaymentIntent の成功を確認する |
PaymentIntent の確定に成功した後、同意書の確認メールと収集した銀行口座情報を顧客に送信する必要があります。Stripe はデフォルトでこれらの処理を行いますが、ご希望に応じてカスタム通知の送信を選択することもできます。
少額入金で銀行口座を確認するクライアント側
すべての顧客が銀行口座を即座に確認できるわけではありません。このステップは、顧客が前のステップで即時確認フローからオプトアウトした場合にのみ適用されます。
このような場合、Stripe は descriptor_
による少額入金を送金し、銀行口座の確認でさらに問題が発生した場合には、amount
による少額入金に戻る場合があります。これらの入金が顧客のオンライン明細書に表示されるには 1 ~ 2 営業日かかります。
- 明細書表記コード。Stripe は、SM で始まる一意の 6 桁の
descriptor_
を使用し、0.01 USD の 1 件の少額入金を顧客の銀行口座に送金します。顧客は、この文字列を使用して銀行口座を確認します。code - 金額。Stripe は、
ACCTVERIFY
という明細書表記を使用し、一意でない 2 件の少額入金を顧客の銀行口座に送金します。顧客は、この入金額を使用して銀行口座を確認します。
前のステップで行った confirmPayment
メソッドの呼び出しの結果として、requires_
状態のPaymentIntentが返されます。この PaymentIntent には、確認を完了するための有益な情報を含む next_action フィールドが含まれています。
請求書メールを指定した場合、Stripe はこのメールで入金の到着予定日を顧客に通知します。このメールには、Stripe がオンラインで提供する確認ページへのリンクが含まれ、顧客はそのページで入金額を確認して銀行口座の確認を完了することができます。
警告
確認の失敗は、明細書表記ベースの少額入金の場合は 10 回、金額ベースの少額入金の場合は 3 回までです。この上限を超えると、Stripe は銀行口座を確認できなくなります。また、少額入金の確認は 10 日経過するとタイムアウトになります。この期間内に少額入金を確認できなかった場合、PaymentIntent は新しい支払い方法の詳細を要求する状態に戻ります。少額入金とは何か、どのように使用されるのかを顧客に明確に伝えることで、確認に関する問題を回避できます。
オプション: カスタムのメール通知を送信する
また、顧客にカスタムのメール通知を送信することもできます。カスタムメールを設定した後は、顧客が確認メールに応答する方法を指定する必要があります。以下の方法のうち、いずれか _1 つ_を指定してください。
Stripe 上のオンライン確認ページを使用します。これを行うには、next_action オブジェクトの
verify_
URL を使用し、顧客に確認プロセスを完了するよう指示します。with_ microdeposits[hosted_ verification_ url] Stripe がオンラインで提供する確認ページを使用しない場合には、ご自身のアプリにフォームを作成します。顧客はこのフォームを使用して少額入金の金額を伝え、iOS SDK を使用して銀行口座を確認します。
- 少なくとも
descriptor code
パラメーター (確認のための 6 桁の文字列) を処理するフォームを設定します。 - また Stripe では、
amounts
パラメーターも処理するようにフォームを設定することをお勧めします。これはこのパラメーターが、顧客が利用する一部の銀行で必要とされることがあるためです。
組み込みは、
descriptor_
「または」code amounts
のみを渡します。組み込みでどちらが使用されるかを判断するには、next_
オブジェクトのaction verify_
の値を確認します。with_ microdeposits[microdeposit_ type] - 少なくとも
銀行口座の確認が成功すると、Stripe は、processing
の status
の PaymentIntent オブジェクトを返します。
確認が失敗する理由はいくつかあります。失敗は、直接的なエラー応答として同期的に発生します。
{ "error": { "code": "payment_method_microdeposit_verification_amounts_mismatch", "message": "The amounts provided do not match the amounts that were sent to the bank account. You have {attempts_remaining} verification attempts remaining.", "type": "invalid_request_error" } }
エラーコード | メッセージ | ステータスの変化 |
---|---|---|
payment_ | 少額入金に失敗しました。指定した銀行口座、金融機関、支店の番号を確認してください。 | status は requires_ で、last_ が設定されます。 |
payment_ | 指定された金額が銀行口座に送金された金額と一致しません。確認試行の残り回数はあと {attempts_remaining} 回です。 | 変化なし |
payment_ | 許容された確認の試行回数を超えました。 | status は requires_ で、last_ が設定されます。 |
PaymentIntent の成功を確認するサーバー側
ACH ダイレクトデビットは、通知遅延型の支払い方法です。このため、顧客の口座から引き落としを開始してから、決済の成功または失敗の通知を受けるまでに最大で 4 営業日かかります。
PaymentIntent を作成すると、その初期ステータスは processing
となります。決済が成功すると、PaymentIntent のステータスは processing
から succeeded
に更新されます。
Webhook を使用して決済が成功したことを確認し、顧客に決済完了を通知することをお勧めします。Stripe ダッシュボードでイベントを表示することもできます。
組み込みをテストする
Financial Connections を使用して即時確認を行うシナリオをテストする方法をご紹介します。
サンドボックスで取引メールを送信する
銀行口座の詳細を収集し、同意書を受け付けたら、サンドボックスで同意書の確認メールと少額入金の確認メールを送信します。
ドメインが {domain} でユーザー名が {username} の場合、{username}+test_email@{domain} というメール形式を使用してテスト取引メールを送信してください。
たとえば、ドメインが example.com でユーザー名が info の場合、ACH Direct Debit 決済のテストには info+test_email@example.com という形式を使用します。この形式により、メールが正しくルーティングされます。+test_email サフィックスを含めない場合、メールは送信されません。
よくある間違い
テスト中にこれらのメールをトリガーするには、Stripe の本番環境利用の申請を行う必要があります。
テスト用口座番号
Stripe では、手動入力の銀行口座の組み込みが本番環境に移行する準備が整ったかどうかを確認するため、テスト用の口座番号と対応するトークンをいくつか用意しています。
口座番号 | トークン | 金融番号 | 動作 |
---|---|---|---|
000123456789 | pm_ | 110000000 | 支払いは成功します。 |
000111111113 | pm_ | 110000000 | 口座が解約済みであるため、支払いは失敗します。 |
000000004954 | pm_ | 110000000 | この支払いは、不正利用のリスクが高いため、Radar によってブロックされています。 |
000111111116 | pm_ | 110000000 | 口座が見つからないため、支払いは失敗します。 |
000222222227 | pm_ | 110000000 | 残高不足のため、支払いは失敗します。 |
000333333335 | pm_ | 110000000 | 引き落としがオーソリされていないため、支払いは失敗します。 |
000444444440 | pm_ | 110000000 | 通貨が無効であるため、支払いは失敗します。 |
000666666661 | pm_ | 110000000 | 支払いで少額入金の送金が失敗します。 |
000555555559 | pm_ | 110000000 | 支払いによって不審請求の申請が開始されています。 |
000000000009 | pm_ | 110000000 | 支払いは無期限に処理中のままになります。これは PaymentIntent のキャンセルをテストするのに便利です。 |
000777777771 | pm_ | 110000000 | 支払い額がアカウントの週次支払い額の上限を超えているため、支払いが失敗しました。 |
テスト取引を完了する前に、自動的に支払いに成功または失敗するテスト用のすべての口座を確認する必要があります。確認するには、下記の少額入金のテスト用の金額または明細書表記コードを使用します。
少額入金の金額と明細書表記コードをテストする
さまざまなシナリオを再現するために、これらの少額入金の金額「または」明細書表記コードの値 0.01 を使用します。
少額入金の金額 | 明細書表記コードの値 0.01 | シナリオ |
---|---|---|
32 および 45 | SM11AA | アカウントの確認をシミュレーションします。 |
10 および 11 | SM33CC | 許容された確認回数の超過をシミュレーションします。 |
40 および 41 | SM44DD | 少額入金のタイムアウトをシミュレーションします。 |
売上処理の動作をテストする
テスト取引は即座に売上として処理され、利用可能なテスト残高に追加されます。この動作は、利用可能な残高で取引が売上として処理されるまでに数日かかることがある、本番環境とは異なります。