The short version
- There are four real routes: Stripe's own $1 Platform app, paid gateway-agnostic connectors like Chargent and Blackthorn, native Salesforce Payments inside Revenue Cloud Billing, and custom Apex. They solve different problems, and the wrong pick is expensive either way.
- Stripe's official app mirrors Billing objects and adds Flow and Apex actions, but it pins an API version from April 2025 and carries a 3.68/5 AppExchange rating; the paid connectors rate near 4.9+ and support many gateways, not just Stripe.
- Custom Apex is the right call when billing logic is your business process: computed amounts, invoice-versus-charge decisions, subscription schedules, and webhook-driven sync, the pattern we run in production for Storehouse.
- Whatever you pick, the production bar is the same: idempotency keys on every POST, webhook signatures verified against the raw body, event-ID dedupe because Stripe guarantees neither order nor uniqueness, keys in Named Credentials, and Stripe Elements in an iframe to stay in PCI SAQ A territory.
The Short Answer
There is no single Salesforce Stripe integration. In 2026 there are four real routes, and teams get burned by picking on price or habit rather than on what they actually bill. This is the landscape as it stands, verified against Stripe's current docs and live AppExchange listings, and then the build pattern we use when custom is the right answer, including the one we run in production for a tax and wealth firm that invoices from the case record itself.
The Landscape: Four Ways In
Here is what each route actually is, with the numbers that matter:
- Stripe's own app for Salesforce Platform. One dollar on AppExchange, built by Stripe. It mirrors Stripe Billing objects into custom objects, adds Stripe actions to Flow Builder and Apex, syncs both ways, and ships quote-to-subscription templates. Two honest caveats: the managed package pins Stripe API version 2025-04-30, roughly sixteen months behind Stripe's current release, and its AppExchange rating sits at 3.68 from 19 reviews, with practitioners most often citing customer matching between Stripe Customers and Salesforce Accounts as the pain. There is also an unmanaged Billing Extension for CPQ and Salesforce Billing orgs (cards and US ACH only), and a separate cartridge for B2C Commerce Cloud.
- Paid AppExchange connectors. Chargent (from $667 per month, 4.93 from 529 reviews) and Blackthorn Payments (from $4,800 per year, 4.97 from 181 reviews) are the incumbents, with Payments2Us (from $300 per year) strong for nonprofits and Asperato for direct-debit-heavy UK builds. The axis that matters: these are gateway-agnostic, Stripe is one of 30 to 120 supported processors, so they fit teams that want portals, virtual terminals, and collections tooling out of the box, or that may not stay Stripe-only.
- Native Salesforce Payments. Inside Revenue Cloud Billing, Salesforce's own payments layer supports exactly two providers, Stripe and Adyen. The catch, current as of early 2026: you cannot bring your existing Stripe account; Salesforce provisions a new merchant account. B2C Commerce has a documented 'Salesforce Payments with Stripe' configuration, and Data Cloud has a Stripe connector, but that one is analytics ingestion, not payment processing.
- Custom Apex. Direct API integration you own: your objects, your amounts, your approval logic, your webhook handling. Highest effort, highest fit. The rest of this post is about when it is right and how to do it properly.
How to Choose
The decision usually falls out of three questions. First, is your billing logic standard or is it your differentiator? Standard subscriptions with list prices fit Stripe's app or a connector; amounts computed from your own fields and approval flows point custom. Second, are you Stripe-only for the foreseeable future? If you might add processors, the gateway-agnostic connectors earn their subscription. Third, who owns it after go-live? A connector gives you a vendor to call; a custom build gives you code your team must test and maintain, which is only a win if you have (or hire) that team.
One honest rule from the field: do not buy a $8,000-a-year connector to press one Charge button, and do not hand-build what a $1 package already does. The expensive mistakes are symmetric.
The Custom Build, Done Properly
When custom is right, the shape we ship looks like the build behind our Storehouse case study: a Send Invoice button on the case that reads the engagement's own rate fields, computes the amount, lets staff choose between a finalized Stripe invoice and an immediate charge, runs recurring engagements on Stripe subscription schedules, and keeps customers and payment methods in sync through a webhook listener. The named Apex classes behind it carry 85 to 100 percent test coverage. Under that shape sit the API norms that make it production-grade:
- Pin your API version explicitly. Stripe now ships monthly non-breaking releases plus twice-yearly majors that can break (the current version is 2026-08-26.dahlia). Send the Stripe-Version header on every Apex callout rather than riding the account default.
- Idempotency keys on every POST. Stripe replays the saved response on retry, so a timeout plus a retry never double-charges. Generate a V4 UUID per logical operation; keys live about 24 hours.
- PaymentIntents for custom flows, Checkout Sessions where you can. Stripe now steers most new builds toward Checkout Sessions with the Payment Element; keep bare PaymentIntents for the flows you genuinely control end to end.
- Subscription Schedules for anything with phases. Up to ten phases, backdating, per-phase proration, and end_behavior=cancel for installment plans. This is the right object for annual engagements billed monthly, not hand-rolled scheduled jobs.
- Verify webhooks against the raw body. HMAC-SHA256 with the whsec secret over timestamp plus raw payload, constant-time comparison, five-minute tolerance, secret stored in Protected Custom Metadata or an External Credential, never in code.
- Return 200 fast, process async, dedupe by event ID. Stripe retries failed deliveries for up to three days, guarantees neither ordering nor uniqueness, and will happily deliver invoice.paid before invoice.created. Acknowledge immediately, queue the work, and make every handler idempotent.
- Keys live in Named or External Credentials. Salesforce encrypts them and keeps them out of debug logs and exports. Hardcoded keys in Apex or Custom Settings are the anti-pattern that fails a security review.
- Respect the callout ceilings. 100 callouts per transaction, 120 seconds cumulative, and no callouts after uncommitted DML. Even Stripe's own package added a setting to reorder DML around callouts; design for it from day one.
The Gotchas That Bite in Production
Every one of these is a real incident we have either fixed or designed out:
- Refunds are not the reverse of a charge. Stripe's processing fees are not returned, refunds go only to the original payment method, and a refund can fail up to 30 days later if the destination account closed. Handle refund.updated and refund.failed, not just the happy path.
- Disputes debit you immediately. A dispute reverses the payment and adds a network fee the moment it is created, and the Dispute object references the charge but not your invoice or subscription. Your Salesforce sync has to resolve that mapping itself, or finance reconciles blind.
- PCI scope is a design choice. Collecting cards with Stripe Checkout or Elements in an iframe served from Stripe's domain keeps you in SAQ A, the lightest self-assessment. Collect card data in your own page and you graduate to SAQ A-EP or SAQ D. This is why our builds embed the Payment Element rather than styling our own card form.
- Customer matching is the quiet killer. Whichever route you pick, decide early which system owns the customer identity and store the Stripe id on the Account. Most connector complaints and most custom-build cleanups trace back to this one decision made late.
The Honest Read
Stripe's own app is genuinely useful and absurdly cheap, and its API-version lag and matching complaints are equally genuine; it fits teams whose billing is standard and who accept the package's pace. The paid connectors are excellent products with the ratings to prove it, priced for teams that will use their breadth. Native Salesforce Payments matters if you live in Revenue Cloud Billing and can accept a fresh merchant account. Custom Apex is not the default; it is the specialist tool for when the way you bill is the way you compete.
That was exactly the Storehouse call: the amount of an invoice depends on engagement type, role-based rates, and fee schedules that live on their own records, and the person sending it is looking at a case, not a billing console. No package puts a correctly computed, client-ready Stripe invoice two clicks from the case. So we built it, tested it like product code, and it has been earning its keep since.
What We Would Do in Your Org
Bring us the three questions from the how-to-choose section and we will give you a straight answer, including 'buy the $1 app' when that is the truth. If the answer is custom, the pattern above is what we ship: you can read the field-tested version in our Stripe integration playbook and the business outcome in the Storehouse case study.
Book a free 30-minute scoping call at cal.com/cloudsheer-consulting/30min with your billing model in hand. Thirty minutes is usually enough to know which of the four routes you are on, and what it will cost either way. Our platform development team takes it from there.