Paxalpay
Paxalpay
In Beta
Overview
Gallery
The Argument I Lost
Paxalpay is a Nigerian fintech product that lets crypto holders convert their tokens into naira — instantly, without the risk of P2P. Send crypto, receive naira. Use it to pay bills, send money, live your life.
I designed the entire product from scratch. App, website, admin dashboard. This is not a walkthrough of all of it. This is about one decision. One I argued against, lost, and shipped anyway.
The Problem Inside the Product
Paxalpay is a financial product. That means trust is not a nice-to-have — it is the product. Users are depositing real crypto, receiving real naira, and moving real money. Security is not a feature. It is the foundation.
So when the authentication architecture came up, I had a clear position.
My Argument
The product doc called for a single PIN — four digits — that would handle both signing into the app and authorizing transactions.
I pushed back.
My concern was straightforward: one PIN doing two jobs creates a single point of failure. If someone watches you unlock your phone, they now have everything. Login access and transaction authorization. There is no second gate. No friction between "I'm in the app" and "I'm moving money." In most apps, that's a manageable risk. In a wallet handling crypto-to-fiat conversions, it's a different calculation.
My position: the login PIN and the transaction PIN should be different. Two separate credentials. Two separate layers of protection.
The Counter-Argument
The engineer's position was equally valid. One PIN means less friction. Less friction means fewer forgotten credentials. Fewer forgotten credentials means fewer support tickets, fewer dropped users, fewer people abandoning the product mid-onboarding.
Fintech products lose users to complexity. A second PIN — even if more secure — is another thing to remember, another failure point, another reason to close the app. The argument was not wrong. It was just optimising for a different risk.
My position: the login PIN and the transaction PIN should be different. Two separate credentials. Two separate layers of protection.
What Shipped
Single PIN. Their call won.
I executed on it cleanly. The implementation is simple, the onboarding is smooth, and the experience holds together. But I still think the trade-off went the wrong way.
In a product where the trust proposition is the product — where the entire pitch is "safer than P2P" — I believe users would accept the friction of a second PIN if we framed it correctly. Not as a burden. As proof that we take their money seriously.
What I'd Do Differently
I'd propose a middle ground I didn't fully explore at the time: a single PIN for login, but a mandatory biometric confirmation for transactions above a threshold. Most modern phones support this natively. It adds a meaningful second layer without asking users to remember anything new.
The security argument survives. The friction argument survives. Nobody loses. That's the version I'd ship.
View project Gallery
Overview
Gallery
The Argument I Lost
Paxalpay is a Nigerian fintech product that lets crypto holders convert their tokens into naira — instantly, without the risk of P2P. Send crypto, receive naira. Use it to pay bills, send money, live your life.
I designed the entire product from scratch. App, website, admin dashboard. This is not a walkthrough of all of it. This is about one decision. One I argued against, lost, and shipped anyway.
The Problem Inside the Product
Paxalpay is a financial product. That means trust is not a nice-to-have — it is the product. Users are depositing real crypto, receiving real naira, and moving real money. Security is not a feature. It is the foundation.
So when the authentication architecture came up, I had a clear position.
My Argument
The product doc called for a single PIN — four digits — that would handle both signing into the app and authorizing transactions.
I pushed back.
My concern was straightforward: one PIN doing two jobs creates a single point of failure. If someone watches you unlock your phone, they now have everything. Login access and transaction authorization. There is no second gate. No friction between "I'm in the app" and "I'm moving money." In most apps, that's a manageable risk. In a wallet handling crypto-to-fiat conversions, it's a different calculation.
My position: the login PIN and the transaction PIN should be different. Two separate credentials. Two separate layers of protection.
The Counter-Argument
The engineer's position was equally valid. One PIN means less friction. Less friction means fewer forgotten credentials. Fewer forgotten credentials means fewer support tickets, fewer dropped users, fewer people abandoning the product mid-onboarding.
Fintech products lose users to complexity. A second PIN — even if more secure — is another thing to remember, another failure point, another reason to close the app. The argument was not wrong. It was just optimising for a different risk.
My position: the login PIN and the transaction PIN should be different. Two separate credentials. Two separate layers of protection.
What Shipped
Single PIN. Their call won.
I executed on it cleanly. The implementation is simple, the onboarding is smooth, and the experience holds together. But I still think the trade-off went the wrong way.
In a product where the trust proposition is the product — where the entire pitch is "safer than P2P" — I believe users would accept the friction of a second PIN if we framed it correctly. Not as a burden. As proof that we take their money seriously.
What I'd Do Differently
I'd propose a middle ground I didn't fully explore at the time: a single PIN for login, but a mandatory biometric confirmation for transactions above a threshold. Most modern phones support this natively. It adds a meaningful second layer without asking users to remember anything new.
The security argument survives. The friction argument survives. Nobody loses. That's the version I'd ship.
View project Gallery