BongLuy Privacy Policy

Two different people appear in a BongLuy payment, and we stand in a different relationship to each.

You, the merchant. You hold an account, register stores, and create payments. For your own account data, we decide why and how it is processed — we are the controller, and this policy is our account of it.

Your payer. Someone who scans a QR you displayed. We hold no account for them and, in the ordinary flow, nothing that identifies them. Where you do send us something about a customer — in a tranId, a merchantStoreId, or a store name — you decide what that is and why, and we process it only to run the service for you. You are the controller of it; we are your processor. This policy is not a substitute for your own privacy notice to your customers, and we cannot write that notice for you.

If you are a payer who has landed here from a checkout page, §4 is the part written for you.

Everything below is a field that exists in our system today, not a category of things we might collect one day.

Your account. Your email address, your name and profile picture as your sign-in provider supplies them, whether the provider has verified the email, and the timestamps of creation and last change. Also which provider you used — Google or GitHub — the provider's own id for you, the scope you granted, and the tokens the provider issued at sign-in. We use those tokens to establish who you are at sign-in. We do not use them to read your Google or GitHub account for anything else.

Your sessions. For each active browser session: an opaque session token, its expiry, and the IP address and browser user-agent the session was created from. We keep those two for abuse investigation and for showing you where your account has been used.

Your stores. The store name, your own merchantStoreId if you set one, the paywayLink you register, and whether the store is active. Also the webhookUrl and webhookSecret if you supply them — see the honest note under §7.

Your payments. One record per payment: amount, the currency label you set, a snapshot of the paywayLink the payment was created against, expireAt, the QR payload, your tranId, and — once settled — ABA's settledTranId, the receipt URL ABA returns, and settledAt. If a payment fails we also store the upstream error text on the record. The system reserves fields for the short-lived ABA client id and token that a payment's status polling runs on; these are internal, never returned by any API route, and never shown to you or anyone else.

Your credentials, as we can hold them. An API key is stored only as a hash, alongside its name, its sk_live_ prefix, its first few characters, its expiry, and counters for how often it has been used and when it was last used. The key itself is displayed once at creation and cannot be recovered by us or anyone else afterwards. Checkout keys are not stored per account at all — they are configuration on the API.

Operational data. Server logs recording payment ids, the account id that owns them, ABA's client id for a transaction, and errors. A short-lived cache in Redis holding each payment's current status, which expires 15 minutes after it is written. Background job queues holding a payment's polling state until the payment reaches a terminal status.

Card numbers. Bank account credentials. PINs. One-time passcodes. Bank balances. A payer's transaction history.

This is a structural fact, not a policy promise we could quietly change. A payer scans a QR and authorises the payment inside ABA's own app, against ABA's own systems. That conversation does not pass through us, and money settles from the payer to your bank account without touching ours. We could not intercept those values if we wanted to.

We will never ask you for an API key, a checkout key, or a PayWay account password — by email, by chat, or by any other means. Treat anyone who does as an impostor.

If a merchant used BongLuy to display the QR code you are looking at, here is the whole of what we know about you.

Nothing that identifies you, unless the merchant sent it. We hold a record of the payment you are about to make: an amount, a status, a QR payload, and the merchant's own reference for it. We do not receive your name, your phone number, your bank details, or your device identity from the payment itself.

We are not the merchant. We do not sell you anything, we do not hold your money, and we cannot refund you, cancel your order, or tell you where your goods are. If something has gone wrong with a purchase, the merchant is the only party who can fix it — their name is shown on the checkout page.

The merchant may have sent us their own reference for you. An order number, an invoice id. What that is, and whether it identifies you, is the merchant's choice. Ask them, or read their privacy notice.

If you believe a merchant is misusing BongLuy, write to us at support@bongluy.com. We will act under §10 of the Terms where it is warranted, but we will usually have to point you back to the merchant for anything about the purchase itself.

tranId, merchantStoreId, and your store name are free text. We store them exactly as you send them, return them in API responses, and keep them for as long as we keep the record they sit on. Your store name is also shown to payers on the public checkout routes, by design, so they know who they are paying.

Put references in them, not people. No national ID numbers, no card numbers, no phone numbers, no email addresses, no health information, no credentials. If you put personal data in a field built for an order id, you have created an obligation for yourself that you cannot then hand to us, and you will have published some of it on a checkout page.

• To run the service — to authenticate you, create payments against your PayWay link, poll ABA for their status, and answer your API calls. This is performance of our agreement with you.
• To keep the service standing up — rate limiting, abuse detection, debugging, and capacity work. This is our legitimate interest in a service that works, balanced against your interest in not being over-monitored: the operational data in §2 is the minimum that supports it.
• To protect against fraud and misuse — investigating suspected credential compromise, transaction laundering, and the conduct prohibited by §6 of the Terms.
• To meet legal obligations — tax and accounting records, and lawful requests from Cambodian authorities.
• To reach you — service notices, breaking-change warnings, and security alerts. These are not marketing and you cannot unsubscribe from them while you hold an account. We do not send marketing email; if that ever changes we will ask first.

We do not sell personal data, we do not share it with data brokers, and we do not use it to train machine-learning models.

We describe these by category rather than by name. Naming the providers we route traffic through would tell an attacker where to aim and a competitor how we are built, without telling you anything more about what happens to your data. If you need the names — because your own compliance obligations require a subprocessor list — ask us at support@bongluy.com and we will provide them under a data processing agreement. If we add a new category of recipient, §15 says how you will hear about it.

About webhooks. You can save a webhookUrl and webhookSecret on a store, and we store both. Nothing reads them. Per-store webhooks are not implemented, no BongLuy request has ever been sent to a merchant's webhookUrl, and a secret saved today is inert. Two consequences worth stating plainly: no payment data has ever left us by that route, and the secret is held as you gave it, so do not save a secret you use anywhere else. When per-store webhooks ship, we will update this policy before the first delivery, not after.

Our database and cache are hosted with cloud providers outside Cambodia. Sign-in is processed by Google or GitHub on their own infrastructure, also outside Cambodia. ABA processes payments on its own systems in Cambodia.

Cambodia has no general cross-border transfer regime of the kind found in EU law, so there is no adequacy decision or standard contractual clause to point you at. What we can tell you is what we do: we choose providers that offer encryption in transit and at rest, we bind them to confidentiality and to processing only on our instructions, and we do not move data to a new region without updating this section.

If your own customers are in a jurisdiction that restricts transfers — the EU or the UK, for instance — that obligation is yours as controller of their data, and you should satisfy yourself before sending us anything about them.

Export before you close. Your payments and stores are readable through the API for as long as your account is open, and not afterwards. There is no self-serve export and no way for us to reconstruct one from a closed account, so pull what you need first.

What we actually do: TLS on everything in transit. API keys stored only as hashes, expiring at 90 days, revocable by you, and manageable only from a signed-in browser session — a key cannot rotate itself. Every authenticated read is scoped to the account that owns the record, so one merchant's key cannot reach another's payments. Payment ids are 122-bit random UUIDs, not sequential, so they cannot be enumerated; the public checkout routes sit behind a separate credential, a per-payment rate limit, and a global ceiling, and they disclose only the store name, amount, status, and QR — never your paywayLink, tranId, receipt URL, or internal errors. Access to production systems is limited to staff who need it.

What we will not claim: no system is perfectly secure, we hold no security certification today, and §14 of the Terms governs liability for any loss.

Your half of it. Your account is only as secure as the Google or GitHub account you sign in with — there is no password for us to protect, which means the provider's security is ours. Keep every credential server-side, and tell us at support@bongluy.com the moment you think one is exposed. Revoke it yourself first; do not wait for us.

If we are breached. Where a breach is likely to affect you, we will tell you by email at the address on your account, without undue delay, with what we know: what happened, what data was involved, what we have done, and what you should do. We would rather send you an early notice that is incomplete than a late one that is tidy.

You can ask us to:

• Show you what we hold about you.
• Correct anything inaccurate. Your name, email, and picture come from your sign-in provider, so a correction there is the durable fix.
• Delete your account and its data, subject to the records we must keep under §9.
• Export your data in a portable form.
• Explain or stop a particular use, where you object to it.

How. Some of this is self-serve: you can edit stores and revoke API keys from the dashboard, and read your payments through the API. Everything else is a manual request — write to support@bongluy.com from the address on your account. There is no API route that deletes an account.

We will answer within 30 days, and tell you if we need longer and why. We do not charge for this, unless a request is repetitive or excessive. We may need to confirm it is really you before acting, and we will refuse a request that would require us to break the law or hand one merchant another merchant's data.

If you think we have handled your data badly, tell us first — we would rather fix it. You retain any right you have to complain to a Cambodian authority.

We set one cookie, and it holds your dashboard session. It is essential: without it you cannot stay signed in. Where our dashboard and API are on the same parent domain, the cookie is scoped to that domain so it travels between them.

We run no analytics, no advertising, no tracking pixels, and no third-party scripts that set cookies of their own. There is no cookie banner because there is nothing to consent to. Google or GitHub may set their own cookies during sign-in, on their own domains and under their own policies.

BongLuy is for businesses. You must be at least 18 to hold an account, and the service is not directed at children. If we learn that we hold an account created by someone under 18, we will close it and delete the data.

This policy and any dispute about it are governed by the law of the Kingdom of Cambodia, and the courts of Cambodia have exclusive jurisdiction.

Cambodia has no single comprehensive data protection statute in force as at the effective date above; a Personal Data Protection Law has been in draft for some years. We therefore apply the obligations that do bind us — including those in the Law on Electronic Commerce (2019) on the handling and retention of records — and, above that floor, hold ourselves to the practices set out in this policy whether or not a statute currently compels them. If and when a Cambodian data protection law comes into force, we will update this policy to meet it.

This is not a GDPR notice. Where you serve customers in the EU, the UK, or anywhere else with its own regime, those obligations attach to you as controller of your customers' data, not to us through you. We will support a reasonable request to help you meet them; ask us before you assume the cover exists.

We may update this policy. For material changes — a new category of data, a new recipient, a new purpose — we will give reasonable notice by email or in the dashboard before the change takes effect, and state the new effective date at the top. Minor clarifications take effect when published.

We will not apply a new purpose retroactively to data we already hold without telling you.

Privacy, data requests, and security reports: support@bongluy.com

Write to us in plain terms about what you want. You do not need to cite a statute to get an answer.