Registrar Unification

Registrar operates outside the billing platform with its own payment flows, checkout surfaces, and fraud exposure. Unifying these into the platform gives Registrar the same payment infrastructure every other product uses — Unified Checkout, PDE confirm-before-commit, 3DS fraud protection.

Registrar is the largest product family still running its own payment flows. Domain purchases, renewals, and transfers each have bespoke payment flows with no Unified Checkout, no PDE confirm-before-commit, and no 3DS fraud protection.

Registrar has 3 bespoke payment code paths (purchases, renewals, transfers) that bypass the billing platform entirely. Target is 0 after all migrations.

A clean API for domain operations — renew, transfer, purchase. Owned by the Registrar team. The convergence point where all three domain flows meet before entering the platform payment path. Decouples domain logic from payment logic.

Domains are immediately useful (hosting, email, resale), hard to claw back once registered, and currently purchasable without any authentication gate. 3DS enforcement adds the gate. Purchases are the fraud target — renewals and transfers operate on domains the user already controls.

Migrate domain renewal flows onto the billing platform via the orders abstraction and Unified Checkout.

Migrate domain transfer flows onto the billing platform via the orders abstraction and Unified Checkout.

Migrate domain purchase flows onto the billing platform via the orders abstraction and Unified Checkout, with 3DS fraud protection.

Q3 asked: can we flip the payment ordering without breaking production? Q4 asked: does it work at scale? Q1 asked: can we delete the old code paths safely? Each yes compounded into the next quarter's starting position.