Skip to main content

​
Real-World Example

A platform operator opens ABC Collections from Manage Accounts to review revenue, consumer-account performance, membership plan details, eco profile information, and company contacts. The view supports platform support work without editing unrelated creditor data.

​
Visual Flow

​
How It Should Work

  • It should show platform-level creditor context needed for support.
  • It should return summary revenue metrics for membership, consumer payments, automated communications, platform campaigns, EcoLetters, and notice responses.
  • It should return performance metrics for total active accounts, settlements, plans, successful payments, disputes, and no-pay accounts.
  • It should return the eco profile, plan, and contacts tabs from one company-scoped response.
  • It should preserve cross-creditor boundaries even for Super Admin users.
  • It should keep membership, merchant, user, and consumer impact visible without returning list-page action metadata.

​
How It Should Not Work

  • It should not return row-level list actions in the detail response.
  • It should not make broad platform edits look like normal creditor self-service changes.
  • It should not update a different creditor because of route or selection mistakes.
  • It should not hide whether a value is creditor-owned or platform-owned.

​
Developer Notes

  • GET /manage-creditors/{company} returns the profile payload for the detail page.
  • The company must have an active root creditor user to be visible from the detail endpoint.
  • Metrics are scoped to the requested creditor company and use successful payment/communication records only where money is shown.
  • Changes here can affect creditor login, billing, merchant readiness, and consumer payment behavior.
  • routes/superadmin/index.php
  • app/Http/Controllers/SuperAdmin/CreditorController.php
  • app/Http/Resources/SuperAdminCreditorDetailResource.php
  • app/Services/SuperAdminCreditorProfileService.php
Last modified on June 16, 2026