# Web Monetized Referral Links

**URL:** <https://forum.interledger.org/t/web-monetized-referral-links/829>\
**Category:** Applications and Use Cases\
**Tags:** web-monetization\
**Created:** [October 31, 2019, 2:52pm UTC](https://forum.interledger.org/t/web-monetized-referral-links/829 "2019-10-31T14:52:38Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![emschwartz](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.interledger.org/emschwartz/32/12_2.png) [@emschwartz](https://forum.interledger.org/u/emschwartz)\
**Post date:** [October 31, 2019, 2:52pm UTC](https://forum.interledger.org/t/web-monetized-referral-links/829/1 "2019-10-31T14:52:38Z")

</div>

If you send someone to a Web Monetized website, it would be nice if you could include your payment pointer in the URL to get a small cut of the money they stream to that website. This would be like a standardized [affiliate link](https://en.wikipedia.org/wiki/Affiliate_marketing). For example, you could rewrite links like this `https://web-monetized-site.example?referrer_pointer=$evan.wallet.example`.

As far as I understand, one of the big problems with these types of programs in the past has been that pay per click and pay per view models incentivize scammers to spam people and get them to click on those links. It seems like this would be slightly less of a problem if the referrer only got a cut of money streamed by the user. That said, depending on how fast money is streamed and how much of a cut the referrer got, it could still incentivize annoying or spammy behavior.

---

<div class="post-metadata">

**Author:** ![elliott](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.interledger.org/elliott/32/429_2.png) [@elliott](https://forum.interledger.org/u/elliott)\
**Post date:** [October 31, 2019, 5:01pm UTC](https://forum.interledger.org/t/web-monetized-referral-links/829/2 "2019-10-31T17:01:40Z")

</div>

> the referrer only got a cut of money streamed by the user

i think the spammy nature of affiliate links/programs as they currently work is due to the fact that the reward comes from the content/product producer only.

if the consumer also needed to approve the fact that part of their payment goes to an affiliate, this could disincentivize spammers. as a consumer, i would like the ability to block referrers i find spammy and whitelist ones i find high quality. on the other hand, this process potentially adds a lot of friction to payment from the consumer.

---

<div class="post-metadata">

**Author:** ![adrianhopebailie](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.interledger.org/adrianhopebailie/32/31_2.png) [@adrianhopebailie](https://forum.interledger.org/u/adrianhopebailie)\
**Post date:** [October 31, 2019, 7:18pm UTC](https://forum.interledger.org/t/web-monetized-referral-links/829/3 "2019-10-31T19:18:04Z")

</div>

This could be something that user (and their browsers) control entirely.

Example: If your browser detects that you go from one monetized site to another it could automatically send a small monetization stream to the referrer based on user settings.

Do we need anything extra for this to “just work”?

---

<div class="post-metadata">

**Author:** ![sharafian](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.interledger.org/sharafian/32/449_2.png) [@sharafian](https://forum.interledger.org/u/sharafian)\
**Post date:** [November 14, 2019, 12:26am UTC](https://forum.interledger.org/t/web-monetized-referral-links/829/4 "2019-11-14T00:26:12Z")

</div>

I like putting it on the site instead of building it into the browser. It would be easier if we supported multiple payment pointers at once with WM so that you don’t need to do a server side revshare but I’ve still not thought of a reasonably simple way to support multiple payment pointers in the WM API

---

<div class="post-metadata">

**Author:** ![radhy](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.interledger.org/radhy/32/660_2.png) [@radhy](https://forum.interledger.org/u/radhy)\
**Post date:** [June 10, 2020, 1:09pm UTC](https://forum.interledger.org/t/web-monetized-referral-links/829/5 "2020-06-10T13:09:03Z")

</div>

I hope the discussion can still continue. I do think a simple way to implement this is through probability revenue sharing + IndexedDB combo (requiring no sign up for stream payment just like WM API does). The only problem is that I’m not sure how reliable it’s [storage persistent](https://web.dev/persistent-storage/) option is for long term affiliate ids storage (which in some cases expected to retain for 1+ year).

This is how I’m planning it on my small JS library [https://github.com/ProgNovel/fundme](https://github.com/ProgNovel/fundme)  
(NOTE: revenue sharing with hashing after payment adress already shipped in v0.1.1, but the affiliate part is not and only a concept for now)

```auto
import { fund } from 'fundme'

// the number following hash after the payment pointers below
// are weights for probability revenue sharing
const paymentPointers = [
  '$wallet.example.com/website-owner#10',
  '$wallet.example.com/article-author#10',
  '$wallet.example.com/article-editor#5'
]

fund(paymentPointers, {
  affiliateId: 'my-product-id',
  affiliateRate: 0.15
})

```

What I’m planning to do with it is looking through key ‘my-product-id’ in IDB, which will store payment pointer for referrer and other details. If exists, it will get appended alongside other payment pointers before the revenue sharing calculation happens.