diff --git a/content/docs/support/faq/app-store-compliance-paywall-events.mdx b/content/docs/support/faq/app-store-compliance-paywall-events.mdx new file mode 100644 index 0000000..fbcf3b9 --- /dev/null +++ b/content/docs/support/faq/app-store-compliance-paywall-events.mdx @@ -0,0 +1,53 @@ +--- +title: "Are Paywall Events and Urgency Messaging App Store Compliant?" +description: "Learn about Apple App Store compliance for paywall events like Paywall Dismissed and Transaction Abandoned, as well as urgency-style messaging." +--- + +This guide covers common App Store compliance questions about paywall interaction tracking and urgency-based messaging. + +## Paywall Events Compliance + +**Paywall Dismissed** and **Transaction Abandoned** events are compliant with Apple App Store guidelines. Tracking paywall interactions and purchase flow analytics is standard practice across the industry. + +### Follow-up Flows + +Re-engagement flows triggered by these events are also compliant, such as: + +- Showing a different paywall with a discount after a transaction is abandoned +- Presenting alternative offers when a paywall is dismissed +- Push notifications to users who showed purchase intent + + +Push notification follow-ups require that users have opted into notifications. Always respect user notification preferences. + + +## Urgency Messaging Compliance + +Apple does not explicitly ban urgency-style messaging on paywalls. Phrases like: + +- "One-time offer" +- "You'll never see this again" +- "Limited time discount" + +These are permitted, but with one key rule: **the offer must be genuine**. + +### What to Avoid + +Apple prohibits deceptive practices under their bait-and-switch guidelines. If your "one-time offer" keeps reappearing to the same user, Apple may flag this as deceptive marketing. + + +If you advertise an offer as exclusive or time-limited, ensure it actually is. Showing the same "one-time offer" repeatedly to users who declined it previously could result in App Store rejection or removal. + + +### Best Practices + +1. **Be honest** - If an offer truly won't return, you can say so +2. **Use genuine scarcity** - Time-limited offers should have real deadlines +3. **Track offer history** - Use user attributes to avoid showing "one-time" offers repeatedly +4. **Document your logic** - Be prepared to explain your offer strategy if Apple requests clarification + +## Resources + +For the complete App Store Review Guidelines, visit: + +- [Apple App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/) diff --git a/content/docs/support/troubleshooting/troubleshooting-sandbox-entitlements-persist.mdx b/content/docs/support/troubleshooting/troubleshooting-sandbox-entitlements-persist.mdx new file mode 100644 index 0000000..4aa9d73 --- /dev/null +++ b/content/docs/support/troubleshooting/troubleshooting-sandbox-entitlements-persist.mdx @@ -0,0 +1,36 @@ +--- +title: "Sandbox Entitlements Persist After Reset" +description: "Why Apple sandbox entitlements remain active after clearing purchase history and reinstalling, and how to work around this limitation." +--- + +When testing subscriptions using Apple's Sandbox environment (via TestFlight or Xcode), you may find that entitlements persist even after taking all the typical reset steps: + +- Clearing purchase history from the Sandbox Apple ID +- Removing and re-adding the Sandbox account +- Deleting and reinstalling the app +- Calling `Superwall.shared.reset()` +- Restarting the device + +This is expected behavior caused by how Apple's sandbox infrastructure caches subscription state. It is not a Superwall issue. + +## Why this happens + +Apple's sandbox environment maintains entitlement state at the server level, not just on the device. Even when you clear local data and purchase history, the sandbox server may still report the subscription as active. This state can persist for an unpredictable amount of time. + +The `Superwall.shared.reset()` method clears Superwall-specific data (user ID, paywall assignments, and cached data), but it cannot clear Apple's StoreKit entitlement state because that state is managed entirely by Apple's systems. + +## The solution: Use fresh sandbox accounts + +The most reliable way to test a clean subscription flow is to use a new sandbox account for each test. Apple allows up to 10,000 sandbox test accounts per developer account, so you can create them freely. + +**Quick tip for creating multiple accounts:** + +Sandbox accounts do not require email verification. Use email aliases with the `+` syntax to create multiple accounts from a single email address: + +- `youremail+test1@gmail.com` +- `youremail+test2@gmail.com` +- `youremail+test3@gmail.com` + +Each alias creates a distinct sandbox account while all emails still arrive at your main inbox. + +When you need a guaranteed clean slate for testing subscriptions, always use a fresh sandbox account. diff --git a/content/docs/support/web-checkout/how-to-retrieve-stripe-customer-data-after-web-checkout.mdx b/content/docs/support/web-checkout/how-to-retrieve-stripe-customer-data-after-web-checkout.mdx new file mode 100644 index 0000000..0b8fb8f --- /dev/null +++ b/content/docs/support/web-checkout/how-to-retrieve-stripe-customer-data-after-web-checkout.mdx @@ -0,0 +1,66 @@ +--- +title: "How do I retrieve Stripe customer data after web checkout?" +description: "Learn how to access the Stripe customer ID and email after a user completes a web checkout purchase." +--- + +## Context + +After a user completes a web checkout purchase via Stripe, you may need to access their Stripe customer ID and email for integration with your backend systems or third-party services. + +## Answer + +Use the `didRedeemLink(result:)` delegate method to access Stripe customer data when a redemption link is successfully processed. + +### Accessing Stripe customer ID and email + +When the redemption result is successful, the `RedemptionInfo` object contains a `PurchaserInfo` with the customer's email and store identifiers: + +```swift +func didRedeemLink(result: RedemptionResult) { + guard case let .success(_, redemptionInfo) = result else { return } + + // Get the customer's email + let email = redemptionInfo.purchaserInfo.email + + // Get the Stripe customer ID and subscription IDs + if case let .stripe(customerId, subscriptionIds) = redemptionInfo.purchaserInfo.storeIdentifiers { + print("Stripe Customer ID: \(customerId)") + print("Subscription IDs: \(subscriptionIds)") + + // Send to your backend or analytics + sendToBackend( + stripeCustomerId: customerId, + email: email, + subscriptionIds: subscriptionIds + ) + } +} +``` + +### What happens if the user kills the app during checkout? + +If a user completes the Stripe checkout but terminates the app before returning, the `didRedeemLink(result:)` callback will not fire. However, their purchase is not lost. + +**Recovery mechanisms:** + +1. **Redemption email**: After a successful Stripe checkout, Superwall automatically sends the customer an email with an activation link. When they tap it, your app opens and `didRedeemLink` fires with the Stripe customer ID and email. + +2. **Plan management page**: Users can visit `https://{yoursubdomain}.superwall.app/manage`, enter their email, and receive a new redemption link. + +3. **Automatic entitlement sync**: The SDK polls for web entitlements when the app enters foreground, so subscription status updates automatically. However, this sync only updates entitlements and does not trigger `didRedeemLink`, meaning you will not receive the Stripe customer ID or email through this path. + + +To programmatically receive the Stripe customer ID and email, the user must tap a redemption link (either from the automatic email or the manage page). + + +### Stripe metadata + +Superwall automatically includes your app user ID in the Stripe checkout session and subscription metadata. The key `_sw_app_user_id` contains the user ID you set via `Superwall.shared.identify(userId:)`. + +This allows you to correlate Stripe subscriptions with your users directly in Stripe or through webhooks. + +## Related + +- [Post-Checkout Redirecting](/sdk/guides/web-checkout/post-checkout-redirecting) +- [How do I disable the activation link email for web checkout?](/support/web-checkout/3969573187-how-do-i-disable-the-activation-link-email-for-web-checkout) +- [Web Checkout FAQ](/web-checkout/web-checkout-faq) diff --git a/content/docs/support/web-checkout/web-checkout-revenue-tracking-is-automatic.mdx b/content/docs/support/web-checkout/web-checkout-revenue-tracking-is-automatic.mdx new file mode 100644 index 0000000..0c70d42 --- /dev/null +++ b/content/docs/support/web-checkout/web-checkout-revenue-tracking-is-automatic.mdx @@ -0,0 +1,45 @@ +--- +title: "Why is there no revenue tracking setup for web checkout?" +description: "Web checkout revenue tracking is automatic when using Stripe, unlike iOS and Android which require manual configuration." +--- + +When using Superwall's web checkout with Stripe, revenue tracking is **automatic**. There is no separate "Revenue Tracking" setup required like there is for iOS (App Store Connect) or Android (Google Play). + +## Why the difference? + +For native mobile apps, Superwall needs you to configure server notifications from Apple or Google because those payment systems are external to Superwall. The revenue events must be forwarded to Superwall so they can be associated with paywalls and campaigns. + +With web checkout, payments flow directly through Superwall's integration with Stripe. Superwall processes these transactions and automatically captures all revenue data, including: + +- Subscription purchases +- One-time purchases +- Renewals +- Cancellations +- Refunds + +## What you need to do + +1. **Configure your Stripe keys** in your Superwall app's [Settings](/web-checkout-configuring-stripe-keys-and-settings) +2. **Create products** in Stripe and [add them to Superwall](/web-checkout-adding-a-stripe-product) +3. **Add products to your paywalls** and start showing them + +Once a purchase completes through your web checkout paywall, conversions and revenue will appear automatically in your Superwall dashboard. + + +It can take a few minutes for new transactions to appear in your dashboard metrics after a purchase completes. + + +## Troubleshooting missing conversions + +If you have completed purchases in Stripe but no conversions showing in Superwall: + +1. **Verify your Stripe keys are configured correctly** - Check that both your Publishable Key and Secret Key are entered in Settings and show "Configured" +2. **Check you're using the correct mode** - If testing, ensure you're using Sandbox keys with test purchases. Production keys are required for live transactions. +3. **Confirm the purchase was made through Superwall** - Only purchases initiated through Superwall paywalls will be tracked. Direct Stripe purchases outside of Superwall will not appear. +4. **Allow time for data to sync** - New transactions may take a few minutes to appear in your analytics + +## Related + +- [Stripe Setup](/web-checkout-configuring-stripe-keys-and-settings) +- [Revenue Tracking for iOS and Android](/dashboard/dashboard-settings/overview-settings-revenue-tracking) +- [Web Checkout Overview](/web-checkout-overview)