Frequently asked questions about DevPayr.

DevPayr is a licensing and enforcement layer you plug into your app or website. It helps you control who can use what you’ve built, where it runs (domains), and how it behaves when someone hasn’t fully paid.

Instead of arguing over screenshots and promises, you create a project in DevPayr, issue a license (optionally tied to a domain), drop a small snippet into your app, and let the system quietly enforce the rules you’ve already agreed on.

DevPayr is for builders who feel that “please, just pay the remaining balance” shouldn’t be their full-time job.

• Freelance developers shipping custom apps, dashboards, and portals.
• Designers and agencies delivering websites, SaaS-style builds, or funnels.
• Startups offering done-for-you setups, white-label installs, or managed instances.
• Creators selling digital products (themes, plugins, scripts, templates) and wanting real license checks instead of “honor system only”.
• Teams who want a central place to see which projects are licensed, which domains are active, and what’s overdue.

If clients or customers can keep using what you built while ignoring your invoice, DevPayr was designed with you in mind.

The basics are simple:

1. Create a project in DevPayr.
2. Generate a license (optionally tied to a domain).
3. Drop the SDK or verification snippet into your app.
4. Decide what should happen if the license is invalid.

If you’re used to working with APIs, it usually feels like wiring in any other 3rd-party service. The heavier parts are not code — they’re decisions: “Do I want to show a modal? Redirect? Go silent and just log?”

We know most people meet DevPayr in the middle of real client work, not in a lab. That’s why there’s a free tier — so you can test it on smaller projects, internal tools, or side-gigs without worrying about a bill.

Exact limits (projects, domains, requests) are listed on the pricing page . If you outgrow them, upgrading doesn’t change your existing integrations — it just lifts the limits.

Changing plans doesn’t break your SDKs or snippets. Licenses, projects, domains — they all stay as they are. The only thing that shifts is:

• How many projects / domains / licenses you’re allowed to manage.
• How many verifications you can run comfortably each month.
• Access to “team” features or higher-level controls (if your plan includes them).

If you know you’re about to onboard a big client, it’s usually smarter to upgrade before they go live, so you’re not thinking about limits on launch day.

Most agencies and freelancers treat DevPayr like any other infrastructure cost: domain names, hosting, email delivery, etc.

You can:

• Include it as part of a “managed” or “care” package.
• Pass it through as a line item (“License enforcement / DevPayr”).
• Absorb it into your price and keep your proposals cleaner.

However you structure it, the goal is simple: you should never be subsidising clients who refuse to honour basic payment terms.

At a high level, you:

1. Call DevPayr from your backend or frontend with your license and API key.
2. DevPayr validates the license, domain, limits, and status.
3. You receive a response that tells you whether this usage is allowed.
4. Your code decides the next step (show, block, limit, or log).

// Pseudo example
verifyLicense(license, domain, apiKey).then((result) => {
  if (result.valid) { /* continue as normal */ }
  else { /* modal / redirect / limited mode / log-only */ }
});

You can integrate via official SDKs or directly against the HTTP API. For more concrete examples, check the docs for your stack.

Project keys are designed for one specific project. They’re useful when you manage a few client builds and want to keep everything clearly separated.

Global keys are better for platforms, marketplaces, or internal tooling where:

• You manage many projects or customers from one system.
• You want to create licenses on the fly from your own dashboard.
• You need to sync things like “plan changed” or “subscription cancelled” back to DevPayr.

If you sell digital products (themes, scripts, plugins) or run your own SaaS, a global key often makes more sense — your code becomes the “bridge” between your billing and DevPayr’s licensing.

When you issue a license, you can:

• Attach it to a specific domain (e.g. client.com).
• Leave it open, and let DevPayr detect the first domain that sends a valid request.

This is handy when a client hasn’t given you the final domain name yet, or when you deploy first and they point DNS later. You get the benefits of license control without blocking yourself during development.

You can still change or reset domains later from your DevPayr dashboard if needed.

DevPayr doesn’t force one behaviour on you — you choose how your app reacts when something is wrong:

• Modal — show a blocking, but polite overlay explaining what’s happening and what the client needs to do.
• Redirect — send users to a specific page (e.g. “billing overdue”, “contact support”, or your own help article).
• Silent — don’t show anything to the user, but let your code decide how much of the app should work (read-only mode, feature limits, etc.).
• Log — record failed or suspicious behaviour without changing what the user sees yet, so you have an audit trail.

Most builders start with Log in staging, then move to Modal or a gentle Redirect in production once they’re comfortable.

Ransomware is about surprise, fear, and total loss of control. DevPayr is about clear expectations and reasonable boundaries.

You decide:

• How much warning a client gets.
• How much of the app should still work if they’re late.
• What message users and stakeholders actually see.

If you’re using DevPayr, we expect you to tell your clients up front: licensing, domains, and what happens if invoices are ignored. No secret switches, no hidden traps — just a clear line between “paid” and “not paid”.

Instead of going from “everything is fine” to “nothing works”, many builders:

• Start with Log mode and internal alerts.
• Move to visible warnings (modals, banners) after a grace period.
• Limit specific features (exports, admin actions, new signups) if the issue continues.
• Only block full access as a last step.

DevPayr gives you the signals; your code chooses how “soft” or “hard” each step should be.

If your app tries to verify a license and DevPayr can’t be reached (network issues, DNS problems, etc.), that check will fail. Without any extra logic, your app will see it as “verification didn’t work”.

This is why we strongly recommend enabling caching or “remembered approvals” in your app:

• Once a license is successfully verified, store that fact locally for a while.
• During that window, if DevPayr is temporarily unreachable, you can treat the license as valid.
• Log the incident so you know something went wrong, but don’t punish honest users for a network blip.

In other words: DevPayr gives you the truth when it’s reachable; your caching strategy decides how forgiving your app should be when the network misbehaves.

Once you delete or disable a project in DevPayr, any new verification attempts for that project will fail. This is expected — it’s like telling DevPayr: “I no longer want to recognise this project.”

If your app uses caching for already-verified licenses, users may still be able to run the app for as long as that cache is valid. After that, they’ll hit the behaviour you’ve configured for failed checks (modal, redirect, limited mode, etc.).

If you’re cleaning up old projects but don’t want to break anything, it’s usually safer to “archive” or “disable enforcement” at your app level first, then tidy up DevPayr once you’re sure nothing depends on it.

Basic good practice still applies:

• Store keys in env variables, not hard-coded in your repository.
• Rotate keys if you suspect they’ve leaked or been shared.
• Use project keys where possible, so exposure is limited to one project.

If you’re embedding DevPayr on the frontend, use the minimum level of information needed, and keep sensitive operations on your backend where you control access.

Depending on your plan, you can invite teammates and give them different levels of access — from “can view logs only” to “can create and revoke licenses”.

This is especially useful for agencies where:

• Developers handle integration and debugging.
• Account managers check license status before client calls.
• Founders only want to see high-level activity and billing.

Check the pricing page to see what your current plan includes.