PocketPay

The problem

Accepting decentralised payments usually means wrestling with tools built for engineers rather than for shopkeepers. PocketPay set out to change that, giving merchants a wallet they could set up themselves and use at the counter, while customers paid in a way that felt as familiar as tapping a card. Behind that simple surface sat a good deal of moving machinery, from merchant accounts and payment codes to a marketplace and the exchange of assets.

What I did

• Mapped the two journeys the product had to serve, the customer paying and the merchant taking payment, and kept the plan built around both.
• Put first things first, placing the wallet and the payment flow at the front of the work so the core was solid before the extra features arrived.
• Kept the Flutter application and the React merchant interface aligned, since a change on one side so often reached into the other.
• Looked after the written guides in Gitbook, so anyone joining the work could understand how the wallet was meant to behave.

The wallet was planned to include:

• Wallets that keep users in full control of their own funds.
• Payments made through SolanaPay.
• A simple interface for merchants to create and manage their accounts.
• Point of sale support that lets merchants generate a payment code for each sale.
• A marketplace for digital collectibles.
• The ability to exchange one digital asset for another.
• Access to decentralised applications.

Why it was tricky

People are careful with their money, and rightly so. Every part of the wallet had to feel trustworthy and behave predictably, even though a great deal was happening out of sight. The hardest part was keeping the experience plain and calm while so many features leaned on one another underneath.

How it turned out

The wallet was delivered with support for decentralised payments through SolanaPay, merchant account management, point of sale codes, and a marketplace for digital collectibles. The product is now being prepared for its public release.