Your storefront is a static site on GitHub Pages. Checkout is a Stripe Payment Link on your own account. A scheduled GitHub Action delivers each sale by inviting the buyer to your private repo.

I wanted to sell something to developers and could not find a good reason to pay a platform 10% for hosting a download link. Stripe already handles the payment. GitHub already handles access to private code. The gap between them turned out to be about 350 lines, so I wrote them and made it MIT. The happy path was the easy part. What took the time was everything that fails without telling you. A payment link you deactivated still returns HTTP 200, so your buy button looks fine and takes nobody's money. A Stripe session can complete 23 hours after it was created, so a scan window sized to your poll interval loses that sale while the job stays green. An empty ledger looks the same whether nobody came or the store broke on Tuesday. None of those throw an error. That is the real problem with this architecture, and it is why the free engine ships with a reconciliation pass instead of just a webhook. If your buyers are not on GitHub this is the wrong tool, since delivery is a repo invite. Rather say that now than have someone find out after. Happy to answer anything, including the awkward parts.

HonorBox is listed across Payments, Developer Tools, Productivity, and Social & Community, which makes me wonder about the first target user. Is this mainly for makers/dev teams handling rewards or recognition, or is the payment angle more central? A concrete example workflow would help place it quickly.

HonorBox

Sell digital products with just Stripe and GitHub

Sell digital products with just Stripe and GitHub