The evening I added Stripe checkout to one of my own sites, the hard part was not the code. Right before publishing, I realized I had not yet decided whether my home address would appear on the disclosure page that Japanese law asks sellers to show.
Code can be fixed a hundred times. A published address, even if you take it down later, tends to linger in search caches. Before you set a price, decide what goes in that field.
If you are building an app with Rork and planning a paid tier for Japanese users, you will probably stand in the same spot. Here is how I read the Consumer Affairs Agency guidance, which fields can be left out, and how I decide as an individual seller.
One caveat first: I am not a lawyer. What follows is what I read on the agency's public pages as of October 2026, plus the order I use in my own work. For your specific case, check with the Consumer Affairs Agency, a consumer center, or a professional.
Fifteen items are listed, and name, address and phone are the ones treated as omittable
The agency's mail-order guide lists what an ad must show: price, payment timing and method, delivery timing, return and cancellation terms, the seller's name, address and phone number, software operating requirements, and the terms of any contract that repeats two or more times, such as a subscription.
What surprised me is how short the omittable list is. In the guide's table, only the name, address and phone number are treated as omittable. Several other fields are explicitly not.
| Field | Can be omitted? | What a solo developer might write |
|---|---|---|
| Seller name | Under conditions | The disclosure-on-request note and a contact point |
| Address | Under conditions | Home address, or a working disclosure process |
| Phone number | Under conditions | Disclosure on request, or a contact number |
| Return and cancellation terms | No | Digital access is non-returnable; how to cancel |
| Terms for repeating contracts | No | Renewal period, next renewal, how to cancel |
| Software operating requirements | No | Minimum supported OS versions |
| Email address | No | An inbox you can always receive at |
So you can decide to keep your address private, but you cannot skip deciding how returns and cancellation are worded. The fields to fill first are the ones that cannot be omitted.
Leaving out your address depends on being able to hand it over promptly
According to the guide, omission is allowed when two things hold: the ad says the details will be provided on request (in writing, or by email for online sales), and you have actually arranged to provide them without delay.
The guide explains that "without delay" means before the buyer decides to apply, and it notes this is hard for short-window transactions. One line saying "available on request" is not enough on its own.
As an individual, I lay out three options and pick the one I would regret least.
| Option | Suits you if | Watch out for |
|---|---|---|
| Publish your home address | You want the least ongoing work | It stays in caches even after removal |
| Disclose on request | You can reply to requests quickly | You need a real inbox and a real process |
| Rent a business address | You do not want your home address public | Check the contract allows use on this page |
The common mistake is choosing disclosure on request without setting up a place to receive requests. Since the email address cannot be omitted anyway, a dedicated support inbox can double as that channel.
Fill the template from the non-omittable fields first
This is the skeleton I write first. The address line changes with the option you chose.
Seller: (name or trade name; or a note that it is disclosed on request)
Address: (your address, or "Provided without delay on request")
Phone: (same as above)
Email: support@example.com
Price: Shown on the in-app purchase screen (tax included)
Payment: At purchase confirmation, via the store's payment method
Delivery: Immediately after payment completes
Returns: Digital content is not returnable after purchase
Cancellation: (steps in the store's subscription management screen)
Requirements: iOS xx or later / Android xx or later
One note on the code block: support@example.com is a placeholder. Do not use an address you might stop receiving at, because the disclosure option stops working the moment mail stops arriving.
In-app purchase only versus your own checkout page changes what you add
Selling only through in-app purchase on the App Store or Google Play is different from running your own checkout, for example with Stripe. The guide asks that the final confirmation screen for online orders show quantity, price, payment timing and method, delivery timing and return terms.
With your own checkout, you build that screen. With in-app purchase only, the store shows the purchase dialog. How the stores treat seller information, such as declarations needed for EU distribution, is a separate matter that you should confirm in Apple's and Google's own documentation. I could not settle that part on my own, so I keep it as a "ask a professional" line in my notes.
For the publishing steps themselves, I keep them in the Apple Developer account walkthrough and the pre-launch revenue checklist.
The order I decide in: returns and cancellation, contact, then address
Put together, my order looks like this.
- Decide the wording for returns and cancellation, the hardest non-omittable field.
- Create an inbox you can always receive at.
- Choose among publishing, disclosure on request, or a separate address.
- Test the chosen option by sending yourself a request.
The last step is worth doing before launch. Email yourself asking for the address and see whether you can answer within half a day. If you cannot, that option does not fit your life, and that is the answer.
Once payments are in and you want to balance ads against subscriptions, I wrote about that in the hybrid revenue model article.
Start today by creating one support inbox. Having a place to receive requests opens up more of the choices on that page, and it is the one order I plan to keep the next time I add a payment.