Add subsc-pay suffix domain

[k-takamori]

Public Suffix List (PSL) Submission

Checklist of required steps

• Description of Organization

• Robust Reason for PSL Inclusion

• DNS verification via dig

• Each domain listed in the PRIVATE section has and shall maintain at least two years remaining on registration, and we shall keep the _psl TXT record in place in the respective zone(s).

Submitter affirms the following:

• We are listing any third-party limits that we seek to work around in our rationale such as those between IOS 14.5+ and Facebook (see Issue #1245 as a well-documented example)

• Cloudflare
• Let's Encrypt
• MAKE SURE UPDATE THE FOLLOWING LIST WITH YOUR LIMITATIONS! REMOVE ENTRIES WHICH DO NOT APPLY AS WELL AS REMOVING THIS LINE!

• This request was not submitted with the objective of working around other third-party limits.

• The submitter acknowledges that it is their responsibility to maintain the domains within their section. This includes removing names which are no longer used, retaining the _psl DNS entry, and responding to e-mails to the supplied address. Failure to maintain entries may result in removal of individual entries or the entire section.

• The Guidelines were carefully read and understood, and this request conforms to them.
• The submission follows the guidelines on formatting and sorting.

• A role-based email address has been used and this inbox is actively monitored with a response time of no more than 30 days.

Abuse Contact: [email protected]

• Abuse contact information (email or web form) is available and easily accessible.

  URL where abuse contact or abuse reporting form can be found: https://www.robotpayment.co.jp/contact/

---

For PRIVATE section requests that are submitting entries for domains that match their organization website's primary domain, please understand that this can have impacts that may not match the desired outcome and take a long time to rollback, if at all.

To ensure that requested changes are entirely intentional, make sure that you read the affectation and propagation expectations, that you understand them, and confirm this understanding.

PR Rollbacks have lower priority, and the volunteers are unable to control when or if browsers or other parties using the PSL will refresh or update.

(Link: about propagation/expectations)

• Yes, I understand. I could break my organization's website cookies and cause other issues, and the rollback timing is acceptable. Proceed anyways.

---

Description of Organization

• ROBOT PAYMENT was founded in 2000 and provides services aimed at solving financial issues for businesses.

Company Overview

• Company Name: ROBOT PAYMENT INC. (株式会社ROBOT PAYMENT)
• Founded: October 2000
• Representative Director: Kenya Kiyoku
• Headquarters: 15th Arai Building 4F, 6-19-20 Jingumae, Shibuya-ku, Tokyo, Japan
• Capital: 222 million yen
• Number of Employees: 118
• Listed Market: Tokyo Stock Exchange Growth Market (Stock Code: 4374)

Business Activities

1. Subscription Pay(サブスクペイ): Automated billing and payment system with cloud-based customer management.
2. Invoice Management Robo(請求管理ロボ): Cloud-based billing and receivables management solution.
3. Delegated Billing Robo(請求まるなげロボ): Intercompany billing delegation service.

Organization Website:
https://www.robotpayment.co.jp/

Reason for PSL Inclusion

Our company provides a service that allows users to create websites using subdomains under a domain we own. For security and privacy protection purposes, we would like this domain to be included in the PSL to prevent cookies from being obtained across the entire domain.

DNS Verification

dig +short TXT _psl.subsc-pay.blog
"https://github.com/publicsuffix/list/pull/2310"

dig +short TXT _psl.subsc-pay.com
"https://github.com/publicsuffix/list/pull/2310"

dig +short TXT _psl.subsc-pay.info
"https://github.com/publicsuffix/list/pull/2310"

dig +short TXT _psl.subsc-pay.net
"https://github.com/publicsuffix/list/pull/2310"

dig +short TXT _psl.subsc-pay.online
"https://github.com/publicsuffix/list/pull/2310"

dig +short TXT _psl.subsc-pay.shop
"https://github.com/publicsuffix/list/pull/2310"

dig +short TXT _psl.subsc-pay.tokyo
"https://github.com/publicsuffix/list/pull/2310"

[wdhdev]

• Expiration (Note: Must STAY >2y at all times)

  • subsc-pay.blog: 2025-05-16T23:59:59.0Z
  • subsc-pay.com: 2025-05-16T08:35:56Z
  • subsc-pay.info: 2025-05-16T08:36:35Z
  • subsc-pay.net: 2025-05-16T08:35:57Z
  • subsc-pay.online: 2025-05-16T23:59:59.0Z
  • subsc-pay.shop: 2025-05-16T23:59:59.0Z
  • subsc-pay.tokyo: 2025-05-16T23:59:59.0Z

• DNS _psl entries (Note: Must STAY in place)

dig +short TXT _psl.subsc-pay.{blog,com,info,net,online,shop,tokyo}
"https://github.com/publicsuffix/list/pull/2310"
"https://github.com/publicsuffix/list/pull/2310"
"https://github.com/publicsuffix/list/pull/2310"
"https://github.com/publicsuffix/list/pull/2310"
"https://github.com/publicsuffix/list/pull/2310"
"https://github.com/publicsuffix/list/pull/2310"
"https://github.com/publicsuffix/list/pull/2310"

• Sorting
• Reasoning/Organization description
• Non-personal email address

---

Notes:

• All your domains must be renewed for > 2 years.
• Please use a non-personal email address as the contact email, such as [email protected].
• Please provide the user count you have, and if possible, please provide it per domain.

[wdhdev]

@k-takamori Are you able to complete the items in the checklist? This is required for your PR to be approved.

If you are not ready to do so, I would suggest moving this to draft status.

[k-takamori]

@wdhdev
Sorry for inconvenience. Now we are ready for registration, so please check this again.

All your domains must be renewed for > 2 years.

updated domains expiration.

Please use a non-personal email address as the contact email, such as [email protected].

[email protected] is not a personal email address.
But is there any rules for the email like must be company contact email and not service contact email and so on.

Please provide the user count you have, and if possible, please provide it per domain.

The current number of users is zero. However, after being listed on the PSL, it is expected that one new user will be added per domain each month.

[wdhdev]

We tend to require 1,000 users before approval.

[k-takamori]

@wdhdev

We tend to require 1,000 users before approval.

Do we need 1,000 customers or endusers?
And this means PSL is not support to register new product?

[wdhdev]

1,000 customers, normally.

And this means PSL is not support to register new product?

Correct.

[k-takamori]

@wdhdev
We understand that 1,000 customers are required, and we have over 1,000 customers our overall products.
Our new product that needs PSL registration currently has 40 existing corporate clients, and we expect to surpass 100 clients next year.
We aim for further expansion in the future, but your support is absolutely essential for that to happen.
Could you please grant us permission somehow?

[wdhdev]

We normally require 1,000 customers on the specific service being applied for.

We rarely ever grant exceptions unfortunately.

[simon-friedberger]

We do support new products although we generally like to wait until a service has at least some users and shows growth.

Note that, for new services, you can get some of the benefits of being on the PSL by only using __Host- cookies.

In this particular case it is concerning that you are requesting seven entries while expecting a growth of one user per month. At that size you can just register individual domains for all your users.

[k-takamori]

Thank you for your support.
I will try __Host- cookies, and if our service is grown up, I will make request again.
I"m gonna close this PR anyway.

[k-takamori]

@wdhdev , @simon-friedberger
I am reaching out to clarify a misunderstanding in the information I shared with you previously.

Earlier, I mentioned that "our overall product has over 1,000 customers, and our new product already has 40 customers." However, the "new product" I referred to at that time actually referred to a new edition of our existing product, "Subscription Pay."

In reality, the entire "Subscription Pay" product has 8,350 customers (https://ssl4.eir-parts.net/doc/4374/tdnet/2528411/00.pdf) , which we believe aligns with the rules of your service.
Please kindly approve the addition to PSL.

Thank you very much for your attention and support.

[simon-friedberger]

@k-takamori Would it be possible to reduce the number of domains? Why are there so many different ones?

[fakeboboliu]

In reality, the entire "Subscription Pay" product has 8,350 customers (https://ssl4.eir-parts.net/doc/4374/tdnet/2528411/00.pdf) , which we believe aligns with the rules of your service.

There could be 8350 customers, but there're no other evidence.
For all your domains, subdomain finder shows only one subdomain observable from the public network: test01.subsc-pay.net.
Are your domains really "public suffix"?

I think it's normal for a new product to join the list, and it's okay to overstate product's user count / try to include an internal only domain in PSL. But it's pretty refreshing to me to see all these in one single PR.

[simon-friedberger]

I think some example pages from the current service would be good to help us understand what you are trying to do here.

[k-takamori]

Why are there so many different ones?

Our company offers a no-code website creation service as part of the subscription payment options. However, when customers try to acquire their own domains, the process tends to be complicated and time-consuming, which poses several challenges.
To address this issue, we aim to provide an option where customers can select from multiple pre-acquired domains and set their desired subdomain. This approach simplifies the process for customers, reduces their burden, and shortens lead times.
However, simply offering subdomains to customers introduces the risk of other customers' domain information being exposed. To mitigate this risk, we plan to register these domains with the Public Suffix List (PSL), ensuring better security and protecting customer information between subdomains.

Are your domains really "public suffix"?

Once the registration with the Public Suffix List (PSL) is approved, we will start offering our domain usage service and register them as public suffixes.

I think some example pages from the current service would be good to help us understand what you are trying to do here.

Here are the demo images of the website created using our service, along with a flowchart image showing whether domain services are included. Please review them.

[groundcat]

My concerns:

• The PR claims 8,350 customers for the Subscription Pay product, but there is only one observable subdomain (test01.subsc-pay.net) across all 7 requested domains. Additionally, it is requesting 7 different TLDs (.blog,.com,.info,.net,.online,.shop,.tokyo) without any current usage, which appears excessive for a new service.

Once the registration with the Public Suffix List (PSL) is approved, we will start offering our domain usage service and register them as public suffixes.

• This looks to reverse the intended workflow—domains should demonstrate genuine public suffix usage before PSL inclusion, not after.
• As @simon-friedberger proposed, the security use case might be solved by __Host- cookies. @k-takamori Are you able to mitigate the risk using this approach?
• Although you have supplied business documentation and DNS verification, there has been no direct confirmation of your capacity to represent ROBOT PAYMENT INC. @k-takamori Please send an email from your @robotpayment.co.jp address to a maintainer (e.g.,simon at mozilla.com) to confirm your affiliation with ROBOT PAYMENT INC.

Our company offers a no-code website creation service as part of the subscription payment options. However, when customers try to acquire their own domains, the process tends to be complicated and time-consuming, which poses several challenges.
To address this issue, we aim to provide an option where customers can select from multiple pre-acquired domains and set their desired subdomain. This approach simplifies the process for customers, reduces their burden, and shortens lead times.
However, simply offering subdomains to customers introduces the risk of other customers' domain information being exposed. To mitigate this risk, we plan to register these domains with the Public Suffix List (PSL), ensuring better security and protecting customer information between subdomains.

Could you explain what you mean by "domain information being exposed" between customers? I know you may have used AI to generate your answers - I'm not against it - but please use it as a translation tool rather than a writing tool, as it tends to overgeneralize instead of providing specific technical details that you could have provided. What we need is: what specific “domain information” you're concerned, why you need 7 different TLDs (.blog, .com, .info, .net, .online, .shop, .tokyo) rather than starting with one, why using __Host- cookies would not meet your security requirements in this case, and how many current users are actually using or would use subdomains across these 7 specific domains (not just total company customers). Please focus on technical specifics rather than marketing or general business descriptions.

[k-takamori]

As @simon-friedberger proposed, the security use case might be solved by __Host- cookies. @k-takamori Are you able to mitigate the risk using this approach?

No, we aren't.
We are using PaaS to serve the web pages, and it does not support setting __Host- cookies.

Although you have supplied business documentation and DNS verification, there has been no direct confirmation of your capacity to represent ROBOT PAYMENT INC. @k-takamori Please send an email from your @robotpayment.co.jp address to a maintainer (e.g.,simon at mozilla.com) to confirm your affiliation with ROBOT PAYMENT INC.

Is the email address correct that local part is 'simon' and domain part is 'mozilla.com'?

Could you explain what you mean by "domain information being exposed" between customers?

We are planning to provide different websites under subdomains using a multi-tenant approach. In this case, if domain isolation is not properly implemented, we understand that there is a risk of cookie leakage between sites and potential threats such as XSS.

why you need 7 different TLDs (.blog, .com, .info, .net, .online, .shop, .tokyo) rather than starting with on

We are planning to our customer to choose one or more from those domains.

how many current users are actually using or would use subdomains across these 7 specific domains (not just total company customers)

Current user is 0.
We are assuming that 10% of the customers will use this option, and that at least one customer will increase each month.

[wdhdev]

We tend to not accept services with < 1,000 users. It is extremely unlikely this will be approved.

[mozfreddyb]

This discussion seems to be a pile-on for the "how many users" discussion, I don't think this needs to be echoed by every contributor. The fact that Robot Payments is a company listed at the tokyo stock exchange with a lot of customers makes it pretty unrealistic for us to demand any kind of validation. I agree that it's icky to have so many domains for one new service, but I don't think we've had rules for that until now. If we want to set those, we shouldn't set them for this one particular request but for all entries.

[simon-friedberger]

@k-takamori Could you maybe reduce the number of domains to one or two?

[k-takamori]

@simon-friedberger
I send email and reduce domains.
Could you check this again?