hollow kestrel
Hi, I am trying to send extra parameters while making a payment. After making a call to BillingServices.BuyProduct(....,1, applicationUsername), param sent to applicationUsername is returned back as Payment.Tag. Will this behavior work for all platforms? Developer payload was deprecated before, that's why I asked whether this will contine or not. I am going to build a new feature depending on this.
Thanks.
inland laurel
Yes, tag will be returned back as you expect it in the billing transaction. Yes, its not developer payload (we use account identifers for storing the tag). Also in v3, we made it more generic as it doesn't need to be username alone. Who knows, you may want to add additional info to that purchase so renamed from applicationUserName to tag every where on all platforms (iOS / Android).
In v3, we made it more accessible, but functionality is similar to what v2 currently offers.
hollow kestrel
For instance I want to gift the purchase to another player, can I safely send that users' info on applicationUsername parameter and receive that in Payment.Tag?
inland laurel
Yes. But not that there is a limit on how much length the tag data will be.
hollow kestrel
What is the limit there?
inland laurel
It's limited to 64 chars.
Also, there is one more constraint on iOS (in v3) after updating to Store Kit 2.
The tag needs to be uuid format.
uuid takes 32 chars. So you can store any additional flags in remaining 32 bytes.
Developer payload used to be good but once they deprecated it, there are only hacks available to store extra params. And as iOS made it like uuid format only, it made it more difficult to get a common api.
@hollow kestrel How much data (in bytes) you want to save in the tag?
hollow kestrel
I may need more than 32 chars
inland laurel
Ouch! Any specific reason?
hollow kestrel
I am currently using order ids as uuid which are 36 chars, i was going to pass uuid + player_id
I can send the player id only and find a solution
inland laurel
In-fact we want to reserver few bytes for ourselves (for plugin to store info about subscription details - Android has very bad api for subscriptions which make it dependent on server)
hollow kestrel
Player IDS are uint, I can send them only
Cross check on the backend, it's doable no worries
inland laurel
Note that - the tag internally used by the platforms to fight back fraud. So make sure its as unique as possible. I think thats why ios imposed uuid format, most likely.
hollow kestrel
hmm
inland laurel
Player IDS are uint, I can send them only
Great!
So I can plan on reserving few bytes for the plugin to store additional info about the purchase (like purchase time, offer id used and all)
hollow kestrel
Maybe I need to find another solution just in case apple or google changes, and skip this implementation as a whole?
inland laurel
Maybe I need to find another solution just in case apple or google changes, and ...
One thing is they can't*** ditch already assigned values. For the same reason, they still continue to pass developerPayload value even now. However setting it is deprecated though.
can't*
So I think you can rely on it if you have no better alternative.
hollow kestrel
I create orders in db first, then verify after payment is verified. I can record gifted player's id in orders and check after verification
Tag would be much easier but like you said, it's a bad habit to rely on 3rd parties 🙂
inland laurel
Ok, after further thinking, its better not to use other than for storing user specific info (player's uuid). As these can change anything.
So, if you have a chance via backend, pick that way.
I just noticed its not 64 chars, iOS makes it too bad by restricting it to 32 only.
https://developer.apple.com/documentation/storekit/transaction/3749684-appaccounttoken?language=objc
hollow kestrel
I normally verify by keeping the last order created in a variable. Sometimes in the middle of a purchase, players close the app. If they relaunch, I verify pending transactions but the order id is lost, since the app is closed.
That's why I wanted to hold some parameters in payment data.
inland laurel
The user will select to gift from the app store iap purchase dialog?
hollow kestrel
Yes, they will purchase the item but gift to another player
The purchase will be loaded to another players balance
inland laurel
I see. It's a nice use-case, I didn't think about this!
hollow kestrel
😄
hollow kestrel
So, if you have a chance via backend, pick that way.
UUID means unique right? So I can't send the player id, if some player is gifted more than once, it would cause a problem. I have to hash it some way.
inland laurel
In v2 (as we use storekit1), it allows to use non-uuid. As you have uint as player id, you can save the required info for your use-case.
But in v3 (as we use storekit 2), it only allows you to set uuid (32 chars). At that point, you may need to change your code to support your use-case. You may need to create a uuid string from your data.
inland laurel
UUID means unique right? So I can't send the player id, if some player is gifted...
Well, it won't cause as the player wont gift that often. They use that value to detect abuse (like lots of purchases from same user from different devices for ex).
hollow kestrel
Ayyappa are you sure it allows 32 chars max? I have sent 36 chars
https://developer.apple.com/documentation/foundation/uuid?language=objc says 4 bytes, is that why you're suggesting 32 chars max?
inland laurel
Ayyappa are you sure it allows 32 chars max? I have sent 36 chars
Yes https://developer.apple.com/documentation/storekit/transaction/3749684-appaccounttoken?language=objc
As mentioned, v2 uses storekit 1 which may support more than 32. But in strorekit 2(v3 essential kit) nedd to use uuid (appaccounttoken) which is uuid(32chars)
hollow kestrel
Ok thanks!