Android: Consecutive sideloader transactions failure
Closed this issue · 12 comments
My scenario is that I do transaction A and it launches PayPal from cold start. I log in, complete the transaction, and it goes back into my application.
I then do a second transaction B and PayPal does a warm launch which does not require me to log in. Nothing from my paypalhere: call invoice is populated and it just has an empty "New sale" screen with 0.00 balance.
If I do transaction A and kill PayPal Here from the app switcher before doing transaction B, I am presented with the login screen again and after logging in my invoice is populated correctly.
I'm able to reproduce this. Will take a deep dive into it and will report back with an update.
Great, thank you!
I just reported a crash to the Play Store, not sure if it's related to this. I switched to using the v2 API for this one using this URL: paypalhere://takePayment/v2?accepted=...&returnUrl=...&invoice=...
Starting with the scenario above:
My scenario is that I do transaction A and it launches PayPal from cold start. I log in, complete the transaction, and it goes back into my application.
I then do a second transaction B and PayPal does a warm launch which does not require me to log in. Nothing from my paypalhere: call invoice is populated and it just has an empty "New sale" screen with 0.00 balance.
From here, I hit the back button and got the logout prompt. I hit OK and was taken back to my application (with an UNKNOWN Type). I then immediately ran another transaction to HERE and briefly saw the login page before it crashed.
@rdantonio I was able to reproduce that crash yesterday, I'm working on a fix along with the behavior you noted in the original post. Thanks for the report!
Hi @rdantonio, we have a fix on the way for this issue! I'll keep this thread updated with the build # and build version when the release is going out..
PPH Android will now properly populate an invoice through sideloader if you're previously logged in, and should not crash on logout.
Great, thank you so much! All the help has been much appreciated.
@rdantonio Can you confirm that the new live build fixes your issue, so I can mark this as resolved?
I apologize for the delay in response, I haven't had a chance to revisit this until today. I did test the multiple scenario case and it does appear to work properly now, so feel free to mark resolved!
No problem, thanks for confirming! Let us know if you run into any other issues!
Actually, quick question regarding the Number: what kind of constraints are set on this field besides avoiding duplicate numbers? I'm sending unique numbers every time similar to this: -2144680996 and the return url always returns {Number} instead of having a value. This worked fine previously - has anything changed regarding this?
For simplicity lets open a new issue while I investigate. Do you want to so
that you become a watcher on the thread?
On Thu, Sep 24, 2015 at 11:39 AM, rdantonio notifications@github.com
wrote:
Actually, quick question regarding the Number: what kind of constraints
are set on this field besides avoiding duplicate numbers? I'm sending
unique numbers every time similar to this: -2144680996 and the return url
always returns {Number} instead of having a value. This worked fine
previously - has anything changes regarding this?—
Reply to this email directly or view it on GitHub
#28 (comment)
.
Brandon Lerner
Sure, no problem