A framework for <podcast:funding> that pays developers, too #781
Replies: 5 comments 19 replies
|
Admittedly, this wouldn't support splits through most alternative payment gateways, like PayPal, X Money, Venmo, and such, unless those payment systems have similar splitting options. But this does support Apple Pay and Google Pay because Stripe supports them. I think this would even support ACH transfers! |
|
So, Podnews's support link is this - https://podnews.net/donate - which I guess can't be "split", since it bounces straight to Stripe's checkout pages. If I understand right, your solution is: I don't think we need to bake Stripe into this at all. Instead, it looks easy enough to me...
Money goes to the podcast app if a) the podcast app signs up with Daniel, and b) it sends the correct ?ref= code. Why does Stripe need to be involved at all? If it's trying to avoid a payment fee, easy is to just make those payments once a month? This would work using PayPal as well, no? |
|
My limited understanding is that you're a money transmitter if you're part of the money flow. You can't accept and split a payment on the user's behalf. You can't have your server direct the user's wallet to send payments. The payment sending process has to be fully under the user's control (e.g. an app running on their device). Again, I'm not a lawyer so that's my basic understanding. The money transmitter problem on the lightning side is primarily around unlicensed custodial wallets and accepting/splitting payments on behalf of other people to work around LNURL split issues. |
This is okay because you are the recipient of the money. Stripe and PayPal are the "money transmitters" and follow the appropriate regulations. The complications arise when I use my Stripe and PayPal accounts to take payments for you. That's essentially what Patreon does, and they have to have a whole legal structure and process to do that appropriately. If I provide a service to you—whether that's creating and hosting your payment page, or enabling the billing system for you to use, or referring people to you—I can be paid for that essentially as a non-employee contractor. This is why it's different for me to run an affiliate program for Podgagement. I compensate my affiliates for sending paying customers to me, and I pay them commissions as contractors. But I'm not accepting payments intended to be for them. So the "splits" model might have two approaches:
|
|
@ericpp > You can't have your server direct the user's wallet to send payments. The payment sending process has to be fully under the user's control (e.g. an app running on their device). I don't understand this bit. This is nothing to do with wallets or apps - it's a simple card payment that we're talking about here. @theDanielJLewis - OK, so as long as the PayPal or Stripe payments are going directly, rather than indirectly via you, then this is fine. Can you help with the documentation page for Stripe talking about how you charge a fee in this instance (aka "splitting a payment")? I'd like to understand a little more about this, but my Google-fu (or, in this case, Kagi-fu) is letting me down |
|
@jamescridland I was talking more in general rather than about this specific proposal. For this proposal, I'm guessing the user would get shipped off to Stripe to confirm and send the payment, which is fine. |
|
@jamescridland, was it a specific page you were struggling with? From a development perspective, I'm still working on fully understanding the implementation myself. |
|
I find this really interesting. The only part I’m a bit uneasy about is relying on a single payment provider. On my podcast’s funding page, listeners can choose between PayPal, Satispay, on chain BTC, lightning, and bank transfer. It’s possible that offering just one option would actually lead to more donations because of choice overload and similar effects. Philosophically, though, as a podcaster who openly supports and advocates for open technologies, taking away those choices doesn’t feel like the right thing to do. |
|
Yeah, and I'm not suggesting taking away such choices. Ultimately, I want the "value pages" I make for my Podgagement users to allow them to offer multiple payment methods, even if I don't get a cut. But that's where such a page could highlight a particular option with something like, "Choosing this helps support [podcast app] at no extra cost to you!" And I'm using Stripe as my example in this because Stripe is what I know, and it's the most common for other developers and site-owners, too. |
|
This thread focuses mostly on how to technically do automatic splits, so I don't want to distract from the main purpose. I'll just offer another direction that the funding tag could be taken that might simplify things, and how I personally think users might like to see it: Make the secondary app split explicit, separate, customizable, optional, and encourage it to be more substantial, like a tip (10% additional, not a 1% cut). Ideal flow, IMO:
The verbiage can all change, but the idea is:
|
|
Yeah, the "simplification" here comes from it being 2 transactions to 2 separate Stripe (or w/e) accounts, and the verbiage change from "fee" to "tip" ("support" is a better word) feels more along the lines of "value for value". The downside is that you have 2 payment provider fees since you have 2 transactions (partially why I'm suggesting a larger "tip", not a small "fee"). But podcaster and app developer could each pick their own payment provider (whatever "supportthispodcast.com" supports), and that could likely be transparent to the user, who is just putting in a value and pressing the Google Pay or Apple Pay button. So the "supportthispodcast.com" site is effectively just a site that lets you pay 2 merchants (podcaster, and optionally app developer) in sequence, in a simple way, not something that manages splitting a single payment in order to assess fees. |
|
Hmm. Why not do it so the user only sees one payment? Support page screen says...
When the user hits submit, the code makes two Stripe payments; one to Podnews, one to the podcast app? Keep the complexity away from the user, and especially don't ask them for two specific payments one after the other? This doesn't turn you into a money transmitter, surely? |
|
AFAIK it wouldn't make you a money transmitter if the platform supports it. But it sort of necessitates that the app and podcaster are using the same platform (and the platform supports it) if you want the user to only have to hit 1 button. If podcaster and developer use separate platforms, the user needs to be involved in both transactions (your payment credentials/approvals can't carry across providers). Splitting it out into 2 transactions every time lets that happen naturally. |
|
I think the listener would likely get confused why they see two charges on their payment method. Besides, this might not be very possible with Stripe and similar payment gateway technology to process two payments simultaneously to different payment accounts. |
|
Ah, sorry if it wasn't clear, but in my view of this, the 2nd charge would be explicit (e.g., you press the Apple Pay button again and have to double-click the side button again). The user would literally see 2 different transactions happening in front of them because they would be triggering both. No podcast app "fees", no secret second charge, everything triggered by the user, but also a lot more friction, and 2 transaction fees, which is the obvious downside |
|
Here's an actual example of what I'm suggesting. This is a payment I received to PodChapters, which currently uses Clerk for the user authentication and billing. 
Stripe and Clerk both offer a "Billing" product (note the capital B). And in this case, Clerk Billing is the system that triggers the one-time and recurring subscription payments. Thus, this is not using Stripe Billing for the recurring payments. Stripe Billing and Clerk Billing are both 0.7%. But since Clerk is the one trigging the payments, they bypass Stripe Billing's fee. So in this sample transaction, you see the Stripe-set 59¢ processing fee, and the Clerk-set 7¢ (0.7%) fee. And Stripe is the only payment transmitter here. Clerk gets their fee via Stripe Connect, but Clerk doesn't need extra legal and financial structures since they not actually taking any payments on my behalf; they are providing the service that allows me to use my Stripe account to charge my customers. If I were to leave Clerk Billing, I would still have all my customers' information in my Stripe account. So I could continue charging my customers with a different system, but that would mean setting up new subscriptions either with a third-party system or Stripe Billing. So in this case, even though I would lose the subscriptions by leaving Clerk Billing, I wouldn't lose my customers or even their payment details. Thus, I have freedom to switch systems (albeit with migration work) because the customer data still belongs to "me" (via Stripe) and is not locked into Clerk. (I hope I'm making sense.) My vision is this same kind of thing for podcasters, but replacing Clerk in this example with one or two other recipients: the payment-page provider, and the podcast app, both getting a percentage (maybe 1–2% each). And if a podcaster left their payment-page provider, they recurring payments would stop, but the podcaster wouldn't actually lose the "customer" data because that remains in the podcaster's own Stripe account. |
|
So for a podcaster, their incoming Stripe payment could look like this:
|
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Following up from the boardroom on July 24, I dug into the Stripe docs and found that it is possible for a payment form to split a payment more than once. Being part of the split requires a prior connection via Stripe Connect.
Once that connection is made, the payment form could delegate splits based on something as simple as a URL parameter.
For example, a podcast could include the payment-page URL in their Funding tag, then PodcastGuru automatically adds
ref=podcastguruto the URL when someone clicks on the funding button.Then, as long as PodcastGuru had already connected their Stripe to the payment page host (such as Podgagement, TrueFans, Buzzsprout, etc.), the page could recognize it's coming from PodcastGuru and give:
This would function almost like an affiliate program where the referrer earns a portion of any payment they refer.
But the downside is that app developers would have to integrate via Stripe Connect with each payment-page provider.
And that integration through Stripe Connect means this requires somewhat centralized systems, albeit with liberty to switch.
For example, PodcastGuru would have to integrate their Stripe Connect with Podgagement, TrueFans, Buzzsprout, and whoever else offers a hosted payment page. But once they're connected, they could get that 1% split of all payments referred to that payment page through PodcastGuru. (In other words, connecting once per provider, and that provider can use that one connection for countless podcasts.)
This doesn't prevent a podcaster for DIYing it, but DIY would mean the app doesn't get a fee because app developers probably wouldn't be interested in integrating their Stripe Connect with 100 individual podcasters.
The liberty for the podcaster is that they could theoretically switch their payment page anytime. The only "lock in" would maybe be for recurring payments, depending on how that's handled. If the payment page host (Podgagement, TrueFans, Buzzsprout, etc.) handles the recurring payments themselves (triggering the charge through Stripe according to an internal schedule), then leaving that host means ending those recurring payments.
(This is how Clerk does it. So when I get paid for PodChapters, which uses Clerk, each payment shows up in Stripe like one-time payments with a 0.7% Clerk fee.)
But if the payment-page host uses Stripe Billing for recurring payments, that doesn't break when the podcaster switches. Using Stripe Billing keeps the recurring payments managed by Stripe instead of the payment-page host, and I'm not sure whether the app could continue receiving fees from the recurring payments if the podcaster moves their Stripe connection to a different payment-page host.
Yes, this centralizes around Stripe, but Stripe seems to be the top payment gateway for developers anyway, especially if they don't need a "merchant of record" like provided by Polar, LemonSqueezy, Paddle, and such.
I'll do more thinking and research on this, but I wanted to start the deeper conversation around this very doable model. I plan to build a feature like this to support
<podcast:funding>with Podgagement, and I'm hoping other service-providers will offer the same (like podcast-hosting providers and maybe even some podcast apps could offer their own for podcasters).All reactions