Teleport
Send users from an iOS paywall to a checkout page you design, take payment in the browser, and bring them back to the app.
Teleport sends a user from your iOS paywall to a page of that same paywall running in their browser. The user pays there with Apple Pay or a card, then returns to your app with access unlocked.
App2Web opens Stripe Checkout in the browser. Teleport opens a page you design in the paywall editor instead, so the browser step keeps your paywall's look, copy and products. In the editor, this page is called the Checkout Page.
Teleport requires the Superwall iOS SDK 4.18.0 or later. On Android, and on older iOS SDK versions, buying a Stripe product from the paywall opens Stripe Checkout in the browser instead.
Teleport is turned on per app. The checkout page options appear once the paywall has a Stripe product. If you still don't see them, contact Superwall support.
How it works
- A user opens your paywall in the app. Superwall prepares the checkout page in the background so it usually opens without a wait.
- The user taps a button that buys a Stripe product, or a button that routes to the checkout page.
- The checkout page opens in the user's default browser on your web paywall domain, with the tapped product selected.
- In the app, the paywall stays open and shows a waiting screen.
- The user pays on the checkout page with Apple Pay or the payment sheet.
- The checkout page shows You're all set with a Return to App button.
- Your app opens, redeems the purchase and runs the purchase button's after-purchase actions.
The checkout page receives the user's state from the app, including user attributes, placement parameters, paywall state and form input values. Free trial eligibility and the paywall, experiment and variant that started the checkout carry over too, so the sale is attributed to the paywall the user saw in the app.
Requirements
- iOS SDK 4.18.0 or later.
- Web Checkout setup. Your iOS app must be in a project that has a Web Checkout app with a web paywall domain. The checkout page opens on that domain. See Creating an app and Stripe setup.
- A Stripe product on the paywall. See Managing products.
- Stripe app iOS configuration. In your Stripe app's settings, under iOS configuration, fill in Apple Custom URL Scheme, Bundle ID and Team ID. Superwall builds the links that return users to your app from these values. See iOS configuration.
- Deep link handling. Your app must pass incoming URLs to Superwall. See Deep links.
Set up the checkout page
- 1
Add a checkout page to your paywall
In the paywall editor, add a page to a multi-page paywall for checkout. Design it like any other page, and add a button that purchases a Stripe product.
- 2
Mark the page as the checkout page
On the canvas, click the globe icon under the page (Use as the checkout page). You can also right-click the page and choose Use as Checkout Page. The page is labeled Checkout Page and shows in a browser frame.
A paywall has one checkout page. Marking a page removes its outgoing routes and any setting that would open the paywall on it, so the paywall always starts in the app.
- 3
Connect your in-app pages to the checkout page
Route buttons on your in-app pages to the checkout page. On the canvas, these connections are labeled Opens in Browser. Tapping one buys the selected product on the checkout page. Any button on an in-app page that purchases a Stripe product also opens the checkout page.
Auto-advancing pages stop on the page before the checkout page. Only a tap opens the browser.
- 4
Choose how users pay
Open the paywall's settings. Web Checkout Location shows Checkout Page, and the Checkout Page section shows Opens in the browser on followed by your web paywall subdomain. Under Checkout Page Payment, choose:
- Apple Pay (default): Apple Pay where the browser supports it, the payment sheet everywhere else.
- Payment Sheet: a card payment sheet on the checkout page.
Apple Pay doesn't support Managed Payments. Purchases made with Apple Pay go through your regular Stripe payments.
To show Apple Pay, add your web paywall domain to Stripe's payment method domains. See Apple Pay domain setup.
- 5
Set free trial behavior
Under Web Free Trial, choose:
- Match App (default): the checkout page offers the trial only when the app says the user is eligible.
- Always: the checkout page offers the trial to everyone.
- 6
Show the paywall to eligible users
Publish the paywall and add it to a campaign. Teleport links users out of your app to buy, so use the same United States storefront audience filter described in App2Web.
Users on iOS SDK versions older than 4.18.0 get Stripe Checkout instead of the checkout page. To show the checkout page only to users who can see it, add an audience filter for app versions that ship SDK 4.18.0 or later.
Checkout page warnings
The editor shows a warning under the checkout page when it can't take payment:
| Warning | Fix |
|---|---|
| Add a button that buys a product, so shoppers can pay here. | Add a purchase button to the checkout page. |
| A button buys a product slot this paywall doesn't have. | Point the button at a product the paywall has. |
| A button buys an App Store or Google Play product. Only Stripe products sell here. | Change the button to a Stripe product. |
If the paywall's project isn't set up for Web Checkout, the Checkout Page settings section says what's missing:
- Add this app to a project with a Stripe app to use a checkout page.
- Add a Stripe app to this project to use a checkout page.
- Set up a web paywall domain on this project's Stripe app. That's where the checkout page opens.
Buttons on the checkout page
On the checkout page, a Close action is labeled Return to App and a back navigation is labeled Back to App. Both open your app without a purchase. The app checks whether a payment went through without showing a purchase loader.
Actions that need the app aren't available on the checkout page, such as restoring purchases, requesting permissions, requesting a review, custom actions, custom placements and setting attributes.
Add the Superwall link domain
When the user taps Return to App, the checkout page opens your app through a universal link on <subdomain>.superwall.link, where <subdomain> is your web paywall subdomain. Add that domain to your app's associated domains so the app opens without an alert:
- In Xcode, select your app target and open Signing & Capabilities.
- Add the Associated Domains capability if your app doesn't have it.
- Add
applinks:<subdomain>.superwall.link. For example, if your web paywall domain ismyapp.superwall.app, addapplinks:myapp.superwall.link.
Without this entry, Return to App uses your app's URL scheme and iOS asks Open in App? first. If neither link is available, the page tells the user they can go back to the app, with no button.
Return links don't dismiss the paywall and don't track deepLink_open. They reach Superwall through the same handleDeepLink call you use for other Superwall deep links.
While the user is in the browser
The paywall in your app shows a waiting screen:
- Finish in your browser: the title.
- Complete in Browser: reopens the checkout page.
- Cancel: closes the waiting screen and runs the purchase button's On Abandon actions. If the user still pays in the browser within a few minutes, the app redeems the purchase.
The app checks the checkout's status in the background. When the payment completes, the app gets access even if the user doesn't tap Return to App.
Handle the purchase in your app
Superwall redeems a checkout page purchase in your app, so no redemption email is sent. Once it's redeemed:
- Entitlements and subscription status update, as with any web checkout purchase.
willRedeemLink()anddidRedeemLink(result:)are called on yourSuperwallDelegate, unchanged from web checkout.transaction_completefires, attributed to the paywall.- The purchase button's after-purchase actions run. The paywall is dismissed, with a
.purchasedresult, when those actions close it or when the button has none. A purchase started from an Opens in Browser connection always dismisses the paywall.
Unlike other web checkout purchases, a checkout page purchase doesn't dismiss the paywall automatically when it's redeemed.
If you use RevenueCat or your own PurchaseController, follow Using RevenueCat or Redeeming In-App.
Events
| Event | When it fires |
|---|---|
teleport_open (SuperwallEvent.teleportOpen) | The paywall opens its checkout page in the browser. |
teleport_return (SuperwallEvent.teleportReturn) | A return link brings the user back to the app. Its reason parameter is purchased or closed. |
Both events show on the user's event timeline in the dashboard. Purchases on the checkout page also report transaction_start and transaction_complete with the paywall, experiment and variant that started the checkout.
Limits
- Link lifetime: a checkout page link expires 30 minutes after it's created if the user hasn't started paying. The page then shows Checkout expired, and the user isn't charged.
- One purchase per paywall presentation: once the user pays in one checkout, other checkouts from the same presentation close. Opening one shows You already bought this in another checkout, so you weren't charged again.
- Visual editor only: checkout pages are set up in the paywall editor. Superwall Framework paywalls use Web Checkout modes instead.
How is this guide?