Standard Subscription Center query string encoding

Question

I have been trying to figure out this use case, unfortunately without success:

A person logs into a portal (client's own portal, nothing to do with any of the Salesforce platforms) and they have the ability to manage their Marketing Cloud subscriptions.

There is no possibility to develop API calls - let's just say this must be a cost-effective solution, so we would like to include a Marketing Cloud Subscription Center link in the panel that the person sees after logging in. This link could be generated based on their Salesforce 18-digit ID or Email Address. The mysterious part is, how is the query string built and encrypted for use with Subscription Center?

I've been looking into the SFMC standard Subscription Portal links, and they all have a 128 character query string:

/subscription_center.aspx?qs=4a061e4f03fad329893841e12f5f587aae588bfbdb31eb7d6033069492594a5f572439116ec6204eeb3f02de8837f6b1da63ee34f66e647c7cabb4f0974d0000

I suppose the query string must be the SubscriberKey or ID encrypted, but I wasn't able to decrypt it using any of the regular AMPscript functions.

The Subscription Center Link itself seems to contain a 64 character query string:

%%[
set @link = concat("%%subscription_center_url%%")
]%%
<a href="%%=RedirectTo(@link)=%%">click</a>

/subscription_center.aspx?qs=dfb1e5f836055bec5e7c1497c44f9b76af1c73eabe14feab3f3e66631e9d0000

So basically, my question is, how do I generate a correct query string for use with the Standard Subscription Center, given that I have access to that person's 18-digit Salesforce ID or their Email Address?

---

EDIT

OK, taking into account Johannes' and Don's comments, what would be a valid workaround?

I don't mind creating an automation to generate those links and update contacts/leads in Sales Cloud, so that every Contact/Lead has their own link that we can then feed to the external portal.

I am aware that this would not be a problem with a custom subscription centre, yet here we need to use the standard one.

Answer 1

This is my understanding and I strongly believe that there shouldn't be any method to encrypt this method by yourself, otherwise there would be a security breach for salesforce.

I believe you will not be able to do it because you do not have the private encryption key and encryption method that salesforce uses to encrypt the data. Therefore you will not be able to encrypt this correctly. It is a security feature that you cannot decrypt that information, otherwise cloudpagesurl and other functions would expose sensible information which you could decrypt when you know the private key. I believe you have no chance at all to cover this.

====

I see multiple problems with a standard subscription center. It takes lots of data when you want good dataviews like unsubscribe or listsubscriptions. Some of them are JobID, SubscriberKey, SubscriberID, BatchID, ListID, .... all these data is usually inside the QS string. When you would then unsubscribe it takes these information to invoke a event to unsubscribe.

When you integrate the subscription-center-link into a cloudpage and add the qs parameter that has been created by a cloudpagesurl function inside an email for example, you can see that its working and transforming that qs parameter in a even different qs-parameter. Therefore it has to take some values (like the subscriberid or subscriberkey) from that qs parameter and generate the new subscription-centers there.

Storing those values of the subscription-centers will not help if you are interested in good data in your dataviews.

For my understanding there is no good way.

=====

Off Solution: Adam Spriggs once answered my questions to a custom unsubscribe center, which you can visit here: