11.1 E-Commerce Items: General

11.1.1 Prohibition Against Creating Independent Platforms

As a basic rule, it is prohibited to use add-on content features to create an independent platform within your software. Specifically, this refers to cases such as the following:

  • Providing a portal service and gathering content for sale on said service (content aggregation or similar services).
  • Selling other applications or products as add-on content within your software (emulators or similar).
  • Selling virtual currency within your application and making said currency usable as payment for services outside of Nintendo platforms.

Contact Nintendo at support@noa.com in advance if you are considering supporting the sale of content that could potentially fit the descriptions above.

11.1.1.1 Handling Prohibition Against Creating Independent Platforms

Guideline Item
The application must not support the sale of content or services that lead to creating an independent platform.
Software to Be Tested
Applications that support the sale of e-commerce items.
Test Method
Check the content of the e-commerce item(s).
Pass/Fail Determination
Passes if the application does not support the sale of content or services that lead to creating an independent platform.

11.1.2 Restrictions on Using Functions that Entail Server Access

Some EC library functions communicate with the Nintendo eShop server when they are called. Calling these functions excessively increases the load on the Nintendo eShop server, and could prevent the server from providing stable network services. Though Nintendo sets no restrictions on the exact frequency of calls to EC library functions, be aware of the following requirements.

As much as possible, avoid specifications that start communicating with the Nintendo eShop server without a corresponding user operation (such as applications that automatically call the nn::ec::CTR::EcApplet::RequestInitializeSession function upon startup).

In particular, if the nn::ec::CTR::EcApplet::RequestInitializeSession function fails, it is prohibited to periodically re-execute this function without a corresponding user operation. After the nn::ec::CTR::EcApplet::RequestInitializeSession function succeeds once, subsequent calls return success without communicating with the Nintendo eShop server. But if the nn::ec::CTR::EcApplet::RequestInitializeSession function fails, calling it again does trigger communication. This means that repeated, frequent failure of this function increases the load on the Nintendo eShop server. It is not a problem if your application calls the nn::ec::CTR::EcApplet::RequestInitializeSession function in response to a user operation to enter or exit an in-game purchase flow.

11.1.2.1 Prohibition of Automatically Retrying Login to the Nintendo eShop Server

Guideline Item
When the nn::ec::CTR::EcApplet::RequestInitializeSession function fails, the application must not periodically execute it again without a corresponding user operation.
Software to Be Tested

Applications that use the nn::ec::CTR::EcApplet::RequestInitializeSession function.

Test Method
  1. Proceed to a scene where the nn::ec::CTR::EcApplet::RequestInitializeSession function is called, then go to Account Developer Portal and configure settings so that the nn::ec::CTR::EcApplet::RequestInitializeSession function will return an error.
  2. Leave the application idle for a short time. (See Note.)
  3. On Account Developer Portal, configure to return a different error from nn::ec::CTR::EcApplet::RequestInitializeSession, and repeat steps 1 through 2.

Note: If an error is displayed, go ahead and close the error dialog box.

Pass/Fail Determination
Passes if in step 2, the nn::ec::CTR::EcApplet::RequestInitializeSession function is not called automatically and periodically (that is, the EC applet does not launch automatically and periodically).

 


CONFIDENTIAL