API によるアカウント登録

Stripe の API を使用して、自社のアカウント登録フローを構築します。

API によるアカウント登録では、Accounts API を使用して、ユーザー向けのアカウント登録フロー、レポート機能、通信チャネルを構築します。アカウント所有者は Stripe を完全に認識できなくなります。ただし、プラットフォームは、アカウントとのすべてのやり取りと、アカウントの確認に必要なすべての情報の収集に対する責任を負うものとします。

その他の責任

API によるアカウント登録の場合、構築するカスタムフローは、貴社が事業を行っている地域のすべての法的要件と規制要件を満たすものである必要があります。また、これらの要件の変更を追跡し、少なくとも 6 カ月に一度の頻度で継続的に最新情報を収集するためのリソースを投入する必要があります。カスタマイズしたアカウント登録フローを実装する場合は、埋め込みアカウント登録を利用することを強くお勧めします。

要件を定める

以下の要因は、連結アカウントの登録要件に影響します。

連結アカウントの所在国
連結アカウントに適用される利用規約タイプ
連結アカウントでリクエストされるケイパビリティ
The business_type (for example, individual or company) and company.structure (for example, public_corporation or private_partnership)

対話型フォームを使用して、これらの要因を変更すると要件にどのような影響が出るかを確認できます。

要件フォーム

情報を収集するフォームを作成する
クライアント側

ベストプラクティスとして、必須パラメーターをアカウント登録フローの論理グループまたはフォームに分類します。Stripe のパラメーターと論理グループのマッピングをエンコードすることもできます。パラメーターに推奨される論理グループは、サンプルの要件表の 1 列目に表示されています。

必須パラメーターをアプリケーションにエンコードした後で、これらの要件に対応するパラメーターの UI を生成します。パラメーターごとに、以下を含む UI フォームを設計します。

それぞれ対応する国と言語に合わせたパラメーターのラベル
それぞれ対応する国と言語に合わせたパラメーターの説明
必要に応じてデータ検証ロジックと書類のアップロード機能を備えた、パラメーターの入力フィールド

今後パラメーターが追加される可能性を考慮して、アプリケーションロジックを構築することが重要です。たとえば、Stripe が新しいパラメーター、新しい確認、新しいしきい値を導入し、それらを徐々にアカウント登録フローに組み込む必要がある場合が考えられます。

Changing any of the factors that determine your connected accounts’ requirements means you must also adjust your collection forms to handle the changed requirements. Country and service agreement type are immutable, while capabilities and business type are mutable.

To change an immutable field, create a new connected account with the new values to replace the existing account.
To change a mutable field, update the connected account.

Include the Stripe Terms of Service Agreement

Your connected accounts must accept Stripe’s terms of service before they can activate. You can wrap Stripe’s terms of service in your own terms of service.

連結アカウントを作成する
サーバー側

Create an Account where your platform is liable for negative balances, Stripe collects fees from your platform account, and your connected accounts don’t have access to a Stripe-hosted Dashboard. Request any capabilities that your connected accounts need. Prefill the business type and any other available information matching your requirements.

または、type を custom に設定し、必要なケイパビリティを指定して連結アカウントを作成することもできます。

国と利用規約への同意を指定しない場合、次のデフォルト値が割り当てられます。

country は、デフォルトでプラットフォームと同じ国に設定されます。
利用規約への同意 (tos_acceptance.service_agreement) は、デフォルトで full に設定されます。

収集する情報を決定する
サーバー側

As the platform, you must decide if you want to collect the required information from your connected accounts up front or incrementally. Up-front onboarding collects the eventually_due requirements for the account, while incremental onboarding only collects the currently_due requirements.

Onboarding type	メリット
Up-front	Normally requires only one request for all information Avoids the possibility of payout and processing issues due to missed deadlines Exposes potential risk early when accounts refuse to provide information
Incremental	Accounts can onboard quickly because they don’t have to provide as much information

To determine whether to use up-front or incremental onboarding, review the requirements for your connected accounts’ locations and capabilities. While Stripe tries to minimize any impact to connected accounts, requirements might change over time.

For connected accounts where you’re responsible for requirement collection, you can customize the behavior of future requirements using the collection_options parameter. To collect the account’s future requirements, set collection_options.future_requirements to include.

To implement your onboarding strategy, inspect the requirements hash of the connected account you created. The requirements hash provides a complete list of the information you must collect to activate the connected account.

For incremental onboarding, inspect the currently_due hash in the requirements hash and build an onboarding flow that only collects those requirements.
For up-front onboarding, inspect thecurrently_due and eventually_due hashes in the requirements hash, and build an onboarding flow that collects those requirements.

{
  ...
  "requirements": {
    "alternatives": [],
    "current_deadline": null,
    "currently_due": [
      "business_profile.product_description",
      "business_profile.support_phone",
      "business_profile.url",
      "external_account",
      "tos_acceptance.date",
      "tos_acceptance.ip"
    ],
    "disabled_reason": "requirements.past_due",
    "errors": [],
    "eventually_due": [
      "business_profile.product_description",
      "business_profile.support_phone",
      "business_profile.url",
      "external_account",
      "tos_acceptance.date",
      "tos_acceptance.ip"
    ],
    "past_due": [],
    "pending_verification": []
  },
  ...
}

ライブネス要件を処理する

アカウントには、proof_of_liveness 要件を持つ 1 人以上の個人を含めることができます。proof_of_liveness 要件により、シンガポールの MyInfo などの電子 ID 資格情報の収集、または Stripe Identity を使用したドキュメントまたは自撮り写真の収集が必要になる場合があります。proof_of_liveness 要件のすべてのバリエーションを満たすため、Stripe がオンラインで提供するオンボーディングまたは埋め込み型のオンボーディングを使用することをお勧めします。

Stripe がオンラインで提供するオンボーディングで、proof_of_liveness 要件のすべてのバリエーションを完了できます。

連結アカウント ID を使用してアカウントリンクを作成し、返された url にアカウントを送信します。

アカウントは、proof_of_liveness 要件と、現在期限が到来しているその他の要件を完了するように求めるプロンプトを受け取ります。Webhook エンドポイントに送信された account.updated イベントをリッスンして、アカウントが要件を完了しその情報を更新したときに通知されるようにします。アカウントが要件を完了すると、そのアカウントは指定の return_url にリダイレクトされます。

連結アカウントを更新する
サーバー側

Update the Account object with new information as your connected account progresses through each step of the onboarding flow. That allows Stripe to validate the information as soon as it’s added. After Stripe confirms acceptance of our terms of service, any change to the Account triggers reverification. For example, if you change the connected account’s name and ID number, Stripe reruns verifications.

連結アカウントを更新する際には、すべての確認エラーまたは HTTP エラーコードに対処する必要があります。

確認エラーを処理する
サーバー側

When the connected account’s data is submitted, Stripe verifies it. This process might take minutes or hours, depending on the nature of the verification. During this process, the capabilities you requested have a status of pending.

ステータスを確認する

連結アカウントのケイパビリティのステータスは、以下によって取得できます。

Account オブジェクトの capabilities ハッシュで、関連するケイパビリティを確認します。
Capabilities API から直接ケイパビリティをリクエストし、関連するケイパビリティのステータスを確認します。
Webhook エンドポイントで account.updated イベントをリッスンし、関連するケイパビリティの capabilities ハッシュを確認します。

After verifications are complete, a capability becomes active and available to the connected account. Account verifications run continuously, and if a future verification fails, a capability can transition out of active. Listen for account.updated events to detect changes to capability states.

構築済みの Connect の実装内容が法令を遵守し、稼働中であることを確認するには、アカウントの charges_enabled と payouts_enabled が両方とも true であることを確認します。API を使用するか、account.updated イベントをリッスンすることができます。その他の関連フィールドについて、詳細はアカウントの requirements (要件) ハッシュを確認してください。アプリケーションおよび関連ポリシーに応じてステータスが変化する可能性があるため、単一の値に基づいて実装を確認することはできません。

charges_enabled は、支払いと送金を含む全体的な支払いパスが正しく機能することを確認し、card_payments と transfers ケイパビリティのどちらがアクティブになっているかを評価します。
payouts_enabled は連結アカウントが外部口座に入金できるかを評価します。リスクポリシーによっては、連結アカウントが入金を有効にせずに取引を開始することを許可できます。連結アカウントに支払うには、最終的には入金を有効にする必要があります。

以下のロジックは、連結アカウントに表示するサマリーのステータスを定義するための開始ポイントとして使用できます。

Ruby
# Set your secret key. Remember to switch to your live secret key in production.
# See your keys here: https://dashboard.stripe.com/apikeys
Stripe.api_key = 'sk_test_BQokikJOvBiI2HlWgH4olfQ2'


def account_state(account)
  reqs = account.requirements

  if reqs.disabled_reason && reqs.disabled_reason.include?("rejected")
    "rejected"
  elsif account.payouts_enabled && account.charges_enabled
    if reqs.pending_verification
      "pending enablement"
    elsif !reqs.disabled_reason && !reqs.currently_due
      if !reqs.eventually_due
        "complete"
      else
        "enabled"
      end
    else
      "restricted"
    end
  elsif !account.payouts_enabled && account.charges_enabled
    "restricted (payouts disabled)"
  elsif !account.charges_enabled && account.payouts_enabled
    "restricted (charges disabled)"
  elsif reqs.past_due
    "restricted (past due)"
  elsif reqs.pending_verification
    "pending (disabled)"
  else
    "restricted"
  end
end

accounts = Stripe::Account.list(limit: 10)

accounts.each do |account|
    puts "#{account.id} has state: #{account_state(account)}"
end

注

API を使用して Stripe のリスク審査に対応することはできません。埋め込みコンポーネント、Stripe のホスティング登録、または修復リンクを使用して、連結アカウントが対応できるように設定できます。ダッシュボードを使用して、連結アカウントの代わりにリスク審査に対応することもできます。

account.updated イベントをリッスンします。current_deadline が着信したときにアカウントに currently_due フィールドが含まれている場合は、対応する機能が無効になり、そのフィールドが past_due に追加されます。

アカウントが情報の修正に使用できる明確な指示が記載されたフォームを作成します。アカウントに通知し、次に Accounts API を使用して、修正された情報を送信します。

すべての確認エラーに対処するカスタムフローの作成を計画している場合:

可能性のあるすべての確認エラーとその対処法に関する詳細を確認します。
確認状態をテストします。

注