> For the complete documentation index, see [llms.txt](https://developers-apps-in-toss.toss.im/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developers-apps-in-toss.toss.im/landing-page/landing-page-en/checklist/app-nongame.md). # Non-Game Release Guide These are the common standards and feature-specific release guidelines for mini apps. Before release, be sure to review the content and follow the guide. If the checklist below is not followed or dark patterns are found, the review will not be approved, and even if they are found after release, service exposure may be restricted or suspended. {% hint style="info" %} **Please note** The items in the release guide below are continuously being updated. {% endhint %} ### Access and in-app features * [ ] The mini app opens normally. * [ ] All service features introduced as “in-app features” can be used in the mini app in the same way. * [ ] The scheme registered under “in-app features” connects normally. * [ ] After entering through the app scheme, the back button works properly. ### Navigation bar * [ ] The Apps in Toss navigation bar is being used. * [ ] If the back button is displayed, it works properly on all screens. * [ ] If the app name and logo are displayed in the navigation bar, use the brand logo registered in app info and the mini app name (Korean). * [ ] If the home button is displayed, it works properly. (Optional) * [ ] Only up to one mini app feature button is displayed. (Optional) * [ ] The Toss navigation bar back button and the mini app’s own back button are not shown at the same time. * [ ] The Toss common features in the more button (⋯), such as report and share, are provided properly. * [ ] The close button and back button are displayed, and their behavior is clear. * [ ] When you press back on the initial screen, the mini app exits. ### Issuance of user identification key * [ ] The user identifier value is checked and stored, and the mini app starts normally. * [ ] The user’s mini app usage history is preserved. * [ ] Even if the mini app is closed and accessed again, the necessary data is preserved. ### Security and stability * [ ] Functions that execute code received from outside cannot be used. (e.g., `eval` etc.) * [ ] You cannot move to or render content from your own site (outside the Toss domain) in any way, such as by manipulating browser history or embedding a web view. The content ultimately displayed must be rendered within the Toss domain. (e.g., `window.location.replace`, nested WebView/iframe loading your own domain, etc.) * [ ] Server-side rendering (SSR) cannot be used. Only client-side rendering (CSR) or static site generation (SSG) may be used. * [ ] If you use WebSocket, only encrypted `wss://` connections are allowed. (e.g., Firebase Firestore, Supabase Realtime, etc.) * [ ] API communication must use only encrypted HTTPS connections. * [ ] Sensitive information such as user login information and payment records (Toss Pay, in-app payment) must be encrypted and stored in the DB. * [ ] It is also recommended to encrypt personal information when sending it from the client to your own server. ### Service usage behavior * [ ] When the Android system back button is pressed, it goes back or the mini app exits. * [ ] Except when absolutely necessary, such as for maps, gesture-based zoom in/out is disabled. * [ ] The mini app theme is implemented in light mode. * [ ] All UI components behave as intended. * [ ] Interaction responses such as scrolling, touching, and screen transitions are not delayed by 2 seconds or more. * [ ] Even if you exit the mini app and re-enter, the necessary data is preserved. * [ ] External links that are essential for using the service open properly. * [ ] In the share feature, `intoss-private://` do not use links, and `intoss://` use the scheme. * [ ] The mini app copy does not contain profanity, slang, or excessive buzzwords. * [ ] It does not contain illegal content such as unlawful or sexual content. * [ ] Device permissions such as location and notifications are requested only after user consent is obtained. * [ ] Even if the user does not allow permissions, the remaining features continue to work properly. * [ ] Network usage does not increase abnormally. * [ ] Memory usage does not increase abnormally. ### UX * [ ] A bottom sheet (Toss Login, notification consent, etc.) does not appear automatically as soon as you enter the mini app. * [ ] Do not force the user’s actions through a bottom sheet during specific screen transitions. * [ ] On every screen, it is clear how the user can leave the mini app. * [ ] By looking at the CTA button, users can predict what action will happen next. * [ ] Do not guide users to your own service or to install your own app through links or components. * [ ] In-app ads are not shown on temporary screens such as intros, loading screens, cutscenes, or popup modals. * [ ] Do not mislead or force users to click in-app ads. ### Toss Login * [ ] If you use Toss Login, provide a service description on the intro page so users can understand what the service is. * [ ] The Toss Login terms screen URL you set is displayed properly. * [ ] If you disconnect login linkage in the Toss app and then access the mini app again, the terms screen requesting login again is displayed. * [ ] When login linkage is disconnected in the Toss app, user data is not left in the mini app. * [ ] Do not provide your own login or any other login method instead of Toss Login. ### In-app payment * [ ] When an in-app payment is in progress, the music playing in the mini app is paused. * [ ] The in-app payment order amount matches the amount shown in the Google or Apple payment window. * [ ] In-app payment proceeds normally. Also verify it in the Google payment test environment. * [ ] When you return to the mini app after the in-app payment is completed, the payment result is reflected properly. * [ ] If you select Cancel in the in-app payment window, you return to the order screen. * [ ] If payment fails due to insufficient balance, users can understand the reason for the failure. * [ ] In-app payment cancellation is processed properly. * [ ] Users can check the payment history for in-app payment products. * [ ] Even if you change the device logged into the Toss app, previously purchased in-app payment data (such as passes) is preserved. ### Toss Pay * [ ] When you proceed with Toss Pay simple payment, the music playing in the mini app is paused. * [ ] The order amount matches the amount shown in the Toss Pay payment window. * [ ] If Toss Pay payment fails, an error message is displayed and users can understand the reason for the failure. * [ ] If you select Cancel just before Toss Pay payment, you return to the previous screen. * [ ] No other payment methods besides Toss Pay are provided. * [ ] If you select Cancel in the Toss Pay payment window, you move to the order screen. ### In-app ads * [ ] When an in-app ad plays, the music playing in the mini app is paused. * [ ] Comply with the Toss Ads SSP policy. ([#](https://developers-apps-in-toss.toss.im/documentation/common/monetization/iaa/interstitial-rewarded-ad#policy)) * [ ] Real in-app ads, not test ads, are displayed properly, and there is no interruption or crashing in the middle. * [ ] Do not show in-app ads at moments users would not expect. * [ ] In-app ads are displayed properly, and there is no interruption or crashing in the middle. * [ ] In-app ads are preloaded. They are not loaded in real time at the time the ad plays. * [ ] When the in-app ad ends, you return to the mini app screen normally. * [ ] After the in-app ad ends, the mini app music plays again. * [ ] If a reward ad is watched to the end, the reward is provided properly. * [ ] Banner ads are displayed in appropriate positions. (top/center/bottom) * [ ] Banner ads are shown only on scrollable screens. ### Share reward * [ ] The configured share reward screen is displayed properly. * [ ] When the share reward screen is closed, you return to the mini app screen normally. * [ ] When a friend invitation is completed, the reward is provided properly. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://developers-apps-in-toss.toss.im/landing-page/landing-page-en/checklist/app-nongame.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.