Sandbox parent authorization

Question

I am making a game with target aoudence children. There are In-App Purchases in it, so I want to sandbox SKPaymentTransactionState.Deferred. I cannot find a way to du that. Any help will be apreciated.

In-App Purchase

4.9k

Posted by

evgeniyraev

Reply

Add a Comment

Answer 1

With regards to Ask-To-Buy support, there is no support for this function in the Sandbox. “Ask to Buy” is not an API implementation, but a support process implemented by iTunesConnect which requires StoreKit interaction with a specific iTunes account. This support only exists in the production environment. For this process to work in the sandbox environement, ITC would need to implement for test accounts to refer to other accounts to grant approval for purchases. I suggest that you submit an enhancement request - via the Apple Developer bug report web page - http://bugreport.apple.com

The primary reason for wanting this support is to be able to test the “Ask To Buy” purchase process. This makes sense, but I have no way to simulate this process. Instead, I can only advise you that in the “Ask to Buy” scenario - that the application not assume that after a purchase via the addPayment method, that the transaction will be either immediately successful or a failure. Instead, the “Ask to Buy” scenario means that the application won’t know until “later” (which could be hours later) of a formal response.

The simple means to support “Ask to Buy” - call the SKPaymentQueue -addTransactionObserver once in the didFinishLauchingWithOptions delegate method and never call the removeTransactionObserver method - make sure that the observer is always active. When the application is frontmost and the transaction response is available, it will be passed to the updatedTransactions delegate method.

Some additional notes - “Ask to Buy” purchases are only deferred for 24 hours. If the parent does not approve (or fail) the “Ask to Buy” purchase within 24 hours, the app can assume that the transaction will never complete. The application is not notified that the transaction failed due to inaction.

If a user initiates multiple “Ask to Buy” purchase attempts, each new request for the same item, overwrites the previous request and restarts the 24 hour timer. This is to prevent mulltiple purchase requests from accumulating.

The application will receive notice of the approved (or failed transaction if the parent denies the request) using the transactionObserver mechanism. This means that the app must either be re-launched, or moved from the background to the foreground. There is no call to the updatedTrnsaction delegate method if the app is active at the time of purchase approval.

rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI

Posted by

rich

Add a Comment

Answer 2

With regards to Ask-To-Buy support, there is no support for this function in the Sandbox. “Ask to Buy” is not an API implementation, but a support process implemented by iTunesConnect which requires StoreKit interaction with a specific iTunes account. This support only exists in the production environment. For this process to work in the sandbox environement, ITC would need to implement for test accounts to refer to other accounts to grant approval for purchases. I suggest that you submit an enhancement request - via the Apple Developer bug report web page - http://bugreport.apple.com

The primary reason for wanting this support is to be able to test the “Ask To Buy” purchase process. This makes sense, but I have no way to simulate this process. Instead, I can only advise you that in the “Ask to Buy” scenario - that the application not assume that after a purchase via the addPayment method, that the transaction will be either immediately successful or a failure. Instead, the “Ask to Buy” scenario means that the application won’t know until “later” (which could be hours later) of a formal response.

The simple means to support “Ask to Buy” - call the SKPaymentQueue -addTransactionObserver once in the didFinishLauchingWithOptions delegate method and never call the removeTransactionObserver method - make sure that the observer is always active. When the application is frontmost and the transaction response is available, it will be passed to the updatedTransactions delegate method.

Some additional notes - “Ask to Buy” purchases are only deferred for 24 hours. If the parent does not approve (or fail) the “Ask to Buy” purchase within 24 hours, the app can assume that the transaction will never complete. The application is not notified that the transaction failed due to inaction.

If a user initiates multiple “Ask to Buy” purchase attempts, each new request for the same item, overwrites the previous request and restarts the 24 hour timer. This is to prevent mulltiple purchase requests from accumulating.

The application will receive notice of the approved (or failed transaction if the parent denies the request) using the transactionObserver mechanism. This means that the app must either be re-launched, or moved from the background to the foreground. There is no call to the updatedTrnsaction delegate method if the app is active at the time of purchase approval.

rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI

Posted by

rich

Add a Comment

Answer 3

1) do we need to finishTransaction on the deferred purchase?

2) an alternative that is 'better' but not 'best' (pun intended) is to remove the transaction observer and the IAP class and give the user the option of "check for approved IAP'. When selected the app instantiates the IAP class and executes an addTransactionObserver. Then after about 10 seconds if no transaction appears it issues a 'found nothing try again later' alert and removes the transaction observer and releases the IAP class. This 'better but not best approach' avoids this remarkable event: "There is no call to the updatedTrnsaction (sic) delegate method if the app is active at the time of purchase approval" which might be problematic in practice.

Posted by

PBK

Add a Comment

Answer 4

The app does not call finishTransaction on a deferred purchase.

As to the "better" option for checking the deferred purchase. I can see the utility of this mechanism as it forces a check on the store at the time of the call. I would propose the "refinement" that if there is no response, why not leave the observer active.

rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI

Posted by

rkubota

Add a Comment

Answer 5

The documents should indicate somewhere that you do not call finishTransaction in a deferred purchase.

You asked:

>if there is no response, why not leave the observer active.

Because:

>There is no call to the updatedTrnsaction delegate method if the app is active at the time of purchase approval.

Posted by

PBK

Add a Comment

Answer 6

I like this solution of manually re-adding the transaction observer as a way of manually checking if the purchase was approved, but I'm wonder if restoring purchases would achieve the same thing? I'm just hoping to avoid having to have a dedicated "Check for purchase approval" button if possible.

Posted by

JonColverson

Add a Comment

Answer 7

The call to restoreCompletedTransactions may not work since there may not be an actual completed purchase or it may work and be redundant! You see, right after (or before) you call restoreCompletedTransactions you add the transaction observer and that will do the trick. So.......change the "Restore" button to a "Get purchases" button (since the person who is looking for the deferred purchase isn't looking for a "Restore" button and a person who is looking for a "restore" button will tap a "Get purchases" button) and be careful not to respond inappropriately to a duplicate call to updatedTransactions (i.e. one after the add transaction observer and one associated with teh redundant restoreCompletedTransactions).

Posted by

PBK

Add a Comment

Sandbox parent authorization

Accepted Reply

Replies