Skip to main content

What are you looking for?

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

Indonesia software delivery: register the system, map the data, then pick a payment method

An Indonesia-facing product usually needs three decisions settled before a supplier starts building: whether the system must register as an electronic system operator, how personal data is mapped under the 2022 Personal Data Protection Law, and which local payment methods, including QRIS, the checkout has to support. Give each decision a named owner first.

Submit a project Explore custom engineering

Reviewed by David Nguyen (CEO) · Updated 29 Sep 2026 · 10 min read

star

OutsourcingVN is operated by Netbase JSC, so this guide is written by a supplier that would like your project. It draws on Netbase's published web-to-print storefront work in neighbouring markets and on official Indonesian references for the registration, data and payment questions your own advisers must confirm. The guides index lists the guides for other markets.

Contents

What decisions shape an Indonesia-facing build?

Four choices come up in almost every Indonesia-facing brief, and each has a different owner.

  • Electronic system registration. Indonesia's Ministry of Communication and Digital Affairs (Komdigi) requires operators of a private electronic system reaching Indonesian users to register through its private-scope registration portal, whether the operating company is based in Indonesia or overseas.
  • Personal data handling. Law No. 27 of 2022 on Personal Data Protection sets out lawful bases, data subject rights, cross-border transfer conditions and breach notification duties that your advisers interpret and engineering then turns into fields, access rules and tests.
  • Local payment methods. Bank Indonesia's QR Code Indonesian Standard, QRIS, is the payment method most Indonesian mobile shoppers expect at checkout, alongside cards and bank transfer.
  • Bahasa Indonesia content. Product copy, legal notices and customer messages in Bahasa Indonesia are not a translation pass added at the end; they change forms, generated documents and support scripts.

Treating all four as one line item in an estimate hides the registration and data-mapping work behind the parts of the brief that are easier to see.

Does your product need to register as an electronic system operator?

Komdigi's registration system lists a private-scope track, "Pendaftaran PSE Lingkup Privat", for private electronic system operators, alongside a separate track for public-sector systems. The practical question for a buyer is not technical: it is whether your organisation, as the entity offering the system to users in Indonesia, has completed that registration, not whether your supplier has.

That ownership matters for a build. A supplier can implement whatever a registration decision requires, such as a way to show a registration status or a channel for a government information request, but the registration itself, its renewal and the account behind it belong to the buyer's own legal entity. Confirm this with your advisers before development starts, because a registration decision can affect what the system must be able to report and to whom.

The nearest published record for this kind of store

The web-to-print stores in four countries record is the closest published example of a comparable build: online storefronts with a design tool that Netbase built for print businesses in Singapore, France, the Netherlands and South Korea. The Singapore store, for vinyl sticker cutting and large-format printing, separates what a specialist, a production worker and a designer can each do inside the tool, a division of roles that carries over to any catalogue-plus-configurator build regardless of the market it serves.

Custom Product Engineering scopes that kind of build for Indonesia in the same way: a catalogue, an account and order system, and a configuration layer in front of checkout, with the registration, data-map and payment decisions above added as their own tasks.

How do you map personal data under the PDP Law?

Turn each PDP Law question into an engineering artefact and a named owner before the first sprint.

PDP Law question What it becomes in the build Owner
What is the lawful basis for each data use? A consent or basis field recorded against the purpose, not the account Legal adviser with product owner
What can a data subject request? Access, correction and deletion flows with a service-level response time Product owner
Does data leave Indonesia? A data-flow map naming every system, region and processor Data steward
How is a breach reported? A logging and alerting path that reaches a named responder Security owner
Who is the data protection officer? A named contact recorded in the product's privacy notice Business sponsor

Our guide to data security and compliance in outsourcing lists the contract questions that sit around this map, including where a supplier's access to production data should stop.

How do you decide on QRIS and other local payment methods?

  1. List how your target customers already pay

    QRIS is the default expectation for many mobile shoppers; cards and bank transfer still matter for other segments.

  2. Choose a licensed payment service provider

    Your organisation opens the merchant account; the provider issues a Merchant ID once your business documentation is verified.

  3. Design for the per-transaction limit

    Bank Indonesia caps a single QRIS transaction, so plan a companion method for high-ticket orders rather than splitting one order into several codes.

  4. Decide which QR mode fits each channel

    A merchant-presented code suits a fixed till; a consumer-presented code suits a delivery rider or a pop-up stand.

  5. Build the reconciliation job before launch

    Match the provider's settlement report against your own order records daily, by Merchant ID and reference.

  6. Add a fallback

    Decide what a shopper sees when the payment provider is unavailable, and test that path as carefully as a successful payment.

Worked scenario: one storefront, two settlement reports

A retailer with three physical outlets in different cities adds QRIS checkout. Each outlet gets its own Merchant ID so the provider can settle funds to the right bank account.

  1. Order placed

    A customer scans the dynamic QRIS code shown at the checkout of outlet two

    Owner
    Engineering
  2. Settlement received

    The provider's settlement file lists the transaction under outlet two's Merchant ID

    Owner
    Finance owner
  3. Automated match attempted

    The reconciliation job expects a single company-wide Merchant ID and cannot find the order

    Owner
    Engineering
  4. Mapping table added

    A Merchant ID to outlet mapping table lets the job resolve any outlet's settlement file automatically

    Owner
    Engineering with finance
  5. New outlet opens

    The fourth outlet's Merchant ID is added to the mapping table before its first sale, not after the first mismatch

    Owner
    Operations lead
  6. Reporting

    A manager sees one balance per outlet and one consolidated total, not raw settlement files

    Owner
    Business owner

The lesson generalises past QRIS: any multi-outlet or multi-brand storefront needs a mapping layer between what a payment provider settles and what the business reports, decided before the second outlet goes live.

Which questions should you ask a supplier?

  • Who holds the Komdigi registration and the account behind it? It should be your organisation, with the supplier working inside the access you grant.
  • Which payment service provider will hold our QRIS merchant accounts? Expect your organisation's name on the account, not the supplier's.
  • How do you reconcile more than one Merchant ID? Look for a mapping table and a daily job, not a manual spreadsheet.
  • How do you answer a PDP Law data subject request inside the deadline? Expect a defined workflow and a response-time target, not an ad hoc process.
  • What happens when the payment provider is unavailable? Look for a designed fallback and a tested failure path.
  • What Bahasa Indonesia content do you expect us to supply, and what do you write? A good proposal separates legal and marketing copy, written or approved by your organisation, from interface labels the supplier drafts and you review.

What usually goes wrong?

  • Registration and payment accounts opened in the supplier's name. Signal: handover stalls because credentials cannot move. Owner: the business sponsor, who should require accounts in the buyer's name from day one.
  • Only one payment provider integrated. Signal: no fallback when the provider has an outage. Owner: the product owner.
  • Bahasa Indonesia content added after the English build. Signal: legal notices and generated documents are translated late and inconsistently. Owner: the language or legal owner, who should approve copy from the first release.
  • The data map skipped. Signal: a data subject request cannot be answered inside the deadline because nobody recorded where the data lives. Owner: the data steward.

How this guide is sourced and where it stops

This guide uses Indonesia's Law No. 27 of 2022 on Personal Data Protection, Komdigi's private-scope electronic system registration portal and Bank Indonesia's QRIS page, all accessed on 2026-09-29, alongside a Netbase delivery record approved in the OutsourcingVN claim register. It is written for founders, product and operations leads preparing a brief. It does not decide whether your system must register, or how the PDP Law applies to your organisation; those conclusions belong to your advisers. Netbase JSC's head office is in Hanoi, Vietnam, and it is the company's only office, so Indonesia-facing projects are delivered remotely, with delivery communication in English.

Plan the next step for your project

Common questions

That depends on whether your system is offered to users in Indonesia, which is a question for your Indonesian legal advisers rather than a technical one. Komdigi's private-scope registration portal is where that registration, once decided, is completed.

This guide does not make that determination for you. What is clear from Bank Indonesia's own QRIS page is that it is the standard many mobile-payment users expect, so most consumer-facing storefronts add it alongside cards or bank transfer rather than treating it as optional.

Most consumer-facing journeys do, including legal notices, receipts and support messages, because those are what a customer or a regulator reads first. Internal back-office tools can sometimes stay in English if your organisation's staff are comfortable with that; write the boundary down rather than deciding it screen by screen.

It isn't, directly: the record's four countries are Singapore, France, the Netherlands and South Korea, drawn from Netbase's own attested delivery facts and approved in the OutsourcingVN claim register. It appears here because the store-plus-design-tool shape of that work matches what many Indonesia-facing catalogue builds need.

Yes, when review and approval rhythms are agreed early. Netbase delivers remotely from Hanoi with weekly reviews and a named project manager, and delivery communication is in English, while Bahasa Indonesia content approval sits with your own language or legal owner.

Plan the first phase

Bring your registration decision, your data map, your payment-provider shortlist and the names of your legal, data and finance owners. The order and payment operations solution shows how payment states connect to fulfilment, and the total software delivery cost worksheet helps you compare proposals line by line. The methodology page explains how the records on this page are sourced. For other markets, the Singapore guide covers phased redevelopment and identity data, and the Philippines guide covers a neighbouring data-privacy and payments regime.

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 registration and data-map decisions, 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