Payments Modernization Solution Accelerator

Modernizing Payment Systems

Several factors are pushing the modernization of payment systems:

• Real-time payments: Customers and businesses expect payments to be processed immediately.

• Regulatory changes: New laws and regulations, like PSD2 in Europe, encourage more open and flexible payment systems.

• Customer expectations: People want payment processes to be smooth and integrated across different platforms.

• Open banking: Open banking makes the financial sector more competitive and innovative, allowing for the development of new payment services.

• Competition: Fintech startups offer new payment solutions, challenging traditional financial institutions to update their systems.

Modernization Challenges

Updating payment systems is challenging due to:

• Complex systems: Payment systems involve many different parties and regulations, making changes complicated.

• Old technology: Outdated systems slow down innovation and make it difficult to meet current standards.

• High costs: Upgrading old systems can be expensive and time-consuming.

• Technical debt: Previous shortcuts in system design can limit future growth and adaptability.

In this example solution, you can learn how you can use MongoDB to modernize payment systems.

Approaches to Modernization

Businesses are embracing the following strategies when updating their systems:

• Domain-driven design: By aligning system development with business needs, domain-driven design ensures that technology changes serve business goals.

• Microservices architecture: By transitioning from a monolithic architecture to a microservices architecture, you can update and scale your system more efficiently.

How MongoDB Supports Modernization

The following MongoDB features support payment modernization efforts:

• Flexible document model: MongoDB's document model allows you to incorporate new payment types and data structures, ensuring that your system can evolve with the market.

• Operational data layer: MongoDB introduces a unified data layer that simplifies access to data across various services, which is crucial for building integrated payment solutions.

• Support for best practices: MongoDB equips businesses with the tools they need to follow industry best practices, such as secure transactions and real-time analytics.

Microservices Architecture

A microservices architecture breaks large monolithic applications into smaller pieces. It allows for faster development, modularity, flexibility and scalability, resilience, organizational alignment, and reduction in cost.

The microservices architecture used in this solution is broken into the following services:

• User Management

• Transaction Processing

• Transaction History

• Account Reconciliation

• Payment Verification

• Reporting

• Notifications

User Management

This service facilitates user and account interactions. The diagram below shows the flow for account creation.

The diagram involves the following entities:

• Data entities: User Account, Payment Method, Bank Account

• Permissions: Read/Write on User Account, Payment Method, and Bank Account

• Inputs: User details, Payment method details, Bank account details

• Outputs: User account creation confirmation, Payment method addition confirmation, Bank account addition confirmation

Figure 2. Account creation flow

You can see an application of this flow in this GitHub repository.

Transaction Processing

This service manages transaction-related operations, such as initiating, completing, or refunding a transaction. In the diagram below, you can see the main flow for initiating a transaction.

This diagram involves the following entities:

• Data entities: Transaction, Bank Account

• Permissions: Read/Write on Transaction, Read on Bank Account

• Inputs: Transaction details, like amount, sender, and receiver

• Outputs: Transaction status update, like pending, completed, or failed

You can see an application of this flow in this GitHub repository.

Figure 3. Transaction flow

This microservice is also responsible for managing external provider transactions. For example, the solution includes a demo of a user getting a PayPal payment. MongoDB's flexible schema allows for variation in the documents that represent transactions.

The diagram below shows the process for the mock PayPal transaction.

Figure 4. External transaction flow

Transaction History

This service deals with transaction logging and archival. It involves the following entities:

• Data Entities: Transaction History, User Account

• Permissions: Read on Transaction History, Read on User Account

• Inputs: User account number

• Outputs: Transaction history data

You can see an application of these entities in this GitHub repository.

Account Reconciliation

This services verifies that the account details are up-to-date. It involves the following entities:

• Data entities: Bank Account, Transaction

• Permissions: Read/Write on Bank Account, Read on Transaction

• Inputs: Transaction details, Bank account details

• Outputs: Reconciliation status, Adjusted account balances

You can see an application of these entities in this GitHub repository.

Payment Verification

This service processes a transaction initiation. The diagram below shows the payment-processing steps, starting from when the service reacts to a payment and ending when it notifies the user about whether the payment was approved or rejected.

This service involves the following entities:

• Data entities: Transaction, User Account, Bank Account

• Permissions: Read on Transaction, Read on User Account, Read on Bank Account

• Inputs: Transaction details, User account number, Bank account details

• Outputs: Verification status (success or failure)

Figure 5. Payment processing flow

You can see an application of these entities in this GitHub repository.

Reporting

To create a view of your payment data, you can use MongoDB Charts.

This involves the following entities:

• Data entities: Transaction History, User Account

• Permissions: Read on Transaction History, Read on User Account

• Inputs: User account number, Report criteria (date range, transaction type)

• Outputs: Generated financial reports

Notifications

This services uses MongoDB Change Streams to notify the user of any changes.

This involves the following entities:

• Data entities: User Account, Transaction

• Permissions: Read on User Account, Read on Transaction

• Inputs: User account details, Transaction details

• Outputs: Notifications and alerts to users

You can see an application of these entities in this GitHub repository.

Users

Documents in the users collection have the following structure:

{
    "_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

Documents in the accounts collection have the following structure:

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

Transactions

Documents in the transactions collection have the following structure:

{
    "_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

Documents in the notifications collection have the following structure:

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

Cross Microservices

• Indexing and scalability

• JSON schema validation

• Permission and data segregation

• Auditing

User and Account Microservices

• Document model: Use MongoDB's flexibility to create user and account structures for different accounts and user profiles.

• Kafka Sink Connector: Stream data from external sources.

• Transactions: Keep account and user data ACID-compliant.

• In-use encryption: Protect your data throughout its lifecycle.

• Full-text search: Search for account IDs and usernames.

Payments Microservices

• Change streams: Payments are event-driven.

• Time series collections: Use a time series collection to hold payment history.

• In-use encryption: Protect your data throughout its lifecycle.

Notification Microservices

• Apache Kafka source: Use Kafka to stream notifications to external systems and users.

• Change streams: Change streams capture notifications, which are then pushed by Websockets.

Reports

• Atlas Charts: Use Atlas Charts to preprocess and visualize your data.