d3cacaaea5a44fbdb2abfa4e0067f412Q: ADVANCED QUESTIONS It's been mentioned before that if we wanted to bundle our access to our subscription ...
service with another service of ours, or for any other reason wanted to handle the payments ourselves, that we could do so using a coupon that sets the subscription to free, but that we would then be responsible for the $1 per subscriber, and also for any billing issues, and management of unsubscribing them if they ever canceled with us.
This is an extremely powerful and useful options as it would mean that MANY useful and advanced things could be done while we wait for potential features to be added to your system that may be one day added, or might never be added... like for example an affiliate program... but it would also give us freedom to use alternative payment processors that we might have special agreements in place to save us processor fees, or use marketplaces or APIs that could be beneficial.
Just to be clear, the method above opens a LOT of doors and makes this all a lot more attractive as it would remove many limits that would otherwise be in place... I was very happy to see this described vaguelly in previous questions.
For clarity:
1. Am I 100% correct that we the above can be done? That we can give out coupons to make it a free subscription to certain customers?
2. For really ramping up ease of use and open up a lot of other possibilities and make managing the above scenarios super powerful... might I suggest a subscribe / unsubscribe API access... Is this possible? If so... any sort of timeline?
3. If the above API is not yet available, or might take a year to add to the system, a middle ground / temporary measure could be that we could bulk subscribe or unsubscribe by CSV upload? Would this be possible? If so... any sort of timeline?
4. Seperate question to the above scenario, but also falling under more advanced usage... many of us would like to incorporate our streaming service into existing sites, or have a sign up button and log in button on landing pages that we control ourselves... It SHOULD be super easy to be able to provide us with the PHP code for these buttons... but I'd like to have it on the record if this is something we CAN do, or if we are going to be told NO to having a sign up and log in on our existing sites.
Jay_Odeum
May 15, 2024A: Thanks for your feedback and follow-up questions. And thanks for your patience in our response. Its been busy!
1) Yes, this is correct. You can do this as you've stated.
2, 3, and 4) I really hate to sound wishy-washy but please understand we've been asked here in the comments about a multitude of features that people want. And while I LOVE so many of the features and fully expect to build them, I also don't want to make promises in a comments section that influence your buying decision. I honestly feel that you should make your buying decision on what exists today, and on your own judgment of if you believe in what we are doing and our honest communication and transparency throughout this process. I just don't want to influence you about what "may be" in the future and risk disappointing you. So... now that i've gotten that off my chest, my answer is that all these ideas seem inevitable to me. But also keep in mind the complexity. We offer direct customer support to your subscribers. So if we give you a way to cancel a subscriber through an API, and the customer asks us why... we won't know. So we need to account for this properly and build requirements into how this works that protects us both. We don't want to throw features into the wind, we want to be smart about how we do it. Ultimately, I can't imagine us not building deeper integrations and APIs and embeddable widgets for you to get the most out of our platform, and as we are doing some of our more complex enterprise integrations, some of these elements are happening in a nice way that we can add to the core product too.
I hope that helps!
Verified purchaser
Since you work with Stripe already, I can only recommend your team having a look at the Stripe solution for marketplaces. While you run these on different channels/ domains, I think it could solve a lot of complexity for you and the publishers:
- not more expensive/ fees than your current single install (apart from the work to implement it on your side that is)
- solving all the international payment stuff immediately
- you can auto-deduct your subscriber fees (risk & work reduction)
- payment fees directly deducted form publisher
- Stripe performs KYC on each publisher "sub-account"
We use it on a B2B marketplace and I can totally say it provides a very good user experience for all sides.
That being said, I am not sure if/how it would implement across different domains, just wanted to share a maybe comparable use case with Stripe. (If allowed, link: https://stripe.com/marketplaces; please delete if not OK).
You hit the nail on the head there with Stripe's marketplace and Connect tools. Its the top solution we are vetting right now and the most likely end outcome for sure. Not sure our timing and we may need an interim solution that is a bit more manual to make sure we cover any new international publishers that launch quickly.