Payments Modernization Solution Accelerator

Use cases: Payments, Modernization
Industries: Financial Services
Products and tools: Atlas, Enterprise Advanced, Atlas Clusters, Change Streams, Atlas Search, Atlas Charts, Atlas Auditing and Enterprise Security, Kafka connector, Queryable Encryption, Time Series
Partners: Confluent (for Apache Kafka integration), AWS (for cloud infrastructure and services)

Solution Overview

Today's payment industry is changing fast. Businesses are working to offer instant, secure, and easy-to-use payment solutions. This need is driven by several factors, including new regulations, customer expectations, and competition. MongoDB gives financial services organizations a powerful tool for modernizing their payment systems efficiently.

Key Drivers for Modernizing Payment Systems

Several factors are pushing the modernization of payment systems:

Real-time payments: Customers and businesses now expect payments to be processed immediately, a trend seen worldwide.
Regulatory changes: New laws and regulations, like PSD2 in Europe, are encouraging more open and flexible payment systems.
Customer expectations: People want payment processes to be smooth and integrated seamlessly across different platforms.
Open banking: This new approach is making the financial sector more competitive and innovative, allowing for the development of new payment services.
Competition: Fintech startups are offering 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 them complex to change.
Old technology: Outdated systems can 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, we'll delve into modernization approaches and how MongoDB plays a pivotal role in this transformation.

Approaches to Modernization

To navigate the complexities of updating their systems, businesses are embracing innovative strategies:

Domain-driven design: This approach zeroes in on the core operations of a business to develop systems that are both scalable and easier to manage. By aligning system development with business needs, domain-driven design ensures technology serves strategic business goals.
Microservices architecture: Transitioning from a monolithic to a microservices architecture provides significant advantages. It introduces more flexibility and allows for quicker updates, facilitating agile responses to changing business requirements.

How MongoDB Supports Modernization

MongoDB is at the forefront of supporting modernization efforts, especially in the context of payment systems, through its comprehensive features:

Operational data layer: MongoDB introduces a unified data layer that dramatically simplifies access to data across various services. This streamlining is crucial for building coherent, integrated payment solutions.
Flexible document model: The platform's document model is perfectly suited to manage the intricate data typically found in payment systems. Its adaptability allows for the seamless incorporation of new payment types and data structures, ensuring the system can evolve with the market.
Support for best practices: With MongoDB, implementing essential payment processing features becomes more straightforward. From securing transactions to facilitating real-time analytics, MongoDB equips businesses with the tools needed to adhere to industry best practices efficiently.

Reference Architectures

This payments modernization solution accelerator will showcase how you can build an operational data layer (ODL) utilizing MongoDB to unlock the value of previously siloed payment data and power applications that can’t be served by existing systems. An ODL deployed in front of legacy systems can enable new business initiatives and meet new requirements that the existing architecture can’t handle – without the difficulty and risk of a full rip and replace of legacy systems. Below we show the architecture that can be built to achieve this.

Without Atlas: Self-hosted MongoDB/other DBMS deployment with manual scaling and management.
With Atlas: Fully managed MongoDB service, ensuring scalability, high availability, and security.

Below, you will find the architecture used to build this payment solution. To learn more about how it works with MongoDB, visit our Real-Time Payments page.

Data Model Approach

The following approach focuses on entities like User Accounts, Transactions, Bank Accounts, and Payment Methods, and their relationships. It includes data attributes for each entity ensuring comprehensive and detailed information covering each entity.

Microservices Architecture

A microservice architecture helps to break large monolithic applications into smaller pieces and provides you with the following benefits: faster time to market, modularity, flexibility and scalability, resiliency, organizational alignment, and reduction in costs. This is broken into the following:

User management (Github repo)

Facilitates the main operations around user/account interaction. In the diagram below, you can see the main flow for creating accounts.

Data Entities: User Account, Payment Method, Bank Account
Permissions: Read/Write on User Account, Payment Method, Bank Account
Inputs: User details, Payment method details, Bank account details
Outputs: User account creation confirmation, Payment method addition confirmation, Bank account addition confirmation

Transaction Processing (Github repo)

Manages transaction-related operations like initiating/completing or refunding a transaction. In the diagram below, you can see the transaction initiation process.

Data Entities: Transaction, Bank Account
Permissions: Read/Write on Transaction, Read on Bank Account
Inputs: Transaction details (amount, sender, receiver)
Outputs: Transaction status update (pending, completed, failed)

One additional functionality that this microservice is responsible for is the management of external provider transactions. For example, a demo shown in the solution is a mock operation for a user to get a PayPal-based payment. This is feasible since MongoDB's flexible schema can have varying documents under the object representing a transaction.

This process as shown below causes a similar payment verification process for this external transaction validation and processing/notification.

Transaction History (Github repo)

Operate transaction logging and archival.

Data Entities: Transaction History, User Account
Permissions: Read on Transaction History, Read on User Account
Inputs: User account number
Outputs: Transaction history data

Account Reconciliation (Github repo)

Verifying the account details are up to date.

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

Payment Verification (Github repo)

This process reacts to a transaction initiation, processing the required steps. The diagram below shows the payment processing steps from the moment the service reacts to a payment until the user notification, including approving or rejecting payments.

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, failure)

Reporting Service

With MongoDB Charts, you can create a materialized view of your payment data.

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

Notification Service (Github repo)

This microservice utilizes Change Streams together with Web Sockets to notify the user UI of any changes.

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

Database Schema and Document Structures

The following document structures and microservices form the backbone of the MongoDB-based payment solution, ensuring scalability, security, and efficient data management.

Users collection

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

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

Transactions collection

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

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

Building the Solution

The code for the following step-by-step guide can be found in this Github repo.

Features Covered

Cross microservices:

Indexing and scalability
JSON schema validation
Permission and data segregation
Auditing

User and account microservices:

Document model: Flexible user and account structure for different accounts and user profiles
Kafka streaming sink: Data being streamed from external sources
Transactions (User to Account references): Keeping account and user data ACID-compliant
In-use encryption
Full-text search: Account IDs and usernames are searchable for users to pick via full-text search.

Transactions and payments microservices:

Change streams: Payments are event-driven by transactions
Time series for transaction history: Transaction history is built in a time series collection
In-use encryption

Notification microservices:

Apache Kafka source: Notifications are being down-streamed to external systems and users via Kafka
Change streams: Notifications are being captured by change streams and pushed via Websockets

Reports:

Materialized views: Materialized views are built to preprocess and clear sensitive data for reporting
Charts

Key Considerations

The proposed solution requires the following considerations to be taken into account:

Security and compliance: Adherence to GDPR, PCI DSS, and other financial regulations.
Scalability and performance: Ensuring efficient query processing and data handling.
Audit and logging: Comprehensive logging for transactions to support audits.
Backup and recovery: Robust plan for data recovery using MongoDB Atlas.

Authors

Pavel Duchovny, Developer Relations, MongoDB
Shiv Pullepu, Industry Solutions, MongoDB
Raj Jain, Solutions Architect, MongoDB
Jack Yallop, Industry Marketing, MongoDB

Back

Manufacturing & Motion