Feature Requests
Under Review

Brand Identity in Customer Portal

Currently, the customer portal displays the account (business) name instead of the brand’s name and identity. This creates a lot of confusion for customers, because the name they see in the portal doesn’t match the brand they actually purchased from.

It would be helpful if the customer portal could:

  • Show the brand name, logo, and visual identity instead of (or in addition to) the parent account name.

This would make it much clearer for customers which product/brand they’re managing and reduce support queries caused by brand/account name mismatches.

2 Comments

Sign in to comment

Amritanshu Rai·2 months ago

Update after rebuilding this in my own app, in case it helps scope the fix.

I replaced the portal with payments.list plus invoices.payments.retrieve and it mostly works. The brand_id filter on payments.list does exactly what I need, and the invoice PDFs come back correctly branded per brand already. So the data layer is brand aware. It really is only the portal shell that is not.

Two more gaps I hit on the way. Both mean the portal can still do things the API cannot, so "just build it yourself" is not a complete answer.

1. Invoices cannot be regenerated with a full address

The portal offers "Download with full address details", where the customer types in address line, state, city and postal code and gets an invoice with the complete address on it. invoices.payments.retrieve only takes a payment id, so there is no way to offer that outside the portal.

This matters more than it sounds. My checkout uses minimal_address, so I collect only postal code and country. Every invoice therefore reads "560024, IN". Anyone expensing the purchase at work needs a real address on the document, and today the only way to produce one is the portal, which is branded as my other business. So the customers most likely to need it are exactly the ones I least want landing there.

2. The billing address is stored on the subscription, not the customer

subscriptions.update({ billing }) works fine for subscribers. But CustomerUpdateParams exposes only email, name, phone_number and metadata. So a one time purchase, in my case a lifetime plan or a one year plan, has no address to edit at all. Those customers cannot complete or correct their billing address by any route, portal or API.

It also means the address is per subscription rather than per person, so someone with two subscriptions has to fix it in two places, and there is no single source of truth for who they are.

What would help, roughly in priority order

  • brand_id on customerPortal.create, as in the original post. That alone unblocks everything, because I could simply link to the portal again and delete the code I just wrote.
  • An address argument on invoices.payments.retrieve, or any documented way to regenerate an invoice with a supplied address.
  • Billing address on the customer object, so one time buyers are not stuck and so an address belongs to a person rather than to a subscription.
  • A payment methods API, so the portal is not the only way to change a payment method.

Happy to test any of these. I have a live account with two brands and real payments on both, so I can verify quickly.

Posting anonymously

Shreya·2 months ago

This makes total sense to prevent customer confusion. We plan to support custom branding (brand name, logos, and visual identity) in the customer portal in a future update.

Thanks for the great feedback!

Posting anonymously