ダイレクト支払いを作成する
連結アカウントで直接支払いを作成し、手数料を回収します。
顧客が連結アカウントと直接取引を行うときに「ダイレクト支払い」を作成すると、多くの場合、顧客はプラットフォームの存在に気付きません。ダイレクト支払いの特徴は以下のとおりです。
- 支払いはプラットフォームのアカウントではなく、連結アカウントに支払いとして表示されます。
- 連結アカウントの残高は、支払いのたびに増加します。
- アカウント残高は、支払いごとに発生するプラットフォーム手数料により増加します。
この支払いタイプは、SaaS (サービスとしてのソフトウェア) を提供するプラットフォームに最適です。たとえば、Shopify はオンラインストアフロントを構築するためのツールを提供し、Thinkific は教育者がオンラインコースを販売できるようにしています。
注
Stripe ダッシュボードの全機能にアクセスできる連結アカウントには、ダイレクト支払いを使用することをお勧めします。

PaymentSheet クラスを使用して、Stripe の構築済み決済 UI を iOS アプリの決済フローに組み込みます。GitHub のサンプル実装をご覧ください。
Stripe を設定するサーバー側クライアント側
まず、Stripe アカウントが必要です。今すぐ登録してください。
サーバー側
この接続方法では、Stripe API と通信するエンドポイントがサーバー上に必要です。サーバーから Stripe API にアクセスするには、Stripe の公式ライブラリを使用します。
クライアント側
Stripe iOS SDK はオープンソースです。詳細なドキュメントが提供されており、iOS 13 以降をサポートするアプリと互換性があります。
注
SDK の最新リリースおよび過去バージョンの詳細については、GitHub の Releases (リリース) ページをご覧ください。リポジトリのリリースをウォッチして、新しいリリースの公開時に通知を受け取ることも可能です。
アプリの起動時に Stripe 公開可能キーを使用して SDK を設定します。これにより、アプリが Stripe API にリクエストを送信できるようになります。
エンドポイントを追加するサーバー側
注
PaymentIntent の作成前に PaymentSheet を表示するには、インテントを作成する前に支払いの詳細を収集するをご覧ください。
この接続方法では、以下の 3 つの Stripe API オブジェクトを使用します。
PaymentIntent (支払いインテント): Stripe はこれを使用して、顧客から支払いを回収する意図を示し、プロセス全体を通して支払いの試行と支払い状態の変化を追跡します。
(オプション) Customer (顧客): 今後の支払いに備えて決済手段を設定するには、決済手段をCustomer に関連付ける必要があります。Customer オブジェクトは、顧客がビジネスでアカウントを作成するときに作成します。顧客がゲストとして支払いを行う場合は、支払いの前に Customer オブジェクトを作成し、後でこのオブジェクトを顧客のアカウントを表す内部表現に関連付けることができます。
(オプション) Customer Ephemeral Key (顧客の一時キー): Customer オブジェクトの情報は機密情報であるため、アプリから直接取得することはできません。Ephemeral Key により、SDK に Customer への一時的なアクセス権が付与されます。
注
Customer にカードを保存したことがなく、リピート顧客に保存されたカードの再利用を許可しない場合は、実装で Customer オブジェクトおよび Customer Ephemeral Key オブジェクトを省略できます。
セキュリティ上の理由により、アプリでこれらのオブジェクトを作成することはできません。代わりに、サーバー側で以下を行うエンドポイントを追加します。
- Customer を取得するか、新規作成する。
- Customer の一時キーを作成する。
- amount、currency、customer、 を指定して PaymentIntent を作成します。オプションで、
automatic_
パラメーターを含めることもできます。Stripe は、最新バージョンの API ではこの機能をデフォルトで有効にしています。payment_ methods - PaymentIntent の client secret、一時キーの
secret
、顧客の id、および貴社の公開可能キーをアプリに返します。
決済プロセス中に顧客に表示される支払い方法は、PaymentIntent にも含まれています。Stripe にダッシュボードの設定から支払い方法を取得するよう指定することも、手動でリストに表示することもできます。選択したオプションにかかわらず、顧客に表示される支払い方法は、PaymentIntent で渡す通貨によって絞り込まれることにご注意ください。たとえば、PaymentIntent で eur
を渡し、ダッシュボードで OXXO が有効になっている場合、OXXO は eur
による決済に対応していないため、顧客に表示されません。
構築済みのシステムで、支払い方法を提供するためにコードベースのオプションが必要になる場合を除き、自動化されたオプションを使用することをお勧めします。これは、Stripe が通貨、支払い方法の制約、その他のパラメーターを評価して、対応可能な支払い方法を決定するためです。自動化されたオプションでは、購入完了率の向上につながり、使用通貨と顧客の所在地に最適な支払い方法が優先的に表示されます。
決済画面を導入するクライアント側
決済画面に Mobile Payment Element を表示するには、必ず以下を行ってください。
- 顧客が購入している商品を合計金額とともに表示する
- Address Element を使用して、必要な配送先情報を顧客から収集する
- Stripe の UI を表示する購入ボタンを追加する
PaymentSheetResult
が .
の場合は、ユーザーに通知します (注文確認画面を表示するなど)。
allowsDelayedPaymentMethods
を true に設定すると、アメリカの銀行口座などの 遅延通知型の支払い方法を使用できます。これらの支払い方法では、PaymentSheet
が完了した時点では最終的な支払いステータスが判明せず、後になって成功または失敗が確定します。このようなタイプの支払い方法に対応する場合は、注文が確定済みであることを顧客に通知し、支払いが成功した場合にのみ注文のフルフィルメント (商品の発送など) を実行するようにします。
戻り先 URL を設定するクライアント側
顧客はお客様のアプリから離れて、(Safari やバンキングアプリなどで) 認証する場合があります。ユーザーが認証後にアプリに自動的に戻れるようにするには、カスタム URL スキームを構成し、URL を SDK に転送するようにアプリのデリゲートを設定します。Stripe はユニバーサルリンクには対応していません。
支払い後のイベントを処理するサーバー側
支払いが完了すると、Stripe は payment_intent.succeeded イベントを送信します。ダッシュボードの Webhook ツールを使用するか Webhook のガイドに従ってこれらのイベントを受信し、顧客への注文確認メールの送信、データベースでの売上の記録、配送ワークフローの開始などのアクションを実行します。
クライアントからのコールバックを待つのではなく、これらのイベントをリッスンします。クライアントでは、コールバックが実行される前に顧客がブラウザーのウィンドウを閉じたり、アプリを終了する場合、また悪意を持つクライアントがレスポンスを不正操作する場合もあります。非同期型のイベントをリッスンするよう組み込みを設定すると、単一の組み込みで複数の異なるタイプの支払い方法を受け付けることができます。
Payment Element を使用して支払いを回収する場合は、payment_
イベントのほかにこれらのイベントを処理することをお勧めします。
イベント | 説明 | アクション |
---|---|---|
payment_intent.succeeded | 顧客が正常に支払いを完了したときに送信されます。 | 顧客に注文の確定を送信し、顧客の注文のフルフィルメントを実行します。 |
payment_intent.processing | 顧客が正常に支払いを開始したが、支払いがまだ完了していない場合に送信されます。このイベントは、多くの場合、顧客が口座引き落としを開始するときに送信されます。その後、payment_ イベント、また、失敗の場合は payment_ イベントが送信されます。 | 顧客に注文確認メールを送信し、支払いが保留中であることを示します。デジタル商品では、支払いの完了を待たずに注文のフルフィルメントを行うことが必要になる場合があります。 |
payment_intent.payment_failed | 顧客が支払いを試みたが、支払いに失敗する場合に送信されます。 | 支払いが processing から payment_ に変わった場合は、顧客に再度支払いを試すように促します。 |
実装内容をテストする
実装内容をテストするためのその他の情報については、テストをご覧ください。
手数料を回収する
支払いが処理されると、プラットフォームはプラットフォーム手数料という形で取引金額の一部を受け取ることができます。プラットフォーム手数料の料金体系は、次の 2 つの方法で設定できます。
- プラットフォームの料金設定ツールを使用して、料金設定ルールを設定してテストします。この Stripe ダッシュボードのノーコード機能は、現時点では Stripe 手数料の支払い責任を負うプラットフォームでのみ利用できます。
- 社内で料金ルールを設定し、プラットフォーム手数料を PaymentIntent で直接指定します。この方法で設定された手数料は、プラットフォーム料金設定ツールで指定された料金体系ロジックを上書きします。
プラットフォームは、以下の制限でプラットフォーム手数料を請求する場合があります。
application_
の値は正の値で、請求金額よりも小さくする必要があります。回収するプラットフォーム手数料は、キャプチャーされた支払い金額が上限になります。fee_ amount - プラットフォーム手数料自体に追加の Stripe 手数料はありません。
- ブラジルの規制ならびに遵守要件に従い、ブラジルの連結アカウントが含まれ、ブラジル国外を拠点とするプラットフォームは、Stripe を通じてプラットフォーム手数料を回収することはできません。
application_
の通貨は、複数の通貨のいくつかの要素によって決まります。fee_ amount
その結果として生じる支払いの Balance Transaction (取引残高) には、Stripe 手数料とプラットフォーム手数料の両方の詳細な内訳が含まれます。レポート作成の操作性を高めるために、プラットフォーム手数料の回収後に、Application Fee (プラットフォーム手数料) が作成されます。プラットフォーム手数料オブジェクトの amount
プロパティをレポート作成に使用します。これにより、Application Fee (プラットフォーム手数料) エンドポイントでこれらのオブジェクトにアクセスできるようになります。
獲得したプラットフォーム手数料は、通常の Stripe の支払いの売上と同じスケジュールでお客様の利用可能なアカウント残高に追加されます。プラットフォーム手数料は、ダッシュボードの手数料収入の合計セクションで確認できます。
注意
デフォルトでは、ダイレクト支払いのプラットフォーム手数料は非同期で作成されます。支払い作成リクエストで application_
オブジェクトを拡張すると、リクエストの一部としてプラットフォーム手数料が同期的に作成されます。application_
オブジェクトを拡張するとリクエストの遅延が増加するため、必要な場合に拡張してください。
非同期で作成されたプラットフォーム手数料に対するプラットフォーム手数料オブジェクトにアクセスするには、application_fee.created Webhook イベントをリッスンします。
手数料を含む売上のフロー
支払いに対するプラットフォーム手数料を指定すると、その手数料の金額がプラットフォームの Stripe アカウントに送金されます。連結アカウントで直接支払いを処理する場合、Stripe 手数料とプラットフォーム手数料を差し引いた支払い額が連結アカウントに入金されます。
たとえば、前の例のように、10 USD の支払いを作成し、そのプラットフォーム手数料が 1.23 USD の場合、1.23 USD がプラットフォームアカウントに送金されます。8.18 USD (10 USD - 0.59 USD - 1.23 USD) が連結アカウントでの手取り額となります (標準的なアメリカの Stripe 手数料を想定した場合)。

複数の通貨で支払いを処理する場合は、Connect でどのように通貨が処理されるかについてもご覧ください。
返金する
プラットフォームは連結アカウントに対して支払いを作成できるのと同様に、連結アカウントに対して支払いの返金を作成することもできます。連結アカウントとして認証済みの状態で、プラットフォームのシークレットキーを使用して返金を作成します。
返金する際に、プラットフォーム手数料は自動的に返金されません。プラットフォームはプラットフォーム手数料を明示的に返金する必要があります。そうしなければ、連結アカウント (支払いが作成されたアカウント) はその金額を失うことになります。返金リクエストで、以下のように refund_
値として true を渡すことによって、プラットフォーム手数料を返金できます。
デフォルトでは支払いの全額が返金されますが、amount
値を正の整数に設定することで、一部返金を作成することができます。支払いの全額が返金されることになった場合は、プラットフォーム手数料の全額が返金されます。そうでない場合は、プラットフォーム手数料の比例配分された部分が返金されます。別の方法として、refund_
値に false を指定し、別途プラットフォーム手数料を返金することもできます。