Accessing response data from own server-side receipt validation.

[Almerick]

Observed behavior

I am in the process of migrating to v13 of this plugin, previously using v11. I make use of my own server-side receipt validation, which includes my own response payloads to handle user flows, based on whether a subscription was successful or not.

In the past, I set the store.validator value to the respective validation URL, then effective use the following to determine the next steps in the user flow, with the response data containing my own payload from the server:

product.verify().success(function (product, payload) {
	// Process validation response payload here...
	// ie. {ok: false, data: []}
	// ie. {ok: true, data: []}
}).error(function(err) {

});

Based on my observation and the documentation for v13, the above doesn't work anymore and the server validation response always returns the data outlined here: api/interfaces/CdvPurchase.Validator.Response.SuccessPayload.md, which doesn't include any of the response data I return from the server. Digging around a bit, I noticed that the payload I was looking for is found at CdvPurchase.store._validator.cache.

Is there any other means to access the response from my own server validation service?

[lincolnthree]

We also need this data for our server validation. Was this removed intentionally?

[tolutronics]

Please why am i getting this error while trying to verify the receipt The data in the receipt-data property was malformed or the service experienced a temporary issue. { "status": 21002 }

[NicholasStine]

Has this issue been addressed? Our validation endpoint currently responds with:

{ "ok": isPaid, "data" {}<object> }

Unfortunately the data element is nowhere to be found client side when store.when().verified((p) => {...}) callback is invoked upon successfully calling our /validate endpoint using of p.verify() in the store.when.approved(...) callback.

This is making it extremely challenging to handle special cases, such as when the validate route is called automatically on store initialization and there's already a transactionId associated with the app installation. (And yes, we are aware that we can use { needsAppReceipt: false } but this is not practical given that we're exclusively implementing subscription purchases).

Thanks!