Roku Developer Program

[rsromeo]

I've set up Roku Web Services and my listener - works fine.  I get the responses back BUT my db only stores the user's email address, username, pw and device info.  The SALE push notification has these values:

$responseKey = $data["responseKey"];
$custid = $data["customerId"];
$transactionType = $data["transactionType"];
$transactionId = $data["transactionId"];
$channelId = $data["channelId"];
$productCode = $data["productCode"];
$price = $data["price"];
$currency = $data["currency"];
$comments = $data["comments"];
$eventDate = $data["eventDate"]; 

I get all these values fine.  My problem is the only possible attribute in this response I can link to in my db is customerId, however, I can't get the customerId from the user with BrightScript (or at least I don't know how).  How can I map these transactions from these push notifications to my customer db so I know which account to update??  I wish we could get the customerId from roChannelStore or roDeviceInfo.  It would be ideal if Roku allowed us to add our own custom parameter to their responses like Paypal and Amazon do.  Anyone have any idea what I can do?

[rsromeo]

Actually found out that I can grab the transaction ID from calling GetResponse() after the isRequestSucceeded() event occurs.  So what I'll probably end up doing is storing that trans id (for new subscription), and then grab the trans id from the push notifications, do a validate transaction call to Roku Web Services, get the ORIGINAL trans id, and use that to lookup my customer and update their account.  Seems a bit of a hassle to do it this way but don't see how else I can.

[destruk]

If you are just doing this for the Roku platform with Roku billing, for subscriptions, you should be able to get away without using push notifications, even to see if it is active.
Since all subscriptions for the same roku account use the same roku billing system, if you only offer a single subscription option, you can query from within the roku channel app itself if any subscriptions are available for the user to purchase.  If yes, then the subscription isn't valid and they have to get one.  If no, offer the available option in the app.  Along the same lines if you offer more than one option and they are all different subscription plans, then the user will most likely only be able to choose one of them at a time, so you can do a simple count of how many are available to purchase, if all options are available they aren't subscribed, if less than the total options are available then they are valid for one of them.  If you need to know if their subscription is valid for outside use on other platforms then your method appears to be correct on how to tell.

[rsromeo]

Thanks for the reply.  I do need to tell if the subscription is valid for an outside platform otherwise I would give what you say a try.  Unfortunately, I need it for something else as well so I think my only option is what I came up with unless you or someone else has a better idea.  Thanks!