“Connect the portal to Stripe” is one of those requirements that sounds like one task and is actually a question about architecture that nobody has asked yet.

A Salesforce customer portal is a rendering layer. It reads CRM data, applies a permission model, and draws pages for people who do not have Salesforce licenses. It is not usually where business logic belongs, which means that for most third-party services, connecting them to the portal is the wrong instruction. You connect them to Salesforce, and the portal displays whatever record the integration produced.

Except when you cannot. Some interactions have to happen inside the authenticated user’s browser session, because the third party needs something only the person sitting in front of the screen can supply. Getting this distinction right on the first attempt saves a rebuild, and Stripe, DocuSign, and Twilio land in three different places on it.

The Test

Before writing any code, answer one question about the integration: does the third party need something that only the human currently looking at the page can give it?

A card number, a signature, a device that receives a one-time code: those are all things the user has and the server does not. Anything in that category has to run in the portal session.

A record update, a notification, a document generated from data you already hold: those need nothing from the user. They belong server side, between Salesforce and the vendor, triggered by a platform event or a flow. The portal’s only job is to show the result.

Getting this backwards produces two recognizable defects. Server-side work pushed into the browser exposes credentials and breaks when the user closes the tab. Browser work pushed server side produces the integration that technically completes but cannot actually collect what it needs.

Stripe: The Portal Session, and Nothing Touches Your Infrastructure

Payments are unambiguously portal session work, and the design is mostly decided for you by compliance rather than preference.

Card data must not reach your servers, your portal application, or Salesforce. Both of Stripe’s supported approaches keep it out: redirecting to Stripe’s hosted Checkout page, or embedding the Payment Element, which tokenizes the card in the browser through Stripe.js. Both are eligible for SAQ A, which is the shortest self-assessment questionnaire and the reason this decision is not really open for discussion. Anything you build that collects card fields yourself moves you into a materially larger compliance scope for no product benefit.

The part teams get wrong is what counts as confirmation.

The browser redirect back to your portal is not confirmation. The user can close the tab, lose connectivity, or land on the return URL before Stripe has finished. Fulfillment logic belongs in the checkout.session.completed webhook, and the webhook handler has to be idempotent, because Stripe can deliver the same event more than once. Store the processed event ID with a unique constraint and let duplicate deliveries fail harmlessly.

What lands in Salesforce is identifiers and outcomes: the Stripe customer ID, the payment intent ID, an amount, a status, and a timestamp on whatever record the payment relates to. Never card numbers, never a CVV. When you need payment detail beyond that, call Stripe’s API for it rather than keeping a second copy.

The portal then does what a portal does. It reads the payment record and shows it. There is a gap between the moment the user returns from Stripe and the moment the webhook arrives, usually short and occasionally not, and the page needs an honest state for that window rather than a blank or a false negative.

DocuSign: The Ceremony Is Theirs, the Status Is Yours

Signing is portal session work too, but for a different reason. DocuSign’s value is the audit trail, and the audit trail depends on DocuSign controlling the signing experience. You are not building a signature capture. You are handing the user to DocuSign under a recipient identity you asserted, and taking back a completed envelope.

There are two shapes, and the choice is about process speed rather than technology.

Emailed envelopes are the default. DocuSign emails the signer, the signer leaves your portal entirely, and the portal shows envelope status when they come back. This is correct for anything that takes days, needs multiple signers, or involves someone who is not a portal user.

Embedded signing keeps the user in the flow. Your server creates the envelope, then requests a recipient view, which is a short-lived one-time URL returned from a POST to the recipient view endpoint on the envelope. The request carries the recipient’s email, name, an authentication method, a clientUserId that marks the recipient as embedded, and a return URL. Inside Salesforce, the Apex Toolkit shipped with the DocuSign Apps Launcher package wraps this for authenticated users through dfsle.SigningService.getEmbeddedSigningUrl. For a portal user who is not a Salesforce user, you build the recipient view request yourself.

Two things about that URL matter. It is one-time and it expires quickly, so generate it at the moment the user clicks and never cache or store it. And because your portal already authenticated the user while DocuSign has no idea who they are, the identity assertion happens server side. That is exactly why the recipient view call must not be made from the browser.

Status comes back through DocuSign Connect, the webhook service. Subscribe to the envelope events you actually act on, which for most portal flows is Sent, Delivered, Completed, and Declined, and write them onto the related Salesforce record. The portal reads that record. Once the envelope completes, retrieve the signed document and store or link it so the customer can get their copy without contacting anyone.

Twilio: Almost Never a Portal Integration

Twilio is the one most often misfiled. Notifications about cases, orders, deliveries, and approvals are triggered by things that happen in the CRM, not by things that happen on a portal page. That is server-side work, and building it into the portal layer means messages stop going out whenever the event originates anywhere else, which it will.

The genuine portal-session case is verification: a one-time passcode at login or at step-up for a sensitive action. Twilio Verify exists for this, the code has to reach the user’s device during their session, and the portal is legitimately part of the flow.

The thing that derails Twilio projects is not code. If you are sending SMS to United States numbers from an application over a 10-digit long code, the number and the use case have to be registered under A2P 10DLC before anything reliably delivers. Registration involves brand and campaign submission, a manual vetting process, and a $15 campaign verification fee. Standard use cases are quoted at up to five business days, and manual vetting has been running two to three weeks. Since 30 June 2026, campaign registration also requires a privacy policy URL and a terms and conditions URL, and submissions without them are rejected outright.

Carriers review the content of those policies. A privacy policy that does not state that opt-in data is not sold or shared with third parties for marketing, or that omits message frequency and the standard rates-may-apply language, gets campaigns rejected. Start this on day one of the project rather than the week before launch, because it is the only part of these three integrations with a lead time you cannot compress.

Three Things That Break in Production

Webhook idempotency. Every one of these vendors can redeliver. Every handler needs to tolerate it. This is the most common cause of duplicate records and double-counted payments in portal integrations.

The window between action and confirmation. The user finished paying or signing, and your record has not updated yet. Decide what the page shows in that window and make it truthful. Silence gets read as failure and produces a support contact and often a second payment attempt.

Secret storage. API keys for these services do not belong in portal configuration that a portal administrator can read, and they do not belong in code. In Salesforce, Named Credentials and External Credentials are the intended home. If your portal layer sits outside Salesforce, it needs an equivalent, and portal admin roles need to be audited against it.

Where Portal Products Fit

Some of this is a solved problem at the product layer. Third-party portal platforms tend to ship payment gateway configuration because every customer wants it. CRMJetty, for example, exposes gateway credentials in portal settings, redirects to the provider’s hosted checkout, and writes the result back to a CRM record along with a transaction log. That removes the build for payments.

It does not remove the design decisions. Which surface each integration belongs on, what the page shows while a webhook is in flight, and whether your Twilio registration will be approved before your launch date are yours regardless of what the portal is built on.

Summary

Sort each integration by whether it needs the human in the browser. Stripe does, and hosted collection keeps you in SAQ A. DocuSign does, through a one-time recipient view URL created server-side. Twilio mostly does not, and its real constraint is a registration process with a multi-week lead time. Confirm everything through webhooks rather than redirects, make every handler idempotent, and keep the credentials somewhere a portal administrator cannot reach.