in-product checkout
Let wallet-native products unlock the next state instantly.
Hosted links, embeds, and API flows can feel like part of the product instead of a borrowed card checkout.
Wallets, DeFi tools, gaming studios, NFT launches, OTC desks, and Web3 apps that want payment links, embeds, API flows, and webhooks.
Live
Embed
API
Webhook
Wallet
User
in-product checkout
Hosted links, embeds, and API flows can feel like part of the product instead of a borrowed card checkout.
Best for
NFT mints
Gaming purchases
Wallet add-ons
Web3 SaaS billing
Best moment
Account top-up, premium access, NFT service fee, OTC invoice, or Web3 product checkout.
Payment flow
Embedded checkout, hosted payment page, or API-created payment.
Who checks it
Product, operations, or support team.
Practical guide
Crypto-native products sell to people who already understand wallets, networks, and stablecoins. The challenge is not convincing them that crypto can pay for things; it is making the checkout operationally clean.
A wallet app, DeFi tool, NFT product, OTC workflow, or Web3 SaaS product needs a payment request that ties back to the customer, order, campaign, or account action.
Live
Wallet users are comfortable sending funds, but a business cannot run on unnamed transfers. The product needs to know who paid, what they paid for, and what action should follow.
A clean payment object keeps the payment connected to the product workflow, whether the next step is access, credit, delivery, review, or support.
Raw transfers do not scale
Support teams should not identify payments from screenshots.
Product actions need status
A paid event can unlock access, add credit, or move an order forward.
Brand still matters
Even Web3 users notice when checkout feels disconnected from the product.
A team can start with hosted links for manual invoices or campaigns, then move into embedded checkout and API-created payments for product-native flows.
Webhooks can carry the paid state back into the app so the product, not support, decides what happens next.
Hosted or embedded
Choose the surface that fits the product moment.
Self-custody settlement
Route settlement toward the wallet strategy the crypto team already uses.
Developer-friendly status
Use API and webhooks to keep payment logic out of chat and spreadsheets.
Decide which product action happens after payment, what metadata is required, and how support can inspect a payment without developer help.
Keep network and asset choices narrow at launch. Too many options can make reconciliation and customer support harder than necessary.
Define metadata
Attach user IDs, order IDs, campaign IDs, or invoice references.
Limit first assets
Start with the assets your customers already request and your team can reconcile.
Test failure states
Know what customers see when a payment expires, underpays, or needs retrying.
Scenario
When your users already live in wallets, MakePay becomes a simple branded checkout layer. Teams can launch hosted links quickly, embed checkout in-product, or build fully custom flows through the API.
Proof layer
Setup path
Launch the first flow, prove the status handoff, then expand into nearby payment moments once the team trusts the signal.
Pick the payment action that most needs a cleaner flow.
Use a link, embed, or API-created payment tied to the user or order.
Connect paid events to access, credit, delivery, or operations.
Adjust copy and metadata so fewer payments need manual research.
Questions
No. Crypto-native teams often need better payment operations even when customers already know wallets.
Yes. MakePay supports hosted and embedded checkout paths along with API and webhook flows.
No. It provides the payment request, checkout, and status layer around the merchant's settlement setup.
Wallet-first checkout
That lets product teams avoid the awkward gap between a raw wallet transfer and a full custom payment system built from scratch.
in-product checkout
ready
API