CODEWITHSUNDEEP
phpandroidin-app-billing
WiTon Nope
WiTon Nope

Reputation: 166

InApp Billing Verifying Order on Web Server PHP

I'm using a simple PHP script to verify Android order to parse download for the customer.

$receipt = $_GET['purchaseData'];
$billInfo = json_decode($receipt,true);
$signature = $_GET['dataSignature'];
$public_key_base64 = "xxxxxxxxxxxxxxxx";
$key =  "-----BEGIN PUBLIC KEY-----\n".
        chunk_split($public_key_base64, 64,"\n").
       '-----END PUBLIC KEY-----';   

$key = openssl_get_publickey($key);

$signature = base64_decode($signature);

//$result = openssl_verify($billInfo, $signature, $key);
$result = openssl_verify($receipt, $signature, $key);
if (0 === $result) {
        echo "0";
    } else if (1 !== $result) {
        echo "1";
    } else {
        echo "Hello World!";
    }

//added the var_dump($result); as asked by A-2-A
var_dump($result);

result is 0int(0)

I made a real order through the App after I published it and when trying to validate the order I get "0" as result.

I tried direct HTTP access

https://domain.com/thankyou.php?purchaseData={"packageName":"com.example.app","orderId":"GPA.1234-5678-1234-98608","productId":"product","developerPayload":"mypurchasetoken","purchaseTime":1455346586453,"purchaseState":0,"developerPayload":"mypurchasetoken","purchaseToken":"ggedobflmccnemedgplmodhp...."}&dataSignature=gwmBf...

I'm keeping the first of the question because my result is still a guess. After further investigation I think it's the signature not being read in a nice clean way as sent by google.

The signature=gwmBfgGudpG5iPp3L0OnepNlx while the browser is reading it as ƒ ~®v‘¹ˆúw

How is it possible to let it be read in the right way?

Upvotes: 3

Views: 1388

Answers (1)

Marc Greenstock
Marc Greenstock

Reputation: 11668

To verify the signature you want to make sure of the following:

  1. INAPP_PURCHASE_DATA is not mutated in any way. Any encoding or escaping changes will result in a invalid verification. The best way to ensure it gets to your server intact is to base64 encoded it.
  2. INAPP_DATA_SIGNATURE also must remain intact, it should already base64 encoded so sending that to your server should not be a problem.
  3. openssl_verify expects both data and signature arguments to be in their raw state, so base64 decode before verifying.
  4. It also takes signature_alg as the last argument, in this case sha1WithRSAEncryption should work as should the default, but if in doubt try a few other sha1 algorithms to see which ones work.

My best guess why it's not working for you right now is that you're not receiving the INAPP_PURCHASE_DATA on your server in the same condition that it was received on the app. This Stackoverflow question had the same problem.

Upvotes: 1

Related Questions