Payy Card review: self-custody and the limits of privacy

I see the Payy Card's main appeal in the separation between holding crypto and spending it: users controlled their wallet, while the card connected that balance to ordinary merchant payments. Kevin Soell's May 30, 2026 review described how that arrangement worked after almost weekly use for roughly nine months. The accompanying description now says the card was discontinued, so the terms below describe its earlier offer.

What the Payy Card was designed to do

Payy combined a crypto wallet with a Visa card issued by a US bank. Purchases drew on the wallet balance and settled through the banking system. That let users spend crypto at merchants without making each payment publicly readable on a blockchain.

Although the creator called it a credit card, his account described funds being deducted from the user's wallet. I would judge it by that funding model rather than assume the credit-card label meant access to borrowing. For anyone comparing crypto cards, the practical questions are where the purchase money comes from and who has to approve the payment.

Getting the card required a light KYC check. KYC, short for know your customer, is the identity verification used by financial services. Users therefore had to identify themselves despite the wallet's privacy features.

The intended use was everyday crypto spending with control over the underlying balance. The creator's regular use offered one account of how it worked, but it could not establish that every merchant would accept every transaction. A payment service still had to connect the wallet to the checkout.

Self-custody changed who controlled the balance

Installing Payy automatically generated a wallet, with its recovery phrase available in Settings. The phrase is the backup needed to restore access; someone who obtains it may also be able to control the funds. Protecting it is part of the responsibility that comes with self-custody.

Money sent into Payy went to the user's own wallet rather than an account controlled by a card provider. The creator argued that nobody else could freeze the balance because only the user controlled access.

I would read that claim narrowly. Having the credentials to move funds does not oblige a bridge, issuer or payment intermediary to process a transaction. Those services can still affect whether a transfer arrives or a purchase succeeds. Control over a balance answers a different question from whether a particular spending route will work.

Self-custody also leaves recovery with the user. Losing both device access and the recovery phrase can make recovery difficult or impossible. Exposing the phrase can be equally damaging. I would keep it out of support chats, messages and websites that request it as a supposed verification step.

A recovery phrase is important, but practical access also depends on compatible software and the system holding the assets. Before relying on an app-linked wallet for essential spending, establish how recovery would work outside the normal app routine. That is a general precaution, not a claim that the creator tested an alternative recovery route.

Funding depended on a bridge

Users could fund Payy from a centralised exchange or from their own wallet over a blockchain. Both routes passed through the Payy bridge onto the Payy blockchain. The bridge connected the separate blockchain systems so value could move between them.

A top-up therefore involved the sending platform, the transfer network and the bridge. I would check which stage was still processing before assuming that the receiving wallet had rejected the deposit. A balance that had not arrived was not yet available for a purchase.

For large exchange withdrawals, the creator warned that the sending exchange could pause the transaction or take longer than usual to process it. He attributed that delay to the exchange's controls, rather than Payy. Sending from a self-custody wallet removed that exchange dependency but still required the bridge.

Bridge capacity was another constraint in his assessment. He expected enough liquidity for six-figure amounts and perhaps smaller amounts in the millions, but those were estimates, not verified capacity figures. Liquidity means the funds available to complete transfers, and he expected it to impose a practical ceiling eventually.

I would not treat those estimates as a deposit guarantee. Bridges introduce software, operational and liquidity risks. A user can retain control of a wallet while a transfer into or out of its network is delayed. The balance a wallet can hold says little about what a transfer route can process at a particular moment.

For a similar product, the basic funding precautions are:

1. Check the receiving network and asset before sending funds. A familiar token name does not establish that the destination supports the version you hold.
2. Send a small initial transfer.
3. Keep the sending transaction record until the balance arrives, and do not count a pending transfer as money available to spend.

Privacy stopped at the card network

Payy's public-blockchain privacy claim covered balances and payments. Its Send function hid the sender, recipient and transaction amount from public view, according to the creator's account. That addressed the visibility users often encounter on transparent blockchains.

The website material accompanying the discussion referred to a privacy layer and zero-knowledge circuits. Zero-knowledge methods can let a system verify that a statement is valid without revealing all the underlying information. For payments, the purpose is to limit what an outside observer can reconstruct from the public ledger.

I find it more useful to ask who can see a payment than to call it anonymous. The creator said Payy held transaction information for transfers between its users. Card purchases left records with the issuer because they settled through conventional financial infrastructure. Neither arrangement kept the transaction away from every service provider.

He also asked support whether data was automatically shared through tax-information exchange arrangements. Support reportedly gave a broad answer about complying with the regulatory standards applicable to each user. He then used an AI interpretation of that response to suggest information might be shared only after an authority requested it.

I would give that interpretation no weight as a legal or operational assurance. An AI reading of a general support reply cannot establish a company's reporting duties. Keeping a transaction off a public ledger also does not establish that its records are unavailable through lawful requests.

Spending crypto can count as a taxable sale in many countries. Privacy features do not remove reporting obligations, and ordinary-looking card purchases can create recordkeeping work. Keep the amount spent, its value at the time and the information needed to establish its acquisition cost under local rules.

The creator supported financial privacy but rejected concealing taxable events. That position allowed for keeping financial activity out of public view while still meeting tax obligations.

Fees and how Payy earned money

The earlier offer was free to obtain, with no additional Payy charge for the main funding and spending actions. These were the creator's provider-fee claims, rather than a complete account of every cost along the payment route.

I would still account for costs outside Payy. An exchange can charge for sending funds, a blockchain transfer can require a network fee, and currency conversion can affect the amount spent. A provider charging nothing for its part does not make the entire transaction cost-free.

The review leaves regional eligibility, the full fee schedule and conversion terms unresolved.

The creator explained Payy's revenue through interchange: merchants paid a card-processing charge, with portions going to participants including the issuer, Visa and Payy. His simplified example was a 100 € supermarket purchase with a merchant charge of 1 to 2 %. Those figures illustrated the business model; they were neither a quoted consumer fee nor a guaranteed merchant rate.

Payy also earned revenue by supplying payment infrastructure to businesses. An app or company could integrate it to let users receive or send stablecoins, crypto assets designed to track a reference value. That gave Payy a source of income beyond individual cardholders.

I would consider those revenue sources when assessing how a service could operate without charging users for each action. They explain where income might come from, but they do not establish that consumer pricing will remain unchanged.

The creator's further view was that Payy prioritised growth over profit and might later add investment services. He identified that as his own thesis, not something support had confirmed. A possible future revenue source could not establish the cost of an existing payment.

Spending limits and declined payments

Support reportedly told the creator that Payy had no fixed card-spending limits. It did use a dynamic fraud and risk-control tool, however, which could reject a transaction even when the wallet held enough funds.

I would read the no-limit statement as the absence of a stated fixed ceiling, rather than unconditional authorisation. The creator attributed possible declines to the extra checks, but that explanation could not establish why every individual payment failed.

Neither he nor his business partner had encountered a declined payment. A community member reported rejections at airports in the United Arab Emirates and Indonesia, as well as at a German Apple Store. The displayed rejection gave that member no further explanation.

Those accounts did not support a calculation of the card's overall reliability. Frequent successful use could not prove universal acceptance, and a handful of failures could not establish a failure rate across merchants.

For time-sensitive purchases, I would keep another payment method available. A customer could not predict a risk-control decision from the wallet balance alone. Relying on one authorisation for a travel connection or essential purchase would leave little room to recover from a rejection.

Cash access was a separate feature. Contactless ATM withdrawals were in private testing and were not live at publication. The broad claim about withdrawal fees therefore did not demonstrate a free ATM service that users could already rely on.

Wallet management, support and speculative rewards

Payy did not support multiple wallets on one device. Switching wallets involved more than selecting another account. The process described by the creator was:

1. Uninstall the Payy app.
2. Manually delete the cloud backup of the recovery phrase.
3. Reinstall the app so installation generates another wallet.

I would not begin a deletion-based process without securing the recovery material and knowing which wallet it restores. A newly generated wallet is a different destination. Creating it does not move the old wallet's balance.

Support was available through the chat function under More. The creator praised the detail of its answers and reported a typical wait of about half a day. He also said he received no special treatment as a creator. These were his observations, not a response-time commitment from Payy.

That wait could matter when a problem needed an immediate answer. I would not depend on asynchronous support to rescue a payment while standing at a till. Detailed replies can help with a complicated issue, but they are different from immediate intervention at checkout.

Payy also had a points programme. The creator, along with others, expected the points would probably lead to a future airdrop, a distribution of crypto assets. He did not present that expectation as a confirmed reward entitlement.

I would assign no dependable spending value to that prediction. Points alone did not establish a cash payment, token allocation or return. Any benefit would depend on the terms of an actual distribution, so the expectation offered no sound reason to increase spending or move more funds.

Calling the programme cashback would also imply more than the available information supported. Cashback suggests a defined benefit tied to qualifying spending. Here, there were points and a prediction about what they might become, with no confirmed allocation to include in the card's economics.

Check the spending route before the rewards

When assessing a similar card, I would start with a concrete purchase and follow the funds from the sending account to the merchant. The useful questions concern how the asset reaches the wallet, how it becomes available for payment and who authorises the purchase. That is more informative than judging the product by its card label.

For pricing, compare the amount removed from the wallet with the merchant's bill. Include the funding expenses discussed above and the exchange rate where conversion occurs. The relevant figure is the total economic cost of completing the purchase, rather than the fee charged by one participant.

I would also identify who can help at each stage. A mistaken blockchain transfer, delayed bridge transaction and rejected card purchase need different remedies. Preserve transaction references so support can determine which part failed instead of having to reconstruct the transfer from a general description.

Continuity deserves its own check. Establish how funds could be accessed if the card stopped working or the app became unavailable, using the recovery considerations above. A contingency plan needs to work without the convenient route that normally handles the payment.

Finally, ask which observer each privacy feature protects against. Public-ledger privacy, access by the service provider and visibility to other payment participants are separate questions. I would want that map of access before giving any value to a rewards programme, especially one whose proposed airdrop remained unconfirmed.