It all started in September 2014, and I was one of the first developers to join that team at that time. We may say then it’s a mature product with a strong stakeholder group and rich feature set.
Besides being just an integration pipe or some adapter between Schibsted brands and payment service providers, Payment Gateway also offers additional services for the Schibsted ecosystem.
- Keeps the history of Schibsted users’ payments delivering tooling for the Customer Success team to troubleshoot whenever users raise payment-related concerns.
- The feature of card-on-file increases the conversion rate by making payments more straightforward. We do that by “remembering” a reference of previously used credit cards, mobile phone numbers, and invoice data. Card-on-file makes the purchase flow smoother, reducing it often to just a single click without the need to enter full credit card details or acknowledge payment with an SMS code.
- The data of payments flowing through the Payment Gateway feeds Schibsted-wide data warehouses to search for new sale opportunities for Schibsted brands.
Besides that, there are many more valuable functions of the Payment Gateway Schibsted brands utilize. The set of use cases Payment Gateway supports include not only one-time purchases but also advanced subscription models.
Currently, the Payment Gateway offers its services to more than 50 well-established Schibsted brands. That most known are:
- FINN.no – the largest Norwegian classified advertisements website;
- Aftenposten – Norway’s largest printed newspaper by circulation;
- VG.no – the second largest Norway’s printed newspaper;
- Aftonbladet – a Swedish daily newspaper published in Stockholm, one of the largest daily newspapers in the Nordic countries;
On the second side of the Payment Gateway, there’s a carefully picked set of Nordic and global payment service providers. The portfolio of available Payment Gateway integrations aligns with the needs of more than 90% of Schibsted users. We still look into new possibilities and market trends to not miss any opportunity to deliver value to Schibsted brands. Until 2021 we developed 17 different integrations. Of course, some of them got deprecated or got replaced, and now six are still operational:
- Swedbank Pay – the payment service provider offering credit card payments supported by Swedbank, a Nordic-Baltic banking group based in Stockholm, Sweden;
- Adyen – the big global player, partner of eBay, offers various payment options, including credit card payments;
- Vipps – a Norwegian mobile payment application designed for smartphones developed by DNB (Norway’s largest financial services group). This payment option is trendy recently;
- Strex – is a Norwegian company offering direct carrier billing. All you need is a mobile phone and your phone number, and all payments are charged to your mobile bill;
- Fortumo Direct – an Estonian company delivering direct carrier billing in Sweden;
- Klarna – a Swedish fintech company that provides online financial services such as payments for online storefronts, direct payments, and post-purchase payments;
The team and how do we work
The Payment Gateway team consists of eight professionals. The whole development team (seven members) is located in Kraków, Poland, the product manager resides in Stockholm, Sweden. More than half of team members are senior-level or above. The experience is essential when maintaining and developing a financial system required to present consistent data regardless of payment service providers’ glitches, availability problems, response times. One of the biggest challenges when integrating with the new payment service provider is to handle as many corner cases as possible to automatically recover from data inconsistencies in case of providers underperformance or network failures.
The technical background of the team is primarily Java-based. Most of the production code is written in Java and Kotlin, with tests written in Groovy (Spock). We prefer Kotlin/Groovy(Spock) combination when we develop new services.
The critical factor is our experience with distributed systems. Payment Gateway consists of about more than 15 services communicating mostly through synchronous HTTP calls. Still, recently we see more and more need for asynchronous communication (we utilize cloud services as a messaging infrastructure – SQS, Kinesis).
Due to consistency requirements, most of the operational data stores are RDBMS with a preference for MySQL. Our build vs. buy philosophy prefers using off-the-shelf, zero-maintenance software and solutions, especially for infrastructure components.
We utilize a broad spectrum of AWS services, including EC2, RDS, SQS, SNS, DynamoDB, Kinesis, Lambda, and many more.
The tech stack of the Payment Gateway, however, is not written in stone. That means the team members are free to experiment with various technologies. Every significant technical improvement or platform reshaping is preceded by a team brainstorming session and proof of concept phase. These PoCs are not always successful, though. Regardless of the result, this phase gives us quick feedback if we choose the right way.
Most of us, the developers, are lazy individuals, so we automate as many things as possible, starting from CI/CD process through the infrastructure-as-a-code approach, acceptance testing, ending with some custom endpoints and procedures fixing our data in case of inconsistency.
The team embraced the scrum framework with two-week-long sprints, bi-weekly retro, and sprint planning. Every sprint has its goals that help us focus on the most important things. We prioritize initiatives in two main work streams: product and tech, putting a comparable amount of work into both streams. That helps us to consistently deliver new product features and gives time to reduce technical debt, improve, reshape the platform according to our long-term tech vision. Prioritization is crucial for us and allows us to focus only on the small subset of our backlog, ignoring things that are not important at the moment.
Payment Gateway going forward
The Payment Gateway’s technical vision and roadmap have recently been reevaluated and adjusted. The product vision and strategy are currently being refined to clarify the brands’ responsibilities and give the Payment Gateway mandate to expand even more within the Schibsted ecosystem. There are still big brands maintaining point-to-point integration with payment service providers. We perceive that fact as an unnecessary duplication of effort and blocker from faster innovation in the brand-specific domains (either media area, online classifiers, or distribution). We see the Payment Gateway as a standard building block of any Schibsted brand wanting to embrace online B2C and B2B payments in their products. Single point of integration, know-how, and troubleshooting are the values proposed to Schibsted brands to offload their payment teams and allow to focus on more domain-specific work.
Technically we see Payment Gateway as a product with an inheritance of about five reorganizations and Schibsted strategy adjustments, so we invest much of our time in the improvements.
We want the future shape and architecture better supporting Schibsted brands’ use cases. In the nearest future, we plan to separate components responsible for querying historical data and processing payment requests to increase the platform’s long-term stability and extensibility. This initiative drives CQRS/ES patterns application. We currently build the data lake designed to offload top-priority components from querying responsibilities completely.
The ideal technical shape of the Payment Gateway we aim at is a kind of plugin-based architecture where even inexperienced developers or consultants may build an integration towards a new payment service provider based only on internal API and events contract.
From the infrastructure perspective, in 2021, we plan to embrace Kubernetes as our only platform and replace heavy EC2-based deployment with lightweight Docker-based ones. The introduction of Kubernetes opens an opportunity to improve our infrastructure-as-a-code adopting Terraform as a replacement of Cloud Formation scripts. We see that need because some drifts appeared between our code and the critical infrastructure components during the last six years.
As you can see, the plans for Payment Gateway are ambitious. We remain realistic about fulfilling the strategy, and most likely, all the work won’t be completed by the end of 2021 or even 2022. Payment Gateway is a critical component with an availability SLA of 99.9%, and every change made must not affect the platform’s availability. I keep reminding myself and the team that when we are up, no one notices that. Payments happen, users pay, money flows to the Schibsted accounts. If we are down, everyone sees that, and many parties are affected. This fact is what I perceive as the nicest thing about the Payment Gateway — the feel of criticality.