Skip to content

Knowledgebase

Recover a FOSSBilling renewal without reusing an updated expiry as a new order

domain-nexus, domains-dns

The FOSSBilling connector uses the domain's pre-renewal expiration timestamp as part of a renewal's stable request identity. Preserve that value while recovering the same billed renewal. A newly synchronised expiry can represent a different renewal request if submitted again.

01 Before submitting a renewal

  1. Check the domain's current registry expiry and the expiration date stored by FOSSBilling.
  2. If the local expiry is missing or invalid, synchronise it before starting the renewal. The connector refuses to submit a charge without a valid expiration timestamp.
  3. Record the local order, requested term and original expiry with your operation evidence.
  4. Submit the renewal through the normal billing workflow and retain the upstream operation reference.

02 Recover a pending or uncertain result

Read the original operation before trying again. A pending result is not confirmation of renewal, and a transport timeout does not establish that the provider did nothing.

When repeating the same billed action through its supported recovery path, preserve the original term and pre-renewal expiry context. After the operation completes, synchronise the final registry expiry and reconcile the local invoice once.

If a scheduled sync already replaced the local expiry with the new date, do not blindly resubmit Renew. Compare that new date with the original operation and ask for reconciliation of the existing order. Submitting from the changed date can request another period.

Common questions

Why does the connector require an expiry before renewal?

It uses that timestamp to identify the intended renewal event. A missing date prevents a stable request and is refused before a charge is submitted.

Does pending mean the payment failed?

Not by itself. Payment, wallet settlement and provider execution are separate evidence. Inspect the original operation and related billing records.

Can I solve an error by changing the term?

A different number of years is a different business request. Correct the error and review a new quote if you intentionally change the term; do not use that change as a retry shortcut.

What should I preserve for support?

Keep the original and current expiry, domain, order ID, requested years, operation ID and exact redacted error. Do not include API keys, signing secrets or a full serialised customer contact object.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support

Powered by WHMCompleteSolution