Deprecated verifyreceipt appstore

[jasonbronson]

Are you still maintaining this package and plan to upgrade this to use the newer methods that Apple has in the API docs?

[https://developer.apple.com/documentation/appstoreserverapi/generating_tokens_for_api_requests ](generate api tokens)

[https://developer.apple.com/documentation/appstorereceipts/verifyreceipt](old method)

[richzw]

@jasonbronson , this package is still maintained and the app store server API is supported in this package.

Please refer to https://github.com/awa/go-iap#in-app-store-server-api

import(
    "github.com/awa/go-iap/appstore/api"
)

//  For generate key file and download it, please refer to https://developer.apple.com/documentation/appstoreserverapi/creating_api_keys_to_use_with_the_app_store_server_api
const ACCOUNTPRIVATEKEY = `
    -----BEGIN PRIVATE KEY-----
    FAKEACCOUNTKEYBASE64FORMAT
    -----END PRIVATE KEY-----
    `
func main() {
    c := &api.StoreConfig{
        KeyContent: []byte(ACCOUNTPRIVATEKEY),  // Loads a .p8 certificate
        KeyID:      "FAKEKEYID",                // Your private key ID from App Store Connect (Ex: 2X9R4HXF34)
        BundleID:   "fake.bundle.id",           // Your app’s bundle ID
        Issuer:     "xxxxx-xx-xx-xx-xxxxxxxxxx",// Your issuer ID from the Keys page in App Store Connect (Ex: "57246542-96fe-1a63-e053-0824d011072a")
        Sandbox:    false,                      // default is Production
    }
    originalTransactionId := "FAKETRANSACTIONID"
    a := api.NewStoreClient(c)
    query := &url.Values{}
    query.Set("productType", "AUTO_RENEWABLE")
    query.Set("productType", "NON_CONSUMABLE")
    ctx := context.Background()
    responses, err := a.GetTransactionHistory(ctx, originalTransactionId, query)

    for _, response := range responses {
        transantions, err := a.ParseSignedTransactions(response.SignedTransactions)
    }
}

Other app store server APIs for version 1.8 has been added to this package. If you have any questions please let me know.

[Daydaylw3]

hi @richzw , it seems that in VerifyReceipt, your api can auto switch sandbox and production. But new api doesn't? Is there any best practise recommend to use if I don't know transactionId is from sandbox or production?

[richzw]

hi @richzw , it seems that in VerifyReceipt, your api can auto switch sandbox and production. But new api doesn't? Is there any best practise recommend to use if I don't know transactionId is from sandbox or production?

One option is that create two app store API servers one enabling sandbox and the other disabling sandbox (aka production), then you could verify the transactionid one by one.

In the test environment, you could call the enabling sandbox API first. And in the production environment, you could call the disabling sandbox first.

[Daydaylw3]

One option is that create two app store API servers one enabling sandbox and the other disabling sandbox (aka production), then you could verify the transactionid one by one.

In the test environment, you could call the enabling sandbox API first. And in the production environment, you could call the disabling sandbox first.

okay, I get it. Just wonder why not like this https://github.com/awa/go-iap/blob/34bac7bd12d3cd730081d27a5cb2556b5947a153/appstore/validator.go#L167C2-L167C2

[richzw]

One option is that create two app store API servers one enabling sandbox and the other disabling sandbox (aka production), then you could verify the transactionid one by one. In the test environment, you could call the enabling sandbox API first. And in the production environment, you could call the disabling sandbox first.

okay, I get it. Just wonder why not like this https://github.com/awa/go-iap/blob/34bac7bd12d3cd730081d27a5cb2556b5947a153/appstore/validator.go#L167C2-L167C2

As far as I know, no such code 21007 indicates this transaction is a sandbox in the server API. Please correct me if I am wrong or missing something.

[Daydaylw3]

One option is that create two app store API servers one enabling sandbox and the other disabling sandbox (aka production), then you could verify the transactionid one by one. In the test environment, you could call the enabling sandbox API first. And in the production environment, you could call the disabling sandbox first.

okay, I get it. Just wonder why not like this https://github.com/awa/go-iap/blob/34bac7bd12d3cd730081d27a5cb2556b5947a153/appstore/validator.go#L167C2-L167C2

As far as I know, no such code 21007 indicates this transaction is a sandbox in the server API. Please correct me if I am wrong or missing something.

I get your point. The most likely description is this:

If you don’t have environment information, follow these steps:

Call the endpoint using the production URL. If the call succeeds, the original transaction identifier belongs to the production environment.

If you receive an [errorCode 4040005] with errorMessage as OriginalTransactionIdNotFoundError, (or HTTP response code 404 from the Send Consumption Information endpoint), call the endpoint using the sandbox environment.

If the call succeeds, the original transaction identifier belongs to the sandbox environment. If the call fails with the same error code, the original transaction identifier isn’t present in either environment.

But as my demo, if I get transaction info for a sandbox tid to prod, I will return errorCode: 4040010, errorMessage: Transaction id not found. actually

So maybe you are right. But I will ask for some help from apple forums.

Thank you for your response, helps a lot!! :)

[richzw]

@Daydaylw3 , thank you very much for your information

If you receive an [errorCode 4040005] with errorMessage as OriginalTransactionIdNotFoundError, (or HTTP response code 404 from the Send Consumption Information endpoint), call the endpoint using the sandbox environment.

Could you please update this line, when you got any response from Apple forums about your issue?

[Daydaylw3]

Could you please update this line, when you got any response from Apple forums about your issue?

Of course I will :)

[Daydaylw3]

@richzw In this post apple declare very clear, hope it will be helpful

[richzw]

@richzw In this post apple declare very clear, hope it will be helpful

Thank you very much for your reply. We could rely on this error code TransactionIdNotFoundError to distinguish whether the receipt is the sandbox or not.