RepoAccess

Every invitation is paid for. An invite cannot exist without a completed purchase, so there is nothing to farm and nobody to defend against. What is left is a buyer mistyping their own handle, once, at their own cost, which makes this a question about input accuracy rather than access control. One account, one purchase, and you can revoke it. The default claim mode has the buyer type the handle on your own page and confirm it before anything is granted.

No. Delivery is a GitHub team invitation sent to the handle they give you, and they accept it from their email. There is no OAuth app for you to run, and no authorisation prompt in front of somebody who has just paid you.

Access is revoked automatically. Grant and revoke is the engine's entire job, so there is no list for you to keep in step with your payment provider and nothing to remember on the day a dispute lands.

The product that was refunded, not the buyer. The worker removes them from the teams mapped to that product and cancels any invitation still in flight, then reconciles their organisation membership against live GitHub state rather than against its own records. So a buyer who owns A, buys B and refunds B loses B and keeps A. One thing worth knowing before your inbox finds out: a buyer left in no team at all also gets GitHub's organisation-removal email, which reads like a ban and is not one. A buyer who still holds another purchase stays in that purchase's team and never receives it.

One, and it is Lemon Squeezy's. Refunds are handled fully; chargebacks are not, in this version. Lemon Squeezy does emit dispute events, but they are absent from its published event types, there is no dispute object in its API reference, and a dispute cannot be triggered in test mode, so there is no payload to build an adapter against. Until that changes, a Lemon Squeezy chargeback has to be revoked by hand. Every other adapter handles chargebacks automatically, apart from Telegram Stars, which has none to handle.

Yes, and for one provider you probably can. A single webhook adapter against Stripe is an evening of work, which is exactly why Core is free and open source: nobody should pay me for that evening. What Pro sells is what the evening does not buy. The edge cases verified against live providers, refunds, disputes, replayed webhooks and signature changes. Every provider beyond Stripe, including the Merchant of Record options. And somebody tracking provider changes for twelve months so the first sign of one is not a buyer who paid and got nothing. The evening is cheap. Keeping it working for a year is the part that costs, and buying that is cheaper than maintaining it.

A platform charging 5% plus 50 cents a sale takes a bit over $100 a month out of $2,000 of monthly sales, and takes it again every month after that. Pro is paid once and takes no cut of any sale, so the only recurring bill is Cloudflare's, which is nothing until you are past a few hundred sales a day. Set the one-time price on this page against a single month of that percentage and the arithmetic does itself. What the percentage buys that this does not is the platform acting as your tax authority, which is why the Merchant of Record adapters exist: pay it to a payment provider, where it buys you something, rather than to a delivery tool.

A one-time payment for the licence and no cut of any sale. The only running cost is Cloudflare's, and it is spent at the moment somebody pays you. On the free plan that works out at roughly 600 sales a day when the handle arrives with the payment, or 250 a day when the buyer enters it on a claim page. Past that, the Workers Paid plan is $5 a month and carries tens of thousands of sales a month before usage adds anything to it. You pay Cloudflare, never me.

Not if you are running it unmodified for your own sales. Deploy Core to your own Cloudflare account, sell access to your own repositories, and you owe nobody anything. Modify it and let buyers interact with your version over a network, and the AGPL's section 13 asks you to offer them your source. Pro is not under the AGPL at all: your Pro licence covers the engine too, so no copyleft obligation attaches to the worker you run. Putting RepoAccess inside a product you ship to other people is a different question again, and Pro does not answer it. The licensing page says what does.

Your own business: selling access to your own repositories to your own customers, on as many deployments and for as many customers as you like, modifying the code, and writing your own adapters. Not reselling it, not handing a copy to a third party, and not running a service whose purpose is managing other people's repositories. The full terms ship in the repo as LICENSE, and they govern.

A second GitHub account, free and throwaway, to play the test buyer. Not your own: an account already in your organization never receives an invitation at all, so it cannot walk the path a real buyer walks, which is invite, accept, refund, revoke. It is the one prerequisite that catches people out, which is why it is here and not in the small print.

About a week before your twelve months end you can renew to keep updates and support running. If you do not, the version you have keeps working, your clone and your deployed worker are untouched, and you simply stop receiving new updates until you renew. Renewing costs a fraction of what you paid the first time: it is a maintenance fee, not a second purchase.

Email to hello@edgekits.dev, answered by the person who wrote the code. I aim to reply within one or two business days, which is a target I hold myself to rather than a guarantee. It covers this software's own behaviour. It does not cover writing your code for you, debugging your infrastructure, or maintaining adapters you wrote yourself, though if you built one from the recipe in AGENTS.md and it will not work, write anyway and I will look. What I most want to hear about is a provider that has changed: all six are monitored weekly for exactly that, and a seller with money on the line still beats a monitor.

Write to me at hello@edgekits.dev within 7 days of your purchase with a short reason, and I will look at it case by case. A refund can be declined where access has already been granted and extensively used, or where the request is abusive or fraudulent. Worth saying out loud: a refund also revokes the repo access automatically, because enforcing refunds is literally what this product does. You are not being asked to trust a promise I would otherwise have to keep by hand.