I see you previously closed a request related to this, as it was out of scope (However I'm assuming you were referring to the pricing preview feature itself).
Seeing as Paddle has mostly replaced all their documentation to refer to the "client side token" instead of the seller id, I think its wise to add support for- and prefer this method of configuration, as Paddle has stated that this is the preferred way now.
Quote from the changelog.
Existing methods that use seller will continue to work, but future methods may require client-side tokens. We recommend that you replace the seller parameter with token and a client-side token when you're next reviewing your code.
This PR adds the client_side_token configuration key, and uses the PADDLE_CLIENT_SIDE_TOKEN env key.
If no client side token is provided, it use the seller_id as before, however the client_side token will be take precedence over the seller_id if provided.
Breaking changes
None.
This change will not have any effect for existing consumers of the package unless they add the new env or config option to their code.
I see you previously closed a request related to this, as it was out of scope (However I'm assuming you were referring to the pricing preview feature itself).
Seeing as Paddle has mostly replaced all their documentation to refer to the "client side token" instead of the seller id, I think its wise to add support for- and prefer this method of configuration, as Paddle has stated that this is the preferred way now.
Quote from the changelog.
https://developer.paddle.com/changelog/2023/client-side-tokens
Implementation Details
This PR adds the
client_side_token
configuration key, and uses thePADDLE_CLIENT_SIDE_TOKEN
env key.If no client side token is provided, it use the
seller_id
as before, however theclient_side token
will be take precedence over theseller_id
if provided.Breaking changes
None.
This change will not have any effect for existing consumers of the package unless they add the new env or config option to their code.