---
title: "Paddle to GitHub Repo Access: Sell Code With Paddle as Your Merchant of Record"
description: "Integration page for RepoAccess Pro with Paddle: what Paddle does and does not do for a code seller, how the buyer gives a GitHub username, what a refund and a chargeback do, and what Paddle requires before it lets you sell."
canonical: "https://edgekits.dev/en/tools/repoaccess/paddle/"
published: "2026-09-22"
tags: ["Paddle", "Merchant of Record", "GitHub", "RepoAccess", "Cloudflare Workers"]
---

You sell a boilerplate, a starter kit or a course that lives in a private GitHub repository, and you take payments through Paddle, or you are about to, because Stripe is not available where you are. RepoAccess Pro is the delivery half: a Paddle sale becomes a GitHub team invitation, and a Paddle refund or chargeback takes that access away. It is a one-time licence, it runs as one Cloudflare Worker on your own account, and Paddle stays the merchant of record on every sale.

This page is what you need to know about Paddle specifically before you buy. The general product, its price and the other adapters are on [the RepoAccess page](/en/tools/repoaccess/).

## What Paddle does for a code seller, and what it leaves to you

Paddle is a merchant of record: it is the seller on the buyer's invoice, so VAT, GST and US sales tax are collected and remitted by Paddle, disputes are handled by Paddle, and you receive a payout net of its fee. Paddle accepts software sellers from [anywhere except a short unsupported list](https://www.paddle.com/help/start/intro-to-paddle/which-countries-are-supported-by-paddle), which is why it is the usual answer for sellers in countries Stripe does not serve.

Two things Paddle does not do. Its checkout has no buyer-facing field, so it cannot ask for a GitHub username on its own. And it has no idea what a GitHub repository is: a completed payment ends with a webhook and a receipt, and nothing happens on GitHub. Both gaps are RepoAccess's job.

## How the buyer gives their GitHub username on a Paddle checkout

The worker serves the storefront. The buyer opens `/checkout` on your own domain, types their GitHub username into a labelled field, and pays inside Paddle's inline frame. The handle travels with the transaction, and on payment the buyer lands on a delivery page with one instruction: check your email for the GitHub invitation. If the handle is missing or does not exist on GitHub, the buyer is sent to a claim page instead and enters it there, once.

If you already run a site on Cloudflare Workers, the storefront is optional: collect the username on your own page and open Paddle's checkout with it attached, and the worker does the delivery over a service binding. Either way there is no "Login with GitHub" and no OAuth. GitHub's own invitation is the identity check, because only the account owner can accept it.

## What a Paddle refund and a chargeback do to the buyer's access

A refund revokes the product that was refunded, not the buyer. A customer who owns two of your products and returns one keeps the other. A chargeback does the same. Both are handled inside a 180-day window after the sale, and a pending invitation that has not been accepted yet is cancelled rather than left open.

One Paddle-specific fact decides how you configure this. Paddle reports a genuine full refund as a partial adjustment, so a policy that revokes only on full refunds would silently skip every refund you issue. The Paddle adapter therefore revokes on any refund, and the setup writes that policy for you. This was found with a real refund, not read in the documentation, which is the kind of provider fact the paid tier exists to keep up with.

## What Paddle requires before it lets you sell

Paddle approves a domain, not an account. Your checkout has to load from a custom domain you control, with a Terms page, a Refund Policy and a Privacy Policy reachable from it; a shared `workers.dev` address will not pass that review. The worker can serve those three pages for you, so no separate marketing site is needed, but the domain approval is Paddle's process and takes Paddle's time.

Everything else is testable before approval. Paddle's sandbox is fully separate from live, takes its own test cards, and the whole flow, pay, invite, refund, revoke, runs there end to end before a real buyer sees it.

## What an evening of DIY does not buy

Wiring one Paddle webhook to the GitHub API is an evening's work, and the free AGPL core exists because that is true. What the evening does not produce is the part that costs you money later: a refund that arrives as "partial" and is ignored, a webhook delivered twice that invites twice, a revoke that trusts a stored flag instead of GitHub's live team membership, a claim link that can be used by two people at once, and a provider that changes its payload next quarter without a changelog.

Pro is the maintained version of all of that, for Paddle and for Lemon Squeezy, Gumroad, Razorpay and Telegram Stars, with twelve months of updates from the day you buy. Every version you download in that window is yours to run without limit. The price and the full comparison with the free core are on [the product page](/en/tools/repoaccess/).

## Before you start

You need a Paddle Billing account (the legacy Paddle Classic does not apply), a GitHub organization with a team per product, a Cloudflare account with a custom domain, and a second GitHub account to play the test buyer. With those in hand, the guided setup walks a coding agent through the deployment in about an hour, sandbox first.

If you want the long read on why Paddle and how the pieces fit, it is in [the Paddle guide](/en/blog/paddle-merchant-of-record-github-repo-access/). If your question is whether Paddle takes sellers from your country at all, start with [the country guide](/en/blog/stripe-not-available-in-my-country-sell-code/).

## Frequently Asked Questions

**Q: Does RepoAccess take a cut of Paddle sales?**

**A:** No. RepoAccess Pro is a one-time licence and never touches the money: the buyer pays Paddle, Paddle pays you, and the worker only sees the webhook. Paddle's own fee is the only per-sale cost, and it is the same whether you deliver the repository by hand or through RepoAccess. The licence price is on the product page.

---

**Q: Can a buyer type their GitHub username inside Paddle's checkout?**

**A:** Not inside Paddle's own frame, because Paddle's hosted checkout has no buyer-facing custom field. RepoAccess works around that in two ways: the worker-hosted storefront at /checkout on your domain collects the handle in a labelled field and then opens Paddle's inline frame, so the handle rides with the transaction; and if the handle is missing or does not exist on GitHub, the buyer lands on a claim page after paying and enters it there once. If you run your own Cloudflare site, you collect the handle on your page and pass it to Paddle's checkout yourself.

---

**Q: Does a Paddle refund revoke GitHub access automatically?**

**A:** Yes, on any refund, full or partial. Paddle reports a genuine full refund as a partial adjustment, so the Paddle adapter revokes on every refund rather than gating on a full-refund flag that Paddle never sets. The revoke is scoped to the product that was refunded: a buyer who owns two products and returns one keeps the other. A chargeback triggers the same revoke, and both are handled within a 180-day window after the sale; a pending invitation is cancelled instead of left open.

---

**Q: Do I need a marketing site to sell GitHub repo access through Paddle?**

**A:** No. Paddle approves a domain and wants a Terms page, a Refund Policy and a Privacy Policy reachable from it, but the RepoAccess worker can serve all of those on your custom domain, along with the checkout page, the delivery page and the claim page. What you do need is the custom domain itself: a shared workers.dev address is unlikely to pass Paddle's review. The sandbox is separate from live, so the whole flow can be tested before the domain is approved.

```json
{"@context":"https://schema.org","@graph":[{"@type":"BlogPosting","headline":"Paddle to GitHub Repo Access: Sell Code With Paddle as Your Merchant of Record","description":"Integration page for RepoAccess Pro with Paddle: what Paddle does and does not do for a code seller, how the buyer gives a GitHub username, what a refund and a chargeback do, and what Paddle requires before it lets you sell.","image":"https://cdn.edgekits.dev/public/products/repoaccess/paddle/paddle-github-repo-access-hero.jpg","author":{"@type":"Person","name":"Gary Stupak","url":"https://x.com/GaryEdgeKits"},"datePublished":"2026-09-22T14:14:00.000Z","dateModified":"2026-09-22T14:14:00.000Z","keywords":["Paddle","Merchant of Record","GitHub","RepoAccess","Cloudflare Workers"],"mainEntityOfPage":{"@type":"WebPage","@id":"https://edgekits.dev/en/tools/repoaccess/paddle/"},"publisher":{"@id":"https://edgekits.dev/#organization"}},{"@type":"Organization","@id":"https://edgekits.dev/#organization","name":"EdgeKits","url":"https://edgekits.dev","logo":"https://cdn.edgekits.dev/public/branding/edgekits-logo.png","sameAs":["https://x.com/GaryEdgeKits","https://github.com/EdgeKits","https://www.linkedin.com/in/gary-stupak/"]}]}
```