Integrations pass and stripe note

content/docs/dashboard/dashboard-creating-paywalls/paywall-editor-styling-elements.mdx

@@ -106,6 +106,28 @@ Available tap actions are:
 - **Delay:** Pauses the action chain for a specified number of **Seconds** before continuing to the next action. This is useful when you have multiple actions on a single tap and want to space them out. For example, setting a variable and then closing the paywall after a short pause. It's also useful for driving animation states or creating auto-advance timers. The **Interruptible** option controls what happens if the user taps the same element again while a delay is pending: **Yes** cancels the current delay and restarts the action chain, while **No** ignores the tap until the delay completes.
 - **Custom Callback:** Sends a named callback request to the SDK, allowing you to run custom app logic and respond with a result. Enter a **Name** for the callback and choose a **Behavior**: **Blocking** waits for the SDK to respond before continuing the action chain, while **Non-blocking** fires the request and continues immediately. You can pass paywall variables to the SDK using **+ Add Variable**. Use the **On Success** and **On Failure** sections to add follow-up actions that run depending on the SDK's response. For example, you could validate something in your app and then update a variable or close the paywall based on the result. In the editor preview, callbacks are simulated with **Success** and **Failure** buttons so you can test both paths. _Requires iOS SDK v4.12.10+ or Android SDK v2.7.0+._
 
+#### Animation
+
+Each tap behavior includes an **Animation** dropdown that plays a visual effect when the element is tapped. Available options are:
+
+- **None:** No animation (default).
+- **Shrink:** The element briefly scales down and back up.
+- **Grow:** The element briefly scales up and back down.
+- **Fade:** The element briefly fades out and back in.
+
+#### Haptics
+
+Each tap behavior includes a **Haptics** dropdown that triggers a platform-native haptic feedback pattern on the user's device. Available on iOS and Android. Available options are:
+
+- **None:** No haptic feedback (default).
+- **Light:** A subtle, light tap.
+- **Medium:** A moderate tap.
+- **Heavy:** A strong, pronounced tap.
+- **Success:** A feedback pattern indicating a successful action.
+- **Warning:** A feedback pattern indicating a cautionary action.
+- **Error:** A feedback pattern indicating a failed action.
+- **Selection:** A light tap suited for selection changes.
+
 If a component has a tap action associated to it, you'll also see a **triangle** icon next to it within the sidebar:
 
 <Frame>![](/images/pe-editor-styling-attached-tap-action.png)</Frame>

content/docs/dashboard/guides/using-stripe-checkout-in-app.mdx

@@ -6,6 +6,10 @@ For users in the United States, you can offer Stripe checkout inside of your app
 
 <Note>Superwall will prioritize showing Apple Pay when available as the first payment option.</Note>
 
+<Note>
+**App Store Review Tip:** If you're using an in-app Stripe checkout sheet, we strongly suggest showing your Stripe purchase experience to Apple during an App Review before testing with users. For recommended reviewer note language, see the [App2Web docs](/web-checkout-direct-stripe-checkout).
+</Note>
+
 <Steps>
 <Step title="Choose a Stripe product on your paywall">
 <Frame>![](/images/scbs_1.jpeg)</Frame>

content/docs/integrations/adjust.mdx

@@ -0,0 +1,197 @@
+---
+title: "Adjust"
+description: "The Adjust integration automatically sends Superwall subscription and payment events to Adjust via the server-to-server (S2S) event API. Track subscription lifecycle events, attribute revenue, and measure campaign performance with automatic event mapping and device-level identification."
+---
+
+In the **Analytics** section within **Integrations**, you can connect your Adjust account to Superwall:
+
+### Required fields
+
+Fill out the following fields and **click** the **Enable Adjust** button at the bottom right to save your changes:
+
+- **App Token:** Your Adjust app token.
+- **Event Token:** The default event token used when sending events to Adjust.
+- **Sales Reporting:** Which revenue value to report in Adjust. Choose between **Proceeds** (after store taxes and fees) or **Revenue**.
+
+### Features
+
+- **Automatic Event Mapping**: Converts Superwall events to Adjust-compatible event names
+- **Revenue Tracking**: Automatic revenue attribution with currency support
+- **S2S Event API**: Events are sent server-to-server for reliable delivery
+- **Device Identification**: Uses Adjust device IDs, IDFA, and GPS advertising ID for attribution
+- **Callback Parameters**: Custom data attached to each event for downstream use
+- **Custom Event Names**: Optional override of default event name mappings
+- **S2S Security**: Optional authentication token for secure server-to-server communication
+
+### Configuration
+
+#### Required settings
+
+| Field | Description | Example |
+|-------|-------------|---------|
+| `app_token` | Your Adjust app token | `"abc123def456"` |
+| `event_token` | Default event token for Adjust | `"xyz789"` |
+| `sales_reporting` | Which value to report | `"Revenue"` or `"Proceeds"` |
+
+#### Optional settings
+
+| Field | Description | Example |
+|-------|-------------|---------|
+| `s2s_token` | S2S security authentication token | `"your_s2s_token"` |
+| Custom event name mappings | Override default event names per event type | `"sw_trial_start"` mapped to a custom name |
+
+#### Example configuration
+
+```json
+{
+  "app_token": "your_adjust_app_token",
+  "event_token": "your_default_event_token",
+  "sales_reporting": "Revenue",
+  "s2s_token": "your_optional_s2s_token"
+}
+```
+
+### Event mapping
+
+Superwall events are transformed into Adjust event names using the standard mapper:
+
+#### Complete event mapping
+
+| Superwall Event | Period Type | Adjust Event Name |
+|-----------------|-------------|-------------------|
+| `initial_purchase` | TRIAL | `sw_trial_start` |
+| `initial_purchase` | INTRO | `sw_intro_offer_start` |
+| `initial_purchase` | NORMAL | `sw_subscription_start` |
+| `renewal` | trial conversion | `sw_trial_converted` |
+| `renewal` | INTRO | `sw_intro_offer_converted` |
+| `renewal` | NORMAL | `sw_renewal` |
+| `cancellation` | TRIAL | `sw_trial_cancelled` |
+| `cancellation` | INTRO | `sw_intro_offer_cancelled` |
+| `cancellation` | NORMAL | `sw_subscription_cancelled` |
+| `uncancellation` | TRIAL | `sw_trial_uncancelled` |
+| `uncancellation` | INTRO | `sw_intro_offer_uncancelled` |
+| `uncancellation` | NORMAL | `sw_subscription_uncancelled` |
+| `expiration` | TRIAL | `sw_trial_expired` |
+| `expiration` | INTRO | `sw_intro_offer_expired` |
+| `expiration` | NORMAL | `sw_subscription_expired` |
+| `billing_issue` | any | `sw_billing_issue` |
+| `subscription_paused` | any | `sw_subscription_paused` |
+| `product_change` | any | `sw_product_change` |
+| `non_renewing_purchase` | any | `sw_non_renewing_purchase` |
+| Any with `price < 0` | any | `sw_refund` |
+
+You can optionally override these default event names with custom mappings in your integration settings.
+
+### Callback parameters
+
+Every Adjust event includes callback parameters encoded as JSON. These are sent alongside the event for downstream processing:
+
+- `event_name`: The mapped Superwall event name (e.g., `sw_trial_start`)
+- `product_id`: The product identifier for the transaction
+- `transaction_id`: The transaction identifier
+- `original_transaction_id`: The original transaction identifier (for renewals and modifications)
+
+These callback parameters are included in the `callback_params` query parameter as a JSON-encoded string.
+
+### Revenue tracking
+
+#### Automatic revenue attribution
+
+Revenue is automatically included for events with non-zero amounts. The `sales_reporting` setting determines which value is used:
+
+| Setting | Value Used | Description |
+|---------|------------|-------------|
+| `"Revenue"` | `price` | Gross revenue before store fees |
+| `"Proceeds"` | `proceeds` | Net revenue after store fees |
+
+When revenue is present:
+- **Positive revenue**: Purchases, renewals, conversions
+- **Negative revenue**: Refunds (automatically deducted)
+- **Zero revenue**: Events like cancellations, expirations, and billing issues do not include revenue data
+
+Revenue is sent with the corresponding currency code from the transaction.
+
+### User and device identification
+
+Adjust uses device-level identifiers rather than user IDs for attribution. The integration reads these values from `userAttributes` on the Superwall event:
+
+#### Device identifier hierarchy
+
+| Identifier | Platform | Description |
+|------------|----------|-------------|
+| `adjustId` | All | Primary Adjust device ID (required) |
+| `idfa` | iOS | Identifier for Advertisers |
+| `gps_adid` | Android | Google Play Services advertising ID |
+
+**Important:** If no `adjustId` is present in `userAttributes`, the event is skipped entirely. Make sure your app sets the Adjust device ID on the Superwall user so that events can be attributed correctly.
+
+#### Platform detection
+
+The integration determines the platform from the store field on the event:
+
+- `APP_STORE` maps to iOS (uses `idfa` if available)
+- `PLAY_STORE` maps to Android (uses `gps_adid` if available)
+
+### Sandbox handling
+
+Adjust does **not** support separate sandbox environments. All sandbox events are skipped and will not be sent to Adjust.
+
+Only production events are forwarded to the Adjust S2S event API. If you need to test the integration, use production or live test transactions.
+
+### Testing the integration
+
+#### 1. Validate credentials
+
+When you save the integration, Superwall sends a test event to verify that your `app_token` and `event_token` are valid. If the test fails, double-check your tokens in the Adjust dashboard.
+
+#### 2. Trigger production events
+
+Since sandbox events are skipped, testing requires live transactions:
+- **iOS**: Use TestFlight with a sandbox Apple ID. Note that StoreKit Configuration files do not generate App Store Server Notifications, so webhooks and downstream integrations will not fire.
+- **Google Play**: Use license test accounts to perform purchases.
+
+#### 3. Verify in Adjust
+
+Check the Adjust dashboard:
+1. **Event Log**: Confirm events are arriving with the correct event token
+2. **Callback Data**: Verify callback parameters contain the expected values
+3. **Revenue**: Confirm revenue amounts and currency codes are correct
+4. **Device Attribution**: Ensure events are attributed to the correct device
+
+### Best practices
+
+1. **Set Adjust device IDs early**: Configure the `adjustId` in Superwall user attributes as soon as the Adjust SDK initializes, so that all subscription events can be attributed.
+2. **Include advertising IDs**: Pass `idfa` (iOS) or `gps_adid` (Android) in user attributes for richer attribution data.
+3. **Use S2S security**: Configure the `s2s_token` to authenticate server-to-server requests and prevent spoofed events.
+4. **Revenue model consistency**: Choose gross revenue or proceeds and keep it consistent across all your analytics tools.
+5. **Custom event names**: Use custom event name mappings if your Adjust setup requires specific naming conventions.
+6. **Monitor attribution**: Regularly verify that events in the Adjust dashboard match your expected subscription activity.
+
+### Troubleshooting
+
+#### Events not appearing
+
+1. **Check adjustId**: The `adjustId` must be present in `userAttributes`. Events without it are skipped entirely.
+2. **Check app token**: Verify the app token matches your Adjust app.
+3. **Check event token**: Ensure the event token is valid in your Adjust dashboard.
+4. **Check environment**: Sandbox events are always skipped. Only production events are sent.
+5. **Check S2S token**: If configured, verify the S2S authentication token is correct.
+
+#### Revenue not tracking
+
+1. **Check amount**: Only non-zero amounts include revenue data.
+2. **Check sales reporting**: Verify whether you selected Revenue or Proceeds.
+3. **Check currency**: Ensure the currency code is present on the transaction.
+
+#### Device attribution issues
+
+1. **Check adjustId**: This is the primary identifier and must be set in user attributes.
+2. **Check IDFA/GPS ad ID**: These are supplementary identifiers. Ensure they are passed in user attributes if available.
+3. **Check platform detection**: Verify the store field is correct (APP_STORE for iOS, PLAY_STORE for Android).
+
+#### S2S API errors
+
+The Adjust S2S event API receives events as URL query parameters. Common issues include:
+- **Invalid app token**: Returns an error from the Adjust endpoint.
+- **Invalid event token**: The event token must exist in your Adjust dashboard.
+- **Authentication failure**: If using `s2s_token`, ensure it matches your Adjust S2S security settings.

content/docs/integrations/appstack.mdx

@@ -0,0 +1,124 @@
+---
+title: "Appstack"
+description: "The Appstack integration forwards Superwall webhook events directly to Appstack for analytics and attribution. As a pass-through integration, it sends the raw event payload without transformation, giving Appstack full access to your subscription lifecycle data."
+---
+
+In the **Analytics** section within **Integrations**, you can connect your Appstack account to Superwall:
+
+### Required Fields
+
+Fill out the following fields and **click** the **Enable Appstack** button at the bottom right to save your changes:
+
+- **Access Token:** Your Appstack API access token, used to authenticate requests.
+- **App ID:** Your Appstack application ID, used to route events to the correct app.
+
+### Features
+
+- **Pass-Through Delivery**: Raw Superwall webhook events are forwarded directly to Appstack without transformation
+- **Simple Configuration**: Only an access token and app ID are required
+- **Credential Validation**: Connection is verified before the integration goes live
+- **Production Events Only**: Sandbox events are automatically filtered out
+
+## Configuration
+
+### Required Settings
+
+| Field | Description | Example |
+|-------|-------------|---------|
+| `access_token` | Your Appstack API access token | `"ask_live_abc123..."` |
+| `app_id` | Your Appstack application ID | `"app_456def..."` |
+
+### Example Configuration
+
+```json
+{
+  "access_token": "your_appstack_access_token",
+  "app_id": "your_appstack_app_id"
+}
+```
+
+## How It Works
+
+Appstack is a **pass-through integration**. Unlike analytics integrations that map and transform events into platform-specific formats, the Appstack integration forwards the raw Superwall webhook event payload directly to Appstack.
+
+When a subscription event occurs:
+
+1. Superwall generates the webhook event.
+2. The integration sends the complete, unmodified event payload to Appstack.
+3. Appstack receives and processes the event on its end.
+
+### API Endpoint
+
+Events are sent to:
+
+```
+POST https://api.event.appstack.tech/superwall/webhook/{app_id}
+```
+
+### Request Headers
+
+```
+Content-Type: application/json
+Authorization: <access_token>
+```
+
+The `access_token` is sent as the `Authorization` header value, and the `app_id` is included in the URL path.
+
+## Sandbox Handling
+
+Sandbox events are **automatically filtered out**. Only production events are forwarded to Appstack. There is no option to include sandbox events or to configure a separate sandbox endpoint.
+
+## Testing the Integration
+
+### 1. Validate Credentials
+
+When you save the integration, Superwall sends a test event to the Appstack validation endpoint to confirm your credentials are correct:
+
+```
+POST https://api.event.appstack.tech/superwall/validate
+```
+
+If validation fails, double-check your access token and app ID.
+
+### 2. Trigger a Production Event
+
+Since sandbox events are filtered out, you will need a production transaction to verify end-to-end delivery:
+
+- iOS: Use TestFlight with a sandbox Apple ID. StoreKit Configuration files do not generate App Store Server Notifications, so webhooks and downstream integrations will not fire.
+- Google Play: Use license test accounts to perform sandbox purchases.
+- Stripe: Use Stripe Test Mode to create sandbox transactions.
+
+<Note>
+  Because sandbox events are not forwarded to Appstack, full end-to-end testing requires a production transaction. Use credential validation to confirm the connection is working before going live.
+</Note>
+
+### 3. Verify in Appstack
+
+Check your Appstack dashboard to confirm events are arriving and being processed correctly.
+
+## Troubleshooting
+
+### Events Not Appearing in Appstack
+
+**Possible causes:**
+- Invalid access token or app ID
+- Events are from a sandbox environment (these are filtered out)
+- Network or endpoint issues on the Appstack side
+
+**Solutions:**
+1. Re-save the integration to trigger credential validation
+2. Confirm you are generating production (not sandbox) events
+3. Verify your access token and app ID match what is shown in your Appstack dashboard
+4. Contact Appstack support if credentials are correct but events are still not arriving
+
+### Credential Validation Failing
+
+**Possible causes:**
+- Incorrect access token
+- Incorrect app ID
+- Appstack service is temporarily unavailable
+
+**Solutions:**
+1. Copy the access token and app ID directly from your Appstack dashboard to avoid typos
+2. Ensure your Appstack account is active and in good standing
+3. Try again after a few minutes if the Appstack service may be experiencing downtime