Stripe では、Stripe App Marketplace に提出されたすべてのアプリとアプリの更新を審査し、それらが設計、信頼性、セキュリティ、信用の面においてユーザーに最良のユーザー体験を提供することを確認します。アプリの審査に提出する前に、アプリがこれらの要件を満たすことを確認してください。
アプリの審査の原則 アプリの審査プロセスを説明する 3 つの主な原則:
品質 : ユーザーは高品質で有益なアプリを求めています。これには、デザイン、ユーザー体験、パフォーマンス、信頼性などの要素が含まれます。セキュリティー : すべてのアプリは、ユーザーデータのセキュリティーとプライバシーに関する Stripe の基準を満たし、あらゆる該当法に準拠している必要があります。信頼 : アプリ開発者は、Stripe のエコシステムの一貫性を保持する信頼基準に従う必要があります。これは、コミュニケーション、サポート、コミュニティーの行動のすべてが対象になります。アプリの審査プロセス 審査を受けるためにアプリを提出すると、以下が行われます。
Stripe ダッシュボードから、アプリリストを作成または更新します。次に、アプリとアプリリストを提出して審査を受けます。アプリを機能させるためにアカウントや追加データが必要な場合には、審査プロセスの一環としてアプリをテストする方法の詳細を示すテストプランと認証情報を提出する必要があります。このステップの手順については、サンプルのテスト用認証情報 アプリを提出して審査を受ける Stripe の審査担当者は、該当するすべての条件に関してアプリとリスト掲載内容を評価します。このプロセスには、自動スキャン、アプリのライブテスト、提供された全情報の人間による審査が含まれることがあります。 アプリとリスト掲載内容がアプリの審査要件をすべて満たしている場合には、このバージョンのアプリと掲載内容が承認され、いつでもマーケットプレイスでアプリを表示できるようになります。マーケットプレイスに掲載するには、承認されたアプリを明示的に公開する必要があります。この手順については、アプリを公開する アプリとアプリ掲載内容の更新でも同じプロセスが使用されます。
アプリの審査要件 審査に合格するには、アプリがこのセクションにある要件を満たす必要があります。審査に提出する前にアプリを徹底的にテストし、バグやエッジケースがないか調べてください。
わかりやすく一貫した料金体系 アプリの料金体系は、隠れた費用や手数料がないように事前に明示する必要があり、マーケットプレイス外での料金体系と一貫していなければなりません。
すべきこと すべきではないこと サービスの料金体系は、分かりやすく、マーケットプレイス外での料金体系と一致している必要があります。 希望する場合、便利な無料の機能をユーザーに提供します。 Stripe App Marketplace 外の料金体系と異なる料金体系の設定。 サービスを無料と広告し、ユーザーがアプリをインストールした後でその機能の支払いを求める。
アプリ開発者の基準 アプリの開発者は、自身とビジネスの目的を明確に記載する必要があります。オンライン・オフラインを問わず、違法または有害な活動に関与することはできません。
すべきこと すべきではないこと 自社の Ｗeb サイトに、連絡先情報など、自社の正確な情報が記載されていることを確認してください。 お客様の事業目的が、Stripe の禁止/制限付き業種 ビジネスが制限付き業種に該当する場合は、追加の審査が行われる可能性があります。 違法または有害な行為に関与する。 自身または目的を偽ること。
アプリリストのページ アプリリストによって、企業はアプリを見つけ、それが事業の運営にどのように役立つかを理解することができます。追加するコンテンツがアプリの機能を明確に説明し、潜在的な質問に対応することで、アプリが自社の事業に適しているかどうかを各企業が迅速に判断できるようにします。詳細については、アプリリストのガイドライン
綴りと文法
掲載内容には正しい綴りと文法を使用する必要があります。対象の読者が読みやすく理解しやすいものにします。
すべきこと すべきではないこと 正しい綴りと文法が使用されているか見直します。 リンクが有効な URL に繋がることを証明します。 入力ミスや文法上の間違いが含まれた掲載内容を提出しないでください。 期限切れのコンテンツや関連性のないコンテンツへのリンクを含めないでください。
アプリ名
すべきこと すべきではないこと 名前のみを入力します。「例: HelpTable」 アプリの掲載とアプリのマニフェストで同じ名前を使用します。 「Stripe」、「app」、「RAK」、「Generator」、「API Key」、「Authenticator」、「free」、「paid」を「HelpTable app」などのようにアプリ名に使うことはできません。 アプリのマニフェストと名前が異なる掲載を提出しないでください。
ロゴ
すべきこと すべきではないこと お客様独自のロゴをアプロードします。必ず、高品質の正方形のものを使用してください。 Stripe のロゴや名前を使用しないでください。 他の会社のロゴや名前を明示的な許可を得ずに使用したり、同意を得ずにアプリの承認を示唆するような方法で使用したりしないでください。 劣化した画像、引き延ばされた画像、要素が切り取られた画像などを提供しないでください。
副題
すべきこと すべきではないこと アプリが Stripe でどのように機能するかを簡潔にまとめます。「例: Stripe ダッシュボードで顧客のサポート履歴を表示および編集します。」 誇張、マーケティング専門用語、キーワードの詰め込み、または証明できない主張を使用しないでください。「例: 世界最高のサポート製品。」
カテゴリー
すべきこと すべきではないこと アプリの主要機能に該当するカテゴリーを選択します。 アプリに該当しないカテゴリーや、ごく部分的にしか該当しないカテゴリーを選択しないでください。
説明
すべきこと すべきではないこと 貴社の業務内容、アプリの対象ユーザー、アプリがもたらす価値について簡単に説明します。貴社のサービスを簡単に紹介したあとで、Stripe アプリを具体的かつ簡潔に説明するのが理想的です。(例: 「HelpTable は、変化の目まぐるしいスタートアップ向けに設計されたシンプルなサポート管理システムです。アプリをインストールすると、Stripe 内のあらゆる顧客のサポート履歴に簡単にアクセスでき、製品とサービスに関する顧客体験の全体像をつかめます。また、Stripe ダッシュボードで直接サポートチケットを表示して管理することができます」) アプリに適用される可能性がある制限事項について説明します。 ビジネスの説明に焦点を置きすぎず、アプリに関する機能の説明を省略せずに記載してください。
機能のハイライト
すべきこと すべきではないこと アプリの主な機能の概要を 1 ～ 3 つ強調し、ユーザーがアプリの内容を簡単に理解できるようにします。 機能のタイトルにはシンプルな言葉を用いて機能の価値を表現します。「例: Stripe でチケットを解決」 機能の説明で、機能がどのように作用しユーザーの役に立つかを説明します。 機能の画像には、必ず高品質のものを使用してください。 アプリにない主要機能を強調しないでください。 スクリーンショットや画像で、実際の顧客データは使用しないでください。 劣化した画像、引き延ばされた画像、歪んだ画像、要素が切り取られた画像などを使用しないでください。
重複しないこと
各アプリはマーケットプレイスに 1 回のみ掲載できます (別名でも重複は不可)。アプリの新しいバージョンを送信する際は、前のバージョンと同じアカウントから行ってください。これができず、サポートが必要な場合は、Stripe サポート
すべきこと すべきではないこと 同じアプリケーションがすでに自分または他者によってアップロードされていないかを確認する。 同じアプリを複数回提出しないでください。具体的には、別の名前で、別のカテゴリーで、または別のアカウントから同じアプリケーションをアップロードするなどです。
アプリの UI 拡張機能 アプリに UI 拡張機能が含まれている場合、ユーザーはアプリドロワーで、アプリの詳細確認などのさまざまなアクションを取ることができます。Stripe ユーザーは、Stripe ダッシュボード全体で一貫した操作性を期待しており、これにはアプリとの連携も含まれます。アプリを通じたワークフローは、直観的かつ自然である必要があります。Stripe ダッシュボードに適していると考えられるアプリの例については、設計ガイドラインをご覧ください。
アプリのインストール
アプリで認証が必要な場合には、適切なユーザーに対してインストール後に認証を行うよう明確に指示します。アプリでは、Stripe ダッシュボード UI から認証を解除するための明確な手順も示す必要があります。
すべきこと すべきではないこと ユーザー認証の明確な手順を示します。ユーザーがアプリをインストールしたら、アプリドロワーで認証を完了するための明確なプロンプトまたはトリガーを提供します。 設定ページまたはアプリドロワーで Stripe アカウントのアプリプラットフォームとの関連付けを解除するための明確なパスを提供します。 アプリの設定でアカウント全体の認証を設定するように、管理者を誘導しないでください。 アプリが、アカウント全体ではなくユーザーを個々に認証する場合には、アプリドロワーからユーザーごとの認証のプロンプトを表示しないでください。
情報とアクション
アプリは、状況に応じた情報やアクションを提供し、Stripe でのユーザーのワークフローに付加価値をもたらします。
すべきこと すべきではないこと Stripe 内でユーザーのワークフローに関連する、該当情報とアクションを提供します。 ディープリンクは、詳細なワークフローの参照に役立てるために、サードパーティーのサービスにリンクする際のみに使用します。 アプリは、Stripe 内でユーザーに具体的な価値を提供する必要があります。単にサードパーティーの Web サイトへユーザーを呼び込みむために使用しないでください。
ナビゲーション
アプリドロワーではいつでも、現在の位置や移動できる場所、元に戻る方法や終了する方法をユーザーが理解できるようにします。
すべきこと すべきではないこと ユーザーがアプリ内を簡単に移動できるように、明確なナビゲーションコンポーネントを提供します。 行き止まりやループを発生させないでください。「たとえば、ユーザーがワークフローを中断する必要がある場合、その場から離れられるように、キャンセル や戻る ボタンを提供してください。」 ナビゲーションの除外やユーザーの足止め、またはナビゲーションに負荷をかけすぎることがないようにします。「たとえば、ユーザーがワークフローの途中で終了する必要がある場合に、キャンセル や戻る ボタンを提供してください。」
ボタンとリンク
事前の知識がなくても、ユーザーが各ボタンやリンクの機能をすぐに理解できるようにしてください。
すべきこと すべきではないこと ボタンやリンクに明確なラベルを付けてください。 外部のリンクを示すには、外部のアイコン 「こちら」という言葉をリンクにせずに、必ず場所を説明してください。
通知とダイアログ
通知とダイアログの使用は、アプリ内で重要な情報または状況に即した情報を提供する場合に限定してください。
すべきこと すべきではないこと ユーザーの注意を必要とする重要な情報がある場合に通知を提供します。 簡単に元に戻せない、費用のかかるアクションや破壊的なアクションには、確認のダイアログを表示します。 関連性のない情報や、アップセル目的の通知は表示しないでください。このようなタイプのメッセージはスパムのように感じられ、アプリと Stripe へのユーザーの印象を損なう可能性があります。 明確に確認することなく、ユーザーが費用のかかるアクションをとってしまうことがないようにします。
状態
アプリは、エラー状態、読み込み状態、およびエッジケースに対して配慮された解決策を提供する必要があります。
すべきこと すべきではないこと エラー状態、読み込み状態、およびエッジケースに対して配慮された解決策を提供します。「たとえば、ユーザーがアプリドロワーでフォームを入力している際にエラーがあれば、ユーザーが送信 を押した時点で通知します。」 エラーメッセージを明確に強調し、「国名を選択してください」など、解決策を直接説明します。 うまくいかない場合のシナリオも考慮します。 ユーザーを立往生させたり、対応がわからないエラー状態を発生させたりしないようにしてください。「たとえば、ユーザーがワークフローで次へ をクリックしても何も起こらない、またはエラーが発生してもメッセージが表示されないためにその解決策がわからない、といった状況です。」
UI のエラー処理
アプリは、エラーを適切に処理して、明確かつ実用的なエラーメッセージをユーザーに送信する必要があります。問題が発生していないかアプリを監視してください。
すべきこと すべきではないこと 提供されたコンポーネントとパターンを使用して、ユーザーにエラー通知を表示します。 問題を明確に説明するエラーメッセージになるようにし、ユーザーにアクション可能な次のステップを案内します。 エラーが発生していないかアプリを監視して、ユーザーに問題が起こったときに把握できるようにします。 「問題が発生しました」というあいまいなエラーメッセージを表示しています。 ユーザーにメッセージを送信せずにエラーを受け入れます。 エラーをキャッチして、技術職でないユーザーに何も表示せずにそのエラーをコンソールのログに記録します。
アプリの設定 ユーザーは Stripe のダッシュボード内でアプリの設定に移動できます。
認証設定
アプリが Stripe 以外のサービスへの認証を必要とする場合、またはアプリユーザーの代理で認証情報を保存する場合、アプリの設定で、再認証やログアウトの方法を提供する必要があります。
すべきこと すべきではないこと アプリがサービスまたはサードパーティーへの認証を必要とする場合、再認証と認証解除の両方の方法を用意してください。 アプリが複数のサービスで認証する場合は、各サービスが個別に認証解除および再認証できることを確認してください。 ユーザーが変更を保存するための、1 つの明確な方法を提供します。 アプリで認証が必要な場合には、認証設定を省略しないでください
ラベルと説明
アプリ設定には、ユーザーがアプリ内を簡単に移動して理解できるようにする、ラベルと説明を含める必要があります。
すべきこと すべきではないこと ユーザーが理解しづらくなるようなラベルを設定しないでください。 設定の説明を省略しないでください。
必須とオプションの設定
アプリでは、どの設定が必須で、どの設定がオプションかを明確に示す必要があります。
すべきこと すべきではないこと 必須フィールドには必須であることを明記してください。そうしないと、アプリが適切に機能しない理由をユーザーが理解できなくなります。
設定の保存
アプリの設定には、変更内容を保存するための明確な方法が必要です。
すべきこと すべきではないこと ユーザーが変更を保存するための、1 つの明確な方法を提供します。 変更内容を保存する方法を省略しないでください。 ページ内で、複数の保存パターンを使用しないでください。
変更の確認
アプリの設定を変更した後には、保存されたことを確認するメッセージが必要です。
すべきこと すべきではないこと 設定の変更が保存されたら、確認メッセージを表示してください。 確認メッセージを省略しないでください。 確認メッセージを表示せずに変更できないようにします。
コンポーネント Stripe の UI コンポーネントをアプリ (特に拡張可能なアプリドロワーとアプリ設定ページ) に使用します。これにより、アプリを Stripe ダッシュボードの一部のように使用できます。
すべきこと すべきではないこと UI コンポーネントを使用してアプリを構築します。 提供されたフォント、アイコン、フォームフィールド、およびカラースキームのみを使用し、ダッシュボードとの一貫性を保ってください。 他の設計システムからの様式化されたコンポーネントを使用しないでください。 コンポーネントをカスタマイズしたり、ブランド化したりしないでください。
視覚素材
アイコン、画像、イラストを使用し、アプリのフローや機能をユーザーが簡単に理解できるようにします。
すべきこと すべきではないこと 視覚素材 (アイコンやイラスト) を使用して、ユーザーがアプリや特定の機能の使い方を理解できるようにします。 高品質の視覚素材を使用します。 装飾のみを目的とした視覚素材は使用しないでください。 劣化した品質の視覚素材は使用しないでください。
ドロワーアイコン
アプリに UI コンポーネントがある場合には、ユーザーがアプリをインストールした後に、それが Stripe ダッシュボードのアプリドロワーに表示されます。アプリのマニフェストに高品質のアプリアイコンを含め、ドロワーにアプリのアイコンが正しく表示されるようにしてください。
すべきこと すべきではないこと アプリのマニフェストに高品質のアイコンを含めます。 アプリのマニフェストからアイコンを省略しないでください。 アプリのマニフェストに低品質のアイコンを含めないでください。
アプリのコンテンツ アプリ全体に明確で一貫したコンテンツを提供します。ダッシュボードの他の部分と一貫した明確な、表現、語句、文法を使用します。
態、トーン、文法、スタイル
すべきこと すべきではないこと わかりやすい記述を心がけ、簡潔かつ具体的な文言を使用します。(例:「ダッシュボードの機能をお試しください」) 能動態を使用します。(例:「カードリーダーを注文します」) 行動喚起 (CTA) にはシンプルな動詞を使用します。対象が明確な一般的なアクションにおいては、主語を省くことができます (「サブスクリプションを作成する」など)。 効率とスペースのために数字を使用します (「審査が必要なチケットが 3 件あります。」など) 企業特有の口調や専門用語を使用しなでください (「このプログラム化されたソフトウェアを活用します。」など)。 不自然な受動態を使用しないでください 。(例: 「カードリーダーは注文されることができます」) UI が英語の場合、代名詞、形容詞、副詞などのフィラーワードや、不定冠詞 (「a」、「an」または「the」など) を使用しないでください。(例: 「Create a subscription」や「Create your subscription」ではなく、「Create subscription」) 強調のために必要である場合を除き、数値には算用数字を使用します (「この問題を解決するには、2 つの方法があります」など)。
センテンスケース (先頭の 1 文字を大文字)
すべきこと すべきではないこと 見出しとボタンを含むすべてのコンテンツにセンテンスケース (先頭だけ大文字) を使用します。(例:「Add bank account」 、「Create subscription」 ) 効率とスペースのために数字を使用します (「審査が必要なチケットが 3 件あります。」など) 固有名詞、頭字語、または文章の最初の文字でない限り、大文字は使用しないでください。(例: 「Add Bank Account」)
句読点
すべきこと すべきではないこと 本文には句点を使用します。これには、小見出し、説明、法的文章、ツールチップが含まれます。句点は、引用符の後ではなく、内側に使用します。 タイトルや見出し、またはメニューラベルやボタンなどのクリックする項目への句点の使用 (たとえば、「もっと知る」リンクの後に句点を使用するなど)。
日付形式
すべきこと すべきではないこと 日付には次の形式を使用してください: 英語で月名を短縮する際には、ピリオドを使用せずに 3 文字の短縮形を使用します (「Jan、Feb、Mar、Apr、May、Jun」など)。月、日、年を記述する際には、日と年の間にカンマを使用します (「January 3, 2021」や「Jan 3, 2021」など)。月と年のみの場合には、カンマは使用しません (「January 2021」や「Jan 2021」など)。 英語で月名を短縮した場合には、ピリオドを使用しないでください。 日付には序数 (1st、2nd、3rd など) を使用しないでください。
時間形式
すべきこと すべきではないこと 時間には次の形式を使用してください: 12 時間制を使用します。大文字を使用して午前を (AM) 、午後を (PM) で示し、数字と AM または PM の間にスペースを入れます。分には 2 桁の形式を使用します。(例: 「3:25 PM」や「10:00 AM」) 24 時間制は使用しないでください。 12 時間制で、AM や PM を省略しないでください。
アプリの機能 アプリは、明確かつ便利で、信頼できるものである必要があります。
有用性
Stripe App Marketplace は、ビジネス間 (B2B) のエコシステムです。マーケットプレイスのアプリは、Stripe ユーザーのビジネスアクティビティーを明確に実現または向上する機能を提供する必要があります。
すべきこと すべきではないこと ユーザーがビジネスをより効率的かつ効果的に遂行できるようにするアプリを提供します。 コンテキスト上の情報やアクションを提供します。Stripe におけるユーザーのワークフローに付加価値をもたらすものにします。ディープリンクは、詳細なワークフローの参照に役立てるために、お客様のサービスにリンクする際のみに使用します。 補完的で重複のない機能を提供します。アプリは、ユーザーにとって有益であり、Stripe でのワークフローを補強する新しい独自の機能を提供するものである必要があります。 ゲームやクイズ、クリックベイトなどの、消費者向け、またはソーシャルアプリは構築しないでください。 アプリは、Stripe 内でユーザーに具体的な価値を提供する必要があります。単に自社のサービスへユーザーを呼び込みむために使用しないでください。ディープリンクは、コンテキスト上の情報やアクションより優先されるべきではありません。
計算とデータ視覚化の正確性
アプリケーションによって実行されるすべての計算は正確で信頼できるものでなければなりません。アプリによって提示されるすべてのデータや視覚化された情報は正確かつ完全でなければなりません。
すべきこと すべきではないこと 財務的に正確な結果を得るために必要なすべての関連情報とデータがある場合にのみ、価値のある計算データをユーザーに提示します。「例: すべての関連情報とデータを含む正確な残高合計。」 結果を正しく計算するための十分な情報がない場合、不確実な情報をユーザーに提示しないでください。「例: 適切な税種別を指定せずに税額を計算する。」 正しく計算するために必要なすべてのデータがない場合、不正確な情報をユーザーに提示しないでください。
決済処理
Stripe による書面の許可がない限り、アプリの主要機能によってトリガーされる決済は、Stripe で処理する必要があります。
すべきこと すべきではないこと アプリ内で必要な決済処理には Stripe を使用してください。 Stripe をバイパスして、アプリで外部の決済代行業者を使用することはできません。
テストのガイダンスとテスト用認証情報 アプリの審査時は、Stripe はテストのガイダンスとテスト用認証情報を使用して、アプリの安定性、コンポーネントの使用状況、ユーザー体験を審査します。お客様は以下の情報を提供する必要があります。
テストのガイダンス : アカウント登録プロセスなど、アプリの主要機能をすべて網羅した複数のユーザーシナリオまたはユースケースを含めます。
テストアカウントのテスト用認証情報 : Stripe がアプリのインストールと利用に使用できるように、1 つ以上のテスト用認証情報を含めます。アプリを使用するためにテストアカウントに特定のデータ (CSV ファイルなど) が必要な場合は、アカウントに含める必要があります。
注意 Stripe では、アプリの審査プロセスに実際の (テスト用ではない) アカウントを使用することを許可していません 。テストの目的で特定のアカウントへのアクセスを提供する他の方法が必要な場合は、Stripe サポート
すべきこと すべきではないこと アプリをテストするために必要な詳細な手順を提供します。 Stripe に表示される、想定される動作の詳細を提供します。 必要に応じて、テストアカウントごとのサンプルデータを提供します。 ビジネスを正確に表すアカウントのテスト用認証情報を提供します。 アプリの一部でテストするために有料アカウントが必要な場合は、有料アカウントのテスト用の認証情報を指定します。 アプリ内で最も権限が高い役割によるアクセスを対象に、テスト用の認証情報を指定します。(例: 「管理者」) システム内のユーザーの役割が、Stripe ダッシュボード UI でのさまざまな要素のレンダリングにどのように影響するかについて、詳細を提供します。(例: 「管理者」、「表示のみ」) アプリを Stripe と連結する手順を詳しく説明します。 データの同期が必要なアプリの場合は、必要なデータを同期する手順とデータが正確であることを確認する手順の両方を提供します。 本番データ (取引など) が必要なアプリの場合は、そのデータを表示するための手順を詳しく説明します。 地域に固有の制限や地理的な制限があるアプリの場合、どの地域がサポートされているか、さらに、アプリの最新バージョンがインストールされた Stripe アカウントのテスト用認証情報に関する詳細を提供します。 多要素認証を無効にするか、審査担当者が認証情報を渡すための手順を提供します。 審査担当者が「理解するだろう」と期待しないでください。
Stripe with Google Sheets などのサンプルアプリのテスト用認証情報の例を以下に示します。
テスト用アカウント名 ユーザー名 パスワード Google スプレッドシート teststripeapps@stripe.teststripeappsStripe teststripeapps@stripe.teststripeapps
Stripe with Google Sheets などのサンプルアプリのユーザーシナリオの例を以下に示します。
ユーザーシナリオ ステップごとの手順 ユーザーとしてサインインする Stripe App Marketplace からアプリをインストールします。 アプリを開きます。 サインイン ボタンをクリックします。Google のテスト用認証情報 (以下で提供) を入力します。 Google アカウントへのアクセス権をアプリに付与します。 アプリにサインインした Stripe ダッシュボードに戻ります。ダッシュボード内のアプリで Google スプレッドシートのサービスを利用できるようになります。 Stripe から Google スプレッドシートにデータをエクスポートする ダッシュボードの決済ページまたは顧客ページに移動します。 ダッシュボードでアプリを開きます。 アプリドロワーで、データをエクスポートするボタンをクリックします。 フォルダーを選択します (オプション)。 データを保存します。データは CSV として Google Drive アカウントで使用できるようになります。
広告なし
アプリには、バナー広告を表示することはできません。
すべきこと すべきではないこと アプリは加盟店に提供する主要価値を重視する必要があります。 何らかの広告を含める (自社の広告または表示広告サービスからの広告)。 今後のリリースの予定を含めないでください。
完全に機能しバグがない
アプリは、完全で洗練され、明らかなバグがないものにする必要があります。バグには、接続できないリンクも含まれます。
すべきこと すべきではないこと アプリが完全に機能するようになってから提出する。 複数のシナリオであらゆるテストを行う。 審査のためにアプリを提出する前に、見つけたバグをすべて修正する。 アプリ内のリンクがすべて有効な URL に繋がることを確認する。 何の機能もないボタンや、未完成のビューなどを残しておかないでください。 既知のバグやクラッシュがあるアプリを公開しないでください。 存在しないページ (404) やエラーメッセージが表示されるページへのリンクを含めないでください。
権限
アプリのマニフェストには、アプリを機能させるために最低限必要な権限を含める必要があります。アプリが、権限をリクエストしていない API コールを試みることはできません。
すべきこと すべきではないこと アプリのマニフェストファイルで、アプリに必要なすべての権限を宣言する。 アプリがアクティブに使用しない権限をリクエストしないでください。 権限をリクエストしていない API コールを試みないでください (コールが失敗するだけでなく、ユーザーの機能操作に悪影響を及ぼします)。
対応処理が必要な変更
バージョン間で、アプリがシームレスに機能するようにしてください。アプリで、アップグレード時にユーザーの対応が必要になる変更が起こらないようにしてください。そのような変更はビジネスの中断を引き起こすことがあります。ユーザーの対応が必要になる変更がある場合には、リリースノートやその他の該当するチャネルでユーザーに明確にその旨を伝える必要があります。
すべきこと すべきではないこと ユーザーの介入を必要とせずに、バージョンのアップグレードを自動的に行うことができるような形式でアプリを進化させてください。 新しい機能が設定されなかった場合でも、アプリが適度に機能するようにしてください。 バージョン間のアップグレードパスをテストし、ユーザーのアップグレードプロセスが正確に反映されていることを確認します。 構成が終わるまでアプリが機能しなくなるような、新しい必須の設定を追加しないでください。
プライバシーとセキュリティ データの使用
アプリは、ユーザーに明確に伝えた、既存のアプリ機能に必要なユーザーデータと API のみを使用できます。アプリを通じて Stripe ユーザーから入手したデータを転売したり公開したりすることはできません。
すべきこと すべきではないこと アプリが機能するために必要なデータのための、適切な範囲の権限をリクエストする。 ユーザーのデータをどのように使用するかをユーザーに説明する。 データを使用する際には、プライバシーポリシーに従って使用してください。 将来使用する予定のデータの権限をリクエストしないでください。 アプリに「隠れた」機能を作成したり、アプリの「隠れた」機能に使用するデータの使用許可をリクエストしないでください。 特定のアプリ機能のためにユーザーからデータを収集し、データの用途を開示することなく他の目的に使用しないでください。 アプリを通じて入手したデータをまとめ、そのデータが含まれるデータセットを販売しないでください。
コードの判読性
難読化されたソースコードを含む UI 拡張機能を提出しないでください。難読化は、悪意のあるコードを隠ぺいするために一般的に使用される方法です。縮小化は受け入れられている方法であり、推奨されています。
すべきこと すべきではないこと 明解な形式でコードを記述する。 構築プロセス中に、コードを縮小化する。 構築プロセス中に、難読化ツールでコードを処理しないでください。
外部エンドポイント
アプリに UI 拡張機能がある場合、その UI 拡張機能が通信するすべての外部エンドポイントをアプリマニフェストで宣言する必要があります。アプリがマニフェストで宣言されていない外部エンドポイントと通信しないようにしてください。
すべきこと すべきではないこと マニフェストファイルで、すべての外部エンドポイントを宣言する。 マニフェストファイルで宣言していないエンドポイントから API コールを実行したり、リソースを読み込んだりしないでください (リクエストは失敗し、アプリは同様のアクティビティーの監視対象となります)。
機密
UI Extensions に必要とされるシークレットマテリアルは、Secret Store API
すべきこと すべきではないこと サービスをさまざまなブラウザーで一貫して安全に認証できるように、ユーザーの OAuth トークンを Secret Store に格納します。 機密情報の保存には、Cookie、ローカルストレージ、または Stripe メタデータを使用しないでください。 ユーザーの設定など、機密情報ではない情報を Secret Store API を使用して格納しないでください。
API コールの成功率
アプリでは一貫して信頼性が高く、正常に実行される API コールを行うようにします。Stripe では、インストールされたすべてのアプリの API コールの成功率を監視します。
API コールの遅延
アプリで行われる API コールは、一貫して遅延が少なくなるようにします。Stripe では、インストールされたすべてのアプリの API コールの遅延を監視します。
ヘルプとサポート ドキュメント
アプリには、適切に作成され、公共のインターネットでアクセス可能なドキュメントが用意されている必要があります。
すべきこと すべきではないこと ユーザーのアプリへの理解を深めて有益に使用するための、包括的なドキュメントを作成する。 ドキュメントを自社の Web サイトでホストする。 ヘルプとサポートのために、ドキュメントにユーザーを誘導する。 「準備中」のドキュメントページにリンクしないでください。 アプリの機能の大部分に関する説明がないドキュメントページにリンクしないでください。
サポート
ユーザーに向けて、明確で簡単にアクセスできるサポート手段を提供する必要があります。少なくとも、サポート問い合わせ用のメールアドレスを提供し、回答までの予想時間を示す必要があります。
すべきこと すべきではないこと サポート用のメールアドレスを、明確な SLA とともに提供する。 チャットやフォーラムなどの、他のサポート手段を提供する。 サポート用として対応者が存在しない「ブラックホール」メールアドレスを指定しないでください。 サポートの問い合わせを不定期に確認し、回答までに数日または数週かけることがないようにしてください。
法令順守 知的財産
使用許可を持つ資産や製作品のみを使用します。他の人の知的財産を侵害しないでください。
すべきこと すべきではないこと 自作したか、商用ライセンスを取得したコード、画像、その他の資産を使用する。 適切に所有者を表記せずに、または許可を得ずに、他の人のコードをコピーしないでください。 ライセンスから外れた方法でオープンソースコードを使用しないでください。 許可を得ずにインターネットの写真を使用しないでください。
データの地域
データの地域管理および該当する法管轄の法律に準拠する責任があります。詳細については、Stripe 開発者利用規約 Stripe App Marketplace 利用規約
迷惑メール防止
ユーザーに対して迷惑メールを送信することはできません。Stripe の迷惑メール防止ポリシーに従い、ユーザーとの通信のすべてが、ユーザー自らがオプトインした妥当性のあるものであり、適用されるメール通信法に準拠したものであることを確認する責任があります。Stripe ユーザーの連絡先情報をサードパーティーに販売することはできません。
輸出管理と暗号機能
アプリのコードは、該当するすべての輸出管理法に従う必要があります。特に、アプリにカスタムの暗号機能を含めることはできません。これは、International Traffic in Arms Regulations (武器に関する国際取引規則)
すべきこと すべきではないこと 標準ライブラリーに組み込まれている暗号化機能を使用します。 一般に知られたオープンソースライブラリーからの、適切な審査が行われた暗号機能を使用する。 独自の新しい暗号化機能を記述し、それを UI 拡張機能のソースコードに含めないでください。
不正活動
アプリは、不正活動に関与したり、不正活動を促進するものであってはなりません。
制限付き業種とアプリ
Stripe の禁止/制限付き業種
すべきこと すべきではないこと 禁止/制限付き業種 お客様のビジネスまたはアプリが、制限されている業種に該当するか、またはお客様のアプリは免許が必要な業種または規制を受けている業種に関連するものであると Stripe が判断した場合は、拡張審査プロセスを開始するために Stripe サポート 管轄区域でビジネスを行うためのすべての規制要件を満たしていることを確認してください。 審査を受けるためにアプリを提出し、Stripe と連携して審査プロセスを完了させてください。 必要なライセンスまたは承認がないのに、規制された業界でビジネスを運営していて、アプリを提出しようとした。 必要なライセンスまたは承認がないのに、制限付きの業種に関連する機能を搭載しているアプリを提出している。 お客様のビジネスとは関係のない情報を使用するアプリを開発するために、Stripe アカウントを作成している。
禁止業種
貴社または開発者は、Stripe の利用規約
制裁対象国
貴社または開発者は、禁輸措置やその他の制限
参照情報 