You can use Openprovider for domain registration and PayRequest as the customer-facing portal for linked domain services, subscriptions and invoices. You manage the registrar connection; customers sign in to their own account area. Available domain and DNS actions depend on the linked service, permissions and DNS configuration.
This guide is for domain resellers and agencies that want customers to find their services and billing information without sharing access to the reseller account.
How does the registrar connect to the customer portal?
Openprovider handles registrar operations. PayRequest connects the commercial customer records and exposes linked services in the portal. A payment provider handles payments, while DNS may be hosted by a separate provider.
These roles matter when a customer asks whether a domain is active, an invoice is paid or a website points to the right server. Those are different questions with different sources of truth.
| Customer question | What you need to connect |
|---|---|
| Where is my domain? | Registrar domain identity and the correct customer service |
| What do I owe? | The customer's invoice and accepted subscription price |
| Can I change nameservers? | An eligible linked domain and permitted registrar action |
| Where do I edit DNS records? | The active nameservers and the provider hosting that DNS zone |
Configure the customer environment first
Set your business details and available customer-portal settings. Review how customers sign in and find invoices, subscriptions, services and support. The PayRequest customer portal documentation describes the core account area.
Use fictional records while reviewing the layout. Ask whether someone unfamiliar with domain reselling can identify their service, understand a payment request and find help. Branding is useful, but correct customer assignment is more important than appearance.
Add your Openprovider connection
In PayRequest, open the Openprovider app within services and integrations. The current configuration includes a connection name, username, password, test mode and default nameservers. Check that your Openprovider account is suitable for the required API access.
Keep provider credentials in the protected connection settings. Customers should use their own portal login, not the credentials for your reseller account.
A connection test checks access. It does not prove that every extension, contact record or future order will be accepted. Resolve account and configuration issues before you publish a paid domain product.
Link each domain to the correct customer
Configure your domain product with the correct provider and extension. Review its selling price and the registrant information collected during checkout. PayRequest's paid domain-order process links a registration to the customer and subscription.
Existing domains require a deliberate review. Connecting a registrar account alone does not prove that every existing domain has been matched to the right customer or billing arrangement. Confirm the domain identity and ownership of the customer relationship before granting access or attempting registration again.
Check these three relationships together:
- The provider identity refers to the intended registrar domain.
- The service is assigned to the intended customer.
- The subscription represents the agreed commercial arrangement.
If any relationship is uncertain, review it before making the service available to that customer.
Decide where DNS will be managed
Nameservers identify the authoritative DNS service for a domain. The registrar and DNS provider can be different companies. A linked domain may expose nameserver management, while DNS-record actions need the appropriate separate connection and setup.
If you use managed DNS through Cloudflare, review that integration too. A nameserver change without preserving the necessary records can interrupt website or email traffic. Before switching, review website records, mail-server records and relevant TXT records.
Domain registration does not create a complete email service. Explain whether you provide mailbox hosting, mail-related DNS configuration or both, and what remains with another supplier.
Use this customer-portal acceptance checklist
This is a recommended review plan, not a statement that these checks have already been performed for your account.
| Check | Expected outcome |
|---|---|
| Sign in as the assigned customer | Only that customer's services, invoices and subscriptions are visible |
| Open the domain service | The domain and linked service belong to that customer |
| Open the invoice | Amount, currency and payment status match the order |
| Review management options | Available actions match the configured service and permissions |
| Trace the DNS path | It is clear which provider hosts the active DNS zone |
| Find support | The customer knows how to contact your business |
Review both the merchant and customer views. An administrator seeing a correct record is not a substitute for checking what the assigned customer can access.
Handle payment and registration exceptions separately
If payment succeeds but registration fails, first check whether the domain already exists at Openprovider before retrying. Investigate the cause and tell the customer the actual delivery status. A payment receipt should not imply that an unconfirmed registration has completed.
Assign someone to handle exceptions. A customer portal can make service information accessible, but it does not remove the need to resolve registrar questions or configuration errors.
Give domain customers one account area
PayRequest Hosting Billing brings billing and customer management together for hosting businesses. The Openprovider connection links domain services to that customer workflow without requiring you to build an entire portal around a registrar API yourself.
Explore the PayRequest Openprovider integration and decide which domain services to offer. The fictional customer portal demo lets you review the account experience before setting up your own customers.
Editorial note: prepared with AI assistance. Product code and sources were reviewed on 5 November 2026. The checklist is a suggested acceptance process. No customer accounts or registrar settings were changed for this article; the cover is an illustration.
