Home → Problems →

Paypal preapproval, user cancels or doesn't do anything

• Edit

Matti Varjokallio

05 Jul, 2011 12:58 PM

User clicks cancel:

-With simulated Paypal the user ends up in canceled state with no cancel-type/cancel-reason -With real Paypal when clicking "cancel and return to chargevault", the user is canceled, however with "paypal-wait" as reason. Isn't this wrong? We will then show:

"Your payment is being validated, please try again in a few minutes." indefinitely http://support.cheddargetter.com/kb/api-8/using-paypal-with-the-api...

User doesn't click anything/navigates away/closes browser when in Paypal:

Does the user stay in "paypal-wait" state forever? Is there a timeout from Paypal or CheddarGetter or should we implement an own timer to put the customer to normal canceled state at some point?

-Matti

1. Support Staff 1 Posted by Marc Guyer on 05 Jul, 2011 07:18 PM

   

   Hi Matti --

   -With simulated Paypal the user ends up in canceled state with no cancel-type/cancel-reason -With real Paypal when clicking "cancel and return to chargevault", the user is canceled, however with "paypal-wait" as reason. Isn't this wrong?

   This might simply be a timing difference. The simulator is probably a little bit faster. The real PayPal sends cancelation push data to CG when the cancel button is clicked. Due to the delay, they could remain in paypal-wait until CG receives the push from PayPal.

   User doesn't click anything/navigates away/closes browser when in Paypal: Does the user stay in "paypal-wait" state forever? Is there a timeout from Paypal or CheddarGetter or should we implement an own timer to put the customer to normal canceled state at some point?

   Something like this is on our todo list. PayPal has a somewhat unreliable "3 hour" time limit on the preapproval. So, if a preapproval isn't approved or explicitly canceled within 3 hours, it is assumed to be canceled. Unfortunately, PayPal does not send the same cancelation push data in this case.

   • Edit

2. 2 Posted by Matti Varjokall... on 07 Jul, 2011 11:56 AM

   

   I tried this one more time. This time I waited something like 1 hour and 30 minutes after clicking the "Cancel preapproval and return to ChargeVault Subscriptions" and the customer was still in "paypal-wait" state. I assume there is something wrong?

   In practice it is quite normal to click around a bit to see how things work, then decide that you are not ready to pay quite yet, and come back next day for example. We don't want to show the user "Paypal preapproval pending" type messages at that point. So it is important that if there is thing like "paypal-wait" state that it is used properly.

   -Matti

   • Edit

3. Support Staff 3 Posted by Marc Guyer on 07 Jul, 2011 01:54 PM

   

   Hi Matti -- That is strange. Judging from our logs, a non-standard workflow is occurring with your test customer with code=pattern-factory.

   1. Normal signup
   2. Preapproval approved
   3. Account canceled
      • was this done manually within the CG GUI or within the PayPal account interface? Other?
   4. "Reactivate" via PayPal method.
      • CG continues to receive push from PayPal for original cancelation (3).
      • Notification corresponding to new preapproval in (4) is not received.

   Can you confirm this progression and elaborate if possible?

   • Edit

4. 4 Posted by Matti Varjokall... on 07 Jul, 2011 03:36 PM

   

   Hi,

   Yes, this is the workflow I tried earlier,
   3.1. This was done with CG API (Sharpy) and Paypal account interface

   Now I also tried the simpler
   1. Normal signup
   2. Preapproval canceled
   and the account was still left in "paypal-wait"

   So would the simplest way to proceed now to judge that the preapproval is canceled if some time (couple of minutes, 15minutes?) is passed from the time the paypal-wait was set and allow the user to request a new preapproval link. Can this cause some issues?

   • Edit

5. Support Staff 5 Posted by Marc Guyer on 12 Jul, 2011 09:37 PM

   

   Matti -- We recently released an upgrade which fixes a couple of issues. Specifically the issue you brought up should be fixed: If a customer cancels the paypal workflow, the account is canceled (instead of staying in paypal-wait).

   • Edit

6. 6 Posted by Matti Varjokall... on 15 Jul, 2011 04:43 PM

   

   Thanks! I will try it in the beginning of next week.

   • Edit

7. 7 Posted by Matti Varjokall... on 18 Jul, 2011 03:13 PM

   

   The cancelation related things seem to work better now.

   However, there is a new issue which I believe was introduced during this update.

   If the customer has done the preapproval and just changes plan, this shouldn't trigger the preapproval again, right? At least couple of weeks ago it didn't, but now it seems to be the case. I tested both:

   1) Forward the user to Paypal
   The user may do anything (even click cancel) and the plan change is still approved, probably because of the earlier preapproval. Is it then necessary to do the preapproval redirect at all?

   2) Don't forward to Paypal
   I just tested this to check if one can just ignore the Paypal redirect url that has been set by CG API. In this case the user ends up in canceled state.

   -Matti

   • Edit

8. Support Staff 8 Posted by Marc Guyer on 18 Jul, 2011 04:54 PM

   

   I'm guessing you're using the API for the plan change. Have you tried issuing the plan change only? In other words, use the Edit Subscription api call but only pass the new plan code.

   • Edit

9. 9 Posted by Matti Varjokall... on 19 Jul, 2011 06:29 AM

   

   Thanks, I'll try that. It seems Sharpy doesn't support the edit-subscription command but does most of the things through customer update so I wasn't so aware of this. Have to think about implementing it.

   -Matti

   • Edit

10. 10 Posted by Matti Varjokall... on 04 Aug, 2011 12:35 PM

    

    Hi,

    It seems that the original account cancelation issue is back there - If user cancels in Paypal, he will end up in paypal-wait state.

    Have you changed the implementation recently? We are launching next week and are not happy about these changes without any notification.

    Are you going to fix this soon? As a quick fix we can remove the customer ourselves after some delay if the customer is in paypal-wait state, but would like more if you could handle this properly.

    -Matti

    • Edit

11. Support Staff 11 Posted by Marc Guyer on 04 Aug, 2011 08:08 PM

    

    Thanks, I'll try that. It seems Sharpy doesn't support the edit-subscription command but does most of the things through customer update so I wasn't so aware of this. Have to think about implementing it.

    The edit-subscription call is just a simplified version of edit-customer. You can use edit-customer and just pass subscription[planCode]

    It seems that the original account cancelation issue is back there - If user cancels in Paypal, he will end up in paypal-wait state.

    We did recently release some fixes (as recently as this afternoon). Please try this again and let us know. You've been a big help in identifying these cancelation issues!

    • Edit

12. 12 Posted by Matti Varjokall... on 04 Aug, 2011 09:38 PM

    

    Ok thanks for info, We'll try using the edit-customer with only planCode.

    Regarding the cancel issue, seems to be still there :(

    -Mattii

    • Edit

13. Support Staff 13 Posted by Marc Guyer on 05 Aug, 2011 01:44 PM

    

    Regarding the cancel issue, seems to be still there :(

    Geez. We definitely want to get to the bottom of this. At this point, I think the best course of action is to replicate your exact workflow. We'd greatly appreciate it if you would spell out your step-by-step workflow which replicates the behavior. I know you've explained it before but to date it has not been detailed enough to replicate exactly.

    • Edit

14. 14 Posted by Matti Varjokall... on 06 Aug, 2011 12:56 PM

    

    Ok, it doesn't get more detailed than this :)

    Running this python code:

    from sharpy.product import CheddarProduct
    product = CheddarProduct(
        username = 'yourusername'
        password = 'yourpassword',
        product_code = 'yourproduct',
        endpoint = 'https://cheddargetter.com/xml',
    )
    
    return_url = 'construct some return url'
    cancel_url = 'construct some cancel url'
    customer = product.create_customer(code='testuser',
                                       first_name='First',
                                       last_name='Last',
                                       email='[email blocked]',
                                       plan_code='PLAN_CODE',
                                       cc_first_name='First',
                                       cc_last_name='Last',
                                       company='Company',
                                       method='paypal',
                                       return_url=return_url,
                                       cancel_url=cancel_url)
    
    print customer.subscription.canceled
    print customer.subscription.cancel_type
    print customer.subscription.cancel_reason
    print customer.subscription.redirect_url
    

    will print out

    2011-08-06 11:57:00+00:00
    paypal-wait
    PayPal preapproval is pending
    https://www.paypal.com/cgi-bin/webscr?cmd=_ap-preapproval&preap...

    Now open browser and go to the given paypal link. Click "Cancel and return to ChargeVault". Run following to check the customer status:

    from sharpy.product import CheddarProduct
    product = CheddarProduct(
        username = 'yourusername'
        password = 'yourpassword',
        product_code = 'yourproduct',
        endpoint = 'https://cheddargetter.com/xml',
    )
    customer = product.get_customer(code='testuser')
    print customer.subscription.canceled
    print customer.subscription.cancel_type
    print customer.subscription.cancel_reason
    print customer.subscription.redirect_url
    

    2011-08-06 11:57:00+00:00
    paypal-wait
    PayPal preapproval is pending
    https://www.paypal.com/cgi-bin/webscr?cmd=_ap-preapproval&preap...

    The user is still in paypal-wait state so we have no way of separating the cases where the Paypal is really processing something or he wanted to cancel the workflow.

    If the Paypal is processing something:
    http://support.cheddargetter.com/kb/api-8/using-paypal-with-the-api...
    this seems like a good way to go

    But we can not do this infinitely if the customer wanted to cancel the workflow. In this case we would want to have the customer in normal canceled state and offer a new link to paypal.

    We could change the cancel_type ourselves when user is redirected to cancel_url .. its just that we are not allowed to update canceled customers. There is the other open thread about this.

    There are probably many ways around this. The easiest that came to our mind is that we don't care about the paypal-wait at all but show the same text to all canceled scenarios and add something like "if you just preapproved paypal payments, try reloading this page after some time". This just isn't that slick for new customers who have approved the payments.

    We had this working somehow couple of weeks ago but then your implementation seem to have changed. Also the documentation doesn't state how this should work so this has been sort of guessing game on our part.

    Hope this helps.

    • Edit

15. 15 Posted by JanneL on 06 Aug, 2011 04:00 PM

    

    Lähetetty iPhonesta

    "Matti" <[email blocked]> kirjoitti 6.8.2011 kello 15.55:

    >

    • Edit

16. 16 Posted by Matti Varjokall... on 07 Aug, 2011 07:27 PM

    

    Got this working. When the user is redirected to cancel_url, we will call the cancel API call ourselves. This seems to change the the cancel_type to "customer" and clean cancel_reason.

    We were at first assuming that you will do this, and we didn't actually have a separate url for the cancel: both return_url and cancel_url just returned to the account main page.

    I also tried the customer update with only plan code and this doesn't redirect to Paypal, so this also sorted out.

    Thanks

    • Edit

17. Support Staff 17 Posted by Marc Guyer on 09 Aug, 2011 06:23 PM

    

    Wow -- Thanks very much for the detailed workflow. That has cleared up quite a bit of the confusion. Unfortunately there's apparently still a disconnect. Our attempts to replicate this behavior continue to fail. Here's the detail:

    1. Create new customer via API with paypal method.
       • Our functional test closely matches your sharpy method call above
    2. Customer is determined to be in paypal-wait state.
    3. Customer is redirected to redirectUrl
    4. Customer clicks cancel and return
       • In this case, we use a fake url for the cancel return so there is no interference.
    5. Customer remains in paypal-wait state for approximately 5-15 seconds.
       • This delay varies but we have not seen more than 15 seconds.
       • Our functional tests wait until the customer is no longer in "paypal-wait" state.
    6. CG receives cancel IPN from PayPal and immediately cancels the customer
    7. Customer is in hard canceled state:
       • cancelType="customer"
       • cancelReason="PayPal preapproval was canceled"

    So, I suppose it's possible that you are checking the status of the customer within the 5-15 seconds of delay. Could this be? It seems unlikely that you would click the cancel button in PayPal, then lookup the customer via sharpy within the 5 seconds every time. Could it be that sharpy is caching the customer data? That sounds unlikely as well.

    The workaround (of the 5-15 sec delay) you suggest is feasible. We actually do the same thing in the hosted pages interface. When the customer is redirected from PayPal back to the 'cancelUrl', we force cancel the customer without waiting for the PayPal cancel IPN.

    • Edit

18. Support Staff 18 Posted by Marc Guyer on 09 Aug, 2011 06:28 PM

    

    FYI, you can always look at the raw xml in a browser for troubleshooting purposes:

    https://cheddargetter.com/xml/customers/get/code/my_customer_code

    Checking the raw xml after the cancel button is clicked in PayPal would cut sharpy out of the mix. Just refresh the xml until the cancelType changes.

    • Edit

19. Dean closed this discussion on 16 Jan, 2013 09:30 PM.