Privacy policy

Payments.lk is the brand under which Payable offers an internet payment gateway to Sri Lankan startups and small businesses. Payable (Pvt) Ltd, of 4th Floor, Huejay Court, No. 32, Sir Mohamed Macan Marker Mawatha, Colombo 03, Sri Lanka, is the licensed payment company whose gateway and acquiring bank relationships process every card payment made through Payments.lk. In this policy "we", "us" and "Payments.lk" mean the operator of the Payments.lk service.

Under the Personal Data Protection Act, No. 9 of 2022 (the PDPA), we are the controller of the personal data described in this policy that is collected through the Payments.lk site, portal and API. Payable is a controller in its own right for the processing it carries out on its gateway, which its own privacy policy governs: payable.lk/privacy. Where a merchant uses Payments.lk to take payments from its own customers, that merchant is the controller of its customer relationship, and we process those customers' details on the merchant's instructions and for our own record keeping duties.

This policy applies to every person whose personal data we handle:

• Applicants and merchants: a person who starts an application, signs up for an account or runs a business that takes payments through us.
• People connected to a merchant: owners, directors, partners, beneficial owners and authorised signatories named in an application, and team members a merchant invites into its dashboard.
• Customers: a person who pays a merchant through a Payments.lk checkout, payment link or card kept on file.
• Visitors: anyone who reads this site.
• Developers: a person who integrates with our API, webhooks or software development kits on a merchant's behalf.
• AI agents: a merchant may give an automated agent a scoped key to work in its account. The agent is not a person, but the merchant who issued the key is, and what the agent does is recorded against the merchant.

From applicants and merchants

• Account details: your email address and mobile number, both proved with a one time code; your password, which is stored only as a one way hash we cannot reverse; your language preference.
• About you: your full name, your role in the business, your identity document type and number (national identity card or passport), and your date of birth.
• About the business: its name, whether it is registered and as what, the business registration number and date, the district and address, what it sells and how, whether the activity is licensed, its stage, the expected monthly volume, the average order value, the website, whether it sells in person, whether it will take foreign or premium issuer cards, how it invoices today, and the names and shareholdings of its owners and directors.
• Where you are paid: your bank, branch, branch code, account holder name and account number, and whether you have a Taxpayer Identification Number or a declaration in its place.
• Documents: copies of identity cards for you and, where they apply, for partners and directors; the business registration or incorporation certificate; Registrar of Companies forms, articles and a board resolution for a company; a partnership deed and authority to onboard for a partnership; proof of your bank account; proof of address; a TIN certificate; any sector licence; and anything else you choose to upload.
• Your logo, if you upload one, which Payable's payment page shows to your customers. It is the one file we publish; text and location data are removed from it first.
• Your choices in the application, such as interest in Surge Cloud, the group's business software, or in a migration grant. These affect nothing about your payments application.
• If you book a call with an onboarding specialist, the details you give Calendly to book it.
• Your declaration that the application is true and your consent to the checks described in this policy.
• A record of what happens in your account: every sign in, change, key issued, refund made and setting altered, with the time, the person or key that did it, and the internet address it came from.

From people connected to a merchant

The names, shareholdings and identity documents of owners, directors, partners and signatories reach us because an applicant enters them, as the law requires. If you are one of these people, the applicant should have told you. A team member invited into a dashboard gives us an email address, a password hash, a proved mobile number and the role assigned to them.

From customers who pay a merchant

• Your name, email address and phone number, which the card networks require with every online payment. The checkout page also asks for your street, city and postal code because Payable's payment page requires them; they are passed to Payable and we do not store them.
• The amount, the currency, what the merchant says the payment is for, and the merchant's reference such as an order number.
• The result of the payment as Payable reports it, the card scheme and the last four digits of the card. Never the full card number.
• If you tick the box to keep a card on file with a merchant, Payable stores the card and gives us a token for it; we keep the token, the scheme, the last four digits and the expiry month so you can recognise the card.

From visitors and developers

• Our hosting and edge providers keep ordinary web server logs: the internet address, the pages requested and the browser type.
• On the public pages of this site (the pages about the service, pricing, the blog, the developer pages and these legal pages), Google Analytics and the Meta Pixel, loaded through Google Tag Manager, record the pages you visit, the page you came from, your device and browser, an approximate location worked out from your internet address, and an identifier kept in a cookie. Neither runs on a checkout, a payment link or a pay page, so neither sees anything you type there.
• In the merchant portal, Google Tag Manager loads the same tags as on the public pages, Google Analytics and the Meta Pixel among them. They record the pages you open, the page you came from, your device and browser, an approximate location worked out from your internet address, the identifiers in their cookies, your account's random id, and the steps of the application you complete, with the option you chose where a step is a choice from our own list (your role, whether and how your business is registered, its district, category and expected monthly volume, your bank, and the like). The steps we report carry nothing you type: no name, email address, phone number, ID number, date of birth, address or account number. The tags do not run on the pages opened from a link we email you (confirming your email, resetting your password, accepting an invitation).
• For a developer, the prefix of each API key and a one way digest of it, when it was last used, the webhook addresses you register, a record of each request that carries an idempotency key, and, if you use the test inbox, the webhook bodies delivered to it.
• For an AI agent, the name you gave it, its scopes, its expiry, when it was last used, and a record of every tool it called: the tool, the outcome and how long it took, but never the values it passed.

• Card numbers, card verification codes and anything else printed on a card. A card is entered only on Payable's hosted payment page, which runs 3D Secure, and Payable tells us the outcome, the scheme and the last four digits.
• Passwords in a readable form. We keep a hash. One time codes are kept only as a keyed hash that cannot be turned back into the code.
• Anything about your customers beyond what a payment needs. We build no profiles and we run no advertising.

The PDPA allows personal data to be processed only on a lawful basis. These are ours, purpose by purpose.

• To assess an application and open a merchant account, including passing it to Payable and its acquiring banks for approval: taking the steps you ask for before a contract, and then performing the contract with you.
• To verify who you are, who owns and controls the business and where it banks, and to keep those records: a legal obligation under the Financial Transactions Reporting Act, No. 6 of 2006, the Prevention of Money Laundering Act, No. 5 of 2006, and the rules the Central Bank of Sri Lanka and the card networks place on Payable and its banks.
• To run checkouts, payment links, cards on file, refunds, webhooks and the dashboard, and to send you the emails and text messages the service needs, such as sign in codes and decisions on your application: performing the contract with you.
• To keep a customer's name and contact details with a payment: performing the merchant's contract with its customer, and our own legal record keeping.
• To keep the audit trail, prevent fraud, detect abuse, rate limit, secure the service and answer a dispute: our legitimate interest in running a safe payment service, and our legal obligations.
• To keep payment and fee records for the period tax law requires: a legal obligation under the Inland Revenue Act, No. 24 of 2017.
• To keep a card on file for a customer: that customer's consent, given by ticking the box at checkout, which they can withdraw by asking the merchant to remove the card.
• To understand how people find and use this site and the merchant portal, where applicants stop in the application, and to measure our own advertising, through Google Analytics and the Meta Pixel: our legitimate interest in knowing whether the site, the application and our advertising work. You can object, and block these cookies, as the section on cookies explains.
• To know which advertisement, email or partner link brought an application, so that Payable's sales team and our marketing can see what works: the campaign tags saved when you arrived are kept with your application and passed to Payable's CRM with it. Our legitimate interest in knowing whether our advertising works.
• To answer a request from a regulator, a court or law enforcement that the law obliges us to answer: a legal obligation.

We do not sell your data. Apart from the visit data the Meta Pixel gives Meta to measure and target our own advertising, we do not use it for marketing by a third party. No decision about your application is made by a machine alone: Payable's onboarding staff decide, and if the application is not approved you are told and can correct it and send it again.

Your data goes to the following parties, and to nobody else.

• Payable (Pvt) Ltd, which processes every card payment, reviews and approves every merchant, holds the merchant record on its gateway and settles funds. Your application, its documents and your settlement account go to Payable's onboarding team, and payment details go to Payable's gateway. Payable passes what its banks need to its acquiring banks, which at present are Commercial Bank of Ceylon, Seylan Bank and Nations Trust Bank, and to the card networks.
• Amazon Web Services, which hosts the platform and its database and object storage in its Singapore region, and Cloudflare, whose network sits in front of the site, the portal and the API and sees the internet address of every request.
• The email and text message providers that deliver the messages the service sends: at present SendGrid, through Payable's account, for email, and Payable's SMS gateway, which relays through the Hutch mobile network, for text messages. Each receives only the address or number and the message.
• Fontshare, from which your browser loads one of this site's typefaces, which means your browser sends its internet address to Fontshare when a page loads.
• Calendly, if you choose to book a call with an onboarding specialist through the link in the dashboard. The booking happens on Calendly's site under Calendly's own policy.
• Google, through Google Tag Manager and Google Analytics, on the public pages of this site and in the merchant portal: the pages visited, the page you came from, the browser and device, the internet address and a cookie identifier, and in the portal your account's random id and the application steps you complete. Meta Platforms, through the Meta Pixel, on the same pages: the same data. Google uses this to give us reports on visits and use; Meta uses it to measure and target our advertising, and may connect a visit to a Facebook or Instagram account under its own policy.
• WhatsApp, run by Meta, if you choose to chat with us through the chat button on this site or in the dashboard. The conversation happens on WhatsApp under its own terms and policy, and reaches our technical team or, for everything else, the Payments.lk WhatsApp assistant, which is an automated service.
• The Central Bank of Sri Lanka, the Financial Intelligence Unit, the Data Protection Authority, a court or law enforcement, when a law, a court order or a regulatory direction requires it. We tell you when the law lets us.

Surge Cloud, the group's business software, is offered to you in the application and the dashboard through links to its own site. Your answer about it stays with your application and is used only to follow up with you if you asked; it is not passed to anyone else.

Where a provider outside Sri Lanka handles your data, the safeguards in the next section apply.

The platform, its database and its document storage run on Amazon Web Services in the Asia Pacific (Singapore) region. Cloudflare's network, which carries every request to the site, the portal and the API, operates worldwide. Email leaves through SendGrid, whose servers are outside Sri Lanka. Payable's gateway and its banks are in Sri Lanka. Google Analytics sends visit and usage data from the public pages and the merchant portal to Google, and the Meta Pixel sends the same data to Meta; their servers are in the United States and elsewhere.

The PDPA permits personal data to leave Sri Lanka where safeguards protect it. Ours are: each provider is bound by a contract that limits what it may do with the data to providing its service; data is encrypted in transit and at rest; identity numbers, dates of birth, account numbers and every document are encrypted under our own key before they reach any provider's storage, so the provider holds ciphertext it cannot read; and each provider is chosen for its own security certifications. If the Data Protection Authority designates adequate jurisdictions or prescribes instruments for transfers, we will follow them.

We keep personal data for as long as the purpose needs it or the law requires, whichever is longer, and then delete or anonymise it. How long each thing is valid or kept:

• Application, identity and business verification records and documents: six years from the end of your relationship with us, because the Financial Transactions Reporting Act requires records of customer identity and transactions to be kept for six years.
• Payment, refund, fee and settlement records: six years from the end of the year they relate to, to satisfy the Financial Transactions Reporting Act and the record keeping duties of the Inland Revenue Act.
• The audit trail of your account: it cannot be edited or deleted by the application at all, and it is kept for the same six years.
• A document you uploaded and then removed before submitting: deleted from storage at once. After submission a document is part of the record and stays for the six years.
• Sign in sessions: thirty days, renewed while you keep using the dashboard, and removed when they expire or you sign out. A one time code is valid for minutes, a sign in link for up to seven days and a password reset link for thirty minutes; the record that one was issued stays with the audit trail.
• A link that lets a reviewer at Payable open one document: thirty days by default, unless it is revoked or replaced sooner. A used link is revoked, not removed.
• A checkout page a customer opened: thirty minutes, after which it can no longer be paid. The payment record it belongs to stays for the six years.
• Operational service logs: fourteen days. Webhook bodies delivered to the test inbox: seven days.
• An AI agent key: until the end date you set when you issued it, at most one year, or until you revoke it. The record of what the agent asked for and what a person decided is kept with the audit trail.
• A card kept on file: until the customer asks the merchant to remove it, the merchant removes it or the merchant account closes. Payable's own retention applies to the card itself.

When a merchant account closes, what the law requires stays for its period and the rest is deleted. Today there is no self service button for deletion; write to us and we do it by hand, and we confirm when it is done.

• Card data never touches our systems. Cards are entered on Payable's page with 3D Secure.
• Everything travels over TLS. Data at rest is encrypted by the hosting provider, and identity numbers, dates of birth, account numbers and every uploaded document are encrypted a second time under our own key before storage, so a copy of the database or the file store on its own reveals nothing.
• Each merchant's rows are isolated from every other merchant's at the database level, so a query that forgets its scope returns nothing rather than someone else's data.
• Documents are read back only by a signed in member of the merchant with the right role, or through a link issued for a reviewer at Payable that expires, can be revoked, and counts every open.
• Every change to an account is written to an audit trail that the application cannot edit or delete.
• Passwords are hashed; sessions, API keys and one time codes are stored only as digests. A leaked copy of our database yields no usable secret.
• Logs are redacted before they are written: no credential, email address, phone number, identity number, account number or card detail reaches a log.
• Staff reach the operations console only through Cloudflare Access with multi factor authentication, through a read only database role that cannot see credentials or raw identity answers.

No system is perfectly secure. If we learn of a breach that puts you at risk, we tell you and the Data Protection Authority as the PDPA requires.

The Personal Data Protection Act gives you rights over your data. You can ask us:

• To confirm whether we process your data and to give you a copy of it.
• To correct data that is wrong or complete data that is incomplete.
• To erase data, where we are not obliged by law to keep it. Verification and payment records must stay for their retention period; we tell you what we can and cannot erase, and why.
• To withdraw a consent you gave, such as keeping a card on file, without affecting what was done before you withdrew it.
• To object to a use of your data, and to be told the outcome.
• Not to be subject to a decision made solely by automated means that affects you significantly. We make none.

To exercise a right, write to [email protected] from the email address on your account, or through the dashboard. We may ask you to prove who you are, because answering a stranger would itself be a breach. We answer within the period the Act allows and we do not charge for a first request. A customer of a merchant should ask the merchant first, since the merchant holds the customer relationship; where the merchant asks us to act, or the request is about our own records, we act.

The checkout and payment pages of this site use only the cookies and storage below, each of them necessary for the service you asked for. The public pages of this site and the merchant portal also set the analytics and advertising cookies listed after them.

• pl_lang: set only when you choose Sinhala or Tamil, so the portal, which has no language in its address, opens in your language. Kept for one year. Holds the language code and nothing else.
• plk_session: the merchant portal's sign in cookie. A random token, readable by no script, sent only to the portal's own address, valid for thirty days and renewed while you use the dashboard. Deleted when you sign out.
• plk_challenge: while you sign up, sign in or prove a mobile number, a random handle that ties the code you were sent to your browser. Sent only to the sign in routes and gone within thirty minutes.
• The public site's notification strip remembers in your browser's session storage that you dismissed it. The application form keeps a draft of your answers in your browser's local storage until you create an account, so nothing is lost if you close the tab; that draft never leaves your device until you save it.

On the public pages and in the merchant portal Google Tag Manager loads Google Analytics and the Meta Pixel. They set:

• _ga and _ga_MBLNQMCCTG: Google Analytics, on the public pages and in the portal, which share it. A random identifier that tells one browser's visits apart from another's, kept for up to two years.
• _fbp: the Meta Pixel, on the public pages and in the portal, which share it. A random identifier for this browser, which Meta uses to measure and target our advertising, kept for ninety days.

When you arrive through a link that carries campaign tags, this site and the merchant portal also set six cookies of their own, to know which advertisement, email or partner link brought you:

• pl_utm_source, pl_utm_medium, pl_utm_campaign, pl_utm_term, pl_utm_content and pl_other_params: the campaign tags in the address you arrived by (such as utm_source=facebook) and its other parameters, such as an advertising click id. Shared by payments.lk and app.payments.lk, kept for ninety days, and replaced when you next arrive through a tagged link. They never hold your name, your email or anything you type. When you create an account they are copied onto your application, and when you submit it they go to Payable's sales team with it.

You can refuse these cookies by clearing and blocking them in your browser's settings, or with a content blocker. Google offers a browser add-on that turns Google Analytics off, and Meta lets you control ads based on your visits in its ad preferences. Blocking them changes nothing about using the site, the portal or a checkout.

The staff console at ops.payments.lk, which merchants never see, sits behind Cloudflare Access, which sets its own sign in cookies for Payable's staff.

A merchant can give an AI agent, such as an assistant it runs, a key to work in its account through our agent endpoint. Because what an agent reads leaves for a model the merchant does not run, the key is limited in ways you should know about.

• The merchant chooses what the key may do when it is issued: read the account, see customer details, make payment links, prepare refunds. A key without the customer scope sees customers masked: a first name and an initial, an email with its middle hidden, the last four digits of a phone number. Whole names, emails and phone numbers leave only when the merchant deliberately ticked that scope.
• Every key has an end date the merchant sets, at most one year, and can be revoked at any moment.
• An agent cannot move money. It can only prepare a refund, and a person with the right role must approve it in the dashboard within twenty four hours, or it expires. Approval is refused if the key that prepared it has since been revoked.
• Text written by customers, such as an order description or a refund reason, is treated as data, never as an instruction to the agent, and is cleaned and capped before it is shown to the model.
• Every call is written to the audit trail with the tool name and the outcome, never the values.

Payments.lk itself sends no personal data to any AI model. The agent endpoint only answers a merchant's own agent with the merchant's own data.

Payments.lk is for businesses. A person who signs for a business must be an adult under Sri Lankan law, and we do not knowingly hold an account for anyone younger. A merchant is responsible for the age rules that apply to what it sells and to whom. If you believe we hold a child's data by mistake, write to us and we will remove it.

When the platform changes, this policy changes in the same release, and the date at the top moves. A change that reduces your rights or adds a new use of your data is sent by email to every account holder before it takes effect. Earlier versions are available on request.

If you think we have handled your data wrongly, write to [email protected] and say what happened. We acknowledge every complaint and answer it in full. If you are not satisfied, or you prefer to go straight there, you have the right under the PDPA to complain to the Data Protection Authority of Sri Lanka. For the card processing itself, Payable's own complaints route is described in its privacy policy.

Payments.lk, a service offered by Payable (Pvt) Ltd, 4th Floor, Huejay Court, No. 32, Sir Mohamed Macan Marker Mawatha, Colombo 03, Sri Lanka.

Data protection and every other question: [email protected].