Keep the customer who holds a domain registration separate from the reseller account that submits and pays for the order. Accurate mapping helps avoid contact errors, failed transfers and confusion when a customer moves to another provider.
IN THIS ARTICLE
01 Record the different identities
| Identity | Purpose |
|---|---|
| End-customer registrant | The person or organisation recorded in the registration contact data. |
| Reseller account | The tenant authorised to manage the domain through Domain Nexus. |
| Billing customer or invoice | The local commercial relationship and payment record. |
| API credential actor | The installation or authorised user making a particular request. |
02 Prepare an order correctly
- Confirm the intended registrant with the customer and collect accurate required contact data.
- Use the connector's standard contact mapping or current API fields. Do not substitute the reseller's company for convenience.
- Keep a stable local customer and order reference linked to the returned domain and operation IDs.
- Verify that the resulting domain belongs to the intended reseller tenant and that the provider accepted the intended registration contacts.
- Document who can authorise future contact changes, transfers and account moves.
03 Handle a customer move
A change of local billing account, a Domain Nexus reseller ownership request and a registrar transfer are different operations. Updating contact details does not itself reassign the Domain Nexus tenant. Likewise, moving operational management does not automatically rewrite registry contacts.
Use the supported workflow for the actual requested move, retain both parties' authorisation evidence and review any registry restrictions before changing a registrant and attempting a transfer.
Common questions
Does paying the invoice make the payer the registrant?
The invoice records payment. Check the actual registration contact data and intended ownership arrangement rather than inferring it from who paid.
Can a master reseller manage a customer's domain with its own key?
Only through permitted delegated routes and the assigned downstream context. The master relationship does not erase the child's ownership or the customer's registration data.
What if the wrong registrant was submitted?
Preserve the order evidence and request a supported contact correction after confirming authorisation. Check the TLD's current verification and transfer rules before making related changes.
Restrict contact data to the staff and systems that need it. Support reports should identify the mismatch without distributing unnecessary identity documents or API credentials.