> For the complete documentation index, see [llms.txt](https://help.getmobly.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.getmobly.com/help-center/host/security-and-payments.md). # Security and payments in Host Answers to the questions IT and security reviewers most often ask about Host's paid-ticketing capability — how payment data is handled, where credentials live, what's encrypted, and what Mobly does and doesn't store. ## Short version **Mobly does not process payments or store any card data.** When you sell tickets through Host, the buyer's browser communicates directly with Stripe via embedded Stripe Elements. Your own Stripe account is connected via Stripe Connect; all payment credentials live in that Stripe account. Mobly's role is the registration page and the lead/check-in record — nothing else touches payment data. ## Does Mobly process payments or store any card data? No. Mobly's database has zero payment-related columns — no card details, no transaction IDs, no payment status fields. All payment processing is handled by Stripe. Host's role is to render the registration page; the card form on that page is a Stripe-controlled iframe (Stripe Elements), and the card data goes directly from the buyer's browser to Stripe without crossing Mobly's servers. ## How is the Stripe integration set up? Embedded Stripe Elements on Host's registration page. The card form is rendered by Stripe inside the page; card details never enter Mobly's domain. The integration model is Stripe Connect: each customer connects their own Stripe account to Host. You remain the merchant of record for tickets sold through your Host pages, and your Stripe account holds the funds. ## How does Host confirm that a payment was successful? Server-side, via signed Stripe webhooks. After Stripe processes a payment, it sends a webhook with an HMAC signature. Host verifies the signature using Stripe's standard scheme and confirms the PaymentIntent status before marking the registration as paid. Host does not rely on the buyer's browser response to confirm payment. ## What authentication mechanisms are used with Stripe? Per-workspace Stripe Connect. Each customer's Host setup authenticates to a customer-controlled Stripe account; the API keys and tokens for that connection live server-side, scoped to the connected account. ## Where and how are Stripe keys and secrets stored? * **Stripe secret keys** — server-side environment only. Never sent to the browser or mobile app, never bundled into front-end code. * **Stripe publishable keys** — client-side only. (By Stripe's design, publishable keys are safe to expose; they can't be used to charge cards or pull data.) * **Stripe Connect tokens** — server-side, scoped per connected Stripe account. No Stripe credentials are present in front-end web bundles or in the mobile app. ## Can transaction-level activity be correlated to leads and CRM records? Today, correlation between (Stripe transaction → Host registration → Mobly lead → your CRM record) is via lead identity (typically email). Each Mobly lead links 1:1 to its Host registration; identity carries forward into your CRM via the standard field-mapping flow. Direct ID-to-ID lineage — embedding the Stripe PaymentIntent ID on the Mobly lead and making it available for CRM sync — is on the roadmap. If your audit or reconciliation workflows need this, ask your CSM to prioritize it for your org. ## What payment data does Mobly have access to or store? **None of the following are stored by Mobly:** * Card numbers, CVCs, or expiration dates (never enter Mobly's systems) * Stripe PaymentIntent or charge IDs (not in the registration sync today) * Payment status (paid / failed / refunded) * Charge amounts or currency Mobly stores what it needs for lead management: name, email, contact info, the registration link, and check-in status. Payment-side metadata (PaymentIntent and invoice IDs, payment status) is retained inside Stripe; nothing more lands in Mobly today. ## Is all network traffic encrypted? Yes. All channels enforce HTTPS / TLS 1.2+: * Buyer browser → Stripe (via embedded Elements): HTTPS / TLS 1.2+ * Stripe → Host webhooks: HTTPS / TLS 1.2+, additionally HMAC-verified using Stripe's signature scheme * Mobile app → Mobly API: HTTPS / TLS 1.2+ * Hub web app → Mobly API: HTTPS / TLS 1.2+ **There is no Mobly → Stripe channel.** Mobly never communicates with Stripe directly — all Stripe interaction is between the buyer's browser, Host, and Stripe itself. All Stripe-side traffic uses official Stripe SDKs, not custom HTTP clients. ## Where to ask deeper questions For Stripe-internals questions that fall outside Mobly's surface area — PCI scope details, retention windows, dispute and refund mechanics, Stripe Connect onboarding requirements — Stripe's own documentation is the source of truth, since those mechanics live entirely in Stripe. For Mobly-specific security questions not covered here, contact your CSM. ## Related articles * [Selling tickets](/help-center/host/selling-tickets.md) — paid ticket types, Stripe setup, VAT, promo codes, refunds * [Connecting to Host](/help-center/host/connecting-to-host.md) — one-time setup * [Getting started with Host](/help-center/host/getting-started-with-host.md) — what Host handles vs. what Mobly handles --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://help.getmobly.com/help-center/host/security-and-payments.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.