The Software House helped Cleeng integrate with the Adyen financial technology platform to process payments.
With a tight deadline and complex data handling needs, Cleeng chose to work with us to develop a highly customized Adyen integration.
Partnership goal:
→ To create a customized Adyen integration that connects with a major business interested in the client's solution.
Cleeng
Cleeng unifies the subscriber experience across web and mobile apps from a single platform, empowering D2C companies to simplify subscription management and maximize customer lifetime value.
Their award-winning Subscriber Retention Management (SRM®) suite delivers comprehensive solutions through an integrated approach – from flexible web payments and in-app subscriptions to sophisticated recurring billing and AI-powered customer support.
Trusted by industry leaders, including the NHL, Big Ten Network, The Weather Channel, TOD/BeIN, and NHK, Cleeng's complete suite helps businesses reduce churn and drive sustainable revenue growth across channels.
Cleeng supports its partners by facilitating a hassle-free method for collecting payments from individuals. To achieve this, Cleeng collaborates with leading payment technology providers, such as Adyen.
We've partnered with Cleeng for the past four years.
INDUSTRY
Media & Entertainment
COUNTRY
The Netherlands
SERVICE PROVIDED
Custom web development
Challenge
Cleeng sought a payment solution that could facilitate the rapid onboarding of new business partners by enabling them to connect seamlessly with the Adyen technology platform. Their aim was not an improvised fix, but a tailored integration that would meet immediate business needs while serving as a long-term asset.
Adyen provides easy-to-implement standardized integrations, SDKs and APIs to offer security, scalability, and performance benefits. For many companies, these out-of-the-box solutions enable rapid go-live and immediate access to Adyen's full suite of features.
However, for businesses with specific or complex data handling requirements, like Cleeng's, Adyen's open architecture and comprehensive APIs allow for the development of custom integration layers or tailored payment modules to align with their unique operational needs.
By making this level of customization accessible, Adyen covers both typical and unusual use cases.
In this context, Cleeng's custom integration logic acts as a bridge between their application's frontend and the Adyen financial technology platform, designed to transmit user input data and process payments according to their precise requirements.
That's why they had a number of requirements:
Security
Payment data is fully secure once processed by Adyen. Adyen's solutions are designed to securely handle and tokenize sensitive payment data at the point of entry, thereby minimizing the scope of PCI DSS for your application.
However, you are responsible for safeguarding users' personal data as it enters your application and during its secure transmission to Adyen. This is achieved through implementing appropriate technologies, robust rules, and strict policies
Scalability
This term has a dual meaning. First, it refers to designing your architecture to manage increasing traffic volumes effectively. Second, it pertains to ensuring the ease with which new features and improvements can be introduced in the future.
Performance
This is crucial for ensuring your application processes payment requests rapidly, even during peak loads, to prevent your system from being overloaded and ensure excellent user experience.
Time-to-market
As Cleeng aimed to onboard a business partner requiring new payment methods rapidly, we operated under a strict deadline. Concurrently, we were committed to delivering a quality solution. Throughout the implementation, we will detail how we balanced these objectives.
Solution
A robust payment solution is more than just the sum of its underlying technologies and techniques, but selecting the right tools for the job is essential for the success.
We focused on leveraging commonly available, high-quality "ingredients" rather than reinventing the wheel.
Security Solutions:
Some of these are particularly relevant to developing payment integrations; others are foundational for building any secure, long-lasting application:
Throttling
Fraudsters may attempt to send millions of requests to discover stolen card credentials, and each request or rejection can incur fees for your business. This technique limits the number of requests a user or system can make within a specified period.
Principle of Least Privilege (PoLP)
Developers or administrators should have access only to the data necessary to complete their tasks and only for the duration required.
AWS KMS
Utilized to encrypt data at rest or that is not actively in transit.
AWS Secrets Manager
Employed to safeguard sensitive information such as database credentials/passwords or API keys.
Scalability Solutions:
For the architectural scalability of an integration layer designed to handle highly varied traffic, we opted for a serverless solution because it can automatically adjust computing power to meet demand.
To ensure easy extensibility, we adopted a modular design. Here are some of our specific choices:
Terraform
Enables infrastructure modification through code, including automation of many tasks, and provides a comprehensive infrastructure overview.
AWS Lambda
Our chosen serverless solution scales the number of execution environments as needed.
Single Responsibility Principle
Our modular architecture was designed so that each module is responsible for a single functionality. This approach simplifies the process of identifying the root cause of any malfunction.
GitHub Actions
When deploying new features via the CI/CD pipeline, GitHub Actions' rollback function allows for painless removal of a release and reversion to the previous state.
Monitoring
To track all critical data, we implemented monitoring for resource usage and potential malfunctions using:
AWS CloudWatch for data collection.
Sentry for monitoring.
AWS X-Ray traces request paths throughout the system and generates trace maps to identify potential bottlenecks.
Grafana for presenting all data in clear, easy-to-read dashboards.
Performance Solutions:
To prevent system overload and ensure the payment integration could handle numerous requests concurrently, we employed two primary strategies:
Rate limiting
This technique prevents an excessive number of unnecessary requests. Unlike throttling, the service is limited once a predefined number of requests is made, rather than blocking a specific user.
Asynchronous data processing with AWS SQS
During significant spikes in usage, data can be processed asynchronously and moved into a queue. An example of such a spike is thousands of users making recurring payments simultaneously.
Additionally, we utilized Sentry to monitor the workload and configured alerts for any significant traffic surges.
Process
1. Creating project documentation & planning for migration
We meant for the integration to be easy to work with for a long time. That’s why we started by writing extensive documentation. It included:
procedures for deployments and rollbacks,
defining a list of steps to perform when manual scalability is required (we may have AWS Lambda, but we need to be ready for any scenario),
a troubleshooting guide,
and flow diagrams so that new developers can understand each function easily.
2. Setting up the project
We created a setup according to standards we developed over time. They allowed for the standardization of the codebase, improving readability and debugging.
We also needed to define the basic Terraform modules we planned to use.
This included:
deploying our own TSH project boilerplate with TypeScript configuration,
standardizing API creation according to the OpenAPI specification,
configuring Terraform modules: one for secrets management, which included an integration with the aforementioned AWS Secret Manager,
and creating another integration with AWS SQS resources that would allow for handling requests asynchronously. A well-configured SQS can really handle a tremendous load!
3. Designing the structure
Finally, we created the basic structure of the integration layer. As part of it, we set up prerequisites for monitoring for security, scalability, and performance. This phase included developing:
only the core components we picked for the MVP (initial release),
clients responsible for communicating with Cleeng’s and Adyen’s APIs,
middleware for request validation,
log and error handling system,
Sentry integration for data collection.
4. Configuring the monitoring
Because we integrated Sentry, we could set up full monitoring and observability, in particular:
setting up release tracking (we actively track Sentry to search for possible errors in every release),
configuring business metrics for monitoring (e.g., initial payment request),
creating custom Grafana dashboards to be able to view all the essential metrics in one place,
setting up tracing with X-Ray.
5. Setting up the CI/CD pipeline
For a scalable, high-traffic solution needing continuous improvements, a smooth CI/CD pipeline was a must. Ours included:
automated building and launching of tests and releases,
implementation of Terraform’s workflow: initialize to prepare the release, validate to verify Terraform configuration files, plan to preview the changes before they go live, and apply to push the release.
6. Deploying
Since we:
documented the entire payment integration,
set up the basic structure,
and implemented safety measures for smooth deployment,
we could finally deploy it!
Outcome
In the end, we were able to help the client meet both its short- and long-term goals.
→ Cleeng developed the Adyen integration on time and still maintained quality
→ The system is ready to handle significant traffic spikes
→ It's designed to be easily extended in the future
