I'm close to go crazy about this...
I'm using nativescript for an app with an auto-renewable inAppPurchase.
It is a new release, so neither the new app nor the inAppPurchase product went through the review process. I think maybe this is the problem? I thought I'd be able to sandbox-test the iap even when they haven't been reviewed, yet?
I'm able to purchase the product with my sandbox-tester-account (at least, I get the purchase screen, can hit buy and when I load the receipt using NSData.dataWithContentsOfURL(NSBundle.mainBundle.appStoreReceiptURL) it seems I get a valid receipt (and I get the base64-encoded string like this:
However, when I try to validate the purchase with https://sandbox.itunes.apple.com/verifyReceipt, I always get a 21002 result, meaning there's something wrong with the payload (I'm doing it from my server with a CURL-Request).
Furthermore, the SKPaymentQueue is accumulating more and more entries. And yes, I'm finishing the transaction every time.
This is the console-output:
The 3 seems to mean that the transation has been restored.
Every time I call the history, there's one more transaction in the queue. Why???
The receipt itself looks a little weird, too (not what I'd expect form a base64-encoded string:
And yes, I tried to replace + signs with %2B.
Especially the last part (<\M-b\M^@\M-&>) looks weird. I tried to remove that from the string, but I still get the 21002.
Any ideas what I'm doing wrong?
I'm using nativescript for an app with an auto-renewable inAppPurchase.
It is a new release, so neither the new app nor the inAppPurchase product went through the review process. I think maybe this is the problem? I thought I'd be able to sandbox-test the iap even when they haven't been reviewed, yet?
I'm able to purchase the product with my sandbox-tester-account (at least, I get the purchase screen, can hit buy and when I load the receipt using NSData.dataWithContentsOfURL(NSBundle.mainBundle.appStoreReceiptURL) it seems I get a valid receipt (and I get the base64-encoded string like this:
Code Block receiptData.base64EncodedStringWithOptions(0);
However, when I try to validate the purchase with https://sandbox.itunes.apple.com/verifyReceipt, I always get a 21002 result, meaning there's something wrong with the payload (I'm doing it from my server with a CURL-Request).
Furthermore, the SKPaymentQueue is accumulating more and more entries. And yes, I'm finishing the transaction every time.
This is the console-output:
Code Block New transaction added to queue <SKPaymentTransaction: 0x283308250> New transaction added to queue <SKPaymentTransaction: 0x2833082b0> New transaction added to queue <SKPaymentTransaction: 0x2833082d0> CONSOLE LOG file: node_modules/nativescript-in-app-purchase/in-app-purchase.ios.js:219:0 ## Update transaction: com.myapp.purchase.appsubscription:Restored 3 CONSOLE LOG file: node_modules/nativescript-in-app-purchase/in-app-purchase.ios.js:219:0 ## Update transaction: com.myapp.purchase.appsubscription:Restored 3 CONSOLE LOG file: node_modules/nativescript-in-app-purchase/in-app-purchase.ios.js:219:0 ## Update transaction: com.myapp.purchase.appsubscription:Restored 3 CONSOLE LOG file: app/user-module/in-app-purchase.js:62:0 history-result <SKPaymentTransaction: 0x283308250> CONSOLE LOG file: node_modules/nativescript-in-app-purchase/in-app-purchase.ios.js:247:0 ## finished transaction state: 3 - product: com.myapp.purchase.appsubscription CONSOLE LOG file: app/user-module/in-app-purchase.js:62:0 history-result <SKPaymentTransaction: 0x2833082b0> CONSOLE LOG file: node_modules/nativescript-in-app-purchase/in-app-purchase.ios.js:247:0 ## finished transaction state: 3 - product: com.myapp.purchase.appsubscription CONSOLE LOG file: app/user-module/in-app-purchase.js:62:0 history-result <SKPaymentTransaction: 0x2833082d0> CONSOLE LOG file: node_modules/nativescript-in-app-purchase/in-app-purchase.ios.js:247:0 ## finished transaction state: 3 - product: com.myapp.purchase.appsubscription
The 3 seems to mean that the transation has been restored.
Every time I call the history, there's one more transaction in the queue. Why???
The receipt itself looks a little weird, too (not what I'd expect form a base64-encoded string:
Code Block MIIXPgYJKoZIhvcNAQcCoIIXLzCCFysCAQExCzAJBgUrDgMCGgUAMIIG3wYJKoZIhvcNAQcBoIIG0ASCBswxggbIMAoCAQgCAQEEAhYAMAoCARQCAQEEAgwAMAsCAQECAQEEAwIBADALAgELAgEBBAMCAQAwCwIBDwIBAQQDAgEAMAsCARACAQEEAwIBADALAgEZAgEBBAMCAQMwDAIBCgIBAQQEFgI0KzAMAgEOAgEBBAQCAgDNMA0CAQ0CAQEEBQIDAiRwMA0CARMCAQEEBQwDMS4wMA4CAQkCAQEEBgIEUDI1NjAPAgEDAgEBBAcMBTMuMC4xMBgCAQQCAQIEELHtwPOBnT9l2uid8M6zbrIwGwIBAAIBAQQTDBFQcm9kdWN0aW9uU2FuZGJveDAcAgEFAgEBBBR0yTwTx3fhZR7bL9hzPkr4vfFJkjAdAgECAgEBBBUME2NoLmt0aXBwLlRlc3RzaWVnZXIwHgIBDAIBAQQWFhQyMDIxLTAyLTEwVDE0OjA5OjQ3WjAeAgESAgEBBBYWFDIwMTMtMDgtMDFUMDc6MDA6MDBaMEICAQcCAQEEOpa2Bz8ZqoL6mkLilpsKVJOcuAowUgcUilsMVCxHob0F3DawnKv/WTiuK7HR9CkFLNCBsvbel7YaHTYwUgIBBgIBAQRKlCTXAynkb9XDoh5OjDmLSJZBvI5u8y2EwCoZ2DB31JNHjLIHIIOpQ+50FsAr7DoDA29naTn3m1wjfOjHW+fNRfed6WCe8NKIl3cwggGUAgERAgEBBIIBijGCAYYwCwICBq0CAQEEAgwAMAsCAgawAgEBBAIWADALAgIGsgIBAQQCDAAwCwICBrMCAQEEAgwAMAsCAga0AgEBBAIMADALAgIGtQIBAQQCDAAwCwICBrYCAQEEAgwAMAwCAgalAgEBBAMCAQEwDAICBqsCAQEEAwIBAzAMAgIGrgIBAQQDAgEA<\M-b\M^@\M-&>
And yes, I tried to replace + signs with %2B.
Especially the last part (<\M-b\M^@\M-&>) looks weird. I tried to remove that from the string, but I still get the 21002.
Any ideas what I'm doing wrong?
