One of the critical security bugs I found in the payment code I reviewed and eachOne of the critical security bugs I found in the payment code I reviewed and each
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
One of the critical security bugs I found in the payment code I reviewed
and each of the bugs could have caused serious financial loss
Bug #1: Trusting the payment gateway's response amount 💸
The code:
Gateway says: charge $1,000,000
System credits: $1,000,000
User actually paid: $1,000
One compromised API response = $999,000 loss.
The fix?
YOUR database is the source of truth.
✅ Store amount at initialization
✅ Verify gateway matches YOUR record
✅ Credit from YOUR database, not theirs
The wallet vote closed. 8% picked counts up front, 92% picked cards.
I promised the reasoning either way, so here it is.
The old home screen showed your credentials directly. You saw the card, you tapped it, done, plus a log of what just happened. A few people made that case in the comments, and they are right that taking it away costs a step.
The reason I took it anyway: the card row only works while the wallet is small. At twenty or thirty documents a horizontal swipe stops being access and turns into a search problem, and the card you need is never the one on screen. So the home screen stopped trying to be the wallet. It became a summary, with the real list one tap down where it can be sorted and filtered, and Scan QR moved to the top because scanning a code is what people open this app to do.
The outside signal we had was weak, and I want to be straight about that. The product sits in a regulated space under NDA, so no open user testing. We ran internal sessions and demoed both versions at industry events, where 88% of partners and investors picked the counts version and kept using the word premium. That tells me it reads as credible to the buying side. It does not tell me how it feels on the tenth open of the month. Different questions.
What would change my mind: if people turn out to open a specific credential often, pinning one or two to the home screen is the cheap fix. I would rather add that later than start from a layout that breaks at scale.
🧪 I don’t trust a mobile feature until I’ve tested the failure case.
Happy-path testing is easy.
What matters is what happens when:
• the API returns 500
• the user goes offline mid-action
• a payment succeeds but the response is delayed
• a push token expires
• the app is reopened after 3 days
• a deep link points to missing content
• the same button gets tapped twice
• background sync fails silently
Most production bugs don’t happen when everything works.
They happen when one dependency behaves differently than expected.
That’s why for React Native apps, I like to test recovery behavior, not just feature behavior.