- Payment and wallet architecture
Case studies
Blockchain
CPay
cpay.worldProduct type:Decentralized infrastructure for crypto payments and crypto wallets
System state:Live system (real merchants, real users)
01
Launch context
At the moment architectural decisions were made, CPay was designed as a live payment infrastructure:
⌵Merchants integrate checkout and charge flows via API,
⌵Users interact through non-custodial or semi-custodial wallet logic,
⌵Payments, refunds, and internal transfers coexist within one system.
Once real users started paying:
•Transaction finality became absolute,
•User mistakes became financially irreversible,
•Any architectural flaw translated directly into trust loss.
There was no safe "post-launch adjustment window".
02
Core risk
Primary risk
A crypto payment system combines irreversible on-chain settlement with wallet and ledger operations that users expect to behave like traditional payments.
Secondary effects
⌵User errors cannot be reversed without breaking trust assumptions,
⌵Internal transfers can obscure accountability if not designed correctly,
⌵Refunds and charge corrections are constrained by blockchain finality.
This was a user-facing systemic risk, not a smart contract bug.
03
Decisions
Early decisions
•Payment flows were designed assuming no manual correction after execution.
•Internal ledger operations were treated as auditable primitives, not conveniences.
•Refunds and charge reversals were modeled as constrained processes, not guarantees.
Explicitly rejected:
"bank-like" UX promises that the system could not technically enforce.
Locked constraints
After the system went live:
•No retroactive correction of completed payments,
•Limited ability to intervene in wallet-level operations,
•Strict separation between on-chain finality and internal accounting.
These constraints were accepted to preserve consistency and auditability.
Validation
•Threat and failure mode mapping before irreversible steps.
•Test strategy focused on abuse paths and operational correctness.
•Review gates before deployment and before any privilege changes.
05
Outcome
What stabilized
⌵Payment and wallet flows behave predictably under real usage.
⌵Internal transfers remain traceable and auditable.
⌵No emergency intervention in completed user payments was required.
The system favors clarity over convenience.
What Remained Risky
⌵User mistakes remain financially final.
⌵Merchant integrations vary in quality and introduce edge cases.
⌵Regulatory and compliance expectations evolve faster than protocol logic.
These risks were accepted, not abstracted away.
06
Ownership
What we owned
- Charge, refund, and internal transfer constraints
- Risk acceptance around irreversible user actions
What the Client Owned
- Merchant onboarding and integration quality
- User education and expectation management
- Business and regulatory exposure