Illustration of selling code from India with Razorpay: a Razorpay Payment Page with UPI, cards and a GitHub username field, a RepoAccess Pro worker on Cloudflare, and invitations to locked private GitHub repositories.

Razorpay to GitHub Repo Access: Sell Code From India With Razorpay as Your Payment Gateway

Integration page for RepoAccess Pro with Razorpay: what a payment aggregator leaves with the seller, how the buyer types a GitHub username on a Razorpay Payment Page, what a refund and a dispute do, and the one thing Razorpay cannot do.

#razorpay #india #github #repoaccess #cloudflare workers

You sell a boilerplate, a starter kit or a course that lives in a private GitHub repository, you are registered in India, and Razorpay is how you take payments. RepoAccess Pro is the delivery half: a Razorpay payment becomes a GitHub team invitation, and a Razorpay refund or dispute takes that access away. It is a one-time licence, it runs as one Cloudflare Worker on your own account, and Razorpay stays your gateway on every sale.

This page is what you need to know about Razorpay specifically before you buy. The general product, its price and the other adapters are on the RepoAccess page.

What Razorpay does for a code seller, and what it leaves with you

Razorpay is a payment aggregator, not a merchant of record. It moves the money and settles it to your Indian bank account in rupees, with UPI, cards and netbanking at the checkout. You stay the seller of record, so GST, invoicing and disputes are yours, along with your own Terms, Refund and Privacy pages.

That is the trade against Paddle, Lemon Squeezy or Gumroad, which take the tax and the disputes and charge for it. For a seller in India with mostly Indian buyers, Razorpay’s domestic rails and rupee settlement are the reason to accept the trade. Selling to buyers abroad needs International Payments enabled on the account, which Razorpay grants separately.

How the buyer gives their GitHub username on a Razorpay Payment Page

Razorpay hosts the whole buyer path. You sell through a Razorpay Payment Page, add a custom input field for the GitHub username, and the buyer types it before paying. The handle travels on the payment as a note, the webhook carries it to the worker, and the team invitation goes out at once: no claim page, no page of yours in the buyer’s way.

The buyer finishes on Razorpay’s own success panel while the grant runs in the background. There is no “Login with GitHub” and no OAuth: GitHub’s own invitation can only be accepted by the account it was sent to, so a wrong handle produces an invitation nobody can accept, not access for the wrong person.

What a Razorpay refund and a dispute 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 pending invitation that has not been accepted is cancelled, and the revoke reconciles against GitHub’s live team membership rather than a stored flag. Whether the refund was full or partial is read from the payment entity in Razorpay’s own refund payload, and under the shipped policy either one revokes.

Disputes are where the aggregator model shows. A merchant of record absorbs a chargeback for you; Razorpay hands it to you as its own event, and RepoAccess treats that event exactly like a refund, so a disputed sale loses its access without anyone touching GitHub. That path is wired and tested against the payload, though Razorpay’s test mode has no way to raise a dispute on demand.

The one thing Razorpay cannot do

A Payment Page has no working way to send the buyer to a page of yours after payment: its post-payment redirect does not fire, and its custom success message takes no dynamic values. So there is no claim page on this rail, and a buyer who mistypes their GitHub handle cannot fix it themselves.

The worker still protects the sale. It validates the handle against GitHub, sends no invitation for a handle that does not exist, and parks the purchase instead of losing it. The correction is support work: the buyer reaches you through the contact on the Payment Page, you find the payment and the handle they typed in its notes, and you add the right handle to the team by hand. One line under the field asking buyers to check their handle before paying does more here than any recovery path.

What Razorpay asks of you before you sell

No custom domain: nothing on the buyer’s path touches the worker, so it can stay on its workers.dev address. Test Mode works without account activation and needs no live payment; it does need an Indian mobile number at checkout, because Razorpay validates the phone field against real numbering, and the Test Mode toggle resets on every login.

Selling for real needs the account activated, which is Razorpay’s KYC review of your business, so it starts before the launch date rather than on it. The live Payment Page and the live webhook are created again in live mode with the same two custom fields and the same three events, and your Terms, Refund and Privacy pages are yours to publish, because on this rail nobody publishes them for you.

What an evening of DIY does not buy

Wiring one Razorpay 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 webhook delivered twice that invites twice, a refund whose full-or-partial status is guessed instead of read from the payload, a dispute that nobody listens for because the tutorial assumed a merchant of record, a revoke that trusts a stored flag instead of GitHub’s live team membership, and a provider that serializes an empty field as an array where its docs promise an object.

Pro is the maintained version of all of that, for Razorpay and for Paddle, Lemon Squeezy, Gumroad 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.

Before you start

You need a Razorpay account, activated before any live sale; a GitHub organization with a team per product; a Cloudflare account; a second GitHub account to play the test buyer; and an Indian mobile number for the checkout. Test Mode covers the payment, the invitation and the refund end to end. With those in hand, the guided setup walks a coding agent through the deployment in about an hour.

If you are weighing Razorpay against a merchant of record, or your buyers are mostly outside India, the country guide compares the rails that take sellers from India, and the full comparison covers every option on the market.

Frequently Asked Questions

Is Razorpay a merchant of record?

No. Razorpay is a payment aggregator: it moves the money, and you remain the seller of record, so GST, invoicing and disputes stay with you. That is the difference from Paddle, Lemon Squeezy and Gumroad, and it is why Razorpay belongs to sellers registered in India rather than to the world. It also changes what the delivery layer has to do: a merchant of record absorbs a chargeback, an aggregator hands it to you, so RepoAccess listens for Razorpay's dispute event and revokes on it the way it revokes on a refund.

Can a buyer type their GitHub username on a Razorpay Payment Page?

Yes. A Razorpay Payment Page takes custom input fields, so you add one for the GitHub username and the buyer types it before paying. The handle rides the payment as a note, the webhook carries it to the worker, and the invitation goes out with no claim page in the path. The buyer never sees a page the worker serves: they pay on Razorpay's page and finish on Razorpay's own success panel, while the grant happens in the background.

Does a Razorpay refund revoke GitHub access automatically?

Yes, on a refund and on a dispute. The adapter reads whether a refund was full or partial from the payment entity in Razorpay's own refund payload, and under the shipped policy it revokes on either. A dispute arrives as its own event and is treated like a refund, because as an aggregator Razorpay does not absorb disputes for you. The revoke is scoped to the product that was refunded, a pending invitation is cancelled, and the check is made against GitHub's live team membership, within a 180-day window after the sale.

What happens if a buyer mistypes their GitHub username on Razorpay?

The worker validates the handle against GitHub, so a handle that does not exist produces no invitation and the purchase is parked rather than lost. What Razorpay cannot do is bring the buyer back to a page of yours: a Payment Page's post-payment redirect does not fire and its success message takes no dynamic values, so there is no claim page on this rail. The correction goes through your support contact on the Payment Page: you find the payment, read the typed handle from its notes, and add the right handle to the team by hand. A buyer added by hand is not a grant the worker made, so a later refund of that purchase is also handled by hand.

September 23, 2026
← RepoAccess

We use cookies to analyze site traffic and improve your experience. By clicking "Accept All", you consent to our use of analytical tracking.