Ability to pass email as parameter in openTrialPage or openPaymentPage

[benf2004]

I already collect the user's email before starting a trial. It would be nice for it to autofill so they don't have to enter their email twice when they click on the "start trial" or "login" button. You could either accept the email as a string or an object. Then you could pass it along as a URL Param and automatically fill in on the form.

[burkybang]

You could add a content script to extensionpay.com, and do it yourself

[WofWca]

Good idea. Unfortunately, there is a drawback. If you don't already have a content script for extensionpay.com, you'll have to add it, which will start showing the permission warning, like it says here

ExtPay/README.md

Line 201 in 37d1da3

The content script is required to enable `extpay.onPaid` callbacks. It will add a permissions warning when installing your extension. If you're using a bundler, you can create a file called something like `ExtPay_content_script.js` that only contains `import 'ExtPay'` or `require('ExtPay')` and use that in the `"js"` field above.

[burkybang]

Right, but as you've quoted adding a content script is required if you want to listen for onPaid callbacks, so developers would likely already have a content script there.

[JordanTreDaniel]

Maybe we need a way to programmatically do a lot of things?

I think this gets at a bigger issue, which is; we should have a way to programmatically sign users in and out, or start trials for them. The standard api of interacting with openThisPage or openThatPage can be a little inconvenient, and for me, I already manage sign-ins and accounts, so I don't like asking my users to sign in twice. (Once for my api/ext, and once for extpay)

It would be nice to:

1. Get/sign in the user from extPay as getUser(email: string = null) (get user should take an email, since I already have one for the user)
   1a. This would eliminate the need to open the login page, as we would be logging them in with their email. (security could be issue, but we could auto-generate a password for them and store it in our own db, passing it in with the email)
2. If user doesn't have a trial, we could potentially start one for them by calling a method with their email (and jwt from step one or password if needed)
3. openPaymentPage would stay as the way to manage subs and what not, as it does make sense. If we didn't like opening the tabs, maybe a way to programmatically do read status and change it would be nice.

I haven't submitted a PR bc I believe the stuff is obscured behind the api at https://extensionpay.com/api please correct me if I'm wrong, but the real sign in logic, as well as trial starting logic is prob inside of the api right?