cryptoinfraEvery crypto wallet comes down to one question: who holds the private key? The key is what signs a payment. Whoever holds it can move the money, and nobody else can.
If your business offers crypto to its customers, this question decides a lot more than security. It decides what your support team can fix, what your users must learn, how fast you can launch and what you are responsible for. This guide explains the two models in plain words and helps you pick the right one.
#The two models in one minute
A non-custodial wallet keeps the key with the user. The user writes down a seed phrase, usually a list of words, and their app signs payments on their own device. Your business never touches the key.
A custodial wallet keeps the key with a provider. The user sees an address and a balance, and asks for a payment. The provider checks the request, signs it and sends it to the blockchain.
Neither model is "better" everywhere. They solve different problems for different products.
#What each model means in practice
| Question | Non-custodial | Custodial |
|---|---|---|
| Who can move the money? | Only the user | The provider, when your app asks |
| User loses their phone or seed phrase | Money is usually gone for good | User signs in again, balance is still there |
| Can your app show balances and history? | Only by reading the chain | Yes, from one API |
| Can you add your own fee to a payout? | Hard, the user signs the payment | Yes, it is part of the payout request |
| Can support help with a stuck payment? | Very little | Yes, every payment has a record and a status |
| What users must learn | Seed phrases, network fees, gas tokens | How to sign in |
| Time to launch | Long, you build the wallet app | Short, you call an API |
#When non-custodial is the right choice
A non-custodial wallet makes sense when the user's control is the product. Think of a wallet app for people who already hold crypto, who want nobody between them and their coins, and who are comfortable keeping a seed phrase safe.
It also fits when your business must never be able to move user money, for legal or trust reasons, and you have the team to build and maintain a secure app on every platform your users have.
The cost is real, though. You cannot reverse a mistake, you cannot recover a lost key, and every support ticket about a missing payment ends with "we can't see or change that".
#When custodial is the right choice
A custodial wallet makes sense when crypto is a feature inside a bigger product. Common examples:
- a marketplace that pays sellers in USDT;
- a freelancer or creator platform with payouts;
- a game or app that keeps a balance for each player;
- a remittance or payroll service;
- an online store that accepts stablecoins.
In all of these, your users want the money to arrive and to be able to send it on. They do not want to learn about private keys. And you need to see every payment, add your own fee and help users when something goes wrong.
#Questions to ask a custodial provider
Custodial does not mean "trust us and hope". It means the provider takes on the job of keeping keys safe, so you should check how they do it. Ask these questions before you choose:
- Where do the signing keys live? They should be kept apart from the servers your app talks to. If an API server can sign a payment, one bug or one break-in can drain wallets.
- How are addresses made? A good setup makes addresses from watch-only keys, which can create an address but never spend from it.
- Are the books checked against the blockchain? Balances in a database can drift. The provider should compare them with the chain often and raise an alert on any gap.
- Can a retried request pay twice? Networks time out. Payouts should take an idempotency key so a repeat returns the first payout, not a second one.
- How is the dashboard protected? A password alone is not enough for a screen that controls money. Look for an authenticator code and an emailed code on every change.
- Can you test without real money? A sandbox with the same API saves you from learning on live funds.
- Does it stay under your brand? Your users should see your name, not the provider's.
On our platform, signing keys never live on the API servers, addresses come from watch-only keys, balances are matched with the blockchain every few minutes, and every dashboard change needs both codes. The security page explains each part.
#How a custodial wallet works, step by step
Here is the flow your app would follow with a custodial wallet API:
- A customer signs up in your app. You create them on the API with your own user id.
- They get a permanent TRON address. It works for USDT, USDC and TRX, and it never changes, so they can save it.
- Someone sends them crypto. The platform sees the transfer, waits for confirmations, credits the balance and sends your app a signed webhook.
- The customer asks to withdraw. Your app asks for a fee quote, shows it, then sends the payout with an idempotency key.
- The payout goes on-chain. You read its status until it is confirmed, and your app shows the transaction to the customer.
Your customer never sees a seed phrase. Your team never handles a private key. You see every step. The wallets page and payouts page show this in more detail.
#Common mistakes
| Mistake | What goes wrong | Better way |
|---|---|---|
| Choosing non-custodial for a mass-market app | Users lose seed phrases and blame you | Use custodial when crypto is a feature, not the product |
| Choosing custodial without asking about keys | One weak server can risk every wallet | Ask where signing keys live, in writing |
| Keeping your own copy of balances as the truth | Your numbers drift from the chain | Read balances from the API |
| Skipping two-factor on the dashboard | One stolen password controls payouts | Turn on two codes for every team member |
| Going live without a sandbox run | The first real error happens on real money | Test deposits, payouts and errors first |
#A simple way to decide
Ask yourself three questions:
- Do my users want to hold their own keys? If yes, and they know how, non-custodial fits.
- Do I need to see payments, add a fee or help with support? If yes, custodial fits.
- Do I want to launch in weeks, not months? If yes, a custodial wallet API is the shorter road.
Most businesses that add crypto to an existing product land on custodial, because their users came for the product, not for key management.
#In summary
Non-custodial gives the user full control and full responsibility. Custodial hands key safety to a provider and gives you visibility, fees and support. For a business, the right question is not which is "more crypto", but which one your users can actually live with, and which provider can show you exactly how the keys are kept safe.
If you want the technical side next, our white-label crypto wallet API guide walks through every call.
Ready to give your customers their own wallets under your brand? Sign up free and try it in the sandbox today.