OutsourcingVN is operated by Netbase JSC, so this guide is written by a supplier that would like your project. It sets out what Netbase can evidence for a Qatar-facing brief, points to the official references your own advisers should read in full, and names the decisions that stay with you. The guides index lists guides for other markets, and the market index compares the first question each one raises.
Contents
- What makes a Qatar-facing build different?
- What can Netbase evidence for a Qatar brief?
- Should Qatar's national identity sign-in be in the first release?
- Worked scenario: a declined national identity sign-in
- What has Netbase built that is relevant to a Qatar brief?
- Which questions should you ask a supplier?
- What usually goes wrong?
- Where will the system and its data run?
- How this guide is sourced and where it stops
- Common questions
- Plan the first release
What makes a Qatar-facing build different?
Four design choices come up in almost every Qatar-facing brief, and each has a different owner.
- Data protection under the PDPPL. Law No. 13 of 2016 on Protecting Personal Data Privacy requires a controller to obtain an individual's consent before processing, unless processing is necessary for a lawful purpose, and sets controller and processor duties around disclosure, accuracy and breach reporting. One provision runs the other way to what buyers often expect: a controller is forbidden from taking a decision that limits cross-border data flow, unless the processing itself breaches the law or risks serious damage to the data or the individual's privacy.
- Qatar Central Bank-licensed payment services. The Payment Services Regulation in force since 2021 requires prior QCB authorisation for issuing e-money, for merchant acquisition (including acquiring QR-code based payments) and for domestic money transfer between Qatar payment accounts; a cross-border money transfer needs a separate exchange-house licence.
- National digital identity sign-in. Qatar's digital government programme organises electronic authentication for government online services under a national e-authentication framework, which means the buyer has to decide which actions need a full identity check against that framework and which can use a lighter check instead.
- Arabic and English content. A bilingual Arabic right-to-left and English build changes layout direction, fonts, generated documents and every message the product sends; the UAE guide sets out the acceptance matrix a Gulf bilingual build is tested against.
A buyer's legal, finance and product owners should settle each of these with their own advisers before discovery starts; engineering then turns the decisions into a consent and transfer record, a payments integration, an identity flow and a language boundary.
What can Netbase evidence for a Qatar brief?
Procurement and security reviewers tend to ask for the same statements. These are the ones Netbase can give, set against what a Qatar-facing brief actually needs decided.
| Decision area | What Qatari rules and infrastructure expect | What a supplier can evidence | Who decides |
|---|---|---|---|
| Data protection | Consent, controller and processor duties, and no decision that limits lawful cross-border data flow | A data processing agreement, an access matrix, a tested breach-response plan | Data protection lead |
| Payments | QCB authorisation for e-money, merchant acquisition and domestic money transfer | A tested payment flow with a designed fallback, built with a licensed provider | Product owner with payments provider |
| Identity | A decision on which actions need the national e-authentication framework | A scoped identity flow with a fallback for a declined or unavailable check | Business owner |
| Language | A bilingual Arabic right-to-left and English journey, including generated documents | A named language owner and a tested acceptance pass per journey | Language owner |
| Hosting and contracts | A written scope, acceptance test and hosting location that respects your data-protection decisions | A written scope with named milestones and acceptance evidence | Business sponsor |
Netbase JSC's head office is in Hanoi, Vietnam, and it is the company's only office. Security practices include secure code review and version control, role-based access control, MFA for admin dashboards, contributors under NDA, and NDAs and DPAs on request. Delivery communication is in English, with the Hanoi office working Monday to Saturday, 9:00-18:15 Vietnam time (UTC+7).
Should Qatar's national identity sign-in be in the first release?
-
Name the action that needs verified identity
Registration, a high-value payment or a government-linked service each justify a different answer.
-
Confirm who owns onboarding
The buyer's organisation holds any relationship with the identity service and its configuration; the supplier implements against access the buyer obtains.
-
Choose the identity-check level
Decide between a full identity-framework integration and a lighter check, such as verifying a Qatari ID number format or a passport number for visitors.
-
Design the fallback first
Define what a person sees when the identity check is unavailable or declined, and which actions stay open to them.
-
Test with authorised test accounts or data
Demonstrate success, decline and an unavailable-service case in a staging environment before release.
-
Launch and keep the record current
Keep the data-processing record current, and re-test identity and payment integrations after any provider or rule change.
If onboarding, test access or the business decision is not ready, a first release can ship with the lighter identity check and add the full framework integration later, provided the business accepts that boundary in writing.
(opens the full-size diagram in a new tab)
Worked scenario: a declined national identity sign-in
A loyalty programme launches a bilingual member portal. A customer taps the national identity sign-in option and declines the consent screen.
-
Return from the identity service
The callback carries a decline; the portal records an audit event with a correlation identifier and no personal data
- Owner
- Engineering
-
Message
The portal shows an approved Arabic or English message explaining the choice and offers registration by mobile number
- Owner
- Language owner
-
Alternative account
The customer registers with a one-time code; the account is marked "identity not verified"
- Owner
- Product owner
-
Limited actions
Browsing and low-value actions are open; actions the business has tied to verified identity stay locked
- Owner
- Business owner
-
Later link
When the customer completes the identity check later, a matching rule links it to the existing account instead of creating a duplicate
- Owner
- Engineering with support
-
Support
An agent can see the account's verification state and the last identity event, not the raw identity attributes
- Owner
- Support lead
Walking one scenario through staging exposes what a proposal must cover: the matching rule, bilingual messages, locked actions and the support view.
What has Netbase built that is relevant to a Qatar brief?
The closest published evidence for a Qatar-facing brief is bilingual commerce for clients in Saudi Arabia and the UAE. For Deyar Printing & Advertising in Riyadh, Saudi Arabia, Netbase scoped and built a bilingual Arabic right-to-left and English web-to-print platform on a Laravel headless commerce foundation, with an online designer studio, dynamic print pricing and print-ready PDF generation; an AI design and pre-press suite, ERP integration and ZATCA e-invoicing were planned third-phase work, not delivered. The bilingual web-to-print platform record has the detail, and the Saudi Arabia guide covers ZATCA and the Saudi PDPL in full. For a Dubai-based loyalty and rewards technology company, Netbase delivered a headless multi-store reward shop platform on Magento 2 Open Source with a Next.js front end, in Arabic and English, for AWS or on-premise deployment; the client is not named. The loyalty reward shop platform record has the scope, and the loyalty and rewards platform guide sets out how a comparable programme is planned.
Which questions should you ask a supplier?
- Who owns the PDPPL consent basis, and who decides on cross-border data flow? It should be your organisation, with the supplier advising rather than deciding on your behalf.
- Which QCB-licensed provider processes payments, and for which service? Ask which of e-money issuance, merchant acquisition and domestic transfer the licence actually covers.
- What happens when the national identity check is declined or unavailable? Look for a designed fallback and locked actions, not "we will handle it".
- Who approves Arabic content, and who drafts interface labels? A good proposal separates legal and marketing copy your organisation approves from labels the supplier drafts for review.
- Where do production data, backups and logs live? Expect one written answer covering all three.
- What is out of scope for the first release? A good proposal names it rather than leaving it implicit.
What usually goes wrong?
- PDPPL consent and cross-border decisions left undecided. Signal: nobody can say whether a data flow out of Qatar is lawful when it actually happens. Owner: the data protection lead.
- A payment integration built against an unlicensed or wrongly scoped provider. Signal: the provider cannot produce a QCB authorisation for the specific service used. Owner: the product owner.
- Identity treated as a launch dependency without access. Signal: the release date waits on onboarding nobody has started. Owner: the business sponsor.
- Bilingual acceptance scheduled as a late pass. Signal: right-to-left mirroring and generated-document defects pile up right before launch instead of being caught early. Owner: the product owner, who should test both languages from the first build increment.
Where will the system and its data run?
The reward shop platform referenced above was built for AWS or on-premise deployment, a useful reminder that hosting is a design input rather than a late decision. Decide early which environment hosts production and backups, who operates the servers, who applies security patches, and who receives monitoring alerts. If your advisers conclude that certain data must stay in a particular location, record that as a requirement with a named owner, and check that staging, logs and support tools follow the same rule. Data security and compliance in outsourcing lists the contract questions that sit around this choice.
How this guide is sourced and where it stops
This guide uses the National Cyber Security Agency's own text of Law No. 13 of 2016 on Protecting Personal Data Privacy, the Qatar Central Bank's Payment Services Regulation, and the Qatari digital government programme's own security management reference on the national e-authentication framework, all accessed on 2026-10-17, together with Netbase delivery records approved in the OutsourcingVN claim register. It is written for product, technology and operations leads preparing a brief. It does not decide whether a specific data flow is lawful under the PDPPL or which payment licence a given provider needs; those decisions stay with your advisers.
Plan the next step for your project
Common questions
The law does not set a general transfer restriction; it instead forbids a controller from taking a decision that limits cross-border data flow unless the processing breaches the law or risks serious damage, so confirm your specific flow with your advisers rather than assuming a blanket restriction or a blanket permission.
Issuing e-money, acquiring merchant payments (including QR-code acquiring) and domestic money transfer between Qatar payment accounts are all regulated; confirm with your payments provider which authorisation covers the exact service your checkout uses.
Not necessarily. Many buyers launch with a lighter identity check and add the framework integration once the business case and access are ready, provided the release boundary is written down.
Not necessarily. Many buyers launch the journeys customers use most in both languages and keep internal back-office screens in English, provided every journey inside the boundary passes bilingual acceptance, including errors and notifications.
Yes, when review and approval rhythms are agreed early. Netbase delivery communication is in English, while Arabic content approval sits with your language owner.
Plan the first release
Bring your PDPPL consent and cross-border decisions, your QCB-licensed payment provider, your identity-check scope and the names of your legal, business and language owners. For neighbouring markets, the UAE guide covers UAE PASS and bilingual acceptance in full, and the Saudi Arabia guide covers ZATCA e-invoicing and the Saudi PDPL; the Thailand guide covers a different data-protection and payments pattern entirely. Time zone collaboration in Vietnam sets out how an overlap window and escalation route are agreed.
Custom Product Engineering is the service for a bounded build, and global delivery explains how remote delivery is organised. OutsourcingVN is Netbase's own outsourcing-services platform: submit a project with your data-protection and payment questions, and a person will reply with whether discovery or a bounded implementation is the right next step.
Related services and solutions
Custom product engineering for a bounded release outcome
One defined release of your product, built to named outcomes and handed over with acceptance evidence.
Learn More
Sources
- National Cyber Security Agency (NCSA), Law No. 13 of 2016 on Protecting Personal Data Privacy
- Qatar Central Bank, Payment Services Regulation (Licensing and Regulating Payment Service Providers)
- Qatar digital government programme, Government Enterprise Architecture, Security Management reference