Skip to main content

​
Pay to Access

Pay to Access sells metered access to something you host yourself — a web app, a members’ page, anything outside PayRequest. After payment, PayRequest issues a random access code with a usage limit (e.g. “5 uses”). Your own backend calls PayRequest’s public API each time someone tries to use the code — PayRequest tracks how many uses are left and locks the code out once the limit is reached.
Pay to Access is available on all plans. Product type: pay_to_access.

No File Involved

Unlike Digital Products or Pay to Unlock, nothing is uploaded or stored — PayRequest only issues and tracks the access code

You Own the Gate

Your app decides what “access” means (a login, an API call, a page view) — PayRequest just answers “is this code still valid?”

Usage-Limited, Not Time-Limited

Caps the number of uses, not just a subscription window — “paid for 5 logins” locks after the 5th, however many people share the code

Revocable

If a code leaks or an order is refunded, revoke it from the order detail page and it stops working immediately

​
Setting Up a Pay to Access Product

1

Start a New Product

Navigate to Products and click New Product. Select Pay to Access as the product type.
2

Set Max Uses and Expiry

Under Access Settings, set Max Uses (how many times the code can be verified before it locks) and Code Expiry (how many days the code stays active).
3

Set Your Price and Save

Enter the price and save. No file upload is required — there’s nothing to store.
4

Integrate the API

In your own app’s backend, call the verify/consume API below at the moment you want to check or burn a use.

​
How Delivery Works

  1. Customer pays — Payment is processed through Mollie.
  2. Code generated — A random 64-character access token is created with the configured max_uses and expires_at.
  3. Shown immediately — The code appears in a copyable “Your Access Code” card on the payment success page, right away — no need to wait for email.
  4. Email delivery — The order confirmation email also includes the access code ({{access_codes}} template variable), so the customer has a backup copy.
  5. Your app verifies it — Your backend calls the public API below to check the code and burn a use.

​
Integrating with Your App

These two endpoints are public and require no OAuth token — the 64-character code itself is the only secret, the same trust model as PayRequest’s existing digital download links. Call them from your own server (not client-side JavaScript, so the code isn’t exposed in browser devtools).
Unlike the rest of /api/v1, these endpoints do not use OAuth. Do not send your PayRequest API token to them — they only need the access code.

​
Verify (read-only)

Check whether a code is currently valid without consuming a use. Use this to show “you have 3 uses left” before deciding whether to actually grant access. 
POST /api/v1/access-tokens/{token}/verify
​
token
string
required
The 64-character access code the customer entered
curl -X POST "https://payrequest.app/api/v1/access-tokens/YOUR_CODE_HERE/verify" \
  -H "Accept: application/json"
Valid code: 
{
  "valid": true,
  "remaining_uses": 3,
  "max_uses": 5,
  "expires_at": "2026-08-01T00:00:00+02:00"
}
Invalid code: 
{ "valid": false, "reason": "limit_reached" }
reason is one of: not_found (404), expired (403), revoked (403), limit_reached (403).

​
Consume (burns one use)

Atomically burns one use of the code. Call this the moment you actually grant access (e.g. right when the customer’s login succeeds) — every successful call permanently reduces the remaining uses. Don’t call it on every page load. 
POST /api/v1/access-tokens/{token}/consume
​
token
string
required
The 64-character access code the customer entered
curl -X POST "https://payrequest.app/api/v1/access-tokens/YOUR_CODE_HERE/consume" \
  -H "Accept: application/json"
Successful consume: 
{
  "valid": true,
  "remaining_uses": 2,
  "max_uses": 5,
  "expires_at": "2026-08-01T00:00:00+02:00"
}
Rejected (limit already reached): 
{ "valid": false, "reason": "limit_reached", "remaining_uses": 0 }
Consuming is atomic under concurrent requests — if two requests for the same code arrive at once with only one use left, exactly one succeeds and the other gets limit_reached. You’ll never see the use count go negative or over the limit.

​
Example: gating a login

// Your app's backend, at the moment a customer tries to log in
const response = await fetch(
  `https://payrequest.app/api/v1/access-tokens/${accessCode}/consume`,
  { method: 'POST', headers: { Accept: 'application/json' } }
);
const result = await response.json();

if (!result.valid) {
  // show "code invalid / no uses left" and stop
  return;
}

// grant access - result.remaining_uses tells you how many logins are left

​
Managing Issued Codes

Open any order containing a Pay to Access product to see its issued code, remaining uses, and expiry. Two actions are available:
  • Reset — sets the use count back to 0 and extends the expiry. Use this if a customer needs more uses.
  • Revoke — immediately invalidates the code (e.g. it leaked, or the order was refunded). A revoked code always returns reason: "revoked", even before its uses or expiry run out.
You don’t need to hunt through orders to find a code, though — the product page (Products → [your Pay to Access product]) lists the 20 most recently issued codes directly, each with its use count, status, a copy button, and a link to the order it came from.

​
FAQ

Nothing stops that — the code isn’t tied to a single device or browser. It simply stops working once max_uses is reached, no matter who used it or how many people shared it. This matches “you paid for 5 uses” rather than “you paid for 1 seat.”
No. The access code itself is the only secret required, the same as PayRequest’s /download/{token} links. Keep the call server-side so the code isn’t exposed in browser devtools.
verify is read-only and never changes the remaining uses — good for showing a “uses left” counter. consume is the one that actually burns a use, and should only be called at the moment you grant access.
Editing the product only changes the default for future purchases. To change an already-issued code’s limit, use Reset on the order detail page (extends expiry and zeroes the use count) — there’s currently no way to change max_uses on an existing code without resetting it.
No. Each Pay to Access product is a single access code sold as one item, so the custom fields step and quantity selection are skipped automatically.

​
Next Steps

Digital Products

For selling files instead of metered access

Pay to Unlock

For blurred-photo/audio-preview style unlocks

Creating Products

Learn about all product types and settings

API Overview

PayRequest’s OAuth-protected billing API (separate from the Pay to Access verify/consume endpoints)