The brief
A payment orchestration provider needed an official Adobe Commerce module: something any merchant could install and trust. It had to support the ways customers actually pay today: cards with 3D Secure, Google Pay, Apple Pay, PayPal and buy now, pay later.
Payments leave no room for shortcuts, and a module that handles real money for many merchants has to meet a higher bar still. A checkout that mostly works is a checkout that loses money and trust.
How we built it
- One module, many payment methods. Each method fits into Adobe Commerce’s standard payment framework, so merchants configure them the same way and checkout behaves consistently.
- Secure by design. 3D Secure for card transactions, and card details handled by the payment platform rather than the store.
- A product, not a project. The module is a versioned Composer package, so merchants install and upgrade it like any other dependency instead of copying code into their sites.
- A dedicated test store. A separate Adobe Commerce Cloud environment let us test every payment method end to end before each release.
- Reviewed, traceable releases. Every change went through a feature branch and pull request tied to its ticket.
Documentation and the Adobe Commerce Marketplace
Writing the module was only half the job. For merchants to find and trust it, it had to be published on the Adobe Commerce Marketplace, and that comes with its own process:
- Documentation covering installation, configuration and day-to-day use, written for merchants and their developers rather than for us.
- Packaging for submission: a clean, versioned Composer package with the metadata the Marketplace expects.
- Adobe’s review: the extension goes through Adobe’s technical review, which checks the code against Magento coding standards and tests installation, as well as a review of the listing itself.
- A repeatable release process, so each new version can go through the same steps without starting from scratch.
Because the code had been written to Magento’s standards from the start, the technical review was a confirmation rather than a clean-up exercise.
Leading the team
As tech and team lead I split the work by payment method, reviewed every change, and kept the module’s structure consistent as it grew. With many payment methods sharing one checkout, consistency is what stops one method’s fix from breaking another.
What it shows
Building for reuse costs more up front: proper packaging, documentation, a test environment and a review process. It pays back every time a merchant installs or upgrades the module without needing anyone’s help.
