1
5 Comments

Demo: the full loop, from payment to revoked access

A 60-second recording of one real run. A buyer types their GitHub username, pays, and is invited to the team that holds the private repo. Then the seller refunds, and the access is gone.

Nobody touches GitHub at either end.

Granting access on payment is the easy half and plenty of tools do it. Revoking it on a refund or a chargeback is where almost everything stops — and that is the half that decides whether you can sell this way at all.

What the refund removes is narrower than it sounds, deliberately. It revokes the product that was refunded, not the buyer: the teams on that grant, plus any invitation still pending, since an unaccepted invite is a grant in flight.

Org membership is then reconciled against live GitHub state — if the buyer is still in a team from another purchase, they keep it and everything it entitles them to.

They leave the organization only when they are in no product team at all. So a buyer who owns A, buys B, then refunds B loses B and keeps A. The check runs against GitHub itself, never against the worker's own records, so it stays correct even after a grant record has aged out.

The video shows the single-product case. The rule above is what happens when you sell more than one thing.

, Founder of Icon for RepoAccess
RepoAccess
on September 10, 2026
  1. 1

    The refund/revocation logic is the part that seems commercially meaningful. Have sellers actually used RepoAccess for paid private repos yet, and did automated revocation remove a problem that was stopping them from selling this way?

    1. 1

      No, not yet — the only seller running it is me. RepoAccess went public a week ago and I have not sold a single paid licence, which is why the revenue on this page says $0 rather than something vaguer.

      So I cannot tell you it removed a blocker for anyone else. What I can tell you is where the design came from. I compared about twenty ways to sell access to a private repo, and almost none of them revoke on a refund: you get the invite automated, and then you are back to watching your provider dashboard and removing people by hand. Of everything I looked at, exactly one re-issues an invitation before it expires.

      Whether that is a real blocker or just an annoyance people absorb is the thing I genuinely do not know yet, and it is the honest gap in the story. My own reason was narrower — I sell from a country the usual processors do not serve, so I needed the whole chain on infrastructure I control regardless of who else cared.

      Are you selling access to anything that way now, or looking into it?

      1. 1

        That distinction between a real blocker and an absorbed annoyance is interesting. I’d be interested in digging into that further. If you’re open to it, what’s the best email to reach you on?

        1. 1

          gary [at] edgekits [dot] dev, happy to dig into it.

          Let me be precise about what I have and what I do not. No data on other sellers using RepoAccess, because there are none yet. What I do have is the survey of what today's tools do about refunds, and one earlier round of solving this myself: back when I sold WordPress plugins I built my own order panel and the matching kill switch inside the plugin, so issuing a refund and ending access were one button. Nobody sold me that. There was nothing to buy.

          So my honest position is that I have evidence this is worth building and none that it is worth buying. Those are different claims, and the second one is what I cannot make yet.

          If you have watched sellers run into this from the other side, that is exactly the part I am missing.

          PS: email address written like that because new accounts here cannot post links yet. It is also in the footer of my site.

          1. 1

            Thanks! I’ve just sent it over.

            Looking forward to hearing your thoughts whenever you have a chance.