Businesses are increasingly looking to offer payment services to enhance customer experiences and capture market share. Most businesses would prefer to use a contactless payment (COTS) or a ready-to-use payment processing product from a third-party vendor for this journey for faster go-to-market and greater ROI. . Greenfield development of any payments product or application is a challenging task, with unexpected hurdles on the way. As I’ve participated in several such implementations payments processing platforms, I’ve realized that the challenges across implementations are quite similar irrespective of geography or the payment rail or payment method utilized. I touch on some of these challenges below to provide some insight to other businesses considering their own end-to-end greenfield implementation, and how they can mitigate any potential project issues.
The ‘Me Too’ Effect
Sometimes when pursuing a payments product implementation, it becomes more about following the herd, rather than truly innovating for business value, and the selected product may be popular but might not be the best strategic idea. This results in uncertainty and an ambiguous vision, which impacts the overall delivery of the product, so it’s critical to select a product based on a solid vision and real needs, not trends.
Requirements Ambiguity
At times, the vision is there, and the product is a good fit, but still the conversion of the vision to business requirements for implementation might not be perfect. It’s important to consider all scenarios end-to-end, with all their nuances and potential pitfalls in the first go, as this will have a direct impact on any go-live roadmap.
Architecture Challenges
Organizations have existing IT infrastructure with well-defined templates and policies. However, when integrating a new third-party payments service or product, an IT team faces challenges with cost, security, and compliance checks. There can be additional challenges associated with infrastructure scalability to support increased transaction volumes arising from new business use cases.
Evolving Design
One major setback for a greenfield implementation is when product stakeholders go back to the whiteboard again and again, as they come up with new ideas, and try to improvise the payments solution, which impacts delivery plans and associated tasks. These iterations may be linked to initial requirements ambiguity, be it functional or non-functional, which once again hammers home the need for clear project goals at the start.
Development Iterations
When requirements and project design evolves, it has a direct impact on application code and leads to unplanned build iterations. This not only impacts any go-live schedule but also impacts developers’ productivity and code quality due to what can feel like endless reworks.
QA Coverage
Preparing a proper test strategy for a greenfield implementation is very difficult in the first iteration. Identifying the needed test cases, with proper testing coverage, also becomes challenging with continuously changing requirements. QA follows the same loops of iteration as the related development cycles and have a “shift-right” impact on the delivery plan.
Inexperienced Team
For the uninitiated, payment processing products can be complex and daunting, particularly for those with limited experience in banking or financial services. Understanding the business use cases and the regulatory needs requires an experienced team for build and QA. Such talent can be difficult to attract and retain, however, and many businesses need to make requires investments in learning, skills development, and training of in-house teams as an alternative to external hiring.
Regulatory Certifications
For a payments processing platform, certification by authorized regulatory bodies — also called Industry Testing — is a presumed prerequisite. This is a very critical testing phase and requires proper planning and strategy for effective execution in a limited certification window.
Compliance Adherence
There are various compliance requirements associated with a payments products such as PCI-DSS, SOC-1, SOC-2, etc. There are also mandates for AML Check, Sanctions Screening, Fraud Detection, and other requirements. Each of these have their own nuances and controls that must be followed, which adds to application complexity and requires SME support and reviews to ensure adherence.
Operational Support
Go-live of a greenfield implementation is a massive success, but it is not the end of the journey. Operational support of the platform is just as critical to ensure adherence to SLAs, compliance, and customer expectations. Well-defined SOPs are needed to support a payments processing platform, and operational manuals and guidelines for future use must be defined well before the go-live date.
Change Management
My final insight is around handling change requests or CRs. For a payments platform, change requests can be caused by various factors such as regulatory modifications, changing business requirements, technical software upgrades, handling technical debt, and more. Planning a resilient design to accommodate ongoing changes will make CRs less painful to implement and ensure long-term product success. At Persistent, we have a team of experts and consultants who like me are working on several such greenfield implementations for payments products, and we put our insights and experience to good use for every client implementation. Our payments expertise, coupled with our product engineering DNA, helps our clients navigate planned and unexpected challenges along the path to a greenfield implementation. Contact us today to learn more.
