Add Default environment as Production for AppStoreServerAPIClient.java, for handling production usecase easily

[sagar-rai]

Generally, while integrating the app to the production use case, its better to by default use the production api call and switch the endpoint in case the response code is 4040010. The decoded transaction info will already contain the correct environment, and it will be easier for the end users to integrate the library into their existing code base.

This makes the job for the end backend developer easier, as it will not require them to manually switch the context and they can do the separate processing if required for sandbox account based on the response from the client.

[sagar-rai]

I propose that we add a similar flag while verifying the signed payload using the SignedDataVerifier class, by adding a boolean flag as method param which will enable or disable the environment check atleast in some of the methods like decoding the TransactionInfo, which in general in the production environment will also have some sandbox calls, due to regression/qa testing

if (!this.environment.equals(transaction.getEnvironment())) {
            throw new VerificationException(VerificationStatus.INVALID_ENVIRONMENT);
        }

[alexanderjordanbaker]

@sagar-rai When the app passes signed data to the server, it should also pass the expected environment, negating the need to check which environment is expected. The environment property can be found on-device here https://developer.apple.com/documentation/storekit/transaction/3963920-environment

[sagar-rai]

@alexanderjordanbaker i completely agree with your point, but i think for maintaining the backward compatibility with the older versions of the app which do not send the signed data but the receipt to the backend, which was earlier used in the verifyReceipt endpoint we can add these changes, in case the application is not sending the environment to the backend.

In these cases we can still use the ReceiptUtility class to extract the transaction Id and do the needful backend process, and in my opinion i think it would be better if we could integrate the above mentioned suggestions, else it adds an add on to the developer to integrate extra boilerplate code just for handling the environment

Please feel free to close the issue if you think the change is not needed @alexanderjordanbaker , else i can open a pr regarding the same

[alexanderjordanbaker]

So in this case it is important the developer be involved in this because, as you said, this is a workaround for clients that don't send all the details needed to validate the receipt. It will depend on the developer how they want to handle it and often times the behavior should be different between Sandbox and Production, like Sandbox might grant "fake" content while Production receipts grant the real thing. A single method that just verifies the receipt without regard to the environment might cause mistakes or imply this is a recommended approach