# About centered applications

**URL:** <https://zatca1.discourse.group/t/about-centered-applications/8640>\
**Category:** Onboarding, renewal and revocation\
**Created:** [October 12, 2025, 7:44am UTC](https://zatca1.discourse.group/t/about-centered-applications/8640 "2025-10-12T07:44:09Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![ahmad2](https://avatars.discourse-cdn.com/v4/letter/a/9dc877/32.png) [@ahmad2](https://zatca1.discourse.group/u/ahmad2)\
**Post date:** [October 12, 2025, 7:44am UTC](https://zatca1.discourse.group/t/about-centered-applications/8640/1 "2025-10-12T07:44:09Z")

</div>

Tldr:

How should I develop things if my app is web based? Because normally you verify every unit a taxpayer uses but that’s unrealistic for a web app.

Full topic:

My app is web based and I am wondering how should I develop the onboarding process?

Should I verify all the taxpayers using the same device info? (Because it’s on a server)

Meaning all the invoices will be signed using the same certificate

I want a guide because the existing guides assume you’re developing a desktop app and you have a technical client.

---

<div class="post-metadata">

**Author:** ![sergei.shishov](https://avatars.discourse-cdn.com/v4/letter/s/f0a364/32.png) [@sergei.shishov](https://zatca1.discourse.group/u/sergei.shishov)\
**Post date:** [October 21, 2025, 2:20pm UTC](https://zatca1.discourse.group/t/about-centered-applications/8640/2 "2025-10-21T14:20:56Z")

</div>

For web based app you have to create and onboard the device for every customer per TRN. The reporting is based on the TRN injected in the device, therefore you cannot use the same device for different customers.

Based on your usage, if you have customer as organization or separate persons are using your app, you have to group persons under the group which share the same TRN, this group can onboard 1 or more devices and use them latter in some round-robin fashion or based on your logic, you can onboard different devices for different documents etc.

But the main idea - you have to create and onboard device per TRN, store certificate and private key somewhere to use later and so on. You have to understand - web-based app is just the “UI” but internally you are using servers and databases, mounted volumes or anything where you can store persistent data.

NOTE: I am not anyhow affiliated with ZATCA and helping with what I know or understand. And I cannot build the full solution for you or give detailed info, until you hire me as a core developer 😃

– Sergei

---

<div class="post-metadata">

**Author:** ![mnuaimi](https://avatars.discourse-cdn.com/v4/letter/m/dbc845/32.png) [@mnuaimi](https://zatca1.discourse.group/u/mnuaimi)\
**Post date:** [October 30, 2025, 9:31am UTC](https://zatca1.discourse.group/t/about-centered-applications/8640/3 "2025-10-30T09:31:43Z")

</div>

In a **web-based invoicing solution** , it’s not practical to treat every physical machine as a separate “device” with its own certificate, unlike desktop setups.

The recommended approach — as discussed in the **ZATCA Developer Forum** — is to treat each **Electronic Generation System (EGS) Unit** as a **virtual device** within your backend infrastructure.

* * *

## Recommended Implementation

- Each **taxpayer** or **branch** should be onboarded as an **EGS Unit** in your backend (server side).
- For each unit, generate:
  - a **key pair (private/public)**
  - a **CSID certificate** specific to that unit.

- All **signing** and **invoice reporting** are handled **server-side** using that unit’s certificate.
- The **frontend (browser)** never stores or uses the certificate — it only sends the invoice payload to the backend API.

* * *

## Concept

> The “device” in a web-based model is a **logical EGS unit** inside your system — not a physical computer.

* * *

### 🔹 Summary

This **virtualized onboarding model** follows **ZATCA’s recommended approach for cloud and web-based invoicing solutions** , ensuring compliance while maintaining scalability and security.