At OnePix, we’ve developed and supported over a hundred payment gateways across various ecosystems — from WooCommerce to Shopify, from OpenCart to Shopware. We know that some platforms allow you to launch in two weeks, while others require months of approvals.
As our CTO, Anton Drobyshev, often says: “In order to understand how a payment gateway should work, you need to understand the architecture of the platform it will be published on.”
In this article, we share our team’s experience — the differences between open and closed systems, the most common mistakes fintech providers make, and what to consider if you plan to scale your payment gateway development across multiple platforms.
Open-source platforms and how they work
Open-source CMSs give fintech providers freedom and a fast start. We have worked with most of them: WooCommerce, Magento, OpenCart, Shopware, PrestaShop. There’s no need to obtain permissions or partnership status for payment gateway development for such platforms — having an API and documentation is enough.
For startups, this is a way to test ideas and gain their first clients without bureaucracy. But despite all the flexibility, open-source platforms require engineering discipline. Without proper maintenance, these solutions quickly lose stability.
With WooCommerce, we can deliver the gateway in just two weeks, but it’s just the beginning. There is a lot of work afterward — updates, maintenance, adaptation to new versions. Without that, any gateway turns into a one-time product.
WooCommerce as the best starting point
WooCommerce remains the ideal platform for a first release. It’s predictable, well-documented, and allows you to publish a working module without intermediaries. It’s perfect for hypothesis testing: to see how the API behaves in real orders, which statuses cause errors, and how merchants respond.
For example, with one of the clients, we initially launched the gateway only on WooCommerce. Within a few months, it was already serving over 700 stores, which helped identify what parts of the API needed refinement and which were ready to scale. Once the base stabilized, we helped the client set up a support system and update process. The gateway still runs today, stable and compatible with new WooCommerce versions.
Other open-source platforms and what we’ve learned
Working with open systems has shown us that each one has its own purpose and audience. Here’s an overview of how they differ by markets, client types, and technical specifics.
| Platform | Where it’s used | Who chooses it | Key features | OnePix experience |
| Magento | Europe, USA | Mid-size and large eCommerce | High load, complex order and tax architecture | Experienced in Magento payment gateway development and custom payment solutions for financial institutions and enterprise retailers where stability and reporting matter most. |
| Shopware | Germany, Austria, Switzerland | Premium D2C brands, fashion, cosmetics | API-first and headless approach, strict UX requirements | Delivered Shopware payment gateway projects where modules were built for both WooCommerce and Shopware, compliant with EU security standards. |
| OpenCart | Eastern Europe, Asia | Small and medium businesses | Simple architecture, unstable plugin ecosystem | Migrated custom payment gateway solutions from WooCommerce to OpenCart, preserving business logic without rewriting the core. |
| PrestaShop | France, Spain, Latin America | Omnichannel retailers, online + offline | Multilingual, multi-currency | Built gateways for retail chains with ERP integration. |
| Drupal Commerce | Europe, education, B2B platforms | Content-heavy and enterprise businesses | Requires strict security and clear API roles | Developed secure Drupal payment gateway modules with extended access control and backend logic for B2B and educational projects. |
On open systems, you need to think structurally. If you don’t build maintenance architecture from the start, the project will “drift” after just a few updates.
Closed platforms and how they work
Shopify, Wix, VTEX, and BigCommerce are different from open-source platforms. The closed platforms control everything — APIs, partnerships, publishing, and updates. From a user and security standpoint, that’s a plus. But for fintech providers entering the market, it’s a serious barrier.
In closed systems, you can’t just upload a plugin. You need to negotiate with the platform first, get access, and only then start development. Otherwise, time and money will be wasted.
Shopify as the most popular closed platform
Shopify remains one of the most in-demand ecosystems for Shopify payment gateway development, but it’s also one of the most selective. Access to the Payments API is granted only to official partners, and the certification process can take anywhere from several months to a year. Many applications go unanswered — and that’s a normal part of the process. Shopify carefully selects partners to maintain full control over payment quality and security.
If your goal is to obtain a direct partnership, it takes time and effort, but totally worth it. At the same time, we recommend not starting development too early: building a gateway before approval often leads to unnecessary costs and rework.
In some cases, we can collaborate with certified payment providers who already have access to the official Shopify Payments API. Through these partnerships, we can offer non-standard — but still fully official and secure — integration options that help launch faster while staying within Shopify’s compliance framework. In this case you will have a fully functioning gateway with direct access but through the third party.
We always look for solutions that are both creative and compliant — there’s no point in doing it any other way.
Once access is granted, whether through your own partnership or via one of our verified partners — we join the project to design the gateway architecture, run tests, prepare documentation, and guide the module through publication. Our goal is to make the process transparent and predictable — even when the platform sets a high bar for entry.
Other closed platforms and what we’ve learned
| Platform | Markets | Key features | What to know | OnePix experience |
| Wix | North America, Europe | Simplified checkout logic, limited API | Requires strict adherence to SDK and documentation | Consulted clients on architecture and API compatibility |
| VTEX | Latin America, enterprise sector | API-first, strict access control | Development possible only after partnership approval | Supported large providers adapting their gateways to VTEX |
| BigCommerce | USA, UK, Australia | Open API, complex moderation | The platform carefully audits security and code quality | Migrated WooCommerce gateways to BigCommerce without changing logic |
| Ecwid | Eastern Europe, SMB | Minimal customization options | Suitable for lightweight solutions and MVPs | Built simplified gateways with webhook integration |
Integrating payments into CRM systems
Payments are increasingly becoming part of business processes, not just on eCommerce platforms. CRM systems like Kommo are now also payment points today. We integrate payments directly into sales funnels — linking transactions to deals, statuses, and notifications.
When a gateway becomes part of a CRM, the key isn’t the interface — it’s the structure. You have to clearly define where the system accepts payments and where it only updates statuses.
This experience helps us design gateways based not on a platform but on the architecture of the client’s processes.
Building scalable multi-platform architecture
Working with dozens of platforms has taught us to think systemically about gateways. We design a core that can be adapted to any environment whether it is WooCommerce or Shopify.
A good gateway it’s a good architecture, first of all, where everything is layered: API, processing, logic, interface. Then transferring it to another platform isn’t a problem.
We build a roadmap for multi-platform solutions together with the client:
- Identify which platform will come first (often WooCommerce).
- Collect feedback from real merchants.
- Stabilize the API.
- Plan scaling — choose where to go next.
This approach saves time and avoids mistakes during expansion, especially when a business enters new markets and needs to connect multiple CMSs without breaking compatibility.
What providers should know before starting
Multi-platform payment solutions require strong development and a deep understanding of the ecosystems you plan to work with. Each platform has its own rules, and planning for them early helps avoid costly rework later.
We believe in a conscious start. It’s better to prepare and understand the limits than to rush and rebuild everything later.
Here are a few things to know before you start:
- Ask your merchants where they want to use your solution.
Start with the platform where your clients already operate. Building a payment gateway for an ecosystem familiar to your users helps you launch faster, test real transactions, and gather feedback from merchants who already trust your product. - Check the rules for access and publishing on each platform.
WooCommerce allows immediate module uploads, while Shopify or VTEX require prior partnership approval. - Verify whether the API is public or restricted.
For example, Shopify Payments API and VTEX Gateway API are available only to approved partners. - Confirm your publishing rights before writing code.
Without API access, it’s impossible to test the logic — and any “future-ready” development will likely be wasted effort. - Avoid starting development without platform approval.
Projects that begin too early often require expensive rework later — taking more time than building from scratch.
We begin the development with consultation and planning in order to check where a client can launch immediately and where they should wait for approval. It saves resources and helps build a strategic roadmap with a clear understanding of how and where the product will grow.
👉Learn more about payment gateway development
