Heading 1
Heading 2
Heading 3
Heading 4
Heading 5
Heading 6
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
Block quote
Ordered list
- Item 1
- Item 2
- Item 3
Unordered list
- Item A
- Item B
- Item C
Bold text
Emphasis
Superscript
Subscript
A payment service provider (PSP) is the company that accepts and processes online payments for you: cards, wallets, bank transfers, vouchers and more. Once live, it sits in every order. Switching later means a new integration, new contracts and a checkout retest across every market, so the choice tends to stick for years.
Start with how you sell, then pick the provider
The right PSP is the one that covers the payment methods your customers already expect in each market. Cards and wallets are universal. Local methods decide conversion in specific countries, and vouchers such as meal and eco vouchers matter for some retailers in Belgium. List the methods per market before you compare providers.
Your business model narrows the field further. Subscriptions need recurring payments. Marketplaces need split payments, where one transaction is divided between vendors and the platform takes its fee, which only some providers support well. Payment links let service teams close an open order by phone or chat. A provider that is strong on cards but weak on your model will cost you in workarounds.
Salesforce also offers its own payments option for B2C Commerce, Salesforce Payments, in selected markets. It deserves a place on the shortlist and should be judged on the same criteria as any independent provider: coverage, business model fit and how it handles refunds.
How the integration works on Commerce Cloud
On Salesforce Commerce Cloud (Agentforce Commerce), most providers connect through a LINK cartridge, a pre-built integration listed on the Salesforce AppExchange. Before we plan any payment integration, we check three things. Is there a cartridge for this provider? Does it support the storefront version the merchant runs? And do existing customisations in the checkout clash with how the cartridge works?
Those answers set the effort. A standard checkout with a maintained cartridge is a contained piece of work. A heavily customised checkout can turn the same integration into a project of its own. Storefront architecture matters too: many cartridges were written for SFRA, while a headless storefront usually integrates through the provider's own APIs and components. That is one of the practical sides of headless commerce with the Composable Storefront.
What we have learned building payment integrations
FORWARD does not only implement existing LINK cartridges. We have also worked with payment providers, including Mollie and SIX Payment Services with Saferpay, on building LINK cartridges for the AppExchange. Building one shows you where integrations usually break: order status updates that arrive out of sequence, partial captures on split shipments, and refunds that never reach the original payment.
That experience changes the questions we ask a provider. A long list of payment methods matters less than how cleanly the provider reports back what happened to each transaction. Clear notifications from the PSP to the storefront are what keep orders, stock and finance in step.
