plz… hurry… 
[import]uid: 134563 topic_id: 22914 reply_id: 117636[/import]
i have this problem, too… [import]uid: 150913 topic_id: 22914 reply_id: 117638[/import]
Clearly the Apple debacle showed that server-side verification is now needed for the in-app purchases. Besides, server-side verification is considered best-practice and should be available in all stores.
Let us know about the ETA. [import]uid: 168273 topic_id: 22914 reply_id: 117936[/import]
I’m running into a rude awakening. After my app is finished I realized that we cannot implement payment options because our item granting is through an external server and there’s no way of verifying purchase unless we receive the signature from Google Appstore.
Of all the features for an SDK, features that allow developers to monetize should be of the highest and upmost importance. It took me a day of reading through Google’s docs to understand the different components of the system, I hope the staff members would do the same and support monetizing features fully. Considering the task at hand is to pass over a few more parameters, this isn’t even a challenge to implement.
A swift response to at least an ETA for this feature would be most appreciated.
[import]uid: 159488 topic_id: 22914 reply_id: 123059[/import]
To emphasize the importance of the feature, imagine an online roleplaying game where user data cannot be trusted on the client side, and all transactions has to happen on the server. We cannot afford any player to hack their client and suddenly introduce billions into the economy. So when users make a purchase, we cannot put any logic on the client side. We need to forward the purchase receipt to the server so that the feature is granted on the server. If there are no signature to verify the validity of the request, any user could forge a request and give themselves limitless amount of items.
It’s not a preference on how we wish to verify purchases, Google stated this one and only way for us to verify purchases, and we all have to follow that route. Hope we can get a response from you soon. [import]uid: 159488 topic_id: 22914 reply_id: 123065[/import]
Passing through the data to verify Android IAP sounds like it wouldn’t be too hard, and has, literally, a big payoff.
I’m considering only allowing purchases on iPhones initially, until Android IAP is secure (to preserve my apps “economy”, as lanzer22 above points out. [import]uid: 79933 topic_id: 22914 reply_id: 123087[/import]
I’m running into a rude awakening. After my app is finished I realized that we cannot implement payment options because our item granting is through an external server and there’s no way of verifying purchase unless we receive the signature from Google Appstore.
Of all the features for an SDK, features that allow developers to monetize should be of the highest and upmost importance. It took me a day of reading through Google’s docs to understand the different components of the system, I hope the staff members would do the same and support monetizing features fully. Considering the task at hand is to pass over a few more parameters, this isn’t even a challenge to implement.
A swift response to at least an ETA for this feature would be most appreciated.
[import]uid: 159488 topic_id: 22914 reply_id: 123059[/import]
To emphasize the importance of the feature, imagine an online roleplaying game where user data cannot be trusted on the client side, and all transactions has to happen on the server. We cannot afford any player to hack their client and suddenly introduce billions into the economy. So when users make a purchase, we cannot put any logic on the client side. We need to forward the purchase receipt to the server so that the feature is granted on the server. If there are no signature to verify the validity of the request, any user could forge a request and give themselves limitless amount of items.
It’s not a preference on how we wish to verify purchases, Google stated this one and only way for us to verify purchases, and we all have to follow that route. Hope we can get a response from you soon. [import]uid: 159488 topic_id: 22914 reply_id: 123065[/import]
Passing through the data to verify Android IAP sounds like it wouldn’t be too hard, and has, literally, a big payoff.
I’m considering only allowing purchases on iPhones initially, until Android IAP is secure (to preserve my apps “economy”, as lanzer22 above points out. [import]uid: 79933 topic_id: 22914 reply_id: 123087[/import]
I’ve implemented a work-around by having a quasi server side verification process.
Google Play doesn’t support server verification like Apple App Store, but they do provide an API for accessing receipt information. So it’s actually pretty straight forward to setup your PHP server to verify purchases.
Here’s some scrappy code to illustrate this. In this example, we’re accessing the PHP script with the get variable called “transaction_id” which contains the transaction_id reported by Google when the client complete a purchase successfully.
[code]
//Check Google checkout
$transaction_id = strval($_GET[‘transaction_id’]);
$xml_response2 = ’
‘.$transaction_id.’
new-order
‘;
$merchant_id = ‘1234567890’;
$merchant_key = ‘HsYXFoZfHAqyLcCRYeH8qQ’;
$auth_key = base64_encode($merchant_id . ‘:’ . $merchant_key);
$server =“checkout.google.com/api/checkout/v2/reports/Merchant”;
$url = “https://$server/”.$merchant_id;
$search_st = ‘’;
$success = false;
$headers = array();
$headers[] = “Authorization: Basic “.$auth_key;
$headers[] = “Content-Type: application/xml; charset=UTF-8”;
$headers[] = “Accept: application/xml; charset=UTF-8”;
$ch = curl_init ($url);
curl_setopt ($ch, CURLOPT_POST, true); // Use a standard HTTP Post
curl_setopt ($ch, CURLOPT_HTTPHEADER, $headers);
curl_setopt ($ch, CURLOPT_POSTFIELDS, $xml_response2);
curl_setopt ($ch, CURLOPT_HEADER, true);
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, true); // Return transfer of the string instead of outputting it directly.
curl_setopt ($ch, CURLOPT_PROXY, ‘http://’ . PROXY_SERVER);
curl_setopt ($ch, CURLOPT_TIMEOUT, 60); // The maximum number of seconds to allow cURL functions to execute.
curl_setopt ($ch, CURLOPT_SSLVERSION, 3); // Latest SSL version
curl_setopt ($ch, CURLOPT_SSL_VERIFYHOST, 0); // Do not checkname in SSL cerfificate
curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, false); // No files holder certificates to verify
$response = curl_exec ($ch);
$timestamp = false;
$item_id = false;
foreach (preg_split(”/((\r?\n)|(\r\n?))/”, $response) as $line) {
if ($item_id == false && strpos($line, $search_st) > 0) {
$success = true;
$item_id = trim(preg_replace("//",’’,$line));
} elseif ($timestamp == false && strpos($line,‘timestamp’)>0) {
$timestamp = preg_replace("//",’’,$line);
$timestamp = trim(preg_replace("/[T-Z]/",’ ',$timestamp));
}
}
[/code]
Look under the XML input categories, and the most important one is “notification type”, which govern if you want basic order info, changes of order status, etc. You can find in-depth documentation at [html]https://developers.google.com/checkout/developer/Google_Checkout_HTML_API[/html]
For authentication, you need to supply a key created by your merchant ID and your merchant key. That information is found in your Google Checkout settings tab.
[text]If your Merchant ID is 1234567890 and your Merchant Key is HsYXFoZfHAqyLcCRYeH8qQ, you would base64-encode the value 1234567890:HsYXFoZfHAqyLcCRYeH8qQ.
[/text]
The authentication key is then placed inside the HTTP header.
Once you receive a response from the server, you can then parse $response to see if the transaction ID is valid. In my example I extract the item_id and timestamp from the receipt. The item_id help identify what to grant the user, and the timestamp is saved to the database to ensure that I don’t grant the same item twice.
Hope this helps! [import]uid: 159488 topic_id: 22914 reply_id: 125312[/import]
I’ve implemented a work-around by having a quasi server side verification process.
Google Play doesn’t support server verification like Apple App Store, but they do provide an API for accessing receipt information. So it’s actually pretty straight forward to setup your PHP server to verify purchases.
Here’s some scrappy code to illustrate this. In this example, we’re accessing the PHP script with the get variable called “transaction_id” which contains the transaction_id reported by Google when the client complete a purchase successfully.
[code]
//Check Google checkout
$transaction_id = strval($_GET[‘transaction_id’]);
$xml_response2 = ’
‘.$transaction_id.’
new-order
‘;
$merchant_id = ‘1234567890’;
$merchant_key = ‘HsYXFoZfHAqyLcCRYeH8qQ’;
$auth_key = base64_encode($merchant_id . ‘:’ . $merchant_key);
$server =“checkout.google.com/api/checkout/v2/reports/Merchant”;
$url = “https://$server/”.$merchant_id;
$search_st = ‘’;
$success = false;
$headers = array();
$headers[] = “Authorization: Basic “.$auth_key;
$headers[] = “Content-Type: application/xml; charset=UTF-8”;
$headers[] = “Accept: application/xml; charset=UTF-8”;
$ch = curl_init ($url);
curl_setopt ($ch, CURLOPT_POST, true); // Use a standard HTTP Post
curl_setopt ($ch, CURLOPT_HTTPHEADER, $headers);
curl_setopt ($ch, CURLOPT_POSTFIELDS, $xml_response2);
curl_setopt ($ch, CURLOPT_HEADER, true);
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, true); // Return transfer of the string instead of outputting it directly.
curl_setopt ($ch, CURLOPT_PROXY, ‘http://’ . PROXY_SERVER);
curl_setopt ($ch, CURLOPT_TIMEOUT, 60); // The maximum number of seconds to allow cURL functions to execute.
curl_setopt ($ch, CURLOPT_SSLVERSION, 3); // Latest SSL version
curl_setopt ($ch, CURLOPT_SSL_VERIFYHOST, 0); // Do not checkname in SSL cerfificate
curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, false); // No files holder certificates to verify
$response = curl_exec ($ch);
$timestamp = false;
$item_id = false;
foreach (preg_split(”/((\r?\n)|(\r\n?))/”, $response) as $line) {
if ($item_id == false && strpos($line, $search_st) > 0) {
$success = true;
$item_id = trim(preg_replace("//",’’,$line));
} elseif ($timestamp == false && strpos($line,‘timestamp’)>0) {
$timestamp = preg_replace("//",’’,$line);
$timestamp = trim(preg_replace("/[T-Z]/",’ ',$timestamp));
}
}
[/code]
Look under the XML input categories, and the most important one is “notification type”, which govern if you want basic order info, changes of order status, etc. You can find in-depth documentation at [html]https://developers.google.com/checkout/developer/Google_Checkout_HTML_API[/html]
For authentication, you need to supply a key created by your merchant ID and your merchant key. That information is found in your Google Checkout settings tab.
[text]If your Merchant ID is 1234567890 and your Merchant Key is HsYXFoZfHAqyLcCRYeH8qQ, you would base64-encode the value 1234567890:HsYXFoZfHAqyLcCRYeH8qQ.
[/text]
The authentication key is then placed inside the HTTP header.
Once you receive a response from the server, you can then parse $response to see if the transaction ID is valid. In my example I extract the item_id and timestamp from the receipt. The item_id help identify what to grant the user, and the timestamp is saved to the database to ensure that I don’t grant the same item twice.
Hope this helps! [import]uid: 159488 topic_id: 22914 reply_id: 125312[/import]
the transaction listener is not fired neither with my own product, nor with the android pruchased test item.
after some time, i get (outside of the app) a notification that the sale failed. this is funny, because inside the app it tells me sth like thanks for buying, your item will appear shortly.
any ideas? [import]uid: 90610 topic_id: 22914 reply_id: 133053[/import]
the transaction listener is not fired neither with my own product, nor with the android pruchased test item.
after some time, i get (outside of the app) a notification that the sale failed. this is funny, because inside the app it tells me sth like thanks for buying, your item will appear shortly.
any ideas? [import]uid: 90610 topic_id: 22914 reply_id: 133053[/import]
Hope we it will get done soon, as we really need it as well! [import]uid: 27699 topic_id: 22914 reply_id: 139350[/import]
Hope we it will get done soon, as we really need it as well! [import]uid: 27699 topic_id: 22914 reply_id: 139350[/import]
Everyone,
As of daily build #1025, which is available today, Corona now provides the information needed to verify a Google in-app purchase. The store transaction event provides this information as follows:
- “event.transaction.receipt” provides Google’s “inapp_signed_data” JSON string.
- “event.transaction.signature” provides Google’s “inapp_signature” string. (This property returns nil on iOS.)
Also note that the signature string will be empty unless your device and app meets the conditions indicated by Table 1 in Google’s in-app billing documentation here…
http://developer.android.com/google/play/billing/billing_testing.html#billing-testing-static
Thank you for your patience. I hope this helps! [import]uid: 32256 topic_id: 22914 reply_id: 142134[/import]
Everyone,
As of daily build #1025, which is available today, Corona now provides the information needed to verify a Google in-app purchase. The store transaction event provides this information as follows:
- “event.transaction.receipt” provides Google’s “inapp_signed_data” JSON string.
- “event.transaction.signature” provides Google’s “inapp_signature” string. (This property returns nil on iOS.)
Also note that the signature string will be empty unless your device and app meets the conditions indicated by Table 1 in Google’s in-app billing documentation here…
http://developer.android.com/google/play/billing/billing_testing.html#billing-testing-static
Thank you for your patience. I hope this helps! [import]uid: 32256 topic_id: 22914 reply_id: 142134[/import]