Payment Plugin Development for PSPs and BNPL Providers

Magento 2 and Adobe Commerce, Shopify, WooCommerce, BigCommerce and SAP Commerce, each as a native plugin on that platform's own payment model rather than a port of another. The five-platform BNPL program on this site covers all of them. If your merchants run a platform not on that list, say so on the call; the specification work is the same and the build is scoped per platform.

We cannot grant approval; Shopify does. Only approved Partners may build payments extensions, and every payments app is approved by Shopify under its Payments Partner terms, revenue share included. What we do is build to the published requirements, prepare the submission, answer the review questions and iterate with the reviewers until the listing is live. The Payments Partner relationship is yours.

We build so card data never touches the merchant's server: hosted fields, tokens or a redirect depending on the platform and the method, and on Adobe Commerce the payment provider gateway, which is designed for integrations that store no sensitive card data. The merchant's scope is reduced by that design; your own PCI obligations as the provider remain yours and your assessor's. This is not compliance advice.

The method appears in the merchant's brand, not yours: its name, its position among the other payment options, the look of the on-site messaging on product and cart pages, and the checkout presentation, all set from the plugin's settings by the merchant without code. Your brand can still appear where you want it, as a setting rather than a default.

Yes, and for an instalment method it matters more than the checkout, because the shopper decides on the product page. The messaging widget reads the price and the eligibility rules from your API, renders in the store's own typography and colours from the plugin's settings, and sits where the merchant places it on product, cart and checkout pages. On the BNPL program it ships White Label on every platform.

The specification takes a few weeks, because it has to read each platform's rules against your payment flows. A single platform plugin follows in weeks to a few months depending on the flows, the review rounds and the test coverage you need; a multi-platform program runs the builds in parallel from the one specification. The platform review itself is on the platform's clock, not ours.

Per platform, after the specification, as a fixed scope. The specification is the paid first step because it decides the size of each build; the platform review rounds and release compatibility after launch are priced with it. There is no price list on this site because no two payment flows need the same work.

You do. Every plugin lives in your repository under your marketplace accounts, with the documentation a future developer needs. We hold no licence over it and no key to it once the engagement ends, which is also what the platform marketplaces expect of a listing published in your name.

Yes. Each platform's releases are tested against the plugin before they reach merchants, the fixes ship as a plugin update, and compatibility with other payment methods, apps and extensions is checked in the same run. That is the support the BNPL program has had for years, and it is where most plugin programs go wrong when it is missing.

Yes. We read the code and the marketplace listings, list what breaks on current platform releases and what the review rules now require, then stabilise before we extend. Where a plugin was one codebase stretched across platforms, the usual answer is a native rebuild per platform on a shared specification, done one platform at a time so nothing goes dark.

Yes, both were part of the five-platform BNPL program. BigCommerce has its own payment integration model and marketplace; SAP Commerce is the enterprise platform larger merchants run, where the plugin is built as an extension to the merchant's own installation rather than a marketplace listing. Each is built to its platform rather than ported.

If you want us to. Most providers keep first-line support in-house and route plugin issues to us; some have us answer merchants directly on installation, customisation and compatibility, as we have done for the BNPL program for years. Either way the fixes ship as plugin updates to every merchant, not as one-off patches.

A sandbox account and credentials, your API documentation and the flows you support (authorize, capture, refund, void, messaging), your brand assets and White Label rules, the marketplace and partner accounts the listings publish under, and a person on your side who can answer questions. With those the specification starts the same week.