マーケットプレイス
マーケットプレイスのチェックアウトと決済操作を連携させ、同時に、買い手、注文、払い戻し、紛争、および調整のコンテキストを維持します。
マーケットプレイス決済フローは、買い手と単一の注文だけでなく、セラーのアイデンティティ、プロバイダーのオンボーディング、商業的な所有権、分割または支払いに関する動作、部分的な履行、払い戻し、紛争、保留金、および財務的な調整にも依存します。
まず、運用モデルを定義してください#
統合を選択する前に、以下の点を確認してください:
- 買い手の取引の取引先は誰ですか？
- セラーは共有された処理アカウントを使用しているか、個別にオンボーディングされたアカウントを使用しているか？
- 手数料、セラーの金額、税金、保留金、および支払いに関する計算は、どのシステムで行っていますか？
- 必要な分割、転送、サブ・マーケットプレイス、または支払い操作をサポートするプロバイダーとアカウントは？
- 払い戻し、紛争、負の残高、およびセラーの決済調整に関する所有権は誰ですか？
DEUNAの公開注文および決済契約は、すべてのプロバイダーが分割処理または支払い機能をサポートすることを意味しません。技術アカウントマネージャーは、サポートされている接続、アカウントモデル、操作、認証情報、および決済に関する動作を確認する必要があります。
マーケットプレイスのコンテキストを維持#
| コンテキスト | 実装に関するガイダンス |
|---|---|
| 買い手注文 | 不変の商社注文参照とDEUNA order_token. |
| セラー | サポートされている商社フィールドまたは名前空間されたメタデータで、安定した、機密性のないセラー参照を使用します。 |
| 商品と履行 | セラー、出荷、キャンセル、および払い戻しの関係を、記録システムに保持します。 |
| 決済試行 | すべてのルート、再試行、キャプチャ、払い戻し、および不確実な結果を、元の注文に関連付けます。 |
| 財務操作 | プロセッサの決済、マーケットプレイスの会計帳、セラーの義務、手数料、保留金、払い戻し、および紛争の証拠を調整します。 |
部分的な操作を意図的に設計#
複数のセラー、出荷、キャプチャ時間、キャンセル、および払い戻しを含む注文をテストします。部分的なキャプチャまたは払い戻しは、アカウントで有効になっている操作とプロバイダーの機能内に存在する必要があります。未知の決済結果から回復するために、別の注文を作成しないでください。
リスク統合でセラーのコンテキストを受け入れる場合、選択したプロバイダーがサポートするフィールドのみを使用し、 不正防止接続。プロバイダーの認証情報や不要なセラーの個人データをメタデータを通じて送信しないでください。
APIと顧客アクションのライフサイクルを実装するために、 プロバイダー機能, キャプチャと払い戻し, 紛争管理, および 支払い照合.