How to Handle Domain Orders, Renewals, and Transfers as a Reseller

A reseller should not treat registration, renewal and transfer as interchangeable order types. They have different checks, customer approvals and failure modes. Use the following workflow whether you process orders manually, through API or via WHMCS.

New registrations: availability is only the first check

Confirm the customer-authorized spelling and extension.
Check availability and the exact first-year price; premium names or TLD requirements may change the final charge.
Collect accurate registrant contacts and any extension-specific eligibility documents.
Collect customer payment and confirm the NiceNIC account has sufficient usable balance.
Submit one registration, inspect its returned result and verify the resulting domain/expiry date in the account.
Send the customer the name, renewal date, nameserver status and any required verification notice.

A query reporting "available" does not reserve the domain. If the registration fails, investigate the error before charging again.

Renewals: verify before and after payment

Read the real expiration date, TLD-specific renewal window and renewal price. Confirm the customer has authorized the period and charge. Submit renewal early enough to address registry exceptions; verify the registry expiry date has actually advanced. If the payment succeeded but the date has not changed, do not automatically rebill—open an exception ticket.

Transfers: obtain authorization and watch state

Confirm the releasing registrar and TLD-specific process, any transfer lock, applicable waiting period, registrant approval and AuthInfo/EPP code where required. Preserve current DNS information. Submit the transfer and track pending/approved/rejected states; completion may require action by the gaining and losing registrars or registries.

Your exception queue

Keep a daily queue with: order ID, domain, action, price, customer consent reference, submission timestamp, last API response, registry state, and next responsible party. Escalate pending paid orders; do not equate HTTP 200 with completed registration.

Use the NiceNIC API v2 documentation for individual operation parameters and Support for registry-specific exceptions.

A practical order-state model

For each registrar action, keep customer payment, reseller submission, NiceNIC API/portal result, and final registry state separate. This prevents a common failure in which a customer receives a "registered" notification immediately after their invoice is paid although the TLD is still awaiting documents.

Name availability, contact accuracy, TLD eligibility, price

Registry-sponsored domain exists with expected registrant and expiry

Renew

Current expiry, allowed term, account balance

Registry expiry advances by the correct term

Transfer in

Current registrar, lock/EPP or ccTLD procedure, authorization

Registrar of record changes and the domain remains delegated

DNS update

Backup zone, customer approval and authoritative host

New answer appears at the actual authoritative nameserver

Example: a failed API call after a timeout

Your application sent a renewal request but the network timed out. Sending it again without checking order history could create a second billable action. First retrieve the account transaction/domain record, verify the registry expiry date and classify the outcome as completed, pending, rejected or unknown. Only retry when the operation is confirmed safe to repeat.

Create alerts for orders stuck in unknown/pending states beyond their expected processing windows. Give each alert a domain name, error code, last action time and responsible person. The customer should receive a meaningful status, not an automatic "success" because their card was charged.