Arvato Financial Solutions Tech Center

Project migration - Payment gateway transition

Today we want to share the success story of application development migration from contractor company to in house.

As a company we’re building an application that helps our merchants to seamlessly integrate payments into their web shops. Our application is a payment gateway, where merchants connects to our API from one side, and we connect to the payment service providers from another side.

Our product has two main benefits. The first one allows merchants to integrate just with a single API and we take care of the changes on payment service provider part. The second one is the simplified security for merchants. When shops want to allow credit card payments, the shop has to follow credit card industry security standards PCI DSS and pass yearly audit to continue operation. That is a complex, lengthy and expensive process to follow. When shops integrate our solution, credit card details go directly to our application and we deal with high security standards and pass audit, while shop takes standard security measures.

When development started back in 2012, it was easier to start with an in-house Architect and an external partner. Now this application became a key core product in our company, and after evaluating all pros and cons a decision to move development in-house has been made.

Once the project officially started in June 2019, a dedicated Project Manager has been nominated to this transition project. Once all details were settled, transition execution started. An in-house team of experienced developers in Tallinn has been formed and in November 2019 they were ready to gain knowledge about application.

As the team was new in the project, we started with trainings. Team learned about the product itself, development processes, infrastructure, monitoring and security practices.

We have identified that the best approach to learn the product is actually to change the code. Thus, we have defined 3 areas that had minimal impact on application but let people to learn it from inside out: bug fixing, unit tests fixing, and addressing static code analyzer findings.

When this step was accomplished, we have identified components and areas of application that team would like to learn deeper. Each item was picked by one the team member, and once learned it was documented and shared within the team. Thus knowledge was spread. After that step, the team was ready to start new feature development.

Development of new features started together with our partner, and developers worked shoulder to shoulder over the wires. Our partner supported the in-house team and  collaboration was very successful. During learning and development of new features, team has identified areas that required additional trainings, and they were provided to us as well.

After 6 months since transition project started, team was able develop new functionality on their own, but due to the complexity of application it was agreed to have a consultant from our partner for another 6 months to reduce the risks and to smooth development.

Conclusion: Project transition went successfully. There are few key advices that we would like to share:

  • Assign a Project Manager for transition project
  • Use a help of Scrum Master to establish development processes and glue the team
  • Give development team enough time to learn the product
  • Keep good relationship with partner
  • Develop application as a one integrated team with partner for some time
  • Use consultant from partner after development switch over
Sergei Prokopov

Sergei Prokopov

Team Manager / .Net Architect

Karl Oolu

Karl Oolu

Projects & Programs Senior Manager