Paymento Embedded Wallets: Crypto Checkout Without Wallet Connection

Crypto checkout should be as simple as sending crypto.

With Paymento Embedded Wallets, a customer paying you in ETH, USDC or SOL scans a QR code or copies an address and pays from the wallet or exchange they already use. we made an experience similar to custodial payment processors while preserving self-custody, No wallet connection. No browser extension. No chain-switching prompt. Only you can authorize where those funds go afterwards.

Today we are launching the infrastructure that makes that possible.

The rest of this post is why that connection step existed in the first place, what we had to build to remove it, and what it does and does not change for you.

The connect-wallet step was never a security feature

It was an accounting workaround.

On Bitcoin and Litecoin, a payment processor can derive a fresh receiving address for every single invoice, for free, from a key you provide once at setup. Attribution is then trivial. Money that lands at that address belongs to that invoice. Nothing else can be true. This is why paying with Bitcoin through almost any processor has always been a scan-and-send affair, with no wallet to connect and nothing to approve.

Account-based chains work differently. On Ethereum, Solana or Tron, a merchant has one account. If ten customers pay into it in the same hour, you get ten inbound transfers to a single address and no reliable way to say which order each one belongs to. Matching on amount sounds workable until you meet exchange-rate rounding, two customers who happen to buy the same item, and payments that arrive slightly short.

So the industry solved it from the other end. If you cannot identify the payment, identify the payer. Make the customer connect a wallet, capture their sending address, bind that address to the invoice, and the attribution works.

It does work. It also puts a technical task in front of a customer who arrived wanting to buy something. They need a browser wallet, funded, on the right network, and they need to understand a chain-switch prompt and approve a transaction they have to read to trust. Every one of those is a place to stop.

What we built

Embedded Wallet stores generate a unique receiving address for every order on account-based chains. It is the same property that made Bitcoin checkout simple, applied to chains that do not hand it to you for free. Those addresses are accounts that only your passkey can authorize a transfer out of, and on EVM chains we use smart contract to consolidate them into the destination you registered. Read more about that here.

The short version: attribution is now solved on the merchant side, so the customer no longer has to do the work of solving it.

What your customer sees

An address, a QR code, the exact amount, the network, and a countdown. They send from Coinbase, from Binance, from MetaMask, from a hardware wallet, from anywhere. They never connect anything and they never install anything.

There is no Paymento wallet for them to learn. That is deliberate. The embedded wallet is infrastructure on your side of the transaction, not a product your customer has to adopt.

What changes for you

Setup no longer asks for an extended public key. Creating an Embedded Wallet store takes a passkey. No xpub, no seed phrase to write down and store safely, no key management decision before you have taken a single payment. For merchants who found the old setup screen intimidating, this is the bigger change.

Settlement becomes something you do. This is the real difference and it deserves to be stated plainly rather than discovered. Payments arrive at per-order addresses inside your store wallet. They stay there until you settle them to the address you registered, which you do from the Settlement page and authorize with your passkey. Paymento cannot move them anywhere. Bring Your Own Wallet stores have no settlement step at all, because funds go straight to your wallet. Embedded stores trade that for the checkout experience.

You do not need native tokens on every chain. Paymento fronts the network fee at settlement and deducts the cost from your Paymento balance, so you are never blocked from settling because you have no ETH or no SOL sitting around.

Set an underpayment tolerance. Because customers now enter or scan the amount themselves, a payment can arrive a fraction short. Without a tolerance those land as partial payments and need your attention. You define an acceptance band below the requested amount, capped under 5%. In practice 0.1% is enough, and it is what we recommend. more on underpayment tolerance docs

Refunds get easier on unsettled funds. If the money is still in the store wallet, you sign a refund directly in the panel with your passkey. Crypto payments are still irreversible, so a refund is a new on-chain transaction recorded against the original order, but you no longer have to send it manually from elsewhere and submit the hash.

Your existing stores do not change. Nothing is being migrated. Bring Your Own Wallet and seed-phrase stores work exactly as before, at 0.5%, with the same wallets and the same behaviour.

What Paymento can and cannot do with your money

The honest version of a non-custodial claim is a list of constraints, not an adjective.

Funds in an Embedded Wallet store can only be settled to an address you registered, and that constraint is enforced in the smart contract rather than in our backend. A backend rule is a promise, and promises fail when the company keeping them is compromised. A contract rule is a property of the system. Changing your registered address requires your passkey plus a verification code sent to your email, and we hold neither.

The key material lives with Turnkey, encrypted, with generation and signing happening inside AWS Nitro secure enclaves. No Paymento server, no Paymento employee and no Turnkey employee can extract that key material or move your funds unilaterally. We name the vendor deliberately. Key storage is a bought component, and telling you which one lets you evaluate the claim rather than take our word for it. The parts we built are the contract-enforced destination, the two-factor requirement on address changes, and the per-order account model described above.

Pricing, including when not to use this

Embedded Wallet stores are 0.5% plus $0.20 per transaction. Your first one is included on the free plan, and new accounts start with $15 in credit that both fees draw against. The blockchain network fee at settlement is not covered by that credit.

The flat $0.20 matters most on small tickets, and it is easier to say so here than to let you find it on an invoice. If your average order is under about $20, a Connect Your Own Wallet store at a flat 0.5% is the better deal and we would rather you took it. Pricing comparison

What this does not change

Tron still requires a wallet connection at checkout. Tron settles by direct withdrawal rather than by consolidating per-order addresses, so the attribution problem described above is not solved there yet. If a large share of your volume is USDT on Tron, this release covers less of your checkout than the headline suggests. Ethereum and Solana are where it lands today.

Settlement still depends on block confirmation. Payments confirm when the network confirms them, and that varies by chain and by congestion. Nothing here makes a transaction final faster.

Payments are still irreversible. That is why there are no chargebacks, and it is also why a refund is a deliberate action you take rather than a dispute someone files against you. There is no dispute layer, by design.

Your compliance obligations are unchanged. Non-custodial architecture changes Paymento’s position. It does not change yours. Whatever KYC, AML, tax and reporting duties apply to your business still apply.

The numbers are coming, and here is why they are not in this post

We built this because our own checkout data showed a wide gap in completion between chains that require a wallet connection and chains that do not. That gap is the entire reason the project existed.

We are not publishing the figure today. The straightforward comparison across chains has problems we found ourselves. It mixes test invoices in with real ones, and the chains involved attract different kinds of customers, so some of the gap is who chose that chain rather than what the checkout asked of them. A number we would have to defend with three caveats is not worth publishing.

The comparison that settles it is the same merchants, on the same chains, before and after this release. That removes the confounds in one move, and it exists in a few weeks. We will publish it then, including if it is smaller than we expect.

Already running a store? There is nothing to re-integrate

If you are live on Paymento today, switching is a configuration change, not a development one. Create an Embedded Wallet store, then update the API key in your plugin or your own integration to the new store’s key. That is the whole migration. The endpoints, the webhook payloads, the verify call and the payment states are all unchanged, so nothing in your code has to move. Your existing store keeps working alongside it, and orders already in flight stay where they are.

Two things to do once you have switched, neither of them code. Set an underpayment tolerance, since customers now enter the amount themselves and 0.1% is usually enough. And check the Settlement page, because funds now wait there for you to consolidate rather than arriving in your wallet on their own.

Try it

Create a store at paymento.io, choose Paymento Embedded Wallet, and authorize it with a passkey. Your first store is included, and the $15 credit covers your first payments while you watch what your own completion rate does.

If you already run a store, tell us what changes. We would rather publish before-and-after numbers that came from real merchants than from our own dashboard.