Skip to main content

​
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 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. 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, where the customer’s bank requires additional verification
Frames and the Customer API surface challenges. The Apple Pay, Google Pay, and buy frames emit a challenge event with a URL to load into the dedicated Challenge frame. The Customer API returns a kyc.challenge URL when verification needs a hosted step. See Handle 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. 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 for the full status table. You have three ways to run verification. By default, the co-branded connect flow captures and verifies everything in MoonPay-hosted UI. Alternatively, you capture KYC data in your own UI and submit it with the Customer API. 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). To pick the path that fits your app, see Choose an onboarding path.

​
KYC sharing

You can export MoonPay-verified KYC data to other services in your app, like setting up a debit card. See Export customer data.The inbound direction is coming soon: reusing KYC data you already capture with a provider like SumSub or Persona to simplify MoonPay onboarding.

​
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.
When you quote by source.amount, the optional feeBehavior field controls how fees relate to that amount:
  • inclusive (default): the customer pays exactly source.amount, and fees are carved out of it.
  • exclusive: fees are added on top of source.amount, so the customer pays source.amount plus fees and the full amount is converted to crypto.
Quotes by destination.amount are always fees-inclusive. The response echoes the effective feeBehavior.
See the quotes API reference for the request fields required to receive executable: true.