When (re)designing an application landscape around Salesforce, every architect and Salesforce team eventually face the same question: where should payments actually live?

Closed deals, membership details, and other customer-related information live in Salesforce. Finance, meanwhile, needs to account for every transaction flowing through the general ledger. Somewhere between those two touchpoints, an actual payment transaction takes place. The decision about where that payment is orchestrated shapes everything downstream: how quickly invoices get paid, how reliable your revenue reporting is, how much manual reconciliation your finance team has to do each month, and how smooth (or frustrating) the payment experience feels to your customers.

This guide walks through the two main approaches to payment processing related to Salesforce: connecting a payment service provider (PSP) directly and backloading the results, or using a native Salesforce payment application. It explains what "native" actually means, where a direct integration is genuinely sufficient, where it isn't, and how to make the call for your organization.

What "payment processing in Salesforce" actually means

Before comparing approaches, it helps to be precise about the pieces involved — the terms get used loosely, and that's where confusion starts.

A payment gateway is the secure channel that captures a customer's payment details and passes them along for processing. A payment processor — usually a PSP such as Stripe, Adyen, Mollie, GoCardless, or Worldpay — is what actually moves money between banks. Salesforce is neither of these. It's the system of record where customer data lives, and (ideally) where payment data should live alongside it.

When people talk about "processing payments in Salesforce," they're really talking about how PSPs connect to Salesforce. There are three broad patterns:

• Direct PSP integration — Salesforce talks to one PSP through a custom-built or pre-built connector. The PSP handles the money; Salesforce receives a record of what happened, sometimes in real time, sometimes not.
• Native Salesforce payment app — an application built on the Salesforce platform that manages payment processing, recurring billing, reconciliation, and recovery inside Salesforce, while connecting to one or more PSPs behind the scenes.
• External billing system synced to Salesforce — payments are managed in a separate platform (NetSuite, Stripe Billing, an ERP) and synced back to Salesforce through integration.

This article focuses on the first two, since they're the most common choices for organizations whose primary system of record is Salesforce.

Option 1: Direct PSP integration

This is the most straightforward setup. A payment form on your website or portal sends payment details to a PSP. The PSP processes the transaction and, depending on how the integration is built, sends a record of the result back to Salesforce.

When it works well

• You only process one-time payments — no subscriptions, memberships, or recurring donations
• You use one PSP and one or two payment methods (typically credit card)
• You don't need real-time payment status inside Salesforce — a daily sync is fine
• Your customer base is concentrated in a single region with uniform payment preferences

For organizations that fit this profile, a direct integration is genuinely fine. There's no reason to add layers you don't need.

Where it gets difficult

The complications emerge when payment needs grow — which they almost always do.

Adding payment methods or PSPs. Every new connection is a separate integration project. Want to offer ACH alongside cards? SEPA Direct Debit for European customers? A local method like iDEAL or TWINT? Each one means new development, new testing, new maintenance.

Recurring payments. Subscription and membership models need indexation, mandate management, payment schedules, and retry logic for failed collections. Most direct integrations handle one-time payments well and treat recurring as an afterthought, leaving you to build the hard parts yourself.

Reconciliation. When payment data lives in the PSP and customer data lives in Salesforce, matching them is manual work. Finance teams export PSP reports, cross-reference them against Salesforce records, and chase down mismatches every single month.

Visibility. A support agent looking at a customer record in Salesforce often can't see the latest payment status without logging into a separate PSP dashboard. That means slower service and more internal back-and-forth.

Failed payment recovery. When a payment fails, a typical PSP retries once or twice and then gives up. There's no native way to run dunning sequences, offer alternative payment methods, or trigger recovery workflows from inside Salesforce — and failed payments quietly become lost revenue.

Option 2: Native Salesforce payment processing

Native payment apps on the AppExchange, such as FinDock, which is built specifically for organizations running recurring revenue on Salesforce, manage the full lifecycle from inside the CRM. Payment data lives inside Salesforce as records, alongside your accounts, contacts, and opportunities. The app connects to one or more PSPs behind the scenes, but the orchestration, reporting, reconciliation, and recovery all happen in the CRM.

What changes operationally

One source of truth. Payment status, customer history, and account data live together. Support agents see everything on one screen. Finance reports directly from Salesforce instead of stitching together PSP exports.

Multiple PSPs, one experience. A native layer can route each transaction to the right PSP based on payment method, region, cost, or compliance requirements — without your team or your customers ever seeing that complexity.

Real-time visibility. Payment events update Salesforce records as they happen, via webhooks. No nightly syncs, no stale data, no spreadsheet reconciliation.

Built-in recurring billing. Mandates, payment schedules, retries, and failed payment recovery are configured in Salesforce, not engineered from scratch. For organizations running memberships, subscriptions, or recurring donations, this is usually the single biggest operational difference.

Reduced PCI scope. All good Salesforce native payment solutions are fully PCI compliant; card data is tokenized and Salesforce stores only references. Compared to a custom-built integration, this meaningfully narrows your compliance footprint.

The trade-off

A native payment layer adds a licensing cost and a configuration step. For an organization processing a small volume of simple, one-time card payments, that's overhead without payoff. For an organization managing recurring revenue, multiple payment methods, or reconciliation across PSPs and bank statements, the time saved typically outweighs the licensing cost within a quarter or two.

Direct PSP vs native payment app: side by side

The bonus feature of Salesforce native payment processing: Context-aware payment orchestration

A feature many organizations don't even really consider upfront, but which proves to be invaluable down the line, is payment orchestration. It is the layer that decides, for each customer and each transaction, which PSP, merchant account, payment method, and channel to use. Without it, every payment follows the same route whether or not that route is the best one. With it, you can route based on cost, success rates, geography, regulation, or customer preference.

A few concrete examples of what that looks like:

• A UK customer makes a one-time payment → routed to a card processor with strong UK acceptance rates and competitive fees
• The same customer signs up for a monthly recurring plan → routed to a processor that supports recurring authorizations, which the first one may not
• A Swiss customer wants to pay with TWINT, a local payment method → routed to the one PSP in your stack that supports it
• A German customer prefers SEPA Direct Debit → routed through bank file processing rather than a card PSP, cutting transaction costs significantly
• A US customer wants to pay a large B2B invoice by ACH bank transfer → routed to a processor that supports ACH directly, avoiding the hefty card fees that would apply to the same transaction on a card PSP

Without orchestration, each of these scenarios is a separate integration — or simply an option you can't offer. With it, customers see the right payment methods for their context, and each transaction takes the most efficient path.

If you operate in one region with one payment method, you don't need orchestration. If you operate across regions, run recurring billing, or want to optimize transaction costs, it becomes a genuine differentiator. For a closer look at how this works in practice, see our breakdown of FinDock versus direct PSPs.

How to choose: five questions

What about Salesforce Payments — the native Salesforce option?

Salesforce offers its own payments product, Salesforce Payments, bundled with certain Commerce Cloud and Order Management licenses and powered by Stripe. For organizations already running Salesforce Commerce, it's a reasonable option for commerce-driven transactions.

Bottom line

For simple, single-PSP, one-time payment processing, a direct PSP integration is sufficient — don't overengineer it.

For most organizations that use Salesforce as their system of record and run recurring revenue, multiple payment methods, or multi-region operations, a native payment layer pays for itself quickly: less manual work, faster reconciliation, better visibility, more recovered revenue.

The right way to decide isn't to pick the "best" option in the abstract. Map your actual payment operations against the five questions above and find where the friction is. That friction is where the ROI sits.