Choose the service
Select a product and billing cycle whose published limits match the workload. Domain availability and product availability are rechecked by the systems responsible for actually fulfilling the order.
Order lifecycle
Paid is not the same thing as provisioned.
DotMoose treats checkout, payment, provisioning and successful service use as separate states. Customers should be able to tell where an order is, and failures must remain visible until they are resolved.
Service order
From checkout to usable service.
Create the customer/order record
The client and invoice/order state are created in the billing system. Contact, billing and service information must be complete enough to fulfil and support the order.
Payment and verification
A successful payment updates the financial state, but it does not by itself prove that hosting, a domain or another service was provisioned successfully. Fraud, payment-authentication or provider checks can require additional handling.
Provisioning
The billing system calls the appropriate hosting, registrar or other provider workflow. A paid invoice does not make a failed provider action successful. The failure stays visible until provisioning is actually complete.
Access and configuration
After the service is created, the customer receives the appropriate account/service access and can complete application, DNS, email or migration steps needed for the workload.
Verify the real result
For a website, that can include DNS resolution, HTTPS, the expected application response and any business-critical email/forms. A provisioned account is not automatically proof that the complete website journey works.
Domains
Availability checks are not reservations.
A domain can appear available during a search and still become unavailable before the registry accepts the registration. Premium, reserved, eligibility or registry-specific rules can also affect the final result.
Registrar-authoritative availability
Purchase decisions use the approved registrar/provider path. A missing WHOIS/RDAP record is not treated as registration availability.
Registry acceptance matters
The domain is not yours until the registrar/registry flow confirms successful registration and the account reflects the resulting domain state.
Registration and hosting are separate
Registering or transferring a domain does not automatically prove the website or mail records are correct. Nameservers and DNS records still need to point to the intended services.
When something fails
Do not hide operational state.
Payment failure
An unsuccessful or incomplete payment should not create a falsely active paid service. Authentication and declined-payment states remain separate from successful settlement.
Provisioning failure
If a hosting platform, registrar or another provider rejects the request, the order is flagged for review and the customer receives a clear outcome.
Service works differently from account creation
A newly created account can still have DNS, application, certificate, migration or mail problems. Support should diagnose the failing layer after provisioning; account creation alone does not prove DNS, applications, certificates, migrations or mail are working.
Cancellation & refunds
Billing state and data state both matter.
Cancellation, renewal, refund eligibility and service termination are governed by the applicable billing/service terms. Customers should preserve data they need before a service reaches its final deletion state.
Billing
Read the billing policy.
Understand renewal, cancellation and refund rules before ordering or cancelling a service.
Billing & cancellationSupport
Need help with an order?
Use the support path for an order, provisioning or service question. Do not send passwords or payment credentials in an ordinary support message.
Contact supportInfrastructure
See where the service boundaries sit.
The public storefront, billing system, shared-hosting workload and backup workload are separated so one function does not need every credential or customer-data path.
Infrastructure & boundariesLaunch gate
Automated sales follow end-to-end tests.
DotMoose should not enable a product merely because checkout renders. The order, payment, provisioning, login/use, failure, cancellation and recovery path must be proven for that product first.