- Principles of Architecture
- High-Level Overview
- In-Store Technology vs. Cloud Technology
- Tenancies and Environments
Since the very beginning, the long term vision has always been consistent, to build a bank-grade platform that we can sell to many merchant service providers around the world. Every technical decision that we make has to be aligned with mx51’s business strategy to achieve this long term vision.
mx51’s platform is sometimes referred to as MSP (Merchant Services Platform).
mx51 sells a white-labelled platform as a managed service to merchant service providers. Commercially and contractually, this is done in the form of a Managed Services Agreement (MSA). We refer to clients of our MSA as Tenants because we allocate each of them a dedicated tenancy consisting of segregated instances of technology components. We brand and configure each tenancy for each specific tenant.
Principles of Architecture ¶
Architecture represents the significant design decisions that shape a system, where significance is measured by the cost of change. – Grady Booch
That cost of change includes opportunity cost as well as the risk and cost from no-change.
Alignment with the Business Strategy ¶
Every significant technical design decision is made with full awareness of mx51’s short, medium and long term business objectives. The longevity of the solution is matched to the expected longevity of the business problem it is solving. Architects at mx51 are in constant conversation with the business visionaries about the product and marketing strategies being undertaken. This is an overarching principle.
“Bank-Grade” Quality ¶
Properties of Quality:
- Usability – A great user experience. Every solution is designed around its users, whether that’s merchants, consumers, employees or engineers.
- Availability – The technology has to be available whenever the user needs it. Different solutions have varying requirements for availability and that is taken into consideration when designing the solution.
- Integrity – The solution needs to be robust in varying environmental conditions. It needs to have fault tolerance and degrade gracefully. Most importantly, it needs to make sure that the data remains integral and that there is no data loss.
Quality needs to be scalable across various dimensions such as the number of tenants, the number of merchants of a tenant, the number of customers of a merchant, the transaction/usage volume and/or the number of mx51 employees.
“Bank-Grade” Security ¶
The properties of Security both overlap with and ensure we fulfil the quality requirements:
- Confidentiality – Important data is protected from cradle to grave. The solution must ensure that data is only accessible to authorised users and protected from leakage.
- Integrity – Data must protected to avoid tampering or unauthorised change. This includes the underlying solution components and infrastructure also.
- Availability – The solution must have defenses in place to protect against disruptive or destructive cyber threats.
Security is not merely a quality of our technology but is a first class principle. Security is incorporated into the design of every solution, no matter how complex or trivial the business requirements being solved for are.
“Bank-Grade” Compliance ¶
mx51 operates in a highly regulated environment. There are at least 3 main fronts of regulation:
- The jurisdiction’s law – mx51 operates from the state of NSW in Australia and therefore the laws of the state and country apply to mx51 as a company.
- Commercial contractual obligations – mx51 signs commercial agreements with its clients, suppliers and investors that must be complied with.
- Industry regulatory and standards bodies – such as the Payments Cards Industry (PCI), Australian Payments Network, and ISO27001.
Every technical design decision at mx51 takes compliance into account.
Cost Effectiveness ¶
The cost of a technical solution is considered during the design phase to ensure there is return on investment in line with the business strategy. Cost includes build, integration, maintenance and SaaS costs and is modelled against the projected number of tenants, number of merchants of a tenant, number of customers of a merchant, the transaction/usage volume and/or number of users. It is important that technical designers understand how mx51 makes money from each feature or capability that is to be designed and built.
Product Technology Architecture ¶
Product technology includes anything that is used to run and operate the mx51 product for our tenants.
High-Level Overview ¶
The context diagram above describes the ecosystem around mx51’s product. It is worthwhile to spend some time analysing it and the following sections often refer to it.
In-Store Technology vs. Cloud Technology ¶
Some of the mx51 product technology runs on devices inside a merchant’s brick-and-mortar store, namely point-of-sale devices and payment terminals, while the rest of the mx51 product technology runs in the cloud and is exposed to end users via web browser dashboards or via APIs.
Loosely speaking, some of our product technology delivers functionality for the in-store experience such as our POS integration and our merchant experience app (MXA) that runs on the payment terminal. Some of our product technology delivers functionality for the online payments experience such as e-commerce. The rest of our product technology delivers functionality across multiple channels of the experience, for example, the merchant dashboard exposes in-store self-service functionality as well as e-commerce management and cross-channel transaction listing.
Tenancies and Environments ¶
Every mx51 tenant gets a dedicated tenancy which consists of segregated runtime instances of technology components. The segregation goes all the way down to the cloud account levels, to networks, data and compute power.
Furthermore, each tenancy has multiple environments inside it that serve different purposes. A real tenant’s production tenancy typically has two environments inside it:
- Live (live) – This is used by real merchants and sees real money. It’s tightly monitored and alarmed and is given highest priority. It has real PII, Card and Financial data.
- Sandbox (sb) – This is mainly used for integration testing with the tenant systems and other related third parties such as Terminal Management Systems and POS systems. It provides a lot of value before a tenant goes live with mx51, while various integrations and customisations are being built and set up. It is primarily used by mx51 and tenant employees that are working on integration, configuration and testing. Note that a tenant’s sandbox environment is still considered as a production environment that mx51 gives to the tenant as part of the service. However, it is typically smaller in size for cost efficiency. It is still closely monitored and alarmed.
Each tenancy is assigned a code. The tenancy code facilitates automation. Each environment is also assigned a code, for example live and sb.
Integration with Tenant’s Own Systems ¶
A tenancy is able to go to market with the least amount of integration work possible but typically there’s always one or two desirable integrations, for example:
- MXA with the tenant’s own payment app for the in-store functionality
- Tenant’s own merchant provisioning and servicing system to mx51’s backend
- Tenant’s document exchange system to mx51’s backend for transaction ingestion, for example
- Tenant’s preferred card-not-present payment gateway
Different tenants will have their own environments and sub-systems serving different purposes. A diagram that maps mx51’s tenancies and environments to the tenant’s environments and subsystems is maintained.
Gecko Tenancy ¶
Gecko Bank is a fictitious merchant service provider brand. The Gecko (gko) tenancy is where mx51 showcases all the latest and greatest platform features.
This tenancy is used for:
- Demonstrating the platform to potential tenants
- Demonstrating the platform to potential partners, such as POS vendors
- Facilitating non-tenant-specific partner integration, testing and certification – such as POS or commerce integration
This tenancy has only one environment, i.e. live.
Non-Production Tenancies ¶
The engineering team also owns two internal tenancies:
- Engineering (eng) – This is used for development and testing of the platform. It has two environments, namely “dev” for development, and “qa” for testing and QA.
- Performance (perf) – Used for doing various performance tests. May have multiple environments for different types of tests. Only runs in stretches during performance testing.
Cross-Tenant Runtime Components ¶
There is very little product technology that is run centrally and used from across all tenancies. It is limited to some minor and not-too-critical functionality in the in-store integration product, namely:
- A server where the Spice software is downloaded (and upgraded) from
- A web-service that the SPI client library uses to get a list of available tenancies to connect to. It’s a bit like a tenant directory.
The observability tools also run cross tenant.