> 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 launch guidelines for mini apps. Please be sure to review the contents and follow the guidelines before launching. {% hint style="info" %} **Please note** The items in the launch guidelines below are continuously being updated. {% endhint %} ### Access and In-App Features * [ ] The mini-app opens properly. * [ ] All service features guided as 'in-app features' can also be used the same way in the mini-app. (#) * [ ] The scheme registered under 'in-app features' connects properly. * [ ] After entering through the app scheme, the back button works properly. (#) ### Navigation Bar * [ ] You are using the App in Toss non-game navigation bar. (#) * [ ] \[Left] The back button (<) works properly on all screens. (#) * [ ] \[Center] The brand logo registered in app information and the mini-app name (Korean) are displayed in the navigation bar. (#) * [ ] \[Center] The home button works properly. (Optional) (#) * [ ] \[Right] Only one mini-app function button is shown at most. (Optional) (#) * [ ] The back button in the Toss navigation bar and the back button implemented by the mini-app do not appear at the same time. (#) * [ ] The More button (⋯) properly provides Toss common features such as report and share. (#) * [ ] The close button and back button are shown, and their behavior is clear. * [ ] When you tap back on the first screen, the mini-app closes. * [ ] If a tab bar is used, it is implemented in the same floating form as in the Toss app. (#) ### User identifier issuance * [ ] The user identifier value is checked and stored, and the mini-app starts properly. (#) * [ ] The user's mini-app usage history is preserved. (#) * [ ] Even if you exit and re-enter the mini app, the required data is maintained. (#) ### Security and stability * [ ] Features that execute code received from outside cannot be used. (e.g.: `eval` etc.) * [ ] Methods that manipulate browser history to redirect to your own site cannot be used. (e.g.: `window.location.replace` etc.) * [ ] Server-side rendering (SSR) cannot be used. Only client-side rendering (CSR) or static site generation (SSG) methods can be used. * [ ] If using WebSocket, use only encrypted `wss://` connections. (e.g.: Firebase Firestore, Supabase Realtime, etc.) * [ ] API communication uses only encrypted HTTPS connections. * [ ] Sensitive information such as user login information and payment details (Toss Pay, in-app purchases) must be encrypted and stored in the DB. * [ ] We also recommend encrypting personal information when transmitting it from the client to your own server. ### Service usage behavior * [ ] Except where strictly necessary, such as for maps, gesture-based zoom in/out is disabled. (#) * [ ] The mini-app theme is implemented in light mode. * [ ] All UI components work as intended. * [ ] Interaction responses such as scrolling, touch, and screen transitions are not delayed by 2 seconds or more. (#) * [ ] Even if you close the mini-app and come back, the necessary data is preserved. (#) * [ ] External links that are essential for using the service open properly. (#) * [ ] In the share feature `intoss-private://` without using a link `intoss://` use the scheme. (#) * [ ] Mini-app text does not include profanity, slang, or excessive trendy expressions. (#) * [ ] Use a TDS modal when user guidance or confirmation is needed. * [ ] It does not contain illegal content such as unlawful or sexual content. * [ ] In React Native apps, user consent is obtained before requesting permissions. (#) * [ ] Even if the user does not grant permission, the remaining features continue to work properly. * [ ] Network usage does not spike abnormally. * [ ] Memory usage does not spike abnormally. ### UX * [ ] A bottom sheet does not automatically open as soon as you enter the mini-app. (#) * [ ] The user's actions are not forced into 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, you can predict what action will happen next. (#) * [ ] It does not guide users to move to the company’s own service or install the company’s app through links or components. (#) * [ ] In-app ads are not shown on temporary screens such as intro/loading/cutscene/pop-up modals. (#) ### Toss Login * [ ] When using Toss Login, provide a service description on the intro page so users can tell what kind of service it is. (#) * [ ] The configured Toss Login terms screen URL is displayed properly. (#) * [ ] If the user selects Close on the screen requesting Toss Login, the mini-app closes. (#) * [ ] If you disconnect the login connection in the Toss app and then access the mini-app again, the terms screen requesting login appears again. * [ ] If the login connection is disconnected in the Toss app, user data is not left in the mini-app. (#) * [ ] Do not provide your own login or other login methods instead of Toss Login. ### In-app purchases * [ ] When proceeding with an in-app purchase, the music playing in the mini app is paused. * [ ] The in-app purchase order amount matches the amount shown in the Google or Apple payment window. (#) * [ ] In-app purchases proceed normally. Also verify in the Google payment test environment. * [ ] After an in-app purchase is completed and you return to the mini app, the purchase result is reflected properly. * [ ] If you select Cancel in the in-app purchase window, you return to the order screen. * [ ] When a payment fails due to insufficient balance, etc., the user can understand the reason for the failure. * [ ] In-app purchase cancellations are handled properly. * [ ] The user can view the payment history for in-app purchase products. * [ ] Even if the device logged into the Toss app is changed, previously purchased in-app purchase data (such as passes) is preserved. (#) ### Toss Pay * [ ] When proceeding with Toss Pay quick 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 shown so the user can understand the reason for the failure. (#) * [ ] If you select Cancel right before Toss Pay payment, it returns to the previous screen. * [ ] No payment methods other than 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 is played, the music playing in the mini app is paused. * [ ] In-app ads are not shown at moments that are difficult for users to anticipate. (#) * [ ] In-app ads are displayed properly, with no premature termination or crashing in the middle. * [ ] In-app ads are preloaded. They are not loaded in real time at the moment of playback. (#) * [ ] 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 you watch a rewarded ad to the end, the reward is granted properly. (#) * [ ] Banner ads are shown in appropriate positions. (top/center/bottom) (#) * [ ] Banner ads are shown only on screens that can be scrolled. (#) ### Share rewards * [ ] The configured share rewards screen is displayed properly. (#) * [ ] When you close the share rewards screen, you return to the mini app screen normally. * [ ] When inviting a friend is completed, the reward is granted 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.