Payment Gateway and BNPL Integration

Connecting a gateway, wallet or buy now pay later provider to the store's payment step and to everything behind it: tokens for saved cards, 3-D Secure rules, webhooks that confirm the payment, capture and refund flows from the admin, and the settlement data your finance system reconciles. On a live store it also means a staging build, test orders on every method and a release window with the old method still available.

Stripe, Adyen, Braintree, PayPal and Authorize.net on the merchant side, plus each platform's own layer where it fits: Shopify Payments, Adobe's Payment Services, WooPayments and the gateways BigCommerce pre-integrates. If you are a payment provider rather than a merchant, the plugin and app work for your merchants is on its own page, payment plugin development.

Yes. Klarna publishes a free Adobe Commerce extension on the Commerce Marketplace for versions 2.4.4 and later, and Affirm publishes an Adobe Commerce extension and a pair of Shopify apps; on WooCommerce the Stripe extension carries Klarna, Afterpay and Affirm as payment options. We install and configure the provider's module where one exists, build the connection where it does not, and add on-site messaging that shows an instalment price only on the products and basket sizes your agreement allows.

Shopify charges a third-party transaction fee on orders paid through a gateway other than Shopify Payments: its pricing page lists 2% on Basic, 1% on Grow, 0.6% on Advanced and 0.2% on Plus, with PayPal exempt when Shopify Payments is your primary provider. Whether a third-party gateway still wins depends on its own rates, your markets and the methods you need, which is arithmetic we run with you before anything is built.

Through a payment module. Adobe bundles Payment Services, PayPal and Braintree; every other gateway and buy now pay later provider is installed as an extension from the Commerce Marketplace, which is where Klarna and Amazon Pay have lived since release 2.4.4. We configure the module, wire its webhooks, test capture, refund and void from the admin, and check it against the theme and the checkout you run, whether Luma, Hyvä or a PWA.

No. The new method is built and tested on staging, then released in a window with the old method still live, so a customer always has a way to pay. If anything misbehaves the new method is switched off and the store carries on as before. The old gateway is retired only after the first settlement has reconciled.

An extra authentication step at the customer's bank, branded Visa Secure, Mastercard Identity Check or American Express SafeKey, that shifts liability for fraud away from you. Strong Customer Authentication under PSD2 has required it for most card payments in the European Economic Area since 14 September 2019, with similar rules in the UK and some other markets; elsewhere it is optional and used to cut fraud. The work is in the rules: challenge the orders that need it and let the rest through.

Yes, through tokenisation at the gateway. The card number is exchanged for a token the gateway holds, so a returning customer pays in one click and no card data ever touches your servers or your database. The same tokens carry subscriptions and renewals.

It depends on how card data reaches the gateway. A redirect or a gateway-hosted field keeps the store in the lightest category, SAQ A; a payment form you render yourself is SAQ A-EP, with far more to prove. Since 31 March 2025 PCI DSS requirements 6.4.3 and 11.6.1 ask merchants to keep an inventory of every script on the payment page, authorise each one, check its integrity and detect tampering as the browser receives the page; the January 2025 revision of SAQ A removed those two from the questionnaire but added an eligibility test that a site with an embedded payment form is not open to script attacks. This is general information, not compliance advice. Your acquirer or QSA decides your questionnaire; we build the checkout so the answer is an easy one.

The store is the system of record for the order, the gateway for the money, and the ERP for the books, so each event is written once and flows one way: a refund issued in the admin reaches the gateway and the ERP without being keyed again, a dispute opened at the gateway is logged against the order, and the daily settlement is matched to orders automatically. The reconciliation report is what tells you the three agree.

Yes, usually through the gateway you already have. Both need the domain verified with the wallet provider, the right certificates and merchant identifiers, and a payment request flow at the checkout and as an express button on the cart. The work is small and the effect on phone conversion is usually the largest of any change on this page.

One method through a platform's own module, with testing and a release window, is usually one to two weeks. A gateway switch with reconciliation into the ERP runs four to six weeks. Subscriptions, multi-currency and markets with their own regulations take longer, and the map at the start gives you the timeline for your store rather than an average.

A fixed fee for a fixed scope, agreed after the map, when we know the platform, the methods, the markets and what the ERP needs. There is no price list on this site because a single wallet on Shopify and a gateway switch across four countries are not the same job.

Partly, and it is worth doing. Soft declines are retried intelligently, expired cards on subscriptions are refreshed through the gateway's updater where the card schemes allow it, customers are told what went wrong in plain words with a way to try another method, and the decline rate is reported so the pattern, not the symptom, gets fixed.