IOSOR ガイド
エンドユーザーの送信は引き続き単一のプリペイド元帳から引き落とされます
埋め込み送信は引き続きISVのプリペイドウォレットを減額します。製品が資金調達していない第2の元帳を捏造しないでください。保留、再試行、冪等性は正確に保たれます。
組み込みメッセージングはエンドユーザーにとって無料で提供されているように見えます。SaaS UI内で「送信」をタップすると、緑色のチェックマークが表示されます。しかし内部では、送信が成功するたびにISVが所有する単一のプリペイド元帳から残高が引き落とされています。APIを組み込んだからといって、2つ目のウォレットが自動的に生成されるわけではありません。ISVが保留分の資金をチャージしていない場合、送信は偽の配信完了状態ではなく、正確な製品エラーとして失敗する必要があります。
架空の会計処理は典型的な障害パターンです。IOSORウォレットに裏付けられていないアプリ内クレジットメーター、プリペイド元帳が消費されている最中のSaaS側での返金、または1つのOTPに対して二重引き落としが発生する冪等性のない再試行などが該当します。組み込み処理によって管理コンソールは隠蔽されますが、資金を負担するのは依然としてISVです。
アーキテクチャの基本原則:エンドユーザーの送信 ≡ ISVプリペイドの引き落とし。すべての設計レビューはこの原則から始まります。
UIに製品クレジットが表示されていても、元帳は常に1つです
テナントに販売されるメッセージパックはISVの商用レイヤーにすぎません。これらは、ISVが資金を供給する単一のIOSORウォレット上のプリペイド保留および引き落としにマッピングされる必要があります。元帳の行と照合できないテナント残高は、将来的にサポート上の大きな負担となります。財務部門が製品側と同じ消費状況を把握できるよう、テナントの使用状況を毎週エクスポートしてウォレット明細と照合してください。
パートナーとしての完全分離が明示的な契約でない限り、テナントごとに2つ目のIOSORアカウントを開設しないでください。埋め込み型のパイロット運用では、ほぼ常に内部のフェアシェア上限を設定した1つのISVアカウントが使用されます。
埋め込みパスでも保留と冪等性は引き続き適用されます
サーバー側の送信処理では、OTPおよびトランザクションSMSに対して冪等性キーを使用する必要があります。SaaS UI上でのダブルクリックによって、単一のユーザー操作に対して2回の引き落としが発生してはなりません。タイムアウト後の再試行は、最終的なDLR(配信レポート)またはマッピングされた失敗が返されるまで、同じキーを追跡する必要があります。
ウォレットで資金の保留ができない場合は、残高不足または送信停止を示す製品固有のステータスを返してください。保留に失敗した際に、配信成功を意味するHTTP 200を絶対に返さないでください。
製品エラーを元帳の真実にマッピングする
| SaaS UIシグナル | 元帳の実態 | 許容される次のステップ |
|---|---|---|
| 送信済み / 配信済み | 引き落とし + DLRパスが存在 | 領収書IDを表示 |
| キュー投入済み | 保留処理中または送信受理 | ステータスをポーリング |
| 失敗 / 停止 | 保留拒否または停止ゲート | 新しい意図でのみ再試行 |
| 偽の成功 | 引き落としなし / 保留なし | 厳格に禁止 |
サポートチームに対して中央の列に基づいた運用教育を行ってください。元帳の明細がないにもかかわらずUI上に緑色の成功が表示されているといったチケット対応は、パイロット検証の貴重な時間を浪費します。
チャネルの引き継ぎは同じウォレット内に留まります
将来的にSMSに加えてEメールや音声チャネルを追加する場合でも、財務部門の承認を得て第2チャネルの引き継ぎを行わない限り、支出は同一のプリペイド元帳に記録されます。埋め込みによって無料のサイドチャネルが作成されることはありません。SaaS設定で別のライブタイルを有効にする前に、ウォレットの隣接性に関するドキュメントを確認してください。
関連する運用パス
IOSORで始める
IOSOR コンソールを開き、テナントのクレジットシステムをプライマリプリペイドウォレット元帳に直接マッピングします。マスターウォレットへのホールドを実行する前に、すべてのサーバーサイド埋め込みリクエストが決定論的なべき等キーを渡すことを確認してください。Webhook エンドポイントを設定して受信 DLR を処理し、オープンのホールドが最終的な元帳の引き落としまたは解放としてクリーンに解決されるようにします。
IOSORの要点
埋め込み型 SaaS インターフェイスはエンドユーザーにカスタムメッセージクレジットを提示できますが、実際の送信はすべて、ISV が資金を提供している単一のプリペイド元帳に結び付けられます。リトライ、チャネルの拡張、ユーザーのステータスシグナルは、裏付けのない UI の抽象化ではなく、ウォレットのホールドに対して直接突合されなければなりません。
厳格なサーバーサイドのべき等キーを必ず適用し、すべてのテナント UI 状態を実際の元帳 DLR 応答にマッピングしてください。裏付けのないセカンダリウォレットを作成したり、具体的な元帳ホールドなしでテナント UI のリトライを実行させたりしないでください。
このガイドは役に立ちましたか?
関連ガイド
- API埋め込みとホワイトレーベル・パートナーポータルの比較
メッセージングを埋め込むSaaSプロダクトはISVサーフェス上に留まります。ホワイトレーベルのパートナーポータルはPartnerの下に配置し、ブランド、キー、運用所有権を混同しないでください。
- 組み込みテナント上限で送信を即座に停止すべき理由
ISV プロダクト内の公平な分配上限は、上限到達時に偽の API 200 配信成功を返さず、該当テナントの送信を確実にハード停止する必要があります。