How to Connect Stripe to Salesforce: A UK Business Guide

If your revenue runs through Stripe but your sales and customer teams live in Salesforce, there's a gap between where the money is collected and where the relationship is managed. Connecting the two means payments, subscriptions, invoices and failed-charge alerts show up against the right Accounts and Opportunities. Your team can see MRR and churn without exporting CSVs, and credit control stops being a finance-only job.

This guide covers why UK businesses connect Stripe to Salesforce, the three realistic routes (AppExchange apps, iPaaS, and a custom build), exactly what data flows in which direction, how to handle subscriptions, MRR, failed payments and dunning, and the gotchas that catch people out.

Why connect Stripe and Salesforce at all

The short answer is visibility and less re-keying. A customer's money lives in Stripe; their relationship, pipeline and history live in Salesforce. When the two don't talk, you get blind spots.

Concretely, teams want:

• Payments and invoices visible on the Account. Account managers can see what a customer has paid, what's outstanding and when, without logging into Stripe or asking finance.
• Subscriptions surfaced in the CRM. Plan, MRR, renewal date and status sit on the Account, so renewals and upsells are driven by real numbers.
• Closed-won Opportunities that create or link a Stripe subscription or charge, instead of someone setting up billing by hand after every deal.
• Failed-payment and dunning alerts in front of the people who own the relationship, not buried in a Stripe email nobody reads.
• Joined-up reporting — pipeline value, won revenue, live MRR and churn in one place.

You don't need all of this on day one. The single best predictor of a project that ships is tight scoping: "successful payments and subscription status show on the Account, and failed payments create a task for the owner." Start there.

What data actually flows, and in which direction

Before choosing any tool, get specific about the objects and the direction of travel. Stripe and Salesforce model the world differently, so the mapping matters. A typical setup looks like this.

Stripe object	Salesforce object	Typical direction	Notes
Customer	Account (or Contact)	Bidirectional, or SF → Stripe	Store the Stripe Customer ID on the Account as the link key
Charge / Payment Intent	Payment (custom object)	Stripe → Salesforce	Amount, date, status, currency
Invoice	Invoice (custom object)	Stripe → Salesforce	Number, status, due date, amount
Subscription	Subscription (custom object)	Stripe → Salesforce	Plan, MRR, status, current period end
Subscription item / Price	Product / Pricebook Entry	Often SF → Stripe at deal close	Map SKU, interval and amount
Closed-won Opportunity	Subscription / Charge	Salesforce → Stripe	The quote-to-cash trigger, if you bill from the CRM
Failed payment event	Task / Case	Stripe → Salesforce	Drives dunning and credit-control workflow

A few decisions fall straight out of this table:

• Who owns the customer record? If sales creates Accounts first, Salesforce pushes new customers into Stripe at billing time. If self-serve signups happen in Stripe, Stripe is the source of truth and creates Accounts. Pick one owner per field; split ownership is fine as long as it's explicit.
• Salesforce has no native billing objects. There's no standard Subscription or Payment object, so you (or your connector) create custom objects to hold this data. How well a tool models subscriptions is the main thing that separates good connectors from weak ones.
• Decide what's read-only. Most billing data should land in Salesforce as read-only display fields. You rarely want a salesperson editing an invoice amount that then writes back to Stripe.

The three ways to connect Stripe and Salesforce

There's no single best method. It depends on your volume, how complex your subscriptions are, and how much custom logic you need.

Approach	Best for	Strengths	Weaknesses
AppExchange connectors	Standard payment and subscription sync	Fast to deploy; vendor-maintained; prebuilt CRM objects and views	Subscription/per-record pricing; opinionated mappings; limited custom logic
iPaaS (Zapier, Make, Workato, Boomi, Celigo)	Flexible, multi-system flows	Branching and filters; brings in other tools; visual and inspectable	You own the logic and error handling; event/task pricing climbs at volume
Custom API build	High volume, bespoke billing logic	Exactly your rules; no per-record fees; full control	Highest upfront cost; you own maintenance; needs a competent owner

Option 1: AppExchange connectors

Several products on the Salesforce AppExchange connect Stripe to Salesforce — connectors such as Breadwinner and Chargent are common starting points — installing as managed packages with their own custom objects, tabs and dashboards. They're the fastest route to payments and subscriptions appearing in the CRM. Shortlist on how well each one models subscriptions and MRR, not just one-off charges.

Strengths: quick to a working sync for standard objects; the vendor handles Stripe and Salesforce API changes; subscription, MRR and payment views often come out of the box.

Weaknesses: subscription or per-record pricing that scales with you; opinionated field mappings you may have to bend your process around; limited conditional logic (routing UK vs EU customers to different Stripe accounts, for example, is often awkward). As an indicative UK figure these tools commonly land in the region of a few hundred pounds per month — always check current vendor pricing rather than relying on a rule of thumb.

Best when your billing is fairly standard and you value speed and low maintenance over flexibility.

Option 2: iPaaS

Zapier, Make and heavier platforms like Workato, Boomi and Celigo sit between the two systems and move data via prebuilt connectors and visual workflows. Stripe and Salesforce both have mature connectors on the major platforms, and Stripe's webhook events map neatly onto iPaaS triggers.

Strengths: flexible branching, filters and lookups; you can bring in a third system (an accounting tool, a data warehouse, Slack) without a separate project; visual, inspectable run history.

Weaknesses: you own the workflow logic, error handling and edge cases — the platform only maintains the connectors. Event- or task-based pricing can creep as transaction volume grows, so model your monthly event counts first. And naive setups break on the awkward cases (a subscription upgrade mid-cycle, a partial refund, a deleted customer) unless you build in handling.

Best when you need more flexibility than a packaged connector gives, or when Stripe and Salesforce are two of several systems you're joining up. Our iPaaS implementation work covers exactly this middle ground, and our comparison of Zapier vs Make vs custom integration goes deeper on the trade-offs.

Option 3: Custom API build

A bespoke integration talks directly to the Stripe API and the Salesforce REST and Bulk APIs, hosted on your own middleware (a small service or serverless functions) and driven by Stripe webhooks.

Strengths: exactly your process — any object, any subscription logic, any conditional routing, any volume — with no per-record platform fees and full control over retries, logging and security.

Weaknesses: highest upfront cost and longest time to first sync; you own maintenance when Stripe or Salesforce change their APIs; and it needs a competent owner. As an indicative UK market range, a focused two-way build typically runs into several thousand pounds and up depending on scope. Treat that as a range to sanity-check quotes against, not a price.

Best when volumes are high, your billing logic is genuinely non-standard, or per-record iPaaS costs would exceed a build over three years. Our Salesforce integration and API integration services explain how we approach these. The pattern overlaps closely with a QuickBooks to Salesforce integration if you also need finance data in the CRM.

Subscriptions and MRR: where it gets interesting

Connecting one-off charges is easy. Subscriptions are where most projects earn their keep, because Stripe's billing model is rich and Salesforce has nothing native to receive it.

• Model MRR deliberately. Stripe gives you subscription amounts and intervals; converting an annual plan to a monthly recurring figure, handling discounts, and excluding one-off line items is logic you (or your connector) must define. Decide whether MRR is calculated in Stripe, in the integration layer, or in Salesforce — and keep it consistent.
• Handle the whole subscription lifecycle, not just creation. Upgrades, downgrades, pauses, cancellations and trial-to-paid conversions all change MRR. A sync that only catches new subscriptions will quietly drift out of date. Listen for the full set of customer.subscription.* events.
• Proration is real money. Mid-cycle plan changes generate prorated charges and credits. If your reporting ignores them, your invoiced figures won't match Stripe.
• Roll up to the Account. Customers often have several subscriptions. Decide how MRR and status roll up so the Account shows a true total, not one arbitrary line.

Failed payments and dunning

This is often the highest-value flow, because a failed renewal is a churn risk the relationship owner can usually save — if they hear about it in time.

• Trigger on the right events. invoice.payment_failed is the key signal; customer.subscription.deleted tells you a dunning sequence has given up and the subscription has lapsed.
• Put it in front of a human. Create a Task or Case for the Account owner, not just a field update. The point is that someone acts.
• Coordinate with Stripe's own dunning. Stripe Smart Retries and dunning emails are already chasing the card. Your Salesforce workflow should complement that — a personal call after the second failure, say — not duplicate it or fire on the first soft decline.
• Reflect recovery, too. When a retry succeeds, clear the alert and update status. Stale "payment failed" flags erode trust in the data fast.

The gotchas that catch UK businesses out

• Match on stable IDs, not names or emails. Store the Stripe Customer ID on the Salesforce Account (and the Salesforce ID in Stripe metadata). Matching on company name or email creates duplicates the first time someone types the name slightly differently. Stripe's metadata fields are the clean place to hold the link.
• Webhooks need delivery guarantees. Stripe retries failed webhooks, but your endpoint must verify the signature, be idempotent (the same event can arrive twice), and acknowledge fast. Missed or double-processed events are the most common cause of silent drift.
• Mind the API limits. Salesforce enforces daily API call limits and rate limits; the Bulk API and sensible batching matter once you're moving more than a trickle of records. A chatty integration can exhaust an org's API allowance.
• Currency and VAT. If you sell in multiple currencies, decide whether you store the charge currency or a settlement figure, and be consistent. Stripe Tax may calculate VAT on invoices — make sure the figures you surface in Salesforce match what the customer was actually charged, and leave the accounting treatment to your finance system rather than reinventing it in the CRM.
• Test on sandboxes first. Use Stripe test mode and a Salesforce sandbox or Developer Edition org — never build against live data. Test the awkward cases on purpose: a mid-cycle upgrade, a partial refund, a failed-then-recovered payment, a customer deleted on one side.
• Plan for failure. Confirm your chosen approach has retries with backoff, an error log or dead-letter queue, and a notification when something doesn't sync. Silent failures are the worst outcome: finance and sales trust the data right up until the day they shouldn't have.

A decision framework

1. Is your billing standard? One-off charges and simple subscriptions, payment status back to the Account, nothing exotic. If yes, start with an AppExchange connector — fastest path, vendor-maintained.
2. Do you need branching, custom logic, or more than two systems? If yes, look at iPaaS. Zapier or Make for lower volume; Workato, Boomi or Celigo for higher volume and richer orchestration.
3. Are volumes high, the subscription logic genuinely bespoke, or would iPaaS per-event costs exceed a build over three years? If yes, go custom.
4. Do you have someone to own it? Custom and complex iPaaS both need an owner. If you don't, factor in support — or choose the lower-maintenance option.

Run the three-year total cost of ownership, not just the upfront number. A connector at a few hundred pounds a month is several thousand pounds over three years — that comparison often changes the decision.

How APIwise can help

We're UK-based, senior and vendor-neutral, so we'll tell you honestly whether an AppExchange connector, an iPaaS workflow or a custom build fits your Stripe and Salesforce setup — rather than defaulting to the most expensive option.

Our fixed-price Integration Health Check maps your objects and fields, pins down sync direction, subscription and MRR logic, and your failed-payment workflow, then gives you a clear, costed recommendation across all three routes. From there we can deliver the build fixed-scope and fixed-price.

Learn more about our API integration, AI automation and data integration services and our Salesforce integration work, or book your Integration Health Check and we'll get your payments and pipeline talking to each other properly.