Investigate the original operation before repeating an order, changing a backend or replacing credentials. A billing record, provider bucket and working customer connection are separate outcomes.

Establish which operation ran

1. Identify the original service and accepted product/options.
2. Confirm the saved Backend, server group and intended account.
3. Inspect Clients & Storage and Activity for its original result.
4. Check the automatic setup policy and payment event.
5. Establish which bucket or credential already exists before retrying an uncertain operation.

An Active WHMCS billing service does not prove module setup ran. A provider bucket can also exist even when a later credential or verification step failed. Repeated orders can create additional resources rather than repairing the original result.

Interpret connection tests by backend

A fresh server needs a saved product/backend association before the module can resolve it. Keep one backend per server and use a separate group for each backend. A saved binding is not changed into a migration by editing a product.

AWS tests bucket listing; R2 tests permission-group and bucket reads; MinIO tests administration and S3 reads. Spaces creates a temporary full-access key for its bucket-list check and attempts cleanup. None proves every provisioning or configuration write. Review the failing backend and permission rather than applying a generic full-access-token repair.

Check customer access separately

Use the application guide to compare the exact endpoint, bucket, current full key pair and signing/addressing settings. Check current access mode and any recent rotation. A failed permission transition does not prove that the requested mode applied, and rotation is not a universal repair for it.

Use usage checks for a stale or incomplete figure and retained-data recovery for a termination mistake. Neither is a reason to purge storage as a reset.

See the PD Object Storage WHMCS guide for related tasks, or explore PD Object Storage.