> ## Documentation Index > Fetch the complete documentation index at: https://dev.moonpay.com/llms.txt > Use this file to discover all available pages before exploring further. # Core concepts > Key terms and concepts for integrating with the MoonPay Platform ## Connections An active **connection** represents a customer's permission to associate the MoonPay account to your application so you can: * List and manage payment methods in your UI * Get quotes that include detailed fees and customer limits * Execute payments (for example, Apple Pay or debit cards) without redirecting the customer * View and track transaction history Read the [hosted onboarding guide](/platform/guides/connect-a-customer) for implementation details. ## Frames The integration uses a combination of API calls and frames. For steps that have compliance or regulatory requirements, you render an embedded frame (a WebView in mobile apps and an iframe on the web). This keeps sensitive data out of your application while MoonPay manages compliance. There are two types of frames: **co-branded** and **headless**. Both communicate with your app using `postMessage` (on web and mobile). Each frame has its own lifecycle events and message patterns, documented in the [frames overview](/platform/frames/overview). You can manage frames yourself, or use the SDK for drop-in frame setup and event handling. ### Co-branded frames Co-branded frames render MoonPay-hosted UI that you can theme to match your application. They are designed for contextual rendering in modals or sheets. A typical example is the MoonPay login flow used when a customer connects their account. MoonPay headless integration co-branded frame ### Headless frames Headless frames are either invisible or display minimal, non-customizable elements such as an Apple Pay button. You can inline these frames wherever needed in your UI. MoonPay headless integration frame ## Challenges Challenges complete specific tasks that require upgraded authentication, identity verification, or connection updates. Common cases include: * Authentication upgrades (required for sensitive or destructive actions) * Identity verification (Know Your Customer, KYC) * Strong Customer Authentication (SCA), such as [3D Secure](https://www.checkout.com/products/authentication-3ds), where the customer’s bank requires additional verification Frames and the Customer API surface challenges. The [Apple Pay](/platform/frames/apple-pay), [Google Pay](/platform/frames/google-pay), and [buy](/platform/frames/buy) frames emit a `challenge` event with a URL to load into the dedicated [Challenge frame](/platform/frames/challenge). The [Customer API](/platform/guides/customer-api) returns a `kyc.challenge` URL when verification needs a hosted step. See [Handle challenges](/platform/guides/handling-challenges) for the full flow. ## Customer A customer is a person using your app who can have a connected MoonPay account. ### Verification (KYC) MoonPay performs Know Your Customer (KYC) checks to meet financial compliance requirements and help prevent fraud and money laundering. MoonPay always decides what verification a customer needs. You choose who renders the UI that captures it. [Verification tiers](/platform/guides/verification-tiers) lists the steps customers complete at each verification level, per region. A customer's KYC standing moves through a lifecycle: `not_created`, then `collecting` while requirements are outstanding, then `verifying` while MoonPay processes the submitted data, and finally `active` (or `unavailable` when verification cannot proceed). The API exposes this as `kyc.status`, with the outstanding items listed in `kyc.requirements`. See the [Customer API guide](/platform/guides/customer-api) for the full status table. You have three ways to run verification. By default, the co-branded [connect flow](/platform/guides/connect-a-customer) captures and verifies everything in MoonPay-hosted UI. Alternatively, you capture KYC data in your own UI and submit it with the [Customer API](/platform/guides/customer-api). [Guest checkout](/platform/guides/guest-checkout) defers verification until a purchase requires it. When MoonPay can't verify a customer from submitted data alone, it falls back to a hosted challenge (see [Handle challenges](/platform/guides/handling-challenges)). To pick the path that fits your app, see [Choose an onboarding path](/platform/guides/onboarding-paths). ## Quotes Quotes provide real-time prices and fees for fiat-to-crypto purchases. Every quote response carries an `executable` boolean: * `executable: true` — the quote can be used to execute a transaction. * `executable: false` — use the quote for cost estimation only. ### Fee behavior When you quote by `source.amount`, the optional `feeBehavior` field controls how fees relate to that amount. The request and response values have different meanings: * `inclusive` (default): the request `source.amount` is the total paid. Fees are deducted from it. * `exclusive`: the request `source.amount` is the source principal. The API adds fees, and the response `source.amount` is the total paid. The following illustrative comparison assumes USD as the quote currency, a request `source.amount` of `$100.00`, and total non-deprecated fees of `$5.00`. Actual fee and destination amounts vary by quote. | | Inclusive | Exclusive | | - | - | - | | Request `source.amount` | `$100.00` | `$100.00` | | What the request means | Total paid | Purchase principal | | How fees apply | Deducted from requested amount | Added to requested amount | | Response `source.amount` (**You Pay**) | `$100.00` | `$105.00` | | Amount used to buy crypto | `$95.00` | `$100.00` | Destination-amount quotes are effectively inclusive. The response reports `feeBehavior: "inclusive"` even if you request `exclusive`. They are not in this comparison because their source output depends on live rates and fees. See the [quotes API reference](/api-reference/platform/endpoints/quotes/get) for the request fields required to receive `executable: true`.