2012-09-11 22 views
6

Mam zakup w aplikacji, dla którego chcę zweryfikować pokwitowanie sklepu. Chciałbym to sprawdzić na losowej maszynie w Internecie za pomocą interfejsu API iTunes firmy Apple. Paragon jest przechowywany w Parse po zakończeniu transakcji. Podążam za przewodnikiem po numerze Apple developer website. Po pierwsze mam transakcję z Parse:IllegalStateException podczas używania Curl do sprawdzenia odbioru App Store?

curl -X GET \ 
    -H "X-Parse-Application-Id: [...]" \ 
    -H "X-Parse-REST-API-Key: [...]" \ 
    https://api.parse.com/1/classes/Transactions/123456789 

który wygląda następująco:

{ 
    "transactionReceipt":{"__type":"Bytes","base64":"asdfqwertyASDFQWERTY="}, 
    "transactionType":"Purchased", 
    "transactionIdentifier":"[...]", 
    "transactionDate":{"__type":"Date","iso":"2012-09-10T06:58:44.071Z"}, 
    "createdAt":"2012-09-10T06:58:37.234Z", 
    "updatedAt":"2012-09-10T06:58:37.234Z", 
    "objectId":"HyPWJBlWzt" 
} 

I wtedy przyjąć wartość base64 wewnątrz transactionReceipt i zwijać go przed końcowym Apple, aby uzyskać pokwitowanie:

curl -H "Accept: application/json" \ 
    -H "Content-Type: application/json" \ 
    -X POST 
    -d '{"receipt-data":"asdfqwertyASDFQWERTY="}' \ 
    https://buy.itunes.apple.com/verifyReceipt 

Wszystko, co otrzymuję, to niezbyt pomocna pomoc:

{"status":21002, "exception":"java.lang.IllegalStateException"} 

co według mnie oznacza "Dane w własności danych pokwitowań były zniekształcone.". Skomplikowanie zwinięcia całej operacji za pomocą --trace-ascii nie ujawniło niczego, co uważałem za istotne, jestem pewien, że problem nie dotyczy samego połączenia.

Nieco zakłopotany tutaj. Wygląda na to, że transakcja została znaleziona na końcu (podkręcenie kilku bajtów w danych-paragonach powoduje wyrzucenie java.lang.IllegalArgumentException), więc domyślam się, że ma to coś wspólnego z samą transakcją. Czy ktoś to wcześniej widział?

Dzięki!

Odpowiedz

1

Wylądowałem tutaj po wyszukaniu tego samego komunikatu o błędzie. W końcu to rozwiązałem - najlepszą radą, jaką mogę dać, jest sprawdzenie, czy paragon jest poprawny i czy publikujesz go pod prawidłowym adresem URL. Dostaję dokładny błąd, gdy korzystałem z nieprawidłowego rachunku (lub prawdopodobnie niewłaściwego rodzaju - było to potwierdzenie przyjęcia aplikacji, a nie pokwitowanie zakupu w aplikacji) oraz podobny błąd, gdy używano ważnego kwitu z piaskownicy wysłanego do " URL weryfikacji do produkcji.

Pierwotnie użyłem przykładowych danych pokwitowania z http://images.worldofapple.com/validating_051110.pdf, po uudecoding go i reencoding go jako base64. Próbowałem delegowania:

Zarówno dał ten sam błąd {"status":21002, "exception":"java.lang.IllegalStateException"}. Podejrzewam teraz, że przyczyną jest fakt, że jest to potwierdzenie przyjęcia aplikacji, a nie pokwitowanie zakupu w aplikacji.

Potem dostał inny przykład otrzymanie od https://gist.github.com/sauloarruda/2559455

Na https://buy.itunes.apple.com/verifyReceipt mam podobnie bezużyteczne odpowiedzi: {"status":21007}

końcu w https://sandbox.itunes.apple.com/verifyReceipt dostałem oczekiwaną odpowiedź:

{ "receipt":{"original_purchase_date_pst":"2012-04-30 08:05:55 America/Los_Angeles", "original_transaction_id":"1000000046178817", "original_purchase_date_ms":"1335798355868", "transaction_id":"1000000046178817", "quantity":"1", "product_id":"com.mindmobapp.download", "bvrs":"20120427", "purchase_date_ms":"1335798355868", "purchase_date":"2012-04-30 15:05:55 Etc/GMT", "original_purchase_date":"2012-04-30 15:05:55 Etc/GMT", "purchase_date_pst":"2012-04-30 08:05:55 America/Los_Angeles", "bid":"com.mindmobapp.MindMob", "item_id":"521129812"}, "status":0}

+3

Odpowiedź "21007" nie jest bezużyteczny, mówi dokładnie, co było nie tak: kwit piaskownicy był wysyłany do środowiska produkcyjnego na żywo żelazne. Dlatego sprawdzanie piaskownicy zadziałało. –

Powiązane problemy