I want a Zen customer to pay for dinner without thinking about us. Let alone the blockchain.
He should see the amount, approve the payment and get back to his evening. If the technology underneath deserves applause, we can applaud it at the office. Making the customer understand our infrastructure before he can buy something is a peculiar interpretation of progress.
This is where I believe stablecoins will earn their place: in ordinary transactions that become easier, cheaper or more dependable because the technology is there. The customer can remain gloriously uninterested in the plumbing.
A Card That Connects Receiving To Spending
On 10 September 2026, MoneyGram launched a card connecting a stablecoin balance with everyday Visa spending and cash access. The launch was in Colombia; wider expansion was planned. Customers could transfer funds to themselves for collection in local currency at MoneyGram locations. A physical card with ATM withdrawals was planned for later in 2026. Those distinctions matter. A product announcement has geographical boundaries, even when its ambitions do not. MoneyGram’s launch announcement.
The arrangement brings together Rain’s card infrastructure, Crossmint’s wallet capabilities and Stellar. What interests me is the practical connection between receiving money and being able to use it. That is a worthwhile direction to build in. Whether any particular product fulfils its promise must be judged through actual use, including its charges and restrictions.
My earlier Liquidity First argument was about making value easier to move. There is a necessary next question: move where, and for what purpose? A payment can reach a wallet while remaining several expensive steps away from the thing its owner wants to buy.
We should stop declaring victory halfway through his transaction.
The Customer Is Not Your Systems Integrator
Imagine a designer who has completed work for an overseas client. He receives digital dollars and wants to keep some, spend some and withdraw the rest as cash. Each intention is reasonable. Now imagine that accomplishing them requires three applications, another identity check, a conversion he does not understand and a trip to a collection point that cannot complete the withdrawal.
Our designer has become an unpaid systems integrator. He had rather hoped to remain a designer.
I start with his purposes. I hold individual freedom and value for value as first principles, and that means regarding the individual as an end in himself. His earnings represent work, judgment and time he has already invested. He has every right to expect the service handling them to respect his choices and explain its terms. His afternoon is not a free resource available to compensate for our unfinished product.
That principle has consequences for how I want ZenWallet and Zen Card developed. Receiving funds, holding a balance, spending and withdrawing need to form an intelligible experience. Where different providers, permissions or accounts are involved, the customer should understand the relevant consequences without being sent off to reconstruct the arrangement himself.
Some complexity can disappear from the screen. Some must remain visible because it affects a decision. Knowing which is which is part of the job. The customer should see supported networks before any funds are sent.
Holding money is a decision too. A customer receiving a payment may want to leave it alone for a while. The application should explain any holding charges or conditions without prodding him into unnecessary conversions. I would be especially careful about presenting an investment or yield feature as the natural destination for an idle balance. Taking additional risk requires a separate, informed choice. The money being readily available does not mean it is ours to put to work.
Nor should access depend on becoming a constant user of the application. Someone who opens it twice a month still deserves a clear balance, functioning recovery and an uncomplicated exit. Usage statistics are our concern; the purpose of his money remains his.
Price Is The Whole Number
Take price. A tiny blockchain fee can be technically accurate and commercially irrelevant to what the customer actually pays. If he spends money entering the system, loses more in conversion and pays again to withdraw, showing him the smallest charge tells him very little.
Consider an illustrative transfer of $500.
| Sent | $500.00 |
| Entry into the system | −$5.00 |
| Conversion | −$7.50 |
| Cash collection | −$4.00 |
| Network charge | −$0.02 |
| Received | $483.48 |
| Total cost | $16.52 |
These are invented figures, not MoneyGram or Zen prices, but they expose the weakness of selling a two-cent transaction while leaving the other sixteen dollars out of the conversation.
I want the customer to know what he gives up and what he receives before committing. If the final amount depends on a rate that can change, explain when it becomes fixed. If another party may charge separately, identify that possibility clearly. There is no honour in a cheap headline followed by an expensive surprise.
And cheap has to be judged against the available alternative. A domestic bank transfer may already serve a particular customer extremely well. I have no interest in making him take a tour through crypto merely because we happen to sell the tickets. Use the route that improves his outcome. Earn from the improvement.
That might be a meaningful saving on an international payment, access outside conventional banking hours, or the ability to retain a chosen currency until he needs it. Sometimes the benefit is simply removing the repeated work of moving between services. Each claim needs a real customer and a transaction against which it can be tested.
Speed Ends When The Cash Is In His Hand
Speed requires similar honesty. A blockchain confirmation is one event in a longer process. Funds may still need checks, conversion or delivery through another system. For someone collecting cash, success occurs when the cash is in his hand. A transaction identifier will not pay the taxi driver who brought him there.
This is why the cash end deserves serious attention. Collection hours, identification requirements, limits and the ability of a location to complete the transaction all belong in the experience we evaluate. Telling somebody to travel before he understands those conditions transfers our uncertainty into his expense.
People will continue to use cash for reasons that make sense in their own circumstances. A merchant accepts it. A relative prefers it. Connectivity is unreliable. I do not need to approve those reasons before respecting the customer’s choice. Financial freedom becomes a rather small idea if it only permits the behaviour favoured by the product team.
The Declined Purchase
Then there is the card payment that fails.
Picture a customer whose wallet shows enough money but whose purchase is declined. Somewhere, an authorisation rule, funding step, spending restriction or technical fault has intervened. To the customer, the relevant fact is brutally simple: the product said he had money, and he could not use it.
The interface needs to distinguish a total balance from the amount currently available to spend. A hold, a pending conversion and a completed debit are different things. Those differences should survive the journey from the underlying systems to the screen. Attractive typography cannot reconcile an incorrect balance.
A failed purchase also needs an intelligible answer. What happened? Is any amount reserved? Is it safe to try again? What should the customer do now? We cannot always disclose every fraud signal or promise immediate resolution, but that does not excuse a blank refusal followed by an invitation to refresh the application.
Payment status is practical information. The words we use determine what somebody does next, including whether he accidentally makes the same payment twice.
Returns deserve equal attention. Buying a shirt and returning it a day later introduces a refund into the system. The customer wants to know where that refund will arrive, which currency he will receive and whether conversion affects the amount. Funding a card with stablecoins does not guarantee an instant refund. Product design has to account for the journey back as carefully as the journey out.
I would test these ordinary inconveniences before congratulating a team on an elegant demonstration. A successful purchase proves one path works. I also want to see what happens when it fails, and whether a customer can follow a refund without sending six screenshots.
A transaction identifier will not pay the taxi driver who brought him there.
Support Is Part Of The Product
Support belongs inside the product economics and the product promise. If the customer arrives through Zen, we should own the work of helping him resolve the problem, even where another company must perform the underlying action. Passing him between partners is a choice about how much of his time we are willing to waste.
The support person needs enough information and authority to help. An apology copied into a chat window cannot establish whether funds moved. Someone must be able to trace the transaction, identify who needs to act and give an honest next update. I would rather hear a precise explanation of a delay than a cheerful assertion that everything is being expedited.
Hide The Machinery, Not The Risk
There is a limit, however, to the promise of making the technology disappear. The risks must not disappear with it.
A balance described as stable still deserves questions. What asset is held? Who issues it? How can it be redeemed? Who controls access? Circle’s USDC terms for users outside the EEA, for example, describe eligibility conditions for direct redemption and circumstances involving blocked addresses or frozen funds. Those are features of a specific issuer’s arrangements, not claims that every stablecoin operates identically. Circle’s USDC terms.
I want those material facts expressed in language a reasonably attentive person can understand. A dollar reference does not abolish issuer risk, and it does not protect somebody whose expenses are in another currency from exchange-rate movements. Nor should a familiar dollar symbol imply protections that the actual product does not provide.
The owner must have enough information to choose. That is compatible with simplicity. Hiding a restriction to improve sign-ups deprives the customer of an informed choice. I have no interest in building a business that way.
Control also has to survive contact with a lost phone, a stolen credential or a suspicious payment request. A person should understand what recovery involves before the emergency. Security measures ought to reduce a real risk and leave a comprehensible route forward for a legitimate user. There is no achievement in making an account equally inaccessible to its owner and a thief.
When I talk about freedom, I include the freedom to refuse a transaction, change a preference and leave a service. I also accept that payment products operate through actual contracts, institutions and laws. We have to explain the boundaries of the control we provide. Claiming unlimited sovereignty over an arrangement with several external decision makers would insult the very independence we claim to respect.
What This Means For Zen
For Zen, this makes the product question larger than which provider offers the most impressive feature list. I want to understand the full route a customer takes and where we are responsible for making it work. The balance he sees, the price he accepts and the assistance he receives have to tell the same story.
That is the direction I am building towards. It requires testing and operating discipline; a partnership announcement cannot supply either. Our standards should apply just as firmly when the fault lies in our own design as when it lies with a supplier. Blaming the supplier is especially unconvincing when choosing and integrating that supplier was our decision.
I would measure whether people complete the task they came to do, how long it takes until they can use the money, and what they finally pay. I also want to see the failures that averages conceal. A service can appear fast because its successful transactions complete quickly while a small group of customers remains stuck for days.
Watch those customers. Read their cases. Find out whether a missing message, an unclear requirement or an avoidable manual step caused the delay. There is useful product work hiding in those complaints, although it rarely arrives wrapped in the language of innovation.
Profit Is The Point, Not The Apology
The business must make money from doing this properly.
I intend Zen to earn a worthwhile profit. That includes a return for taking risk, building the product and putting capital to work. I will not dress up that intention as reluctant charity. The customer wants a useful service at an acceptable price; I want an enterprise whose earnings justify the effort and investment. Both purposes can be satisfied through an honest trade.
To know whether that trade works for us, we have to count the costs that flattering presentations omit. Provider charges, conversions, fraud losses and support consume revenue. A transaction that requires repeated manual intervention can destroy the apparent benefit of cheap settlement. Making the underlying transfer cheaper is useful, but the saving needs to survive everything around it.
This gives us a reason to solve the customer’s problems properly. Clearer instructions can reduce failed attempts. Accurate balances can reduce anxious support calls. Reliable records can shorten investigations. Some of the best improvements to profit begin with removing something that was irritating the customer anyway.
There will be cases where the economics do not work. Then we should change the service, charge honestly or decline to offer it. A promise of permanent convenience funded by permanent losses eventually becomes somebody else’s unpleasant surprise.
Nobody Should Have To Care
Stablecoins are useful to me insofar as they help build an experience worth choosing. I do not require customers to admire the mechanism, adopt a financial identity or regard ordinary spending as participation in a movement. They have their own lives to live. That is rather the point.
I will judge Zen by whether a person can get paid, understand what he holds, use it on known terms and receive competent help when something goes wrong. Earning his continued business depends on making that sequence work.
When he can finish dinner, settle the bill and return to the people at his table without wondering how his money travelled, the technology will have done something worth celebrating.
Quietly, at our end. He has better things to do.
