Open Collaborative Technology Pty Ltd is an end to end technology services provider of custom Payments solution, specialising in High Performance Payment Hubs. We provide end-to-end integration, custom development, testing and support services.
Our technology selection and a frameworks based approach allow us to deliver diverse and complex Payments solutions:
- High Performance Payment Solutions
- Point of Sale and Retail Store Front applications
- eCommerce solutions
- eCommerce implementations and integrations
Our software
In Septermber 2010 Open Collaborative Technology Pty Ltd introduced version 1 of it's flagship product the High-Performance Payment Hub. This product is based on our own Adaptive Payments Framework (APF). In 2011 APF was available as SDK. Because of the nature of the payments business, which requires high level of customisation and integration, we have abandoned the idea of an SDK and now APF is distributed with the product.
Payments processing and Payment Hubs
Payments – everyone makes them and all financial institutions have to process them. There seems to be little consensus as to what a payments hub is (even among those who are building them) and where it sits in the overall payments system.
So what is a Payments Hub?
A payments hub, sometimes referred to as enterprise payments architecture, is an IT system that allows banks to build their own version of a best-in-class payments architecture.
A payment hub can be seen as the infrastructure that ties together the specialized services required to build payments applications such as data completion, exception handling and settlement.
Hubs normalise the different transaction types into a standard ‘payment’ and then process that through a flexible to change workflows, where business users can define rules to finesse howdifferent payment types or customers are managed. This provides a much more agile environment for the business.
From a technology perspective, as payment hubs are new and therefore based on modern technology generally Java or J2EE, they can scale well with the appropriate hardware and can handle any type of payment.
Payment hubs offer a cost effective alternative to complex reengineering of back office systems with a payment engine. They utilise modern technology to work in harmony with existing back office functions to centralise, standardise and automate the management of payments, putting control in the hands of the business while protecting the back office from change. They allow new products and channels to be brought to market quickly. Implementation can be phased and return on investment (ROI) can be rapid using packaged components and frameworks instead of building interfaces and functionality with toolkits and code.
So the Payment Hub is a repository of flexible services, not a repository for payments?
As we see it, a payment services hub is the centralisation of payments services within a financial organisation to support processing all types of payments through all payment mechanisms.
What does a payments services hub offer a bank or financial institution?
First of all, it allows a bank to consolidate disparate payments processes into a single standardised and coordinated operation. This lowers the cost of ownership and reduces maintenance costs and risk. A payments services hub also enables supervision and control of liquidity, allowing for better cash management, which is a primary objective for both the bank and the bank’s customers.
Most importantly, a well-designed, multi-entity payments services hub is the most effective way the bank can support insourcing of white label business and offer personalised services to its customers – both retail and corporate – across the globe.
Never ageing technology!
Another important characteristic of a well-designed payment services hub is an open architecture, which is easy to update. Transaction processing logic and rules are maintained as meta-data. This means that the system never becomes legacy because, it allows the bank to replace parts as they retire, and to upgrade the supporting technology as necessary. The payment services hub is more than just a framework and it should not be a purely technology-driven decision.However, it should provide a way for banks to cost effectively support customised services and should offer a high degree of flexibility and agility, so it can serve the business users and easily adapt and change.
Are you building a Payments Hub yourself? Herewith the common mistakes and pit falls to watch out for:
1. Inappropriate application design:
a. Excessive use of the database, even for intermittent data
b. Excessive use of commit points as wrongly understood exception handling and recovery mechanism
c. Wrongly understood and designed flexibility. Developers and architects are tempted to use XML, CLOB and LOB as a way to add dynamic data into their database. Very often if overdone, these exotic columns data types end up costing significant performance degradation
2. Architectural mistakes:
a. Lack of separation of online processing and end-of-day/batch style processing
b. Very small amendments and additions require system shutdown and expensive planned system outage
3. Use of inappropriate technology - In a high performance online system with hundreds of concurrent short live payment requests the use of BPEL may not your best choice:
a. It is very slow
b. Not easy to change or replace flow items – it is suppose to be used by business people, but you really need big budgets for specialised consulting
c. inappropriate for fast running processes
d. BPEL can add value only for long lived manual/human interaction or inter-system processes. The Payment Hubs are not this kind of systems
e. Use of heavy containers
4. Maintenance and scalability deficiency:
a. The Hub requires constant tuning and tweaking – threads, connection pools, JVM parameters, Garbage collection require attention and re-configuration
b. Lack of graceful shutdown and drain stop without affecting in-flight processes
5. Everyone rushes to complete the development of the functional requirements, so at the end of the implementation there is no time and budget left for:
a. Business activity monitoring
b. Resilience and horizontal scalability
c. Operational monitoring
6. Undesirable result - instead of being the most flexible, agile and easy to amend and modify infrastructure, the Payment Hub has become:
a. The new legacy (downstream systems are asked to change and the Hub becomes un-touchable)
b. The new single point of failure and respectively increased liability
Consulting Services
Application Development and frameworks
Open Collaborative Technology Pty Ltd offers a comprehensive list of bespoke application development and integration solutions, which include:
- Application architecture and development solutions
- Test strategy and test execution solutions
- Deployment and post-production support
Open Collaborative Technology Pty Ltd provides reliable blend of technical excellence complimented with development methodologies and innovative technology selection. We focus on application development in large scale High Performance Payment Processing systems.
Open Collaborative Technology Pty Ltd Pty Ltd provides development expertise in Open Source technologies with a focus on Java and J2EE.
Leveraging our considerable technical expertise and strong innovative technology, we developed several re-usable, extensible and easy to use frameworks to reduce time-to-market and increase product quality and reliability.
We specialise in high performance, high availability applications. We have niche development capabilities on SEDA (Stage and Event Driven Architecture) and distributed in-memory cache technologies.
Adaptive Payments Framework (aka APF) Features
1. Fast and reliable Stage and Event Driven Architecture (SEDA)
2. Powerful software re-use and integration and with Java DSL
3. Distributed In-memory cache (the grid) - using in-memory cache APF guarantees to write to database no more than twice per payment
4. Hiding the Middleware
This provides a number of benefits, such as choosing the right middleware solution for your deployment and switch at any time:
- JVM messaging with SEDA
- using JMS with variety of JMS providers such as IBM MQ or ActiveMQ
- Hibernate or JPA to use an entity bean / table as a queue
- JDBC for raw SQL access
- string decoupling from middleware APIs using Spring remoting or Bean integration
5. In-flight payment monitor and Business activity monitor
- The payment monitor displays textual and graphical information regarding payment being processed or re-tried within the Payment Hub for a given period of time
- Payment Monitor is a tool built to monitor and manage the in-memory data grid
- The Business Activity Monitor provides capabilities for testing and business verification processes across multiple message exchanges
6. Parallel Processing and Ordering - It is a common requirement to want to use parallel processing of messages for throughput, load balancing and performance reasons, while at the same time process certain kinds of messages in order (sequentially)
7. APF supports pluggable shutdown strategy responsible for shutting down routes (flows) in a graceful manner, allowing in-flight transaction to complete processing
8. APF routes and flows can run standalone (JVM) or in any container (such as WAS, WebLogic, Tomcat or JBoss)
9. Performance and tuning
10. Non-disruptive scale-out from one to hundreds of servers
11. Unlimited scalability with dynamic on-demand capacity
12. Cost effective growth - scale with lower cost commodity servers
13. Zero down time
14. Throttling
15. APF comes with In-bound and Out-bound (downstream) throttling capabilities
16. Scheduler - Internal scheduler for batch processing and end of day house-keeping operations
17. Security - Security is JAAS based pluggable security framework which can be used to authenticate both cluster members and clients and do access control checks on client operations.
Why us and our software?
1. Our technology selection uses software from the most trusted, reliable and proven Open Source and Commercial software
2. We will give you the product, as well as the source code. We will support it and let you make changes by yourself or by third party SI
3. Our product consists of:
- 50% intimate knowledge of the Payment Processing
- 50% implementation of Enterprise Patterns using best of breed Open Source and Commercial software
