Skip to main content

What are you looking for?

Explore our services and discover how we can help you achieve your goals

Qatar software delivery: PDPPL, payments, identity and Arabic-English build

A Qatar-facing release usually turns on four decisions outside the feature list: how the Personal Data Privacy Protection Law treats consent and cross-border data flows, whether checkout needs Qatar Central Bank-licensed payment services, which national identity sign-in belongs in scope, and which of Arabic and English ship first. Hosting and contract scope follow once those are settled.

Submit a project Explore custom engineering

Reviewed by Huy Nguyen (David), CEO · Updated 17 Oct 2026 · 12 min read

star

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?

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?

  1. Name the action that needs verified identity

    Registration, a high-value payment or a government-linked service each justify a different answer.

  2. 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.

  3. 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.

  4. Design the fallback first

    Define what a person sees when the identity check is unavailable or declined, and which actions stay open to them.

  5. Test with authorised test accounts or data

    Demonstrate success, decline and an unavailable-service case in a staging environment before release.

  6. 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.

Diagram of a Qatar digital identity decision pipeline: the action that needs identity, who owns onboarding, the identity-check level and a fallback designed first lead to success or decline, tested in staging before the release launches (opens the full-size diagram in a new tab)
Diagram of a Qatar digital identity decision pipeline

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.

  1. 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
  2. Message

    The portal shows an approved Arabic or English message explaining the choice and offers registration by mobile number

    Owner
    Language owner
  3. Alternative account

    The customer registers with a one-time code; the account is marked "identity not verified"

    Owner
    Product owner
  4. Limited actions

    Browsing and low-value actions are open; actions the business has tied to verified identity stay locked

    Owner
    Business owner
  5. 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
  6. 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.

Custom product engineering for a bounded release outcome 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
line

Tell us what you want to build or automate.

Submit a project