No where to pass AppPayload for android purchases.

[yarontt]

Hi,

The plugin is missing a way to pass App Payloads in the Android billing flow.
I saw you had partial support for that (in the .java files) that was deleted. Is there a plan to support this?
I'm willing to help out with this.

[mohamnag]

the problem with developer payload is that it is simply not supported in iOS and I will to make a library which can be used on both platforms the same. as this is not supported in iOS, I decided against it.

[yarontt]

Ah...
The main problem is that without this it's not really possible to verify a purchase on the server.
I'm not too familiar with iOS purchases though. How would you do server side validation of a purchase there?

[mohamnag]

Sure you can verify the purchase even without payload.
If you have a server side verification, using the API you can send the token you can obtain from the plugin to do the verification. There you will verify the product that is bought and you can also control the time or status of the purchase. Thats absolutely better than just matching your payload.

if you cant use the server side verification, the plugin does a local validation of the purchase data integrity using your public key. even though this is not as safe as server side verification (as the application may be "cracked") but it makes sure that the data passed to your code is at least signed with the right private key (which only Google has).

[yarontt]

I understand your point (though not sure I agree :) ).

In any case, I was looking forward at your master branch, and was wondering if you could add to the buy() response the full original payload (including full purchase data json and data signature). That could just be in a originalPayload field in the Purchase (js code) and will be clearly labled platform dependant.
WDYT?

[mohamnag]

@yarontt sorry for late response, Im totally out of time now a days.

regarding the original payload, I think there is one problem here, and that is, that there is no such thing in iOS! once the payment is processed on iOS, you can only get the purchases from app receipt and there are all the purchases listed together.

I can see your point, but you have to consider that my goal in this plugin was to help developer deal with ONE api instead of two complete sets of apis. you are looking at this as stand point of an android developer, and the other side of story can also happen when a iOS developer asks for some iOS specific features.

if you are really looking into having all the details that each platform provides, then you are searching in the wrong place and better use two separate plugins.

[yarontt]

I'm actually using your plugin because it does support iOS. I'm writing both code paths as I go along.

I think the SKPaymentTransaction (a json of it) might suite what I mentioned as an original payload since that's what the iOS callback gets.

I think the main thing is this: Your plugin is x-plat, however on the server side there's no x-plat code. On Android it's possible to validate server side without calling any Google backend. Providing the exact original payload returned to the app, allows developers to be more flexible with the server side logic.

Considering the fact that there IS an original payload in iOS (SKPaymentTransaction), I would urge you to reconsider my request.
I really like your plugin and it's API and it's the only thing missing for me.

[mohamnag]

@yarontt sorry for my late reply, I'm currently in a situation that remains me scarce time for putting on side projects, I'm not sure when can I put some time on these changes.
but until then, I would totally recommend you to do a validation on your server WITH contacting apple/google servers. the reason are some hacks that can generate a totally valid signature and payment payload without paying anything. contacting google/apple servers for validation is the ONLY way to make sure you are doing the validation in the right way.

[yarontt]

Hi,
I understand that server-to-server validation is the safest, but it's still very difficult to hack a valid transaction with a signature. If you know of a way, I think Google will pay you for exposing it.

For most apps (at least in their early days), no one will put a lot of effort in hacking them.

In any case, I don't want to invest time in server-to-server validation, and I think adding the original payload to your API doesn't break x-platform in any way.
If you agree, I can do it myself.

Regards

[mohamnag]

sorry, since this campaign, I decided to stop any further development to this plugin:

https://www.indiegogo.com/projects/phonegap-cordova-in-app-purchase-ios-and-android

[yarontt]

got it.
Do you have any timeframe re your work of adding the Android support to the iOs plugin?

[mohamnag]

sorry I'm not going to be involved in that project. I dont believe they will also adopt my changes. anyway I hope also much success for that project.