Does gdx-pay-server support iOS subscriptions at all?

[kdbeall]

Reading the Apple pay docs, the Json sent to Apple to validate a receipt is as follows.

Key	Value
receipt-data	The base64 encoded receipt data.
password	Only used for receipts that contain auto-renewable subscriptions.
exclude-old-transactions	Only used for iOS7 style app receipts that contain auto-renewable or non-> renewing subscriptions. If value is true, response includes only the latest renewal transaction for any subscriptions. Unless there's some magic in Base64Util.

From what I see in your PurchaseVerifieriOSApple.java: 64, you only have the receipt-data field being sent for validation.

final String receiptData = Base64Util.toBase64(receipt.getBytes());
final String jsonData = "{\"receipt-data\" : \"" + receiptData + "\"}";

I'm still a bit confused about whether subscription receipt validation is supported or not. I'd just like to be sure about this. Thank you!

[noblemaster]

Yes, it is supported but the code is currently wrong. You need to use getTransactionDataSignature() for purchase validation. See: https://github.com/libgdx/gdx-pay/issues/166

[keesvandieren]

Are you actually using it? We consider to remove it if no one uses it.

[kdbeall]

I ended up rolling my own based on the code in libgdx. Ended up not using it because I switched to Python and Django. But, here's the repository!

[MrStahlfelge]

@keesvandieren I think we should remove the server component as it is outdated, incomplete and confuses new users.

[noblemaster]

I think doing server-side verification is somewhat important. That said, the code is incomplete and needs testing. Not sure what you mean by "outdated"? I am not aware of a more modern approach to server side verification!?

In any case, if everyone thinks removing it is a good idea (no one does server side verification?), let's go ahead. However, we should still have some sample code available in the Wiki for example that shows how it works. That's what the 'transationData'/'transactionDataSignature' fields in Transaction.java are for. By removing the server side code we stop explaining also how those fields are to be used.

[MrStahlfelge]

You are absolutely right with providing a documentation what fields are needed to be sent to a server. If there is different information needed depending on the payment server, this should be stated on the payment service related page.

I don't think server-side verification is superflouus, but it is not important for everyone. And I am convinced that it is not important for a libGDX extension. libGDX is a client-side framework. so server code is not part of the task here. Indeed, I assume the majority of libGDX games work without a dedicated backend, and even of the games using a backend there will only be a fraction using a Java-powered backend.

About outdated, that is just an assumption because the code is 4 years old and I doubt it works without changes. I really doubt anyone uses it given the fact that it even Google Play is not implemented at all.

[kdbeall]

I think it should ideally be separated out (perhaps a maintainer could be found).

[piotr-j]

Verification is not terribly complicated to deal with server side. Simple example probably doesnt hurt. Google verification can be done with 'google-api-services-androidpublisher' stuff. Im sure theres something like that for amazon as well.

[MrStahlfelge]

@piotr-j I have seen you made some fixes for this in your repo. Feel free to create a PR when you are done and testet it, and perhaps to write a wiki page how to use the server side verification. Thanks in advance!

[piotr-j]

Will do when i test it properly.

[keesvandieren]

Closing as we received no reaction from #166, which is an indication that it is resolved