Payment methods on your paywall: embedded vs redirect, cards & wallets

Step 2 of launch: understand how each paywall type shows payment, and do the one required step (in Segmently's Stripe settings) that turns on Apple Pay and Google Pay.

Where this fits in your launch

Getting to a funnel you can run ads against follows a fixed order: (1) connect Stripe, (2) create and attach a paywall product, (3) set up email passing, (4 - optional) wire ad-pixel events, then (5) publish and test. This is part of step 2. Before you read on, your Stripe account must already be connected (step 1) and you should have at least one paywall product created and attached to your paywall. The next required step after this one is email passing (step 3), so the right customer record and receipt follow each sale. This article does not ask you to pick a payment method anywhere in Segmently - it explains what each paywall already does and the single required setting, in Segmently's Stripe integration settings, that unlocks wallets.

The three paywall types and how payment appears

Segmently offers three paywall types, and the payment surface differs by type. Native Paywall: products attach as subscription rows you pick in the editor, and payment is collected with an embedded Stripe Payment Element right inside the funnel. Flexible-layout paywall: you assemble the screen from sections, attaching products through a product-catalog section and/or a custom-embed section - and a custom-embed section is always rendered inside an iframe at runtime. (The flexible-layout editor shows an iframe toggle on a custom-embed section, but that toggle is not honored at runtime for flexible-layout custom embeds: they always run inside an iframe regardless. So for wallet-sensitive paywalls, use a web-embed paywall with iframe rendering off, not a flexible-layout custom-embed.) Web-embed paywall: you bring your own HTML and attach products to your own buy controls, and a single toggle - 'Render in iframe (full isolation)' - governs the surface. Turn that toggle ON and the HTML runs in a legacy, fully isolated iframe; turn it OFF and the HTML runs in a Shadow DOM that shares the host window - this is the recommended, wallet-safe embedded surface and the one that includes the modern paid subscription flow. In short - the payment surface is set by which paywall type you chose plus, for a web-embed paywall, this iframe toggle - not by a single global on/off switch.

Embedded vs redirect

There are two ways a shopper can pay. Embedded means the Stripe Payment Element - card fields plus any available wallets - appears inside your funnel and the buyer never leaves your page. Redirect means the buyer is sent to a Stripe-hosted checkout page to pay, then returned to your funnel. A native paid subscription is collected through the embedded path. A web-embed paywall is also an embedded surface as long as you turn its 'Render in iframe (full isolation)' toggle off: that Shadow DOM mode includes the modern paid subscription flow and preserves the synchronous wallet gesture chain, so it is the recommended wallet-safe embedded surface. The surfaces that do not carry the embedded subscription path are the legacy iframe-on web-embed and the flexible-layout custom-embed section (always an iframe at runtime, even though the editor shows a toggle that is not honored there). What about redirect? Redirect is not a property of the paywall type at all - it is a per-paywall checkoutMode setting, and when it is set to 'redirect' the buyer is always sent to Stripe-hosted Checkout, a choice that is checked first regardless of paywall type. So the practical takeaway: the surface a buyer sees follows from three things - your paywall type, the web-embed iframe toggle, and the checkoutMode setting - not from one global toggle and not from paywall type alone.

Cards work out of the box

Card payments are available the moment your Stripe account is connected - this step is required, but you have already done it in step 1, so there is no extra setup. Every shopper can always pay by card on your paywall. Wallets and Link, covered next, are added on top of cards when they are available; cards remain the dependable baseline that works on every device.

Apple Pay and Google Pay

Apple Pay and Google Pay appear automatically when the shopper's device supports them - you do not toggle the methods themselves. There is one required, one-time step: register your domain as a payment method domain on your connected Stripe account - and that domain must be the connected custom domain your funnel runs on, not a generic published web address. Segmently gives you a control for this - open your Stripe integration settings and use the Apple Pay Domains section to add your connected custom domain (do it for the same mode, test or live, that you will run). Once it shows as active, wallets can appear; until then, shoppers fall back to card. This pairs naturally with connecting a custom domain (step 5), which is required to publish in the first place: as a regular (non-admin) customer you cannot publish your funnel until an active custom domain is connected, and that same https custom domain is what you register here for wallets. A local preview address does not qualify.

Link

Link is Stripe's accelerated checkout that remembers a shopper's saved card and details across Stripe-powered sites. It is offered automatically in the embedded Payment Element when Stripe decides it is relevant - there is nothing for you to set up and nothing to enable in Segmently. Which methods show, and the order they appear in, is decided by Stripe based on the shopper and their device; it is not a setting you configure.

Email is a hard prerequisite for subscriptions

No matter which paywall type or payment method a shopper picks, a subscription will not start without the buyer's email. The runtime guards on this: if no customer email is available when a subscription purchase begins, the purchase is rejected before it ever reaches Stripe. That is why email passing (step 3) is not optional polish - it is a hard prerequisite for every paid subscription paywall. Set it up before you go live: collect the email on a screen before the paywall, store it in a variable, and select that variable as the email source for your web placement. See the collect-email-before-paywall article for the exact steps.

What you control in Segmently vs in Stripe

Keep the split clear so you set things up in the right place. In Segmently you choose the paywall type, attach your products, and register your published domain for Apple Pay and Google Pay (in your Stripe integration settings, the Apple Pay Domains section). There is no payment-method picker, because which methods show is not a Segmently setting. On the Stripe Dashboard you control which methods are eligible on your account - for example enabling extra regional methods you want to accept. So: paywall layout, product attachment, and wallet domain registration = Segmently; the menu of eligible payment methods = Stripe. If a method you expect is missing, check that your domain is registered (Segmently) and that the method is enabled on your Stripe account.

Bottom line: where wallet-safe custom paywalls live

If you are building a custom paywall and want Apple Pay and Google Pay to work, the safe choice is clear: use a web-embed paywall with 'Render in iframe (full isolation)' turned off, so the HTML runs in Shadow DOM. That is the only custom surface that preserves the synchronous wallet gesture chain and carries the modern paid subscription flow. The two surfaces that break wallets are the iframe-on web-embed (legacy isolation) and the flexible-layout custom-embed section (always an iframe at runtime) - keep wallet-sensitive paywalls off both of them.

Next: set up email passing

With your paywall type understood, your products attached, and your wallet domain registered in your Stripe integration settings, you are ready for step 3: collecting and passing the buyer's email before the paywall so each sale ties to the right customer record and receipt. If you still need to review your products, open the paywall products article; to continue the launch, move on to collecting email before the paywall.