DEV Community: Hem

Building for Indonesia? What UU PDP Actually Requires From Developers (a Practical Checklist)

Hem — Wed, 10 Jun 2026 14:11:20 +0000

If your product touches users in Indonesia, the country's Personal Data Protection Law — UU PDP, Law 27/2022 — is now fully in force. The two-year transition ended in October 2024, and the law is extraterritorial: it applies to you even if your company sits in Singapore, Australia or Berlin, as long as you process the data of people in Indonesia.

Most engineering teams treat "privacy" as a checkbox near launch. UU PDP is closer to GDPR than to a checkbox, and a lot of what it requires lands directly on the codebase. Here's the developer-level version — what it actually means for what you build.

(Not legal advice — talk to an Indonesian lawyer for your specific case. This is the engineering-side map.)

The five things that hit your code

1. A lawful basis and real consent (Art. 26). You need a lawful basis for every processing activity, and for most consumer products that means consent — real consent, not a pre-ticked box. Practically: granular opt-ins (don't bundle "marketing" with "create account"), a record of what was consented to and when, and a way to withdraw it that actually stops the processing. If you can't show the consent log, you can't prove compliance.

2. Transparent privacy notices. Users must be told what you collect and why, in plain language, before you collect it. That's a product surface, not a PDF nobody reads — wire it into signup and data-collection points.

3. Nine data-subject rights → you need endpoints for them. UU PDP grants users rights including access, correction, deletion, and portability of their data. In engineering terms: you need to be able to export a user's data and delete it on request, reliably, across every service and backup that holds it. If "delete my account" leaves data scattered in logs, analytics and a warehouse, that's a problem. Design for export/delete from day one — retrofitting it is painful.

4. Breach notification within 3×24 hours. If you have a qualifying breach, Art. 46 requires written notice to the affected users and the authority within three days, including what was breached, when and how, and your remediation. You cannot meet a 3-day clock if you have no idea what happened — so this is really a requirement for logging, monitoring and an incident process that exist before the breach.

5. Data minimization. The cheapest way to comply is to not hold data you don't need. Every extra field is extra liability — especially anything payment-adjacent or sensitive. "We might use it later" is how you end up over-exposed.

The ones that hit your architecture and org

Cross-border transfer. If you host or process Indonesian data outside Indonesia, you need appropriate safeguards. Know where your data physically lives and where it flows.
DPO and DPIA. Large-scale or sensitive processing can require appointing a Data Protection Officer and running a Data Protection Impact Assessment for high-risk features. Build the DPIA habit into how you scope risky features.
Per-tenant isolation. For multi-tenant products, isolating each customer's data cleanly isn't just good architecture — it makes access control, deletion and breach scoping dramatically easier to honor.

Why take it seriously

Administrative fines can reach up to 2% of annual revenue, and the law also carries criminal liability. The dedicated PDP Agency is being stood up (targeted for 2026); for now enforcement sits with Komdigi. The point isn't to panic — it's that "we'll add privacy later" is now an expensive default in this market.

A pragmatic build checklist

Granular, logged, withdrawable consent — not a single bundled checkbox
A privacy notice wired into collection points, in plain language
A working export-user-data path and a working delete-user-data path across all stores
Logging and monitoring good enough to detect and describe a breach within 3 days
Collect the minimum; drop fields you don't actually use
Know where data is hosted and how it crosses borders
DPIA for high-risk features; DPO if your scale/sensitivity triggers it

Common mistakes I see

"Delete account" that only flips an is_active flag and leaves the data everywhere
Consent stored as a single boolean with no record of scope or timestamp
No way to assemble everything you hold about one user (so you can't honor access/portability)
Treating compliance as a launch-week task instead of an architecture decision

If you'd rather not own all of this in-house, studios that build UU-PDP-aware products for the Indonesian market — for example H-Studio — can bake it into the architecture from the start. But the checklist above is the same whoever builds it.

FAQ

Does UU PDP apply if my company isn't in Indonesia?
Yes — it's extraterritorial. If you process data of people in Indonesia, it applies regardless of where you're based.

How fast do I have to report a breach?
Within 3×24 hours (three days) to the affected users and the authority, with details of what happened and your response.

Do I need a DPO?
Not always — but large-scale or sensitive-data processing can require one. Check your thresholds.

What's the penalty for ignoring it?
Administrative fines up to 2% of annual revenue, plus possible criminal liability — on top of the reputational hit.

Takeaway

UU PDP turns three things into engineering requirements: real consent you can prove, the ability to export and delete a user's data on demand, and enough observability to report a breach in three days. Build those in early, collect less data, and know where it lives. It's far cheaper as an architecture decision than as a launch-week scramble — or a 2%-of-revenue fine.

How are you handling UU PDP in your stack? Comparing notes in the comments.

Sources: DLA Piper – Indonesia data protection · ASEAN Briefing – Indonesia PDP Law guide

Integrating Payments in Indonesia: Midtrans vs Xendit (and When to Pick Which)

Hem — Wed, 10 Jun 2026 14:08:48 +0000

If you're shipping anything that takes money in Indonesia, two names come up before all others: Midtrans and Xendit. They're both solid, both support the payment methods Indonesians actually use, and both will get you live. But they're tuned for different kinds of projects, and picking the wrong one means either fighting the API or migrating later. Here's a developer-level comparison, plus the QRIS basics you need either way.

QRIS is the backbone — start there

Whatever gateway you pick, QRIS (the national QR standard) is non-negotiable for the Indonesian market: one QR that works across every bank and e-wallet. Good news for your budget — the QRIS merchant fee is regulated by Bank Indonesia at 0.7% per transaction, the same on both gateways. So QRIS pricing is not a differentiator; the developer experience and the surrounding features are.

Midtrans in one paragraph

Midtrans is part of the GoTo group, which gives it one concrete advantage: native GoPay integration — Indonesia's largest e-wallet. Customers can be redirected straight into the GoPay app instead of scanning a QR. It tends to have faster settlement, a large library of ready-made plugins for popular CMS and e-commerce platforms, and the deepest pool of Indonesian-language tutorials and community — which matters a lot if your team is junior or local. The trade-off: it's focused on receiving payments.

Xendit in one paragraph

Xendit's reputation is the clean, modern API and genuinely good docs — the nicer developer experience if you're building something custom and API-first. Its standout feature is Disbursement: programmatically sending money out to bank accounts. If your product pays sellers, drivers, freelancers or refunds at scale, that's a big deal Midtrans doesn't cover. The trade-off: no native GoPay redirect (GoPay users still pay via universal QRIS, just with a scan instead of an app hand-off).

How to actually choose

A few honest rules of thumb:

You're on a CMS or e-commerce platform (WooCommerce, Shopify-style, Laravel with existing packages) → Midtrans usually wins on ready plugins and time-to-live.
You're building custom and comfortable with APIs → Xendit's API is the more pleasant place to live.
You need to pay money out, not just take it in (marketplaces, payouts, refunds at scale) → Xendit, for Disbursement.
GoPay redirect UX matters for conversion and your audience leans GoPay-heavy → Midtrans's native integration is smoother than a QR scan.
Faster settlement is critical to your cash flow → lean Midtrans.

For a lot of marketplaces the real answer is both: Xendit for disbursement to sellers, plus whichever fits your collection UX best.

The gotchas nobody mentions

Webhooks are your source of truth, not the redirect. Don't mark an order paid because the user landed back on your success page — confirm via the gateway's server-side notification/webhook, and make the handler idempotent.
Settlement time ≠ transaction time. Money confirmed today isn't money in your account today. Model that in your cash-flow and your seller payouts.
UU PDP applies to you. The moment you store customer data tied to payments, Indonesia's Personal Data Protection Law is in scope — consent, a processing policy, and sensible data handling. Don't store card-adjacent data you don't need.
Test mode lies a little. Sandbox behaviour for QRIS and e-wallets doesn't always match production edge cases. Budget time for a real-money smoke test before launch.

There are other players worth a look depending on your case — DOKU and iPaymu among them — but for most new builds the decision is Midtrans vs Xendit.

If you'd rather not build it in-house

Payment integration is one of those tasks that looks like "just add a button" and turns into webhooks, reconciliation, payouts and edge cases. If it's outside your team's wheelhouse, studios that build Indonesian payment and platform integrations — for example H-Studio — can take it end to end. Either way, the decision framework above is the same.

FAQ

Is QRIS cheaper on Midtrans or Xendit?
Neither — the QRIS merchant fee is regulated at 0.7% on both. Choose on developer experience and features, not QRIS price.

Which is better for a custom-built product?
Xendit, generally — cleaner API and better docs for API-first builds. Midtrans shines when you're on a CMS with ready plugins.

I need to pay out to sellers — which one?
Xendit, for its Disbursement feature. Midtrans focuses on collecting payments, not sending them.

Do I need both?
Many marketplaces do: Xendit for payouts plus the best collection UX for their audience. For a simple checkout, one is enough.

Takeaway

Midtrans and Xendit are both good — they're just good at different things. CMS and GoPay-heavy, fast-settlement shops lean Midtrans; custom, API-first products and anything needing payouts lean Xendit. Decide based on what your product does with money, wire up webhooks properly, and remember UU PDP the moment you store customer data.