The first tension was between compliance and momentum. Regulated money movement requires KYB. KYB takes time. A creator in the middle of a viral moment does not have time.

The decision was to decouple the two halves of a recipient’s lifecycle. A new user could create an account with only essential information and immediately generate a working contribution link. Funds collected during this window accrued in a held state. Settlement unlocked once KYB completed.

The tradeoff was operational. Holding funds adds reconciliation complexity and creates a state the support team has to be ready to explain. It was worth taking because time-to-live was the dominant variable for recipients, and any product that gated link generation behind KYB would lose them at the moment they were most ready to adopt it.

The Design A single sign-up screen with intentional scope. Name, email, country, business name, business identifier, password, OTP. Country drives the compliance profile. Business identifier drives the URL slug. OTP closes the loop on email validity. Everything else moves into the KYB flow, where it belongs. The user lands on a working dashboard with a generated link, ready to share, within minutes of sign-up.

The product’s centre of gravity sat on the link rather than the account. The dashboard, the QR code, the embed, the shareable URL are not separate features. They are the same payment page expressed in four distribution contexts.

This decision was structural, not cosmetic. The data model put the link at the centre and let the account hang off it, rather than the other way around. The consequence was that customisation propagates automatically. The recipient never has to think about propagation, because propagation isn’t a feature. It’s a property of the model.

Recipients didn’t talk about “managing their Payaza account.” They talked about “the link” they shared. The product respected that mental model in the architecture.

The Design A single “Create Link” action on the dashboard generates four artefacts simultaneously: the live URL, a dynamic QR code, an embed snippet, and a copyable share string. All four point to the same payment page. Update the logo once, and the page behind the link, the QR on the flyer, the embed on the website, and the bio link in Instagram all reflect it.

The design question was what to expose and what to hold. Logo, copy, and background carry the recipient’s identity, so they got exposed. Layout, typography, button placement, and field order carry the donor’s expectation of what a checkout looks like, so they stayed held. The 2x2 from synthesis (donor confidence vs. recipient control) was the framework that decided each surface element.

The Design A customisation panel with four controls: logo upload, sub-heading text, background image, and background gradient. A real-time preview shows changes before publishing. After save, a modal surfaces the shareable URL. The moment of completion is also the moment of distribution, by design.

The default state, before any customisation, is already functional. Usable, shareable, not embarrassing. The recipient adds polish on their own timeline.

The donor surface was designed against an e-commerce benchmark rather than a donation benchmark. The heuristic evaluation in Track 1 set the bar. Wallet-first, single-context, inline validation, no redirects.

The decision to lead with wallets cost us something on the recipient side. Recipients sometimes asked for card to be the prominent option because that’s what they were used to. The decision held because the data from the comparative teardown was unambiguous: wallet-first surfaces outperformed card-first surfaces across every product we benchmarked.

The Design Apple Pay or Google Pay appears as the first option on supported devices, ahead of card entry. Card entry uses the patterns donors recognise from any well-designed checkout: autofill, smart field validation, inline errors that don’t break the flow. Currency selection happens in one place. International payment methods surface based on the donor’s region, not the recipient’s. The entire flow lives on a single page, with no redirects.

The journey mapping in Track 3 surfaced that currency decisions were being asked of donors who had no context, and of recipients in moments where they had no headspace. The fix was to move the decision to the place where the recipient had both: at setup, and at any quiet moment after.

The Design Settlement currency is exposed at the dashboard level, not buried in settings. The recipient picks USD or their local currency, and can switch at any time. The product absorbs the back-office complexity (multi-currency reconciliation, FX margin, settlement timing across rails) so the recipient sees a toggle and nothing more.