More insights
Co-founder Briqpay
September 17, 2026 at 07:00 AM
commercetools is built on the idea that a merchant should pick the best tool for every job and connect them through APIs. That composable model is exactly why growing brands choose it, and it applies to payments as much as to search, tax or PIM: nothing is bundled, so you are free to work with the providers that fit each market.
The flip side shows up a year or two in. A card acquirer went in first. Then a BNPL provider, because customers kept asking for instalments. Then a local wallet for the market you expanded into. Then an invoice provider for the business buyers who started ordering through the same storefront. Each one arrived as its own connector, with its own processor logic, its own frontend component, its own credentials and its own release cycle. The architecture is clean; the payments layer inside it quietly became a collection of point integrations.
That is not a criticism of commercetools. It is the natural result of a platform that hands you the building blocks and lets you decide how to assemble them.
commercetools has done real work to make payments easier to add. Connect is a managed runtime for integrations, so a payment connector no longer needs its own hosting, and the payment integration template gives developers a standard shape to build to: an enabler application that renders the payment method in the frontend and keeps sensitive data out of your PCI scope, and a processor application that handles the transaction lifecycle. The Connect marketplace lists ready-made connectors for well-known providers, and commercetools Checkout can host several of them side by side.
The template is explicit about where that leaves a merchant, though: developers still have to "implement the final API calls to the selected PSP." Every provider is its own connector, built or installed, configured and maintained, and commercetools itself states that it "is not responsible or liable for any Connectors" built by third parties.
Even the happy path illustrates the point. commercetools' own guide to running two PSPs in Checkout walks through installing two connectors, building a complete checkout application, defining routing rules by geography, currency and transaction size, integrating the SDK and monitoring events. Two providers, five steps, and the routing logic lives in your Checkout configuration. The moment you want a third provider, a local method that has no marketplace connector yet, or a B2B invoice flow with a credit check, you are back to building.
Why does it matter commercially? Because payment method availability still decides checkouts. Baymard Institute's long-running checkout usability research finds that roughly 9% of shoppers who abandon a cart do so specifically because there were not enough payment methods available. On a platform chosen precisely for multi-market growth, "we will add that method next quarter when the connector is ready" is a conversion cost, not a technical footnote.
A payment orchestration layer changes the unit of work. Instead of one connector per provider, commercetools talks to one payment integration, and that integration talks to every provider behind it.
For a commercetools merchant that means three practical things:
commercetools Checkout and an orchestration layer are not competing ideas. Checkout is where the shopper experience is assembled; orchestration is what sits behind the payment step so that the experience does not need to be rebuilt every time the provider list changes.
commercetools is unusual in how many of its merchants serve both consumers and business buyers, often from one project with several stores. Payments are where that split is most visible. A consumer wants a card, a wallet or an instalment option in one tap. A business buyer wants a credit check, invoice or account terms, and a purchase order reference, sometimes in the same session where the person next to them is buying as a consumer.
Handled connector by connector, that usually means two payment stacks: a consumer set and a separate invoice or trade credit integration, with decisioning logic written into your own code to work out which one applies. An orchestration layer built for both customer types removes the split. The storefront registers one payment step; the layer underneath identifies the buyer type and serves the right methods, credit decisions and terms. Our own analysis of B2B checkout speed shows why that matters: business buyers stall in exactly the places where a consumer-first flow forces them to improvise.
None of this means every commercetools project needs an orchestration layer from day one. A single market with one or two payment methods and a marketplace connector for each is fine, and commercetools makes that path straightforward. The question arrives when the roadmap includes another market, a local method the marketplace does not cover, a switch of acquirer, or business buyers alongside consumers. At that point the connector-by-connector model starts costing more in development time than it saves in provider choice, which is the opposite of what composable was supposed to deliver.
Briqpay's connector for commercetools is built around the pattern described here: one integration into your commercetools project, an orchestration engine behind it that connects any payment provider, and rules for B2C and B2B checkout configured in a merchant portal rather than in code. You contract directly with your providers; Briqpay supplies the layer that lets you change your mind about them later.
The same architecture on other platforms is covered in payment orchestration on Magento 2 and payment orchestration on PrestaShop. If you are comparing orchestration providers for a composable stack, how Briqpay compares with Primer covers the main differences for European merchants. And for the bigger picture on why payment mix, not any single method, is what moves conversion and cost, see what actually reduces checkout costs and cart abandonment.
We analyzed Briqpay's own B2C checkout data across more than a dozen markets and found that speed has quietly converged almost everywhere. What still separates a good checkout from a bad one is whether it offers the payment methods a market actually prefers.
Every new payment method on PrestaShop usually means another module to install, configure and maintain. Here is how a payment aggregator changes that, giving merchants access to more payment methods, the ability to mix providers by market, and a single way to serve both B2C and B2B checkout.
Sweden just ran a live test of how its regulators handle a hard credit-licensing deadline, and most of the market didn't survive it. We look at what the July shakeout tells us about November 20, why most of the EU still isn't ready for CCD2, what critics are saying that Klarna isn't, and why the application date landing one week before Black Friday changes how merchants should plan the next ten weeks.
Connect any payment provider. Optimize your payment flow. Scale without limitations - with Briqpay’s Payment Integration Platform.
