🔁Validation Flow

1. What “Validation” Means in DevPayr

Validation is the heartbeat of DevPayr. It’s the moment your software checks in with DevPayr to ask a very simple question:

“Is this copy of the product allowed to run?”

Everything else — licenses, injectables, paid state, domains, fingerprints — revolves around this moment of truth.

Validation happens whenever your app sends DevPayr a small request containing a license key and an identifier for where the app is running.

From that one request, DevPayr determines:

  • Is the license valid?

  • Has the customer paid?

  • Is the license being used on an allowed device or domain?

  • Has this license reached its daily usage limit?

  • Is the customer trying to use a test license in production or vice-versa?

  • Should we send any injectables for this installation?

  • Does this copy have permission to keep running?

Your app will then decide what to do:

  • unlock full features,

  • enable trial mode,

  • show a “license required” screen,

  • or block access entirely.

DevPayr does not force you into any particular UX. It only gives you a truthful, secure, tamper-resistant answer about the state of your product.

What Goes Into a Validation Request?

Every validation request includes three important ingredients:

1. A License Key

This is the key your customer enters or your backend generates after a purchase. It tells DevPayr which customer or which purchase this request belongs to.

2. The Application Identifier (X-Devpayr-Domain)

This is not only for websites. Think of it as “What device or environment is trying to run this software?”

It could be:

  • a real domain (clientapp.com)

  • a desktop hostname (JOHN-PC)

  • a device fingerprint

  • a hardware-based hash

  • a container ID

  • a subdomain

  • or any other identifier you choose

Whatever value you send becomes the identity DevPayr remembers when enforcing device limits, domain limits, test environments, or license migrations.

3. Optional Flags (like include=injectables)

These tell DevPayr whether to also return tracking scripts, configuration snippets, or custom data you stored for that project(also known as injectables in Devpayr)

What Comes Out of a Validation?

DevPayr responds with a single, predictable JSON structure. At minimum, you’ll always get:

  • has_paid — whether the project/customer has been marked as paid

  • valid — whether the license is legitimate, active, not expired, and not revoked

  • message — human-friendly status information

If requested, DevPayr can also return:

  • Injectables (scripts, HTML, configs, encrypted payloads)

Your software then makes its decisions based on these values.

When Should You Validate?

There’s no single “correct” answer — it depends on your product. But here are the most common patterns:

✔ On First Activation

User enters their license → app checks with DevPayr → license becomes associated with that device/domain.

✔ On App Startup

Good for SaaS, desktop apps, plugins, and tools that need tighter control.

✔ Periodically (e.g., once per day)

Useful for products that work offline but still need occasional checks.

✔ Before Unlocking a Premium Feature

For apps where certain features are behind paywalls or require injectables.

Why Validation Matters

Without validation, anyone could:

  • use a paid version without paying

  • activate the same license on unlimited devices

  • bypass environment rules

  • get injectables content meant only for paying customers

  • modify your code and skip license checks

Validation is what keeps your product protected without you having to build an entire licensing backend yourself.

2. The Core Pieces in the Validation Flow

To understand how DevPayr decides whether a license is valid, it helps to know the four pillars that work together during every validation request:

  1. The License Key

  2. The Application Identifier (X-Devpayr-Domain)

  3. Your Project's Domain Rules & Environment Rules

  4. Usage Limits, IP Rules & Payment Status

These pieces form the “logic chain” that DevPayr uses to approve or deny an activation. Below is how each one fits into the flow.

1. The License Key

Every validation begins with a license key.

This key is what identifies the customer or installation, and it carries several properties:

  • Whether it's active or revoked

  • Whether it has expired

  • Whether it's a test or production license

  • How many domains/devices it can be used on

  • Whether it has usage limits

  • What environment it’s meant to run in

  • Whether injectables should be returned

Think of the license key as the contract between your software and DevPayr. Every rule for that copy of the product is tied to the license.

If the license is invalid, expired, deactivated, or non-existent, the flow stops immediately.

2. The Application Identifier (X-Devpayr-Domain)

This is the most important part of the validation process — and the most misunderstood.

Despite the name, this value is not restricted to domains.

It is simply the identifier your application uses to represent where it is running.

You can send:

  • A real domain (clientsite.com)

  • A staging domain (staging.clientsite.com)

  • A desktop hostname (DESKTOP-7J4A7)

  • A device fingerprint

  • A hardware hash

  • A container name (docker-service-4)

  • A mobile device ID

  • Anything else that represents the installation

DevPayr treats this value as the identity of the installation.

Why it matters:

  • It’s how DevPayr enforces domain limits

  • It distinguishes between devices

  • It prevents license sharing

  • It helps detect abuse

  • It decides whether the environment is production or test

  • It's what ties validation logs to a specific machine or domain

Your app has full freedom to choose what identifier makes sense. DevPayr only needs one thing:

Whatever you send must consistently represent the installation.

If the same license appears with different identifiers on different days/devices, DevPayr will treat those as separate environments.

3. Your Project’s Domain & Environment Rules

Projects may have domain rules depending on how you set things up:

A. Project-Level Domains

Domains you add inside the DevPayr dashboard. These may be marked as:

  • Production

  • Staging

  • Development

If a license is configured to validate against project domains, then:

  • Only the domains you explicitly added are allowed

  • Test licenses can only run on test/localhost domains

  • Production licenses cannot run on test domains

This is useful when you’re delivering websites or SaaS instances where the domain is known ahead of time.

B. License-Level Domains

Some licenses allow the domain/device to be discovered dynamically.

In this case DevPayr will:

  • Accept the first domain/device

  • Save it

  • Count it toward the allowed quota

  • Reject new ones after the limit is exceeded

  • Enforce subdomain limits where applicable

This is perfect for desktop apps, plugins, themes, and downloadable software.

4. Usage Limits, IP Rules & Payment Status

After domain/environment checks, DevPayr moves to the final stage of evaluation:

A. Daily Usage Limits

If a license has max_usage_per_day, DevPayr checks how many times that license has already validated today.

If the license has reached the limit, DevPayr returns a 429 with a clear message.

B. IP & Country Rules

If the license has IP or country restrictions, DevPayr will:

  • Compare the request’s IP

  • Determine the country

  • Reject the request if it violates the restriction

This is often used for compliance, premium tier controls, or region-specific licensing.

C. Payment Status

Finally DevPayr determines:

Has the customer paid for this project?

This is usually handled by your backend:

  1. Your customer pays you

  2. You update DevPayr via API (mark project as paid)

  3. DevPayr starts returning has_paid: true on validations

Your software can then unlock features or switch out injectables.

This part is intentionally flexible because every business handles payments differently.

How These Four Pieces Work Together

When your app validates a license, all four pillars form a chain of checks:

  1. Is the license key real, active, and not expired?

  2. Does the identifier match allowed domain/device rules?

  3. Is the environment allowed for this license type (test vs production)?

  4. Is the license still within its usage quota?

  5. Is this IP/country allowed?

  6. Has the customer paid?

  7. Should injectables be returned?

Only if all checks pass does DevPayr return:

If any check fails, DevPayr responds with the correct error code and a clear message.

3. Real-World Validation Scenarios (Web Apps, SaaS, Desktop Apps, Plugins, Mobile Apps)

If you understand this section, you understand DevPayr.

Every software product validates differently. A WordPress plugin behaves differently from a SaaS dashboard. A desktop app behaves differently from a CLI tool. A mobile app behaves differently from an Electron application.

DevPayr is flexible because real products are different — and this section explains how to design validation correctly depending on what you’re building.

3.1 — Freelance Developers & Agencies Delivering Client Projects

If you build websites, web apps, dashboards, or custom systems for clients, DevPayr is literally built for you. In fact, this scenario is where DevPayr shines the most.

Your client will take your code, deploy it somewhere you don’t control — cPanel today… a random VPS tomorrow… and maybe a server you’ve never heard of next month.

You cannot rely on access to their server. You cannot rely on SSH, Git, or “please don’t remove this file” agreements. And you definitely cannot rely on “they will pay the remaining balance”.

DevPayr exists to solve this exact problem.

The Core Problem Freelancers Face

When you deliver a project:

  • Clients move hosting without telling you

  • They copy your code to other businesses

  • Some run the project on multiple domains instead of the one they paid for

  • Others delay or avoid final payment after deployment

  • You lose visibility once the project leaves your hands

DevPayr stops all of that with one simple mechanism:

Your project will only run when DevPayr says it is allowed to run.

And DevPayr makes that decision based on:

  • The license key

  • The domain/device the project is running on (via X-Devpayr-Domain)

  • Whether the client has paid

  • Whether the environment is allowed

  • Whether usage limits were exceeded

  • Whether injectables need to be delivered

Let’s walk through how this works in real life.

Step 1 — You Build the Project Normally

Laravel, React, WordPress, Node, Go — doesn’t matter.

You build your client’s project exactly the way you normally do.

Then you ask yourself one question:

“Where should I add the license validation check?”

Most freelancers simply validate the license:

  • On every request

  • Or only on startup / boot

  • Or only on protected modules (admin, premium features, etc.)

It’s flexible. Do what fits your workflow.

Step 2 — You Create a Project in DevPayr

Inside your DevPayr dashboard:

  1. Click Projects → Create New Project

  2. Name the project (e.g., “Apex Laundry POS”, “Emma Boutique Website”)

  3. Add optional project meta if you want

  4. Save

This project now represents the client’s software installation.

Step 3 — You Issue a License Key for the Client

Inside the project:

  1. Click New License

  2. Choose how many domains the client is allowed to run on

  3. Decide if subdomains should count separately

  4. Choose daily usage limits (optional)

  5. Add any IP/country restrictions if needed

  6. Click Create License

That’s their activation code. You will put it inside the client’s codebase.

Step 4 — The Client Deploys the Code

They upload your project to:

  • cPanel

  • CyberPanel

  • Namecheap

  • Hostinger

  • Renamed VPS from 2012

  • Or wherever they host things

DevPayr doesn’t care where it runs. It only cares whether:

  • The project sends its license

  • The project sends the domain/device identifier (X-Devpayr-Domain)

  • The license is still valid

Step 5 — Your Code Validates Itself Automatically

Here is what validation looks like in real life.

📍 The client opens the application.

Your software immediately calls DevPayr:

The SDKs send this automatically. If you aren’t using an SDK, you just add it to your HTTP request.

DevPayr checks:

  • Is the license real?

  • Is the license expired?

  • Is this the correct domain?

  • Is this production or test?

  • Is usage limit exceeded?

  • Is the license revoked?

  • Has the client actually paid?

  • Should we inject anything before code continues?

If everything is fine → "has_paid": true.

If anything is wrong → your code doesn’t boot.

Step 6 — What DevPayr Returns

A simple runtime example response:

If you included injectables, your SDK automatically injects them.

If you didn’t? Your app just runs normally.

Step 7 — What Happens When the Client Hasn’t Paid?

DevPayr returns:

Your code decides what to do:

  • Show a “Payment Required” page

  • Disable admin access

  • Lock premium features

  • Stop serving the application entirely

  • Display a reminder banner

Most freelancers simply disable login until the client pays.

Step 8 — What Happens When the Client Moves to a New Host?

If they migrate to another host:

  • Domain changes → your license blocks access

  • You are notified the license was used from a new environment

Perfect. Now you can demand payment before reactivating the license for the new domain.

This is how you stop unauthorized migrations and cloned deployments.

Step 9 — Real Code Examples

Node.js Example (Express)

PHP Example (Laravel Middleware)

Step 10 — How Injectables Help Freelancers

Injectables let you remotely push:

  • Version updates

  • Scripts

  • Config flags

  • “Trial expired” banners

  • “Your payment is late” UI

  • Feature toggles

  • Analytics snippets

All per project, from your DevPayr dashboard, without touching their server.

Why Freelancers Love This Setup

Because it solves the one problem freelancers never fully solve:

"After I deliver this project, how do I remain in control?"

With DevPayr:

  • No one can run your project without authorization

  • Clients cannot skip final payment

  • Clients cannot copy your system to multiple businesses

  • Clients cannot clone your code to multiple domains

  • Clients cannot silently migrate away from you

It is your remote control panel for every project you deliver. More features and controls are being worked on and you can contribute to these features here

3.2 — Product Developers & Marketplace Sellers (CodeCanyon, Gumroad, Envato, Plugin Authors)

If you build products that customers download and install — plugins, themes, scripts, desktop tools, mobile apps, SaaS starter kits, or anything sold on CodeCanyon/Gumroad/Envato — then DevPayr is your silent security guard.

Unlike client projects (where you know exactly who you are building for), product distribution is a different world:

  • Strangers buy your product

  • You never see their server or machine

  • Copies spread through groups and Telegram channels

  • People resell your work without your permission

And this is where DevPayr becomes priceless.

Your product might be downloaded 1,000 times, but only users with valid license keys can activate it. Everyone else gets nothing but frustration.

Why Product Developers Need Runtime Validation

Selling downloadable products is risky:

  • Your ZIP file can be shared

  • Your plugin can be cracked

  • Your theme can be uploaded anywhere

  • Your website scripts can be run on multiple domains

  • People can activate on multiple clients

  • One leaked license can be used hundreds of times

DevPayr shuts all of that down using four simple checks:

  1. License Key Verification

  2. Domain / Device Verification (X-Devpayr-Domain)

  3. Environment + Usage Restrictions

  4. Payment Status

Let’s break this into a real scenario.

Scenario: You Sell a SaaS Starter Kit or Dashboard Template

Suppose you sell a Laravel SaaS Starter Kit on CodeCanyon.

A customer downloads the ZIP. They install it on their server. On first run, your onboard script shows:

“Enter your license key to activate your copy.”

The user enters: DP-A1B2-C3D4-E5F6.

Your code immediately sends a validation request:

DevPayr responds:

Activation successful. The software runs.

Now here’s where DevPayr becomes powerful.

If the User Uploads It to a Second Domain

A second installation sends:

If the license allows only 1 domain, DevPayr responds:

Your software blocks activation automatically.

This single feature alone eliminates most unauthorized sharing and resale. To make it even more powerful, you can utilize injectables by including injectables in the SDK installation:

If the User Requests a Refund or Files a Chargeback

Your payment platform (Stripe, Paystack, Flutterwave, Gumroad, Paddle, etc.) notifies your server.

Your server calls DevPayr:

DevPayr revokes the license.

Next time the user opens the software:

The system immediately locks. No future updates. No injectables. No access.

Buyer remorse? Yes. Your business loss? No.

If The License Is Shared in a Telegram/WhatsApp Group

Hackers love sharing “nulled” copies.

But your validation flow stops them:

  • First user activates → domain saved

  • Second user activates → different domain → blocked

  • Third user activates → different domain → blocked

  • Fourth user → same pattern → blocked

Your product becomes “not worth cracking” because:

Every license is tied to a domain/device fingerprint.

Your support workload drops massively.

Using Injectables for Product Updates

Injectables give product developers superpowers. With it you can push:

  • Bug fixes

  • Temporary patches

  • Security overrides

  • Version-specific notices

  • Feature toggles

  • UI adjustments

  • “Upgrade to premium” banners

  • “Your license is expiring soon” messages

…directly from DevPayr, without touching the user’s installation.

Your product becomes dynamic — like SaaS — even though it is self-hosted.

While Injectables are one of DevPayr’s strongest features, the automatic handling of injectables in the SDK is currently in Beta. We recommend overriding the default handler and plugging in your own logic based on how your product works. You’ll find examples and guidance in each SDK.

For high-value or sensitive injectables (e.g. premium templates, paid scripts, or dynamic feature flags), we strongly suggest processing them in memory or via streaming, rather than writing them permanently to disk.

Persisting injectables as files makes it easier for pirates to bundle and redistribute your work.

In other words: let DevPayr deliver the injectable, let your app use it, but think carefully before storing it forever in a public, human-readable folder.

Why Domain/Device Validation is Critical for Product Sellers

Without a unique identifier (domain/device hash), your product is essentially:

“Install me anywhere, unlimited times.”

That’s suicide for product businesses.

DevPayr uses X-Devpayr-Domain, which you can set to:

  • A real domain (for hosted products)

  • A fingerprint hash (desktop / mobile)

  • A device ID

  • A unique machine token

The SDK handles this automatically, but you can override it.

This ensures:

  • One license = one installation

  • Or whatever limits you configure

  • Not whatever your users feel like doing

How This Helps Your Business Grow

  • Prevent Piracy

Your product cannot be installed unlimited times.

  • Reduce Support Overload

No more supporting users who never paid.

  • Maintain Recurring Revenue

Renewals matter — DevPayr enforces them.

  • Gain Observability

You see domain usage, device usage, environment usage, frequency of validation, and more.

  • Deliver Features Remotely

Injectables let you ship things instantly without new version releases.

Conclusion

If you sell any kind of downloadable software or product — Web/mobile app scripts, WordPress plugins, React templates, Electron apps, Python tools, desktop applications — DevPayr makes your product:

  • Safer

  • More secure

  • Traceable

  • More profitable

  • Easier to maintain

It adds SaaS-level control to self-hosted products.

3.3 — Startups & SaaS (Self-Hosted / On-Prem / White-Label Deployments)

Many startups offer a cloud version of their product, but also provide a self-hosted, on-premise, or white-label edition that customers install on their own servers. These installations run completely outside your control — on the customer’s infrastructure, domain, and environment.

Because you no longer control the server, you must rely on DevPayr to:

  • verify the customer’s license

  • enforce renewed payments

  • prevent unauthorized duplication or multiple installations

  • bind each installation to a domain or internal hostname

  • push configuration updates or feature flags remotely

  • revoke or suspend access when needed

This is where DevPayr shines. It gives you a centralized licensing and enforcement layer for software running anywhere in the world.

How DevPayr Fits Into a Self-Hosted SaaS Model

Every installation behaves like its own “instance.” DevPayr treats each installation as part of a licensed project and provides your software with a trusted external source of truth.

A typical lifecycle looks like this:

  1. A customer purchases a self-hosted edition of your product.

  2. Your billing system confirms payment.

  3. You create a project for that customer and issue a license for their installation.

  4. The customer installs the software on their server.

  5. The installation periodically verifies itself with DevPayr using:

    • their license key

    • a stable installation identifier (domain, hostname, fingerprint, etc.)

  6. DevPayr responds with:

    • whether the customer is paid

    • whether the license is valid

    • whether the installation environment matches expectations

    • any configuration or injectable updates meant for that installation

  7. Your application uses the response to decide what to unlock, restrict, or disable.

Through this simple loop, your self-hosted software behaves predictably and securely — even though it is no longer running under your infrastructure.

Choosing an Installation Identifier

Self-hosted products are installed in different and unpredictable environments. Some customers use:

  • a public domain

  • an internal corporate domain

  • a local machine

  • an internal hostname

  • a containerized hostname

  • or a unique installation ID

DevPayr is flexible. You can send:

  • a domain

  • a hostname

  • a device/server fingerprint

  • or any opaque identifier your application can generate consistently

Whatever you send becomes the installation’s identity for licensing, domain rules, usage limits, and history.

Why Self-Hosted SaaS Needs DevPayr

  1. Enforcing Payments and Renewals

If the customer stops paying, DevPayr instantly reports that their installation is no longer paid. Your software can then remove premium access, disable features, or switch to restricted mode.

  1. Preventing Unauthorized Copies

Without DevPayr, a customer could copy the installation to multiple servers. With DevPayr, each installation must identify itself — and multiple unauthorized environments will immediately fail validation.

  1. Controlling Which Domain or Host Can Run the Software

You can bind a license to:

  • one specific domain

  • multiple allowed domains

  • production vs test environments

This eliminates “server hopping” or unauthorized replication.

  1. Remote License & Environment Management

You can remotely:

  • revoke access

  • suspend the license

  • reactivate it

  • change environment rules (e.g., move from staging → production)

  • update license attributes without touching the customer’s server

All installations automatically follow the new rules during their next validation.

5. Feature Flags & Configuration Through Injectables

Injectables let you deliver small targeted configuration updates per installation. Examples include:

  • showing trial-ending banners

  • enabling a module only for Enterprise customers

  • adjusting behavior for specific installations

  • providing emergency configuration overrides

🔔 Important: Injectable handling in the SDKs is currently in Beta. We strongly recommend overriding the default injectable handler in your SDK configuration. Instructions for this are included in each SDK. Also, for security reasons, you should stream injectable content at runtime rather than storing it permanently.

Operational Benefits for Startups

  • Licensing That Scales With You

No matter how many self-hosted installations you deploy, DevPayr gives you a single control panel to manage them. Each installation behaves predictably, because licensing logic is standardized.

  • No More Manual Key Management

Renewals, suspensions, domain updates, and limits are all controlled from DevPayr’s dashboard or API — not through email or file transfers.

  • Security Without Heavy Infrastructure

You don’t need your own licensing servers. DevPayr sits between your business logic and your customers’ servers without adding complexity.

  • Predictable Commercial Control

Self-hosted software normally loses commercial visibility the moment it leaves your infrastructure. With DevPayr, you always know:

  • where it is installed

  • how it is being used

  • whether the customer is up to date on payments

  • whether features should be active or restricted

This gives your startup a solid commercial backbone for distributing software safely and profitably outside your own cloud.

When DevPayr Is a Perfect Fit for Self-Hosted SaaS

Use this architecture when:

  • customers run your system on their own servers

  • you sell enterprise deployments

  • you distribute software packages installers

  • you offer offline or behind-firewall versions

  • you need ongoing payment enforcement

  • you want controlled feature access per customer

  • you want a remote kill-switch or emergency override

  • you need a central dashboard to oversee all installations

In short:

If your software leaves your server, DevPayr becomes the gatekeeper that protects your revenue, enforces your rules, and keeps every installation accountable — no matter where it runs.

3.4 Final Notes on Real-World Integrations

Every real product uses DevPayr slightly differently, but the flow remains universal:

  1. Your application identifies itself using a domain, device fingerprint, machine hash, tenant hash, or any marker you choose. This is sent via X-Devpayr-Domain.

  2. The application sends a license key either through the SDK or via raw HTTP.

  3. DevPayr validates everything including:

    • license status (active / revoked / expired)

    • payment status

    • environment rules

    • domain or device constraints

    • usage limits

  4. DevPayr returns a structured JSON response and your application decides what to do next — unlock features, activate a user session, show a limit warning, or block access.

DevPayr is flexible enough to support:

  • self-hosted SaaS (client installs on their domain)

  • web apps that run in browsers

  • mobile apps, desktop apps, CLI tools

  • distributed software bundles

  • agency-delivered client projects

  • licensed plugins and themes

  • internal commercial tools

In every case, the integration is built on the same foundation:

Validate → Respond → Enforce behavior in your app.

PreviousLicense Types & LifecycleNextDomains / Devices / IP Restrictions

Last updated