Paypal_r issue -- Dates not lining up properly!

Discussion in 'Payments processing' started by amadeus, Sep 4, 2010.

  1. amadeus

    amadeus Member

    Joined:
    Jan 16, 2009
    Messages:
    42
    Something, I think, has changed with paypal and I'm not sure if it's their error or not.

    Notice in this screenshot what I'm seeing in the control panel:
    [​IMG]

    And, now the corresponding screenshots taken directly from the paypal website when viewing the individual subscriptions in my history:
    [​IMG]
    [​IMG]

    Now, it looks to me like paypal's math is wrong and that they're actually not charging until the end of the 6th day, instead of the end of the 5th day. For example, using the second subscription above:

    CREATED: Sept. 4 at 07:35
    END OF DAY 1: Sept 5 at 07:35
    END OF DAY 2: Sept 6 at 07:35
    END OF DAY 3: Sept 7 at 07:35
    END OF DAY 4: Sept 8 at 07:35
    END OF DAY 5: Sept 9 at 07:35
    ...this is where payment should be made since the user has now had 5 days of trial period...right?
    END OF DAY 6: Sept 10 at 07:35
    ...this is the date that paypal is showing as the "Next Payment Date"



    ------------------

    Anyway, this is causing havoc with my system. Is there a quick way to fix this in amember until paypal fixes it (or, in case they don't fix it?)
  2. amadeus

    amadeus Member

    Joined:
    Jan 16, 2009
    Messages:
    42
    Update:

    After talking to paypal this morning I think that the easiest thing is going to be to simply provide an extra day or two to the subscription INTERNALLY within amember. So, if anyone has a quick edit for that, it would be great.

    I'm still going to try and get paypal to review the system; however, you know how it is with them....
  3. amadeus

    amadeus Member

    Joined:
    Jan 16, 2009
    Messages:
    42
    Well, rather than utilize some complex method of fixing this problem (which is occuring with EVERY paypal payment), I went for an easy solution. I'll share it in case anyone else wants to use it.

    See comments for more information. And, obviously, let me know if you see anything that I might be missing with this. I'm going to watch it for a few days to see if anything goes amiss, but the way I understand amember and how it handles paypal callbacks, this logic should be fine.


    This is in product.inc.php ...in the function "get_expire" right before the line that reads "switch ($unit){":
    Code:
    		/////////////////////////////////////////////////////////
    		// Paypal is unreliable as to which day they actually bill the customer.  Often, amember
    		// is expecting a payment on a particular date; however, paypal is not doing the transaction
    		// until the following day.  THEREFORE, to avoid unecessary complications, I am simply adding
    		// a day to each payment/term as a "padding".   Therefore, as an example, although paypal will 
    		// receive the information (and the customer will see the terms) as a trial period of x days, amember
    		// will expect the payment in x+1 days.
    		//
    		// I suppose an extra "free day" may bother some folks, but it doesn't bother me.  It's well 
    		// worth the tradeoff in having less customer services issues.
    		if ($unit == 'd')
    			$count++;
    		//
    		/////////////////////////////////////////////////////////
    
    Yea, it's a hack ...but it works. Check out the two screenshots now and you can see how they now match up properly with the addition of the hack above.

    [​IMG]

    [​IMG]


    Also, just for the record, it appears as though paypal has been doing this bullshit since the beginning; however, it was only the latest version of aMember that started causing problems for me. Which means, I guess, that aMember wasn't handling things precisely before huh? :)

Share This Page