The core step of Payjoin is simple: paste the full payment request (BIP21 URI) given by the receiver into your wallet's send field, instead of copying only the address. That URI contains a pj= parameter. Your wallet uses it to find the receiver's collaboration endpoint, and both parties build the transaction together.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
If you are already familiar with normal Bitcoin transactions, using Payjoin feels almost the same. The difference is that the receiver adds an extra input, so in the final broadcast transaction, not all inputs come from the sender.
Sending Payjoin: What You Actually Do
Mainstream mobile wallets that currently support sending Payjoin directly include Cake Wallet (v4.28 and above) and Bull Bitcoin Mobile. The desktop wallet Wasabi Wallet also supports it, but Wasabi requires Tor to be enabled.
Using Cake Wallet as an example, there is no extra "Payjoin mode" switch. Just send normally:
On the send page, paste or scan the receiver's full Payjoin link. If you only copy the address part starting with bitcoin:, Payjoin will not trigger and it becomes a normal transaction.
Check the amount and receiver label, and confirm the fee. Payjoin does not add extra cost. Both sides pay normal network fees.
After confirming, the wallet negotiates with the receiver's Payjoin endpoint in the background. You do not need to do anything extra after sending. Just wait for broadcast.
Wasabi Wallet's path is slightly different: paste the BIP21 URI containing pj= into the "To" field of the send dialog. The rest of the confirmation flow is the same as a normal payment.
There is one easy misunderstanding here: clicking "Send" does not mean Payjoin definitely succeeded. If the receiver has no available UTXO to contribute right now, the address formats are incompatible, or the Payjoin server cannot be reached, the wallet will fall back to a normal transaction. The money still arrives, but the privacy benefit is lost.
Fallback is a designed behavior, not a failure. But if you clearly need Payjoin's privacy effect, you cannot rely on this fallback. It means "tried but did not succeed," not "failed and money was not sent." Before paying, it is best to confirm with the receiver that they are also using a Payjoin-supporting wallet.
Receiving Payjoin: You Need Coins First
The receiver's steps depend on the wallet. Using Cake Wallet as an example:
Go to Settings → Wallet settings → Privacy, and turn on Use Payjoin.
Go back to the receive page. A "Payjoin enabled" mark will appear below the QR code. Share this QR code or link normally.
When the sender scans it with a Payjoin-supporting wallet, collaboration happens automatically. You can see the status change in the app (waiting for sender transaction, in progress). You do not need to manually confirm anything.
One hard requirement: your wallet must have coins. Payjoin requires the receiver to contribute an input. An empty wallet has no UTXO to contribute. So when a new wallet is just created and the balance is zero, even if the receive page shows the Payjoin mark, it will actually receive money as a normal transaction.
If you use a wallet that does not run a receiving server (like the current version of Ginger Wallet), you cannot be a Payjoin receiver. You can only collaborate as a sender with a receiver who supports Payjoin.
How Much Better Is Privacy? Verification Standards
Payjoin aims to break the most basic assumption in blockchain analysis: all inputs of a transaction belong to the same person. This assumption is called Common Input Ownership Heuristic (CIOH). On-chain analysis companies use it to cluster addresses.
In a normal transaction, Alice pays Bob 0.1 BTC. Alice uses one 0.19 BTC UTXO as input. There are two outputs: 0.1 to Bob and 0.08999 change back to herself. Analysts can easily tell which output is the payment and which is the change.
In a Payjoin, Bob also adds one of his own UTXOs, for example 0.07341 BTC. The outputs become Bob receiving 0.17341 (0.1 payment plus his own 0.07341 back) and Alice receiving 0.08999 change. Neither output is a round number, and neither amount matches the actual payment amount. Analysts see two inputs and two outputs. They cannot determine which output is the payment, and they cannot assign both inputs to the same person.
But the statement "Payjoin always successfully hides information" needs conditions. The official Payjoin blog analyzed real cases and found that wallet fingerprints can break privacy again.
Fingerprints come from differences in how wallets build transactions. One example is signature format: some wallets always produce low-r signatures, while others produce them randomly. If one input in a Payjoin transaction has a low-r signature and another has a high-r signature, analysts have reason to suspect the inputs came from two different wallets. They may then try to assign inputs and outputs to different owners. Another example is inconsistent default nSequence values, or sighash bytes being explicitly written in some cases and omitted in others.
This means: if both parties use different wallets, Payjoin's privacy effect may be reduced. The transaction still does not look like a normal transfer, but analysts may be able to separate "sender" and "receiver" again. If both parties use the same wallet and the same version, the fingerprint signal is much weaker, but this is not something users can fully control.
What you can verify as a user is limited. After broadcast, check the transaction on a block explorer. What you can see is: number of inputs, number of outputs, and amounts. You cannot directly tell from on-chain data whether it successfully hid ownership relationships. That requires analysis tools and counterparty information. What you can do is confirm the transaction was broadcast and the amount is correct. If privacy is a hard requirement, align with the receiver on which wallet types both sides use.
When Payjoin Is Not Suitable
Payjoin helps privacy for normal transfers, but there are several scenarios it cannot solve:
The receiver already knows your identity. If you pay for a real-name order, the receiver already knows who you are and what you bought. Payjoin changes what on-chain observers see, but it does not change the transaction information the receiver already knows.
You use a hardware wallet. Ginger Wallet's documentation clearly states that the current version rejects Payjoin requests initiated by hardware wallets. Cake Wallet's support list also does not mention Payjoin support for hardware wallets.
You are using Tor and the receiver only provides an onion endpoint. Ginger's implementation rejects onion-only endpoints when Tor is enabled. The receiver needs to provide a compatible HTTPS alternative address. Whether this limitation applies to other wallets depends on the specific implementation version.
You need a "guaranteed success" privacy guarantee. Payjoin's fallback mechanism means that if negotiation fails, you will send a normal transaction. If a normal transaction would expose information you do not want to expose, confirm with the receiver before initiating that they are indeed using a compatible wallet and current version.
Version and Implementation Status
The currently recommended Payjoin protocol is BIP 77 (v2). Its core improvement is being asynchronous: sender and receiver do not need to be online at the same time, and neither side needs to run their own server. Communication goes through a "Payjoin Directory" relay. Messages are end-to-end encrypted. The directory server cannot see transaction content. IP metadata is protected with Oblivious HTTP (OHTTP).
v1 (BIP 78) is still used by wallets like Wasabi. It requires the receiver to run a server and both parties to be online. If you see operational differences between two versions in documentation, first confirm which version your wallet uses.
Payjoin Dev Kit 1.0 was released in August 2026. The core state machine API is stable, but the BIP 77 specification itself is still in Draft status and not yet finalized. This means there may be compatibility differences between wallet implementations, and cross-wallet Payjoin negotiation may not succeed every time.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
References
- Payjoin·Payjoin Dev Kit 1.0, page published or updated: 2026-08-11; checked: 2026-10-12.
- Wasabi Wallet·WalletWasabi v2.8.3 Release, page published or updated: 2026-09-13; checked: 2026-10-12.
- Cake Wallet Blog·Bitcoin Privacy Takes a Leap Forward: Cake Wallet Introduces Payjoin v2, page published or updated: 2025-05-18; checked: 2026-10-12.
- Cake Wallet Docs·Payjoin, page has no update date; checked: 2026-10-12.
- Wasabi Wallet·PayJoin, page published or updated: 2026-01-09; checked: 2026-10-12.
- Ginger Wallet·PayJoin and Message Signing, page has no update date; checked: 2026-10-12.
- Coldcard·What is PayJoin?, page published or updated: 2026-06-04; checked: 2026-10-12.
- Payjoin·Wallet Fingerprints Damage Payjoin Privacy, page published or updated: 2026-03-24; checked: 2026-10-12.
- Payjoin·Async Payjoin (BIP 77, V2), page has no update date; checked: 2026-10-12.
- Payjoin·The Evolution of Payjoin: From Two-Party Protocol to Multiparty Framework, page published or updated: 2025-03-17; checked: 2026-10-12.
