Paywall tag

[redimongo]

UPDATE: Please see implantation document for L402 - #670 (comment)

I understand that the want to keep RSS open and content free. However we now have creators reaching out to us and wanting to put their audiobooks in podcast players but only if that podcast player can support a paywall like system.

Here the idea.

The sample of the audiobook would use the enclosure tag that Apple uses (default) we would use the Alternative enclosure tag to put the paywall audio file in.

However we need the player to say if <podcast:paywall>true</podcast:paywall> then don't allow this audiobook to be listened to until the user as paid for access to the audiobook.

Note the audiobook could be purchased using the lightning network which means we could use the v4v payment tag to trigger payment and this allows us to not duplicate a tag feature.

I understand that people see v4v different than some others, but we are trying to allow players who want to take licensed content that the creator wants to offer as a paid product in a podcast player.

Just shooting out ideas and can't wait for constructive solutions to solve this problem.

[jamescridland]

It would be trivial to steal this content without payment, and I can't conceive a time where content creators would be comfortable to run a virtual honesty-box. (Value 4 Value of course works for some; but that's different to a paywall).

I think you need to explore how you DRM-protect audio first. Here's how that might work...

The trailer or teaser goes into https://example.com/audio.mp3 as the main enclosure. As a free and open download, everyone would get that.

The paid audio lives in the alternateEnclosure. It's streamed-only, not downloaded. It needs a key to be played. That key has to be given by the creator's server. The app needs to visit the creator's server, request a key in some way, then attach that key in some way to the request.

So something similar to...

<podcast:alternateEnclosure
src="https://example.org/audio.m3u8"
type="audio/m3u8"
keygen="v1"
keygensrc="https://example.org/request-a-key.php"
/>

... listen to https://example.org/audio.m3u8 without a valid key, and you get a message to buy the content. Perhaps even an intelligent one saying "You need to buy this content. You're using Pocket Casts which doesn't support buying content. Try Truefans."

...but if the app knows you've bought the content, then it (somehow) proves that to the creator's server by supplying a signed key, and then that lets the creator's server deliver the audio via a streamed playlist.

But - I have to say, once you've added all this complication, it's difficult to see the benefit of using RSS to deliver this. It's significantly easier to roll a proprietary service.

[redimongo]

Really smart idea James. It's mainly to support the players that do support payment via the lightning network but also apps that want audiobooks.

But - I have to say, once you've added all this complication, it's difficult to see the benefit of using RSS to deliver this. It's significantly easier to roll a proprietary service.

Yes I agree, be easier just to send these audiobooks as mp3 files to each player and say "here a new audiobook" but that defeats our mission at PodToo, we want to show that RSS can be used for many things like paid content.

But I do have to say I like your code

<podcast:alternateEnclosure
src="https://example.org/audio.m3u8"
type="audio/m3u8"
keygen="v1"
keygensrc="https://example.org/request-a-key.php"
/>

This would make a lot of sense, but we could potentially take it one step further by when for example Truefans requests the RSS because we know their IP address we can show the <podcast:alternateEnclosure and anyone else we hide that part of the rss from them.

We will have to trial this method.

[Dwev]

I'm a little against "buying" something that I then have to rely on a service being available for me to be able to utilize. If the only way to play the paid content is to stream it, then in effect it is just renting a license to play.

Maybe look to something like Bandcamp as an example of how you can have a mix of streaming and bought media, where the bought media is DRM-free. The artists on Bandcamp don't seem to mind, and as a consumer, I love it since more of my money goes to the artist, and not the middlemen. It also means if Bandcamp dies in future, I still have what I bought.

[redimongo]

@Dwev So it is up to the podcast player app, if they let you download the purchased items. Clearly our opinion is if you "BUY" & not rent an item you should be able to download it from the player. Also because it is linked to your wallet, as long as you have the purchased data and you purchased from an artist or author or creator that used PodToo we would support you in recovering your data if say a podcast player went under.

We would need your purchase preimages (which you can get from your wallet)

[adamc199]

A paywall is not Value4Value. Lightning is not V4V, it is a payment mechanism.

There are many ways to build paywalls. Even with the lightning network but let's not confuse it with V4V

This is one way to do what you want: https://lightning.engineering/posts/2020-03-30-lsat/

[redimongo]

Thank Adam, I'll take a look at that.

Am not commenting about V4V meaning on here. It's a really big conversation I'd rather have a spoken discussion with someone over the phone or something.

[samsethi]

[redimongo]

I thumbs down this negitive post, sorry Sam you know I love you. But these are the tough discussions we as a community have to have.

With Spotify SOA and Apples Subscription for podcasts there is one community that is missing out on a paywall idea (or subscription model idea).

Sadly the Podcast namespace and some of the community may be idealist, and we love them for that. But when we have what we can all agree is the competitor of RSS even @adamc199 has said that Spotify doesn't care about RSS, when even that company has come up with a solution to a problem that they see. Which is "Podcasters want to charge for content, and not offer it for free".

While Patron use to be the main way for this to happen, Now we as a hosting company but more as a community can solve this at the player level, with a little teamwork and listening to the community I think we can all solve this problem before RSS is no longer.

I feel (could be wrong), that the community just would like us not to confuse Pay 4 Podcast with Value 4 Value, and I see their point, let's be real we are not giving these items for free. Our platforms are making a deal together (which is open to other players if they want to take the content as well) to allow your users to purchase or subscribe to content via a paid RSS product.

It is truely a game changer (maybe for the better, maybe for the worst) but it's us pushing the boundaries that allow us to see what the consumer wants and is will to pay for.

The issue for me with V4V is I can listen to @jamescridland podnews and pay per stream - which I did when I first joined Truefans (because that was how it use to be set up as, I know you changed it). But then it stopped playing when I ran out of sats. I didn't at first understand what happened (because I was new to V4V) and well then I went to my trusty Apple Podcast and listened their for free.

Now with Subscriptions or Paywalls this is different, because say I am listening to a RSS content that has been clearly marked as paywall then I know doesn't matter if you try going onto Apple Podcast you will still have to pay the fee over their to access this content.

I think also some of the confusion is that some people see RSS as something that anyone can look at and do what ever they want to do to it, yes majority of people will use a player and not understand the technology behind it. If Spotify can do this via RSS then Podcast Namespace can do this via RSS.

And yes I understand the frustration I think some people see it as "Gee Russell, we just got V4V working, please don't (INSERT BAD WORD ) that up." and I get it, we don't want to confuse v4v with a paywall (P4P) they are two separate things.

[ericpp]

I think you could accomplish something similar to Spotify's SOA program through the use of podcast:txt tags. This would be completely backwards compatible with players who choose not to implement it.

Using Spotify's example ( https://developer.spotify.com/documentation/open-access/tutorials/content ) :

<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:podcast="https://podcastindex.org/namespace/1.0">
  <channel>
    <title>The Dark Side</title>
    <description>Lunar's Bonus Content</description>
    <podcast:txt purpose="authentication">https://yourdomain.com/oauth</podcast:txt>
    <item>
      <title>Free Episode #1</title>
      <!-- Note no entitlement txt -->
      <enclosure length="10" type="audio/mpeg" url="https://l-i.com/free1.mp3"/>
    </item>
    <item>
      <title>Bonus Episode #1</title>
      <podcast:txt purpose="entitlement">lunar_dark_side</podcast:txt>
      <enclosure length="10" type="audio/mpeg" url="https://l-i.com/bonus1.mp3"/>
    </item>
  </channel>
</rss>

When presented with an "entitlement" txt tag, a compliant player would use the url in the "authentication" txt tag to authenticate the user with the provider. The player would then get an oauth token that it can use to download bonus/premium episodes.

A player who attempts to download the episode without providing a token would either get an error message or a different file indicating that they need to login/pay.

[redimongo]

Yes, I could see that way working as well. The only thing am worried about in that situation is it doesn't reward the player and allow them to take a few (I could be thinking about it wrong)?

One of the biggest issues I hear podcast players saying is that they don't have ways to monetise, was thinking this always similar to value split to occur.

Am I missing something? Like I don't understand how Spotify takes a percentage via the SOA solution.

[ericpp]

They don't really say in the docs. It looks like you have to register with them as a partner before you can even access their system. I'm assuming they take a cut of the sales and give it to you as a "partner".

Some of the PC 2.0 players do provide options to send them sats or include them in the splits. Most are too modest to include themselves in the splits by default.

[redimongo]

@ericpp payment is done outside of Spotify I tested their example partner and unless the partner ends up getting a bill from Spotify later on, it looks completely like Spotify doesn't get a cent.

[jamescridland]

Not speaking about Spotify, but there is no reason why the player can’t take part in an affiliate scheme.

Apple Podcasts has an affiliate scheme which pays 30% of the first month's subscription (I think) to someone who links to it. You just link to the podcast and you’re away. So the link below - which goes via a geo-redirect because Apple is too dumb to do it itself - includes my affiliate code (“at”) and a tracking code so I know where you came from (in this case, podcast id i8xe9.

https://podnews.net/apple-podcasts-geo/podcast/feed/id1325018583?ls=1&at=11lo6V&ct=i8xe9

These links are relatively simple to achieve and to add programmatically to raw untracked links.

The downside of this is, of course, that affiliate schemes aren’t part of the specification, and therefore a podcast app would need to sign-up to every affiliate system. Would be better if we could convince everyone to, at least, use the same source code - I.e. every affiliate system takes an “at” code and I lay claim to “11lo6V” as mine. But I doubt that’ll happen.

[redimongo]

@jamescridland not a bad idea I could potentially see that kinda working, and yes you are correct about the downside.

My thinking was if people are paying via Lightning and "IF" the player allowed you to link your own wallet, all your preimages would be in there which would allow you to unlock every item you have purchased or subscribed to. I personally think that is a better option but I don't know which players would allow such a thing (and still looking into the technical side of it.) - what is your thoughts on that solution?

[redimongo]

Just a further update, as PodToo moves forward with L402 as a payment method, I have also created a version which will work with FIAT payments on a player side as payments are handled by the podcast player and not PodToo.

Demo of a L402 player - https://codepen.io/redimongo/pen/oNKyjeE
Demo of how we generate F402 (Server Side) - https://codepen.io/redimongo/pen/QWemPBm
Demo of how a player uses F402 (Client Side) - https://codepen.io/redimongo/pen/poMLBZZ

I expect to be able to show a fully integrated demo of F402, in the next week or so.

Huge thanks to everyones input and please any suggestions are more than welcome.

I want to stress that F402 does require players to sign up to an agreement with the podcast / audiobook provider in this case PodToo, as PodToo will issue monthly invoices at the end of the month asking for payment. This will allow an iOS and Android app to comply with the Google/Apple tax as they will "add" the 30% to the amount that they wish to offer the audiobook or paid product for.

The idea is to help players earn an income stream, without having to rely on ads or donations. This method allow an app to say add 10%+30% (app fee) to the list price of the item say $9.99 for them to cover costs + make a little profit. Note PodToo will NOT control how much a app can add on as a fee.

L402 player app fees, will be included in the generated invoice and PodToo will automatically send that to them on a successful LSAT preimage, and as this is lightning payments it will happen in real time. Again podcast players like @samsethi TrueFans can add whatever percentage they want to a transaction.

(thanks to @adamc199 - for the idea of L402 and @daveajones giving me the idea of creating F402)

[redimongo]

Here an interesting read.

In-app purchases (IAPs) and integrating Apple Pay via the web SDK into your app are two distinct methods for processing payments within iOS applications. Here’s an overview of each:

In-App Purchases (IAPs):

•	Definition: IAPs are transactions that occur directly within your app, allowing users to purchase digital goods, services, or subscriptions.
•	Apple’s Requirements: Apple mandates that digital content or services consumed within the app must utilize the IAP system. This includes features like premium content, virtual goods, or subscriptions. Apple charges a commission—commonly 30%—on these transactions. 

Apple Pay via Web SDK:

•	Definition: Apple Pay is a payment method that enables users to make secure payments using their Apple devices. The web SDK allows integration of Apple Pay into websites, facilitating payments through Safari.
•	Integration in Apps: While Apple Pay can be integrated into apps for physical goods and services, using the web SDK within an app to process payments for digital content is generally not permitted. Apple’s guidelines specify that digital goods and services consumed within the app must use the IAP system. 

Attempting to Bypass the 30% Commission:

Using Apple Pay via the web SDK within your app to process payments for digital content, aiming to circumvent Apple’s commission, is against Apple’s App Store Review Guidelines. Such practices can lead to app rejection or removal from the App Store. 

Recent Developments:

In response to regulatory pressures, particularly from the European Union’s Digital Markets Act (DMA), Apple has made some adjustments:

•	External Links: Developers can now include links to external payment options within their apps. However, Apple imposes a “store services fee” on sales made within a year of an app’s installation, regardless of the platform. This fee is 20% for apps only available on the App Store and 10% for those supporting third-party stores, coupled with additional fees. 
•	Additional Fees: An extra 5% “initial acquisition fee” also applies to digital goods purchased within one year of the app’s installation. In total, Apple can take up to a 25% commission. 

These changes indicate that while Apple is allowing some flexibility, it continues to enforce fees on transactions involving digital content within apps.

Conclusion:

To comply with Apple’s guidelines and avoid potential issues, it’s advisable to use the IAP system for digital goods and services consumed within your app. Attempting to bypass the 30% commission through alternative payment methods like the Apple Pay web SDK is likely to violate Apple’s policies and could result in app rejection or removal.

[jamescridland]

@redimongo - how does this work within the Apple system, do you know?

Example 1

I am using a podcast app. I see an ad or promotion for an egg boiler. I click the ad for the egg boiler. It opens a website. I buy the egg boiler.

I assume this isn't deemed as an in-app purchase? Even if the podcast app gets money per order?

Example 2

I am using a podcast app. I see an ad or promotion for a paid podcast. I click the ad for the paid podcast. It opens a third-party website. I buy the paid podcast. It offers to deliver the paid podcast to my choice of podcast app.

Two examples of this:

Someone puts "Become a member of The Rest Is Politics +, for ad-free episodes - click here" in their podcast description. Would Apple expect money from every podcast app for that, even though there's no monetary relationship?

Second - if, say, Acast+ gave you an affiliate revenue share to promote a paid show in your app... would Apple expect a share of that affiliate revenue - even though the content you're buying can be played in any podcast app?

I'm thinking that the Acast+ example here would still be fine under Apple rules, assuming that Acast takes the money, and that you can still listen in any podcast app. No difference to any other form of advertising.

[redimongo]

@jamescridland I can't speak for Apple, and because I don't want to answer your question wrongly. I am going to paste the agreement that us app developers sign when we join Apple Development program to publish apps.

Parts we take note of (due to being warned by Apple in the past)
3.1.1 In-App Purchase, 3.1.1(a)

3.1.1(a) screenshot that would appear each time a user clicks a link in your app.

The link you provide in your app must:

1. Go directly to your website without any redirect or intermediate links or landing page;
2. Open a new window in the default browser on the device, and may not open a web view;
3. Not pass additional parameters in the URL in order to protect the user (for example, their privacy);

It's point 3 that makes it extremely difficult for external payment sites to know which user an app is sending to us and then trigger a redirect. Also technically the website is meant to be owned by the podcast app developer.

3.1 Payments
3.1.1 In-App Purchase:
If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase. Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, cryptocurrencies and cryptocurrency wallets, etc.

Apps may use in-app purchase currencies to enable customers to “tip” the developer or digital content providers in the app.

Any credits or in-game currencies purchased via in-app purchase may not expire, and you should make sure you have a restore mechanism for any restorable in-app purchases.

Apps may enable gifting of items that are eligible for in-app purchase to others. Such gifts may only be refunded to the original purchaser and may not be exchanged.

Apps distributed via the Mac App Store may host plug-ins or extensions that are enabled with mechanisms other than the App Store.

Apps offering “loot boxes” or other mechanisms that provide randomized virtual items for purchase must disclose the odds of receiving each type of item to customers prior to purchase.
Digital gift cards, certificates, vouchers, and coupons which can be redeemed for digital goods or services can only be sold in your app using in-app purchase. Physical gift cards that are sold within an app and then mailed to customers may use payment methods other than in-app purchase.

Non-subscription apps may offer a free time-based trial period before presenting a full unlock option by setting up a Non-Consumable IAP item at Price Tier 0 that follows the naming convention: “XX-day Trial.” Prior to the start of the trial, your app must clearly identify its duration, the content or services that will no longer be accessible when the trial ends, and any downstream charges the user would need to pay for full functionality. Learn more about managing content access and the duration of the trial period using [Receipts](https://developer.apple.com/documentation/storekit/original_api_for_in-app_purchase/choosing_a_receipt_validation_technique) and [DeviceCheck](https://developer.apple.com/documentation/devicecheck).

Apps may use in-app purchase to sell and sell services related to non-fungible tokens (NFTs), such as minting, listing, and transferring. Apps may allow users to view their own NFTs, provided that NFT ownership does not unlock features or functionality within the app. Apps may allow users to browse NFT collections owned by others, provided that the apps may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than in-app purchase.
3.1.1(a) Link to Other Purchase Methods: Developers may apply for entitlements to provide a link in their app to a website the developer owns or maintains responsibility for in order to purchase digital content or services. Please see additional details below.

StoreKit External Purchase Link Entitlements: apps on the App Store in specific regions may offer in-app purchases and also use a StoreKit External Purchase Link Entitlement to include a link to the developer’s website that informs users of other ways to purchase digital goods or services. Learn more about these [entitlements](https://developer.apple.com/documentation/storekit/external_purchase). In accordance with the entitlement agreements, the link may inform users about where and how to purchase those in-app purchase items, and the fact that such items may be available for a comparatively lower price. The entitlements are limited to use only in the iOS or iPadOS App Store in specific storefronts. In all other storefronts, apps and their metadata may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than in-app purchase.
Music Streaming Services Entitlements: music streaming apps in specific regions can use Music Streaming Services Entitlements to include a link (which may take the form of a buy button) to the developer’s website that informs users of other ways to purchase digital music content or services. These entitlements also permit music streaming app developers to invite users to provide their email address for the express purpose of sending them a link to the developer’s website to purchase digital music content or services. Learn more about these [entitlements](https://developer.apple.com/documentation/storekit/external_purchase). In accordance with the entitlement agreements, the link may inform users about where and how to purchase those in-app purchase items, and the price of such items. The entitlements are limited to use only in the iOS or iPadOS App Store in specific storefronts. In all other storefronts, streaming music apps and their metadata may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than in-app purchase.

If your app engages in misleading marketing practices, scams, or fraud in relation to the entitlement, your app will be removed from the App Store and you may be removed from the Apple Developer Program.

3.1.2 Subscriptions: Apps may offer auto-renewable in-app purchase subscriptions, regardless of category on the App Store. When incorporating auto-renewable subscriptions into your app, be sure to follow the guidelines below.

3.1.2(a) Permissible uses: If you offer an auto-renewable subscription, you must provide ongoing value to the customer, and the subscription period must last at least seven days and be available across all of the user’s devices. While the following list is not exhaustive, examples of appropriate subscriptions include: new game levels; episodic content; multiplayer support; apps that offer consistent, substantive updates; access to large collections of, or continually updated, media content; software as a service (“SAAS”); and cloud support. In addition:

Subscriptions may be offered alongside à la carte offerings (e.g. you may offer a subscription to an entire library of films as well the purchase or rental of a single movie).
You may offer a single subscription that is shared across your own apps and services.
Games offered in a streaming game service subscription may offer a single subscription that is shared across third-party apps and services; however, they must be downloaded directly from the App Store, must be designed to avoid duplicate payment by a subscriber, and should not disadvantage non-subscriber customers.
Subscriptions must work on all of the user’s devices where the app is available. Learn more about [sharing a subscription across your apps](https://developer.apple.com/documentation/storekit/in-app_purchase/offering_a_subscription_across_multiple_apps).

Apps must not force users to rate the app, review the app, download other apps, or other similar actions in order to access functionality, content, or use of the app.

As with all apps, those offering subscriptions should allow a user to get what they’ve paid for without performing additional tasks, such as posting on social media, uploading contacts, checking in to the app a certain number of times, etc.
Subscriptions may include consumable credits, gems, in-game currencies, etc., and you may offer subscriptions that include access to discounted consumable goods (e.g. a platinum membership that exposes gem-packs for a reduced price).
If you are changing your existing app to a subscription-based business model, you should not take away the primary functionality existing users have already paid for. For example, let customers who have already purchased a “full game unlock” continue to access the full game after you introduce a subscription model for new customers.
Auto-renewable subscription apps may offer a free trial period to customers by providing the relevant information set forth in App Store Connect. [Learn more about providing subscription offers.](https://developer.apple.com/app-store/subscriptions/#providing-subscription-offers)

Apps that attempt to scam users will be removed from the App Store. This includes apps that attempt to trick users into purchasing a subscription under false pretenses or engage in bait-and-switch and scam practices; these will be removed from the App Store and you may be removed from the Apple Developer Program.
Cellular carrier apps may include auto-renewable music and video subscriptions when purchased in bundles with new cellular data plans, with prior approval by Apple. Other auto-renewable subscriptions may also be included in bundles when purchased with new cellular data plans, with prior approval by Apple, if the cellular carrier apps support in-app purchase for users. Such subscriptions cannot include access to or discounts on consumable items, and the subscriptions must terminate coincident with the cellular data plan.

3.1.2(b) Upgrades and Downgrades: Users should have a seamless upgrade/downgrade experience and should not be able to inadvertently subscribe to multiple variations of the same thing. Review [best practices](https://developer.apple.com/app-store/subscriptions/) on managing your subscription upgrade and downgrade options.

3.1.2(c) Subscription Information: Before asking a customer to subscribe, you should clearly describe what the user will get for the price. How many issues per month? How much cloud storage? What kind of access to your service? Ensure you clearly communicate the requirements described in [Schedule 2 of the Apple Developer Program License Agreement](https://developer.apple.com/support/terms/apple-developer-program-license-agreement/#S2).

3.1.3 Other Purchase Methods: The following apps may use purchase methods other than in-app purchase. Apps in this section cannot, within the app, encourage users to use a purchasing method other than in-app purchase, except as set forth in 3.1.3(a). Developers can send communications outside of the app to their user base about purchasing methods other than in-app purchase.

3.1.3(a) “Reader” Apps: Apps may allow a user to access previously purchased content or content subscriptions (specifically: magazines, newspapers, books, audio, music, and video). Reader apps may offer account creation for free tiers, and account management functionality for existing customers. Reader app developers may apply for the External Link Account Entitlement to provide an informational link in their app to a web site the developer owns or maintains responsibility for in order to create or manage an account. Learn more about the [External Link Account Entitlement](https://developer.apple.com/support/reader-apps/).

3.1.3(b) Multiplatform Services: Apps that operate across multiple platforms may allow users to access content, subscriptions, or features they have acquired in your app on other platforms or your web site, including consumable items in multi-platform games, provided those items are also available as [in-app purchases within the app](https://developer.apple.com/app-store/review/guidelines/#in-app-purchase).
3.1.3(c) Enterprise Services: If your app is only sold directly by you to organizations or groups for their employees or students (for example professional databases and classroom management tools), you may allow enterprise users to access previously-purchased content or subscriptions. Consumer, single user, or family sales must use in-app purchase.

3.1.3(d) Person-to-Person Services: If your app enables the purchase of real-time person-to-person services between two individuals (for example tutoring students, medical consultations, real estate tours, or fitness training), you may use purchase methods other than in-app purchase to collect those payments. One-to-few and one-to-many real-time services must use in-app purchase.

3.1.3(e) Goods and Services Outside of the App: If your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry.

3.1.3(f) Free Stand-alone Apps: Free apps acting as a stand-alone companion to a paid web based tool (e.g. VoIP, Cloud Storage, Email Services, Web Hosting) do not need to use in-app purchase, provided there is no purchasing inside the app, or calls to action for purchase outside of the app.

3.1.3(g) Advertising Management Apps: Apps for the sole purpose of allowing advertisers (persons or companies that advertise a product, service, or event) to purchase and manage advertising campaigns across media types (television, outdoor, websites, apps, etc.) do not need to use in-app purchase. These apps are intended for campaign management purposes and do not display the advertisements themselves. Digital purchases for content that is experienced or consumed in an app, including buying advertisements to display in the same app (such as sales of “boosts” for posts in a social media app) must use in-app purchase.

3.1.4 Hardware-Specific Content: In limited circumstances, such as when features are dependent upon specific hardware to function, the app may unlock that functionality without using in-app purchase (e.g. an astronomy app that adds features when synced with a telescope). App features that work in combination with an approved physical product (such as a toy) on an optional basis may unlock functionality without using in-app purchase, provided that an in-app purchase option is available as well. You may not, however, require users to purchase unrelated products or engage in advertising or marketing activities to unlock app functionality.

3.1.5 Cryptocurrencies:
(i) Wallets: Apps may facilitate virtual currency storage, provided they are offered by developers enrolled as an organization.
(ii) Mining: Apps may not mine for cryptocurrencies unless the processing is performed off device (e.g. cloud-based mining).
(iii) Exchanges: Apps may facilitate transactions or transmissions of cryptocurrency on an approved exchange, provided they are offered only in countries or regions where the app has appropriate licensing and permissions to provide a cryptocurrency exchange.
(iv) Initial Coin Offerings: Apps facilitating Initial Coin Offerings (“ICOs”), cryptocurrency futures trading, and other crypto-securities or quasi-securities trading must come from established banks, securities firms, futures commission merchants (“FCM”), or other approved financial institutions and must comply with all applicable law.
(v) Cryptocurrency apps may not offer currency for completing tasks, such as downloading other apps, encouraging other users to download, posting to social networks, etc.

3.2 Other Business Model Issues
The lists below are not exhaustive, and your submission may trigger a change or update to our policies, but here are some additional dos and don’ts to keep in mind:

3.2.1 Acceptable
(i) Displaying your own apps for purchase or promotion within your app, provided the app is not merely a catalog of your apps.
(ii) Displaying or recommending a collection of third-party apps that are designed for a specific approved need (e.g. health management, aviation, accessibility). Your app should provide robust editorial content so that it doesn’t seem like a mere storefront.
(iii) Disabling access to specific approved rental content (e.g. films, television programs, music, books) after the rental period has expired; all other items and services may not expire.
(iv) Wallet passes can be used to make or receive payments, transmit offers, or offer identification (such as movie tickets, coupons, and VIP credentials). Other uses may result in the rejection of the app and the revocation of Wallet credentials.
(v) Insurance apps must be free, in legal compliance in the regions distributed, and cannot use in-app purchase.
(vi) Approved nonprofits may fundraise directly within their own apps or third-party apps, provided those fundraising campaigns adhere to all App Review Guidelines and offer Apple Pay support. These apps must disclose how the funds will be used, abide by all required local and federal laws, and ensure appropriate tax receipts are available to donors. Additional information shall be provided to App Review upon request. Nonprofit platforms that connect donors to other nonprofits must ensure that every nonprofit listed in the app has also gone through the nonprofit approval process. Learn more about becoming an [approved nonprofit](https://developer.apple.com/apple-pay/nonprofits/).
(vii) Apps may enable individual users to give a monetary gift to another individual without using in-app purchase, provided that (a) the gift is a completely optional choice by the giver, and (b) 100% of the funds go to the receiver of the gift. However, a gift that is connected to or associated at any point in time with receiving digital content or services must use in-app purchase.
(viii) Apps used for financial trading, investing, or money management should be submitted by the financial institution performing such services.

3.2.2 Unacceptable
(i) Creating an interface for displaying third-party apps, extensions, or plug-ins similar to the App Store or as a general-interest collection.
(ii) Intentionally omitted.
(iii) Artificially increasing the number of impressions or click-throughs of ads, as well as apps that are designed predominantly for the display of ads.
(iv) Unless you are an approved nonprofit or otherwise permitted under Section 3.2.1 (vi) above, collecting funds within the app for charities and fundraisers. Apps that seek to raise money for such causes must be free on the App Store and may only collect funds outside of the app, such as via Safari or SMS.
(v) Arbitrarily restricting who may use the app, such as by location or carrier.
(vi) Intentionally omitted.
(vii) Artificially manipulating a user’s visibility, status, or rank on other services unless permitted by that service’s Terms and Conditions.
(viii) Apps that facilitate binary options trading are not permitted on the App Store. Consider a web app instead. Apps that facilitate trading in contracts for difference (“CFDs”) or other derivatives (e.g. FOREX) must be properly licensed in all jurisdictions where the service is available.
(ix) Apps offering personal loans must clearly and conspicuously disclose all loan terms, including but not limited to equivalent maximum Annual Percentage Rate (APR) and payment due date. Apps may not charge a maximum APR higher than 36%, including costs and fees, and may not require repayment in full in 60 days or less.

[jamescridland]

I wonder if my examples fall under "advertising" and not "purchasing". I wonder what the advertising rules say...

[redimongo]

@jamescridland Maybe but that also falls under strict rules I would recommend reading the following 94 page document.

https://developer.apple.com/support/downloads/terms/apple-developer-program/Apple-Developer-Program-License-Agreement-20241023-English.pdf

Sorry I can't be much help in this area, its why we have lawyers who decipher this stuff for us and based on the feedback I have had, the only current way for Australia is the way we are doing it.

Note even the external payment links are meant to only be valid for US, Norway, South Korea & EU.

This is the part we would look at, and it's why Apple stopped allowing app developers using the Device ID and instead makes them use an AdvertisingID

E. Advertising Identifier and Tracking Preference; Ad Network APIs
You and Your Applications (and any third party with whom You have contracted to serve
advertising) may use the Advertising Identifier, and any information obtained through the use of
the Advertising Identifier, only for the purpose of serving advertising. If a user resets the
Advertising Identifier, then You agree not to combine, correlate, link or otherwise associate, either 
Program Agreement
Page 22
directly or indirectly, the prior Advertising Identifier and any derived information with the reset
Advertising Identifier. For Applications compiled for any Apple-branded product providing access
to the Ad Support APIs, You agree to check a user’s Tracking Preference prior to serving any
advertising using the Advertising Identifier, and You agree to abide by a user’s setting in the
Tracking Preference in Your use of the Advertising Identifier and in Your use of any other user or
device data for tracking.
In addition, You may request to use the Ad Network APIs to track application advertising
conversion events. If You are granted permission to use the Ad Network APIs, You agree not to
use such APIs, or any information obtained through the use of the Ad Network APIs, for any
purpose other than verifying ad validation information as part of an advertising conversion event.
You agree not to combine, correlate, link, or otherwise associate, either directly or indirectly,
information that is provided as part of the ad validation through the use of the Ad Network APIs
with other information You may have about a user. Apple reserves the right to reject any
requests to use the Ad Network APIs, in its sole discretion. 

You are severly limited & are not allowed to pass on UUID or any identifying information like email address.

[yoshimo]

Why not use basic auth and an individual feed for content like people currently do? There are feeds with ads that are free and there are authenticated individual feeds for the donation /subscription version without ads? For now the only issue is missing a link between different versions of the same episode so that switching between feeds screws over your listening history.

[redimongo]

So with advertising, we can't attach any user ID to the ad url, also Spotify doesn't have seprate RSS feeds for it's users. It has partner RSS feeds and a oAuth link which asks the user to link their spotify account to the supportingcast platform.

So in that method what we would require every player to have oAuth and also private RSS feeds that only go to partners.

The Apple / Google Tax is a cost of business, we should not be trying to work out ways to get around it, its a cost of business in my opinion and it only applies to Apple / Google apps.

We would recommend L402 first and foremost.

[jamescridland]

So with advertising, we can't attach any user ID to the ad url

Of course not. But https://example.com?ref=podtoo is perfectly fine.

So in that method what we would require every player to have oAuth

No, not suggesting that. Suggesting that you simply link to a provider of premium podcasts (like SupportingCast), and leave the generation of the private RSS feed, as above, to them. It'll work in any podcast app, of course. But if the link to SupportingCast is an affiliate link, then you get money if someone buys the content. And if your podcast app is any good, they'll add the RSS feed directly to it. SupportingCast could even automate that with one-click.

The Apple / Google Tax is a cost of business

In this case, I'm actually not suggesting "getting round it" - just that nobody needs to pay Apple or Google a percentage of money spent with advertisers. And, advertisers can pay using Cost-Per-Action as well as Cost-Per-Impression.

In short - we have a system that sells premium content via RSS feeds already. SupportingCast, AcastPlus, Supercast, Captivate, and other companies already provide this as a feature. Our job is to convince these companies of the benefit of promotion within podcast apps, and to pay podcast app platforms an affiliate payment on each successful sale. Let's not reinvent the wheel, and instead see if we can use the currently-existing solution. I believe we can.

<podcast:funding type="subscription" url="https://example.com/buy-my-podcast-service/url">Get Russell +, and get these podcasts ad free!</podcast:funding>

...if you have an affiliate agreement with example.com then excellent news - you'll know what to append the URL with.

[redimongo]

My understanding is we are not allowed a ref in the url as well (we can't use it in any of our ads that we run in our radio station app), and technically you have to show each item with the ad icon. This might have changed.

Also this is about bringing more than podcasts into the ecosystem.

What's the point of having lightning wallets in podcast apps if we don't use that technology for payment?

Additionally app developers that I talk to say I'll do it the IAP way as Apple wants me to as then I have the safety of Apple and the user return policy.

Having credit card fraud and having to manage that can be really frustrating for small businesses. Apple and Google have been doing this for a long time and have proven that users refund rates or fraud rates are not as high as normal credit card payment on 3rd party systems.

Each podcast hosting platform, and each podcaster will need to work out the best way for them to do premium content.

This is the way PodToo is doing it to meet our contractual obligations with our audiobook partners (to be announced soon).

I share the technology with the community to show them how it can be done and hope that a wider adoption happens.

SOA doesn't protect the mp3 file it's just a partner RSS feed. L402 does protect the mp3 file as you can't request the file without paying the fee.

F402 protects the mp3 because it requires an authority token from the app player that a transaction has been successful.

There will always be other ways to do what we are doing, maybe our way is better than the others and maybe it's not only time will tell.

[jamescridland]

My understanding is we are not allowed a ref in the url as well

I think your understanding is faulty here. You must be able to link to an ad with some form of tracking from the app, otherwise nobody could check for effectiveness.

What's the point of having lightning wallets in podcast apps if we don't use that technology for payment?

Because it fixes nothing here. Paying $4.99 on a credit card means payment costs of around 30 cents. It's absolutely fine. And lightning wallets are a massive impediment to taking payment. But, more to the point, YOU don't run any of the payment in my scenario.

I believe you are reinventing the wheel - to one that is much more complex. Good luck with it!

[redimongo]

But, more to the point, YOU don't run any of the payment in my scenario.

Correct, the implementations that we are suggesting, anyone could roll out and create their own version the L402 is an open standard and anyone can do it. F402 is a token handshake standard with partnerships that we are doing with apps, authors and podcasters to bring FIAT payments to podcast players in a native way that supports all parties. It's not in my interest to develop something that doesn't help the community.

You have pointed out that there are many ways to do what we are wanting to do, and I think that is a great thing for the industry as a whole as we are all navigating this complexity world.

Paying $4.99 on a credit card means payment costs of around 30 cents

This is wrong, stripe and other payment providers charge up to 3.5% of international cards to be processed, while local transaction are charged 1.7% + 0.30c

I believe you are reinventing the wheel

So I think there might be a miss understanding of what we are doing with F402. F402 is a token signature system that allows an application to send us that they received a successful payment using what ever means (this could be 3rd party payment provider, apple pay, google app, IAP or anything that does FIAT payment even Paypal.)

We at the end of the month invoice the podcast app (for FIAT payments made directly to the app when accessing our clients content). For L402 payments we pay the podcast application in real-time via Lightning transaction.

This payment method is handled by the player and NOT by the hosting company, or by the podcaster themselves. Imagine if MyPodcastApp did the payment and they use paypal, they signed the payment Macaroon+preimage and send that back to the hosting company. This is basically the same way that L402 works.

The payment is just signed once the payment method has been made.

You raised a really good point

to one that is much more complex

Yes it's why we are not rushing out the F402 system and from day one will first support L402.

Here is how our system works in a user Diagram

[redimongo]

L402 paywall audiobook demo.

view-source:https://feed.podtoo.com/audiobook/fuyktrnd

We have added the tag paywall in channel and item level, as to trigger the invoice to make payment you need to select a item with the tag paywall.

For audiobooks any item that you end up paying from that XML will give you the rights to listen to all audiofiles in said XML.

Internally we have a tracking system that allows a user to access only the audiobook ID that matches the macaroon token.

Channel level

Item Level

Here is version 0.0.2 of the documentation (L402)

Integrating the L402 Protocol Paid Audio_ A Comprehensive Client-Side Guide - version 0.0.2.pdf

F402 will follow the same steps except preimage generation.

[samsethi]

So we have worked with @redimongo to get L.402 working on TrueFans which we have termed Secure RSS as the content is encrypted and not open.

For example: This audiobook is behind a paywall tag. You cannot copy the MP3 as it is encrypted. Try it. Only after we have provided confirmation of the payment to PodToo does the buyer get the option to play the audiobook.

We have also added the option to either buy or rent the audiobook. In the next few weeks, we will also add F.402 to allow the user to pay in a Fiat currency.

TrueFans: https://truefans.fm/the-three-little-sheepdogs-and-their-journey-home
Secure RSS: https://feed.podtoo.com/audiobook/fuyktrnd

We are currently working with @nathangathright's Transcribe.FM which also uses L.402

[samsethi]

We have now completed the L.402 integration with @nathangathright Transcribe.fm. We have it working in the creator admin dashboard and also for users to buy a transcription in the episode page. We enable creators/users to buy in either SATs or Fiat.

The user requests the transcript, gets a price via the API based on the length of the transcript and then make a payment which we confirm to Transcribe.fm - once they get a confirmed payment they deliver the transcription.

In addition, if the user chooses to pay more than the minimum required by Transcribe.fm, then we pay the additional payment to the podcaster. i.e we do three-way splits - Transcribe, Truefans (5%) and Creator.

SecureRSS is akin to Spotify SOA. Spotify have the payment for paid content on their partners website to avoid the Apple tax. Then Patreon and/or Memberful confirm the payment to Spotify who then give the user access to the content.

TrueFans does it the other way. We get the content images and description delivered via RSS. But when the user buys the audiobook or music track we send a payment conformation to the host. The host then unencrypts the file(s). The same is true with Transcriber.fm - we send then payment confirmation before they deliver the transcription.

I would like SecureRSS included in Phase8 - we have two hosts (PodToo and Transcribe.fm) as well as one app (TrueFans) no using L.402