When I started working with Adobe Developer App Builder, I was told it would be easy. As an Adobe Commerce Technical Architect, it should have been a smooth transition—after all, Adobe Developer App Builder is designed to simplify extensibility, and out-of-process is the future. However, I quickly realized that I was juggling not one, but three codebases: Adobe Commerce, Adobe Commerce Storefront, and Adobe Developer App Builder. Running everything locally was more complex than expected, making this project a deep dive into Adobe’s extensibility model.

I’ve been an Integration Specialist focused on Adobe Commerce, though I had only experimented with Adobe Commerce Storefront and Adobe Develop App Builder before. My background with commerce events made me initially think that Adobe Developer App Builder was purely event-driven, but I soon realized it offers much more flexibility. While I’m dedicating 50% of my work time to this project, I often find myself working after hours to refine implementations and troubleshoot.

Early Challenges with Adobe Developer App Builder

I’m a Technical Architect and Integration Specialist working with Adobe Commerce for almost a decade. Recently I had my first experience with Adobe Developer App Builder, Adobe’s new extensibility platform for Adobe Commerce enabling the same level of deep customizations in a more performant and scalable way. I recently built a fully integrated Adobe Commerce app for the first time using App Builder and Adobe Commerce Storefront.

Before officially beginning, I experimented with the checkout starter kit to integrate a payment method. My prior hands-on experience with Adobe Developer App Builder was limited to a newsletter event trigger, which has not been used yet but may go live as part of another project I’m working on.

Right away, I ran into authentication issues, misconfigurations in YAML files, and problems with authorization key setups. Debugging these configurations took up valuable time, reinforcing how critical proper setup and documentation are when working with Adobe’s extensibility tools.

Environment Setup and Adobe Commerce Storefront

Once I had authentication working, I moved on to Adobe Commerce Cloud environment setup. Our Pro Adobe Commerce Cloud account needed cleanup, with staging functional but production requiring significant fixes. Upgrading to Adobe Commerce 2.4.7-p4, updating services, and resetting the database were necessary first steps. However, authentication entitlements issues slowed progress, requiring a support ticket with Adobe.

Adobe Commerce Storefront integration, by comparison, was smoother. Connecting it to staging and Catalog Service worked well, and integrating the payment SDK required adding drop-in UI components, an area where I had little experience, especially in terms of styling.

Refining the Implementation

A major realization came when I discovered that Adobe Developer App Builder is not just event-driven—its runtime actions allow for API execution independent of Adobe Commerce events. Initially, I assumed everything had to be triggered through webhooks and event listeners, but I was wrong.

Once I understood this, I began replacing hardcoded API calls in Adobe Commerce Storefront with Adobe Developer App Builder runtime actions for payment processing. The Minimal Viable Product (MVP) required several key capabilities:

• Dynamically enabling/disabling the payment method
• Securely storing and retrieving payment API keys
• Handling payment processing within Adobe Developer App Builder

With all the code written, I started putting everything together. At first, I thought I had structured the logic correctly, but I ran into issues with how payment actions were being handled. The system worked but was not always generating fresh transactions as expected. After debugging, I realized I needed to move some logic from the runtime action to the client side for proper execution.

After refining the structure, I finally had everything working correctly. The process now executed in the right order, and data was being properly saved across Adobe Commerce and Stripe, ensuring consistency. This was a key milestone in making the integration functional and scalable.

Key Takeaways from My Experience

• Adobe Developer App Builder extends beyond event-driven workflows—its runtime actions enable broader use cases.
• Managing multiple codebases such as Adobe Commerce, Adobe Commerce Storefront and Adobe Developer App Builder takes coordination. Running them locally within a shared sandbox environment introduces unexpected challenges.
• Environment setup is critical but time-consuming. Authentication entitlements and Adobe Commerce Cloud configurations can slow progress.
• Structuring API calls correctly is essential. Some logic is better suited for runtime actions, while others must be executed on the client side.
• Adobe Commerce Storefront integration is relatively straightforward, but front-end work requires extra effort when it's not your specialty.

This project has been a learning experience in real-world extensibility with Adobe Commerce, Adobe Commerce Storefront, and Adobe Developer App Builder. I’m still refining the implementation, but I now have a better understanding of how these tools interact and what it takes to build an out-of-process payment integration effectively.

Interested in Adobe Developer App Builder for your business? Contact Blue Acorn iCi to learn more about how we are shaping the future of commerce applications.