決済モダナイゼーションソリューションアクセラレーター

支払いシステムのモダナイゼーション

決済システムのモダナイゼーションを推進する要因はいくつかあります。

• リアルタイム支払い: 顧客と組織は、支払いをすぐに処理されることを期待しています。

• 規制の変更: ヨーロッパの PSD2 のような新しいルールとルールは、よりオープンで柔軟な支払いシステムを後押しします。

• カスタマーの期待: 支払いプロセスをスムーズに、さまざまなプラットフォームに統合したいと考えています。

• オープン ブロッキング: オープン ブロッキングにより、金融セクターの競合性とイノベーションが実現し、新しい支払いサービスの開発が可能になります。

• 競合: Finders スタートアップは新しい支払いソリューションを提供し、従来の金融機関がシステムを更新するよう要求します。

モダナイゼーションの挑戦

決済システムの更新は、次の理由により困難です。

• 複雑なシステム: 支払いシステムには多くの異なる関係と規則が関係するため、変更は複雑になります。

• 古いテクノロジー: 古いシステムはイノベーションを遅くし、現在の標準を満たすことが困難になります。

• 高コスト：古いシステムのアップグレードには費用と時間がかかる場合があります。

• 技術的負債：システム設計における過去の手抜きが将来の成長と適応性を制限する可能性があります。

この例ソリューションでは、 MongoDBを使用して支払いシステムを最新化する方法を学べます。

モダナイゼーションへのアプローチ

ビジネスは、システムを更新する際に次の戦略を採用しています。

• ドメイン駆動型設計: システム開発をビジネス ニーズと整合性のあるものにすることで、ドメイン駆動型設計により、技術の変更がビジネス目的で使用されるようになります。

• マイクロサービス アーキテクチャ: 単調なアーキテクチャから マイクロサービス アーキテクチャに移行する ことで、システムの更新と増やすをより効率的にすることができます。

MongoDB がモダナイゼーションをサポートする方法

次のMongoDB機能は、支払いモダナイゼーションの作業をサポートします。

• 柔軟なドキュメントモデル: MongoDB のドキュメントモデル、新しい支払いタイプとデータ構造を組み込むことができ、システムがマーケットに合わせて変化することが保証されます。

• 運用データレイヤー: MongoDB、さまざまなサービスにわたるデータへのアクセスを簡素化する統合データレイヤーが導入されています。これは統合支払いソリューションを構築するために重要です。

• ベストプラクティスのサポート: MongoDB は、安全なトランザクションやリアルタイム分析など、業界のベストプラクティスに従うために必要なツールをビジネスに提供します。

マイクロサービスアーキテクチャ

マイクロサービス アーキテクチャは、大規模な単調アプリケーションを小さな部分に分割します。これにより、開発が迅速化、モジュール性、柔軟性とスケーラビリティ、回復力、組織の整合性、コストの削減 が可能になります。

このソリューションで使用されるマイクロサービス アーキテクチャは、次のサービスに分割されます。

• ユーザー管理

• Transaction Processing

• トランザクション履歴

• アカウントの調整

• 支払い検証

• レポート作成

• notifications

ユーザー管理

このサービスは、ユーザーとアカウントの相互作用を容易にします。以下の図は、アカウント作成のフローを示しています。

この図には、次のエンティティが含まれています。

• データエンティティ：ユーザーアカウント、支払方法、銀行口座

• 権限: ユーザーアカウント、支払い方法、金融アカウントの読み取り/書込み

• 入力: ユーザー情報、お支払い方法の詳細、銀行口座情報

• 出力：ユーザーアカウント作成確認、支払方法追加確認、銀行口座追加確認

図2。アカウント作成プロセス

このフローのアプリケーションは、 GitHubリポジトリで参照できます。

Transaction Processing

このサービスは、トランザクションの開始、完了、返金など、トランザクション関連の操作を管理します。以下の図は、トランザクションを開始するための主要なフローです。

この図には、次のエンティティが含まれます。

• データエンティティ： トランザクション、銀行口座

• 権限: トランザクションの読み取り/書き込み、銀行口座の読み取り

• 入力: トランザクションの詳細（金額、送信者、受信者など）

• 出力: 保留中、完了、失敗などのトランザクション ステータスの更新

このフローのアプリケーションは、 GitHubリポジトリで参照できます。

図3。トランザクションフロー

このマイクロサービスは、外部プロバイダーのトランザクションの管理も行います。例、ソリューションには、PayPal の支払いを受け取るユーザーのデモが含まれています。MongoDB の柔軟なスキーマにより、トランザクションを表すドキュメントのさまざまな変更が可能になります。

以下の図は、架空の PayPal トランザクションのプロセスを示しています。

図 4. 外部トランザクションフロー

トランザクション履歴

このサービスは、トランザクションのログとアーカイブを取り扱います。これには、次のエンティティが含まれます。

• データ エンティティ: トランザクション履歴、ユーザー アカウント

• 権限：トランザクション履歴の読み取り、ユーザーアカウントの読み取り

• 入力: ユーザー アカウント番号

• 出力: トランザクション履歴データ

GitHubリポジトリでは、これらのエンティティのアプリケーションを参照できます。

アカウントの調整

このサービスは、アカウントの詳細が最新であることを確認します。これには、次のエンティティが含まれます。

• データエンティティ：銀行口座、トランザクション

• 権限：銀行口座の読み取り/書き込み、トランザクションの読み取り

• 入力：トランザクションの詳細、銀行口座の詳細

• 出力：照合ステータス、調整後の口座残高

GitHubリポジトリでは、これらのエンティティのアプリケーションを参照できます。

支払い検証

このサービスはトランザクションの開始を処理します。以下の図は、サービスが支払いを処理した時点から始まり、支払いが承認されたか拒否されたかをユーザーに通知した時点で終了する支払い処理手順を示しています。

このサービスには、次のエンティティが含まれます。

• データ エンティティ: トランザクション、ユーザー アカウント、銀行アカウント

• 権限：トランザクションの読み取り、ユーザーアカウントの読み取り、銀行口座の読み取り

• 入力：トランザクションの詳細、ユーザーアカウント番号、銀行口座の詳細

• 出力: 検証ステータス（成功または失敗）

図5。決済処理フロー

GitHubリポジトリでは、これらのエンティティのアプリケーションを参照できます。

レポート作成

支払いデータのビューを作成するには、MongoDB Charts を使用できます。

これには、次のエンティティが含まれます。

• データエンティティ： トランザクション履歴、ユーザーアカウント

• 権限：トランザクション履歴の読み取り、ユーザーアカウントの読み取り

• 入力：ユーザーアカウント番号、レポート基準（日付範囲、トランザクションタイプ）

• 出力：生成された財務レポート

notifications

このサービスはMongoDB Change Streamsを使用して変更をユーザーに通知します。

これには、次のエンティティが含まれます。

• データエンティティ： ユーザーアカウント、トランザクション

• 権限: ユーザーアカウントの読み取り、トランザクションの読み取り

• 入力: ユーザーアカウントの詳細、トランザクションの詳細

• 出力：ユーザーへの通知とアラート

GitHubリポジトリでは、これらのエンティティのアプリケーションを参照できます。

ユーザー

usersコレクション内のドキュメントには次の構造があります。

{
    "_id": ObjectId,
    "username": String,
    "email": String,
    "password": String, // hashed
    "linkedAccounts": [
        {
            "accountId": String,
            "accountType": String,
            "externalDetails": {
                "apiEndpoint": String,
                "accessKey": String,
                "additionalInfo": String
            }
        }
    ], "recentTransactions": [
        {
            "transactionId": String,
            "date": Date,
            "amount": Number,
            "type": String, // e.g., 'debit', 'credit'
            "status": String // e.g., 'completed', 'pending'
        }
    ]
}

アカウント

accountsコレクション内のドキュメントは次の構造をしています。

{
    "_id": ObjectId,
    "userId": ObjectId,
    "accountNumber": String, // Encrypted
    "accountType": String,
    "balance": Number,
    "limitations": {
        "withdrawalLimit": Number,
        "transferLimit": Number,
        "otherLimitations": String
    },
    "securityTags": [String],
    "encryptedDetails": String
}

トランザクション

transactionsコレクション内のドキュメントは次の構造をしています。

{
    "_id": ObjectId,
    "account_id": ObjectId,
    "amount": Number,
    "date": Date,
    "type": String, // e.g., 'debit', 'credit'
    "status": String, // e.g., 'completed', 'pending', 'refund'
    "details": String, // Encrypted if sensitive
    "referenceData": {
        "sender": { ... },
        "receiver": { ... },
        "steps": [{ ... }],
        "relatedTransactions": [{ ... }],
        "notes": String,
        "reportingTags": [String]
    }
}

notifications

notificationsコレクション内のドキュメントは次の構造をしています。

{
    "_id": ObjectId,
    "relatedEntityId": ObjectId,
    "userIds": [ObjectId],
    "message": String,
    "createdAt": Date,
    "statuses": [
        {
            "userId": ObjectId,
            "status": String // e.g., 'unread', 'read'
        }
    ]
}

クロスマイクロサービス

• インデックスの作成とスケーラビリティ

• JSON schema validation

• 権限とデータの分離

• 監査

ユーザーおよびアカウントのマイクロサービス

• ドキュメントモデル: MongoDB の柔軟性を使用して、さまざまなアカウントとユーザー プロファイル用のユーザーとアカウント構造を作成します。

• Kafka Sink Connector : 外部ソースからのストリーム データ。

• トランザクション: アカウントとユーザー データはACID準拠で維持されます。

• 使用中の暗号化: ライフサイクル全体でデータを保護します。

• 全文検索 : アカウント ID とユーザー名を検索します。

支払いマイクロサービス

• 変更ストリーム : 支払いはイベント駆動型です。

• 時系列コレクション :時系列コレクションを使用して支払い履歴を保持します。

• 使用中の暗号化: ライフサイクル全体でデータを保護します。

通知マイクロサービス

• Apache Kafkaソース: Kafkaを使用して、外部システムとユーザーに通知をストリーミングします。

• 変更ストリーム : 変更ストリームは通知をキャプチャし、その後 Websockt によってプッシュされます。

レポート

• Atlas Charts : Atlas Charts を使用してデータを前処理および視覚化します。