Salesforce Stripe Integration: Reconcile Customers, Subscriptions and Payments

A Salesforce Stripe integration should connect the correct sales account to its billing records, preserve payment and subscription states, and make failures recoverable. Start with the Stripe app for Salesforce Platform when you need billing visibility and Salesforce automation. Decide separately whether Salesforce should create subscriptions or collect payments. Copying a paid invoice into the CRM does not, by itself, authorize a new charge or prove how much cash Stripe collected.

Jafrin Akter AloLast updated 29 October 202614 min read

On this page

Which Salesforce Stripe integration do you actually need?

Choose the integration according to who owns billing and which actions Salesforce must perform. Stripe's Platform app provides an integration builder, billing objects, synchronization and Flow or Apex actions. Its extensions serve different jobs, so confirm the package and workflow instead of asking only whether a product “connects Stripe.” Stripe Platform app overview For the Salesforce side of the build, see our Salesforce consulting.

The Billing Flows Extension is an unmanaged package with templates for subscription-schedule creation from Salesforce Order activation. Its flows and mappings can be adapted for Sales Cloud or Revenue Cloud, with or without CPQ. The Salesforce Billing Extension is a different unmanaged package that uses Stripe through the Salesforce Payment Gateway, including card and ACH payments.

An opportunity becoming Closed Won is a commercial milestone. Your design must decide whether that milestone merely updates visibility, prepares an order for approval or triggers a supported billing workflow. If the product application already creates subscriptions, do not give a second uncoordinated process the same responsibility.

For a team that only needs a trusted customer account page, start with visibility and reconciliation. Add subscription creation or payment actions after the billing owner has approved the inputs and stopping conditions. Include the required Salesforce edition, package entitlements and operating work in the Salesforce cost review.

What should you configure before syncing live billing data?

Configure the app in the intended test environment with a separate Stripe connection, then verify permissions, mappings and outcomes before production activation. Stripe's installation guide distinguishes test and production installations, calls for Lightning Web Security and recommends installing for administrators first. The wizard uses a publishable key and restricted access key and installs its documented API extension. Platform app installation

For a separate history load into custom objects your integration owns, follow the Bulk API 2.0 billing-history guide. Keep managed-package objects under their supported synchronization path.

1. Record the Salesforce organization, Stripe account and test or live environment for this connection.
2. Install the Platform app and the extensions required by the chosen workflow.
3. Complete the setup wizard with the appropriate restricted key and review who can access billing data or execute actions.
4. Configure the required billing objects, account associations and synchronization mode.
5. Reconcile a small set of representative source and destination records.
6. Enable downstream actions only after duplicate, failure and recovery tests pass.

Stripe says OAuth-based authentication is no longer offered from Platform app version 1.17; an existing OAuth connection uses the reauthorization path to API keys. The installation guide currently selects the 2025-04-30 API extension. Treat that as the app's supported extension choice, rather than assuming it is interchangeable with whichever Stripe API version another service uses.

When upgrading the API extension, update Flow actions and Apex nodes that reference the older version. Installing the newer extension does not update those references automatically. API extension upgrade behavior

For Salesforce sandbox clones, Stripe instructs teams to exclude stripeGC objects and configure the app independently in each organization. Preserve that separation in the sandbox template. A cloned production connection is a billing risk that a test-only report filter cannot solve. Environment and configuration rules

Should you use real-time or scheduled Billing Sync?

Use real-time Billing Sync for an operational workflow that needs prompt billing changes; use scheduled synchronization where the agreed reporting delay is acceptable. Measure the end-to-end delay to the Salesforce field or task that matters, including failures and backlog.

Stripe permits one Billing Sync mode per account. Real Time uses webhooks and allows object selection. Scheduled Recurring uses a global schedule across linked Stripe accounts and syncs all objects or none; configure it in the app wizard rather than Salesforce Scheduled Jobs. Billing Sync settings

Avoid describing a real-time configuration as a guaranteed latency. Define what happens if the customer view is stale, which queue holds failed work and who restores service. Record source observation time separately from successful Salesforce delivery time so an old snapshot cannot appear current merely because it was copied again.

How should customers, accounts and subscriptions be matched?

Keep a durable mapping between the commercial account, the Stripe billing relationship and each subscription. A billing email can belong to an accountant, a shared mailbox or an external payer; it is insufficient evidence that two Salesforce accounts should be combined.

Inspect the Account and Contact chosen during Lead conversion before treating that CRM relationship as the billing customer mapping.

Stripe's default Platform mapping includes Salesforce Account to Stripe Customer, while its billing model also represents subscriptions, invoices, charges and related objects in Salesforce. Validate the installed mapping against your business structure. If you use customer-configured Accounts v2 in Stripe, confirm compatibility with the app and mapping instead of treating that model as interchangeable with the Customer-based flow. Platform object model

For a custom Salesforce writer, use an explicitly designed external key. A conceptual key includes the source Stripe account, environment, object type and object ID. This is your integration convention, not a pre-existing managed-package field. Store its components as well, so operators can investigate a record without decoding an opaque string.

Salesforce external-ID upsert creates on no match, updates one match and rejects multiple matches. updateOnly prevents creation when a workflow is only permitted to update; the Unique attribute is separate from the External ID attribute. Salesforce external-ID behavior

Choose create permission by operation. A newly approved billing customer may be allowed to create a record. A nightly refresh of known customers should stop for investigation if its account mapping disappears. The CRM property ownership guide helps prevent a billing writer from overwriting sales-owned fields while it updates financial facts.

Which billing states should the Salesforce account page preserve?

Preserve invoice settlement, subscription status and payment movement as separate facts. A single “paid customer” checkbox loses the reason a sales or customer-success team needs to act.

Use a subscription MRR model when recurring value is needed alongside invoice and payment state.

Stripe's invoice.paid event can mean that an invoice payment succeeded or that the invoice was marked paid outside Stripe. A subscription marked active also does not necessarily mean every outstanding invoice has been paid; the configured invoice-resolution policy matters. Invoice event meaning, subscription status rules

The Invoice object distinguishes total, amount due, paid and remaining amounts. Do not map whichever amount field is easiest to find into a generic revenue field. The Refund object has its own lifecycle, including pending, succeeded and failed states; the CRM should retain that distinction.

If an account has two subscriptions and one has a collection problem, preserve the affected subscription and invoice. The account owner needs a specific case to resolve. Replacing the whole account's state with the most recent event can hide the healthy subscription or erase the unresolved one.

For MRR, churn and finance reconciliation, use a defined metric model. The Stripe-to-CRM revenue reconciliation guide covers the broader accounting comparison. An integration should deliver that agreed result with its supporting records rather than inventing a new metric inside a Salesforce Flow.

How do you reconcile amounts without doubling or shrinking them?

Reconcile unique source transactions by currency and state before aggregating a Salesforce summary. Keep source minor units intact until the display conversion is explicit. Stripe uses currency-specific minor units: USD amounts normally use cents, while JPY uses whole yen. Stripe currency units

This hypothetical snapshot contains one captured payment and one successful partial refund per currency. It calculates captured payments less successful refunds only. It excludes fees, disputes, currency conversion and other balance adjustments, and it is not recognized revenue or a bank-payout reconciliation.

For USD, (120000 - 30000) / 100 = 900. For JPY, 5000 - 500 = 4500. Dividing both rows by 100 would turn the JPY amount into an incorrect 45 yen. Adding the two displayed values would also be meaningless without an agreed exchange-rate policy.

A repeated webhook for the USD payment must leave the captured amount at 120,000 minor units. A second delivery of the same refund must leave the successful refund at 30,000. A different refund ID is a different transaction that needs its own current state and relationship check.

Add a pending USD 100 refund to the test. The completed-payment-minus-successful-refund figure stays USD 900 while the pending refund is shown separately. If it succeeds, the figure becomes USD 800; if it fails, USD 900 remains. This is a deliberately narrow operational measure. Finance should determine how pending refunds, disputes and other adjustments appear in its own reports.

If analytics purchases also feed this view, the purchase reconciliation skill can compare those purchases with billing records without treating the CRM total as the source of truth.

How should webhooks and Salesforce actions survive retries?

Treat incoming delivery, Salesforce record updates and billing actions as separate operations with separate evidence. Stripe can repeat webhook deliveries and does not guarantee event order. Event IDs identify repeated receipts, while a snapshot event's seconds-level creation time cannot establish a complete ordering. A custom endpoint should verify the raw-body signature and process accepted work through a queue. Stripe webhook handling, Event timestamp definition

Budget retries against the shared Salesforce API limits instead of treating every integration as a separate allowance.

With the Platform app, configured Stripe events are stored as Salesforce Stripe Event records. Stripe documents record-triggered flows using that object and event-name conditions. Test the resulting Flow behavior rather than equating an event record's presence with a completed customer update. Configure Platform events

For a custom route or additional business logic, use this processing contract:

1. Retain the source account, environment and event identity with the accepted delivery.
2. Resolve the event to its verified commercial account and source object.
3. Refresh the relevant current source state before writing current-state CRM fields.
4. Serialize or otherwise control competing updates for the same account or subscription.
5. Store the Salesforce write result separately from the incoming delivery receipt.
6. Before a task, reminder or billing action, check its business-level eligibility and prior outcome.

Suppose a failure event arrives after the invoice has already been paid. Refreshing the invoice lets the processor close or suppress the recovery task instead of reopening it from the old snapshot. Retain the historical failure as history while keeping the current customer view accurate.

For Stripe API actions, reuse the correct idempotency key when retrying the same intended operation. Stripe's API v1 saves the response once execution begins, including errors, and a key can be pruned after at least 24 hours. Reusing a pruned key can create a new request. Maintain a durable business-action receipt alongside API idempotency so a late replay does not become a second subscription or charge. Stripe idempotency

Include the idempotency key when creating new Platform app flows or activating packaged flows. The app's Transaction Tracking uses it to prevent reprocessing Salesforce-initiated Stripe transactions. Inspect the associated records in Stripe API Transactions when diagnosing a duplicate or an unexpectedly ignored event. Platform transaction tracking

Give a subscription-creation action a stable business identity, such as an approved order and revision. A changed commercial order may require an amendment, while a network retry of the same order should remain the same action. Preserve the destination subscription or schedule ID and investigate an unknown outcome before issuing a fresh create request.

What should your failure and replay tests prove?

Test the adverse cases against the customer record and the downstream action, including successful recovery. A connected app or a webhook response only proves one stage of the handoff.

Do not clear a failure just because a retry was submitted. Re-read the destination record, compare its source association and relevant fields, then close the exception. For a customer-facing action, confirm that the owner, recipient and exit condition remain valid at execution time.

Read diagram as text

• Resolve the source scope and customer mapping to Mapping and current state are verified?.
• Mapping and current state are verified? to Repair identity or refresh source state: No.
• Repair identity or refresh source state to Resolve the source scope and customer mapping.
• Mapping and current state are verified? to Write and read back the Salesforce state: Yes.
• Write and read back the Salesforce state to Destination agrees with the source?.
• Destination agrees with the source? to Repair the failed write and retain its receipt: No.
• Repair the failed write and retain its receipt to Resolve the source scope and customer mapping.
• Destination agrees with the source? to Business action eligible and not completed?: Yes.
• Business action eligible and not completed? to Keep visibility without repeating the action: No.
• Business action eligible and not completed? to Run the approved action and record its outcome: Yes

Open full diagram

The diagram begins after the connection or event has passed its authentication checks. The last step records an action's actual result; a failed or unknown action remains in its own recovery queue. A successful CRM readback must not be treated as proof that a later payment operation succeeded.

What belongs in the production handover?

The production handover should let another operator explain a customer balance, identify a failed record and recover the approved workflow without guessing. Include the installed app and extension versions, object mappings, connection owners, operational queues and representative reconciliation results.

Our CRM and lifecycle implementation work connects those account facts to sales and recovery workflows. Bring one representative customer, its subscriptions and invoices, and the action the team needs to take. That gives the implementation a concrete acceptance case before additional automation is designed.

Written by

Jafrin Akter Alo

Data Engineer and Co-founder at Martechdevs and Growth and Analytics Partners

Jafrin writes practical guides to marketing technology, customer data, analytics and AI workflows. Martechdevs is a Growth and Analytics Partners company.

View LinkedIn profile