Question

When creating a subscription, I log the orderID that gets created in the database intending to reference it later to handle a cancellation postback. My cancellation postback never seems to work however.

My postback stores the original order when it's created and then it tries to reference it on cancellation and update the database but the orderID is slightly different and cannot update properly.

This is the orderID that got stored directly from the decoded JWT in the database:

GWDG_S.886160e8-49b6-4f92-b485-9787c4cb4c06.0..0

This is the orderID that gets sent according to firebug in the console during the subscription cancellation:

GWDG_S.886160e8-49b6-4f92-b485-9787c4cb4c06.0.

This is the orderID that gets sent in the email to the user cancelling the subscription:

GWDG_S.886160e8-49b6-4f92-b485-9787c4cb4c06

I'm not sure what's going on here. How do I go about accounting for these changes?

Any input is welcome! Thanks!

Was it helpful?

Solution

Can't seem to reproduce...in my sandbox :

Subscription Purchase

At test web page:

javscript alert box


Buyer's sandbox wallet:

buyer wallet sandbox


Postback Data

This is the debug email I send to myself showing purchase and subsequent cancellation postbacks


email screenshot


Buyers do get receipts with what I believe is the "incrementing" transaction number you are seeing (unless I'm corrected by a Googler) each time their subscription is renewed -

e.g. on 5th renewal [...]6a6c4.0..5


Sample cancellation postback over a period of time:

long subscription cancellation

OTHER TIPS

Looks you need to normalize the orderID to the last format. For this particular one, the following regex will do.

preg_match('([^\.]+\.[^\.])\.', $orderID, $matches);
$orderID = $matches[1];
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top