S2 not cancelling old payments

[peterhuk]

Hi jason Chris,

I thought all was well but I just noticed something very worrying.

Whilst in test mode I did a number of user updates (approx 7
Modifications via S2 pro forms on the same day within a couple of
hours using the same user).

Note: My updates does note change the user role i.e 0 – 4,
but simply the user Custom Capabilities.

I have just received a number of Paypal ipn’s and discovered that
this test user has sent a number of payments .

Approximately 7 payments for this test user has been sent. I was
under the Impression that 1 payment would be sent and 6 would
be cancelled and payment voided.

There were changes in the Paypal payment profile as six of the
Payment email addresses were changed to
delete-xxxxxxxxxxxxxxxxx@sandbox.paypal.com

Where xxxxxxxxxxxxxxxxx was some random number.

Is this an error? Or Are these one off payments? Or are they
likely to come up again for additional payments.

If they are likely to come up again to take subsequent payments
this is a big problem .

If these are one off payments then is there away that S2 can notify
the administrator so that timely refunds can be issued prior to
customers demanding refunds on noticing multiple payments?

Many thanks

PeterH

[Jason Caldwell]

Hi Peter. Can we see the s2Member Button Shortcode that you're using please?

Also, what version of WordPress/s2Member?
If you have any log entries from s2Member, those would be helpful also.

Thanks!

[peterhuk]

Hi Jason,

Just a little background, all members start life as free subscribers. But I have 2 sign up forms
one for free subscribers and the other for people who want to be paid members.

I add an extra hidden input for the people who want to be paid subscribers so after signup
the pricelist will shows up for them only.

Okay that being said all Level1 members new or existing are provided with the S2 Pro form
With the modify attribute set. The ccaps, desc ra,etc are auto filed with dynamic data depending
on the members selection.

Values requested as follows:

Code: Select all

[s2Member-Pro-PayPal-Form modify="1" level="1" ccaps="cmem" desc="Basic Membership" ps="paypal" lc="" cc="GBP" dg="0" ns="1" custom="my-domain.com|user_id" ta="0" tp="0" tt="D" ra="9.95" rp="1" rt="M" rr="1" rrt="" rra="2" accept="paypal" accept_via_paypal="paypal" coupon="" accept_coupons="0" default_country_code="GB" captcha="0" success="/wp-admin/?vacc_mod=1" /]

WordPress Version; 3.2.1
S2Member Version: 110812
S2Member Pro Version: 110731

Code: Select all

Array
(
    [mc_gross] => 9.95
    [period_type] => Regular
    [outstanding_balance] => 0.00
    [next_payment_date] => 03:00:00 Sep 17, 2011 PDT
    [protection_eligibility] => Ineligible
    [payment_cycle] => Monthly
    [tax] => 0.00
    [payer_id] => xxxxxxxxxxxxx
    [payment_date] => 03:07:17 Aug 17, 2011 PDT
    [payment_status] => Completed
    [product_name] => Basic Membership:
    [charset] => windows-1252
    [rp_invoice_id] => xxxxxxxxxxx:0 D:1 M~mydomain.com~1:cmem
    [recurring_payment_id] => I-xxxxxxxxxxxx
    [first_name] => Test
    [mc_fee] => 0.05
    [notify_version] => 3.1
    [amount_per_cycle] => 9.95
    [payer_status] => verified
    [currency_code] => GBP
    [business] => my-email@address.com
    [verify_sign] => xxxxxxxxxx-xxx-xxxxxxxxxxxx-xxxx.xxxxxxxxxxxxxxxxxx.xxxx
    [payer_email] => delete-xxxxxxxxxxxxxxxxx@sandbox.paypal.com
    [initial_payment_amount] => 9.95
    [profile_status] => Active
    [amount] => 9.95
    [txn_id] => xxxxxxxxxxxxxxxxx
    [payment_type] => instant
    [last_name] => User
    [receiver_email] => my-email@address.com
    [payment_fee] =>
    [receiver_id] => xxxxxxxxxxxxx
    [txn_type] => recurring_payment
    [mc_currency] => GBP
    [residence_country] => GB
    [test_ipn] => 1
    [transaction_subject] =>
    [payment_gross] =>
    [shipping] => 0.00
    [product_type] => 1
    [time_created] => 16:17:52 Jul 17, 2011 PDT
    [ipn_track_id] => xxx-xxxxxxxxxxxx-xxxxx
    [s2member_log] => Array
        (
            [0] => IPN received on: Wed Aug 17, 2011 10:08:20 am UTC
            [1] => s2Member POST vars verified through a POST back to PayPal.
            [2] => Transaction type (  `^recurring_?`   ), but there is no match to an existing account; so verification of   `$_SERVER["HTTP_HOST"]`  was not possible.
        )

    [subscr_gateway] => paypal
    [custom] =>
)


Many thanks
PeterHuk

[Jason Caldwell]

In your log file entry, is the extra .com a typo, or is that how it's coming out in the logs?

Code: Select all

[rp_invoice_id] => xxxxxxxxxxx:0 D:1 M~mydomain.com.com~1:cmem

[peterhuk]

Sorry Jason that’s just me changing the identification details to protect
the innocent (or however the saying goes).

PeterHuk...

[Jason Caldwell]

Gotchya. Thanks.

OK. So based on the log entry you posted, it looks like the Member associated with this transaction, no longer exists in your WordPress installation, is that correct?

Sorry, I'm trying to put the pieces together here, but I'm not sure I understand what's going on exactly. Can you please elaborate just a bit further on what you said here please?

I have just received a number of Paypal ipn’s and discovered that
this test user has sent a number of payments .

Approximately 7 payments for this test user has been sent. I was
under the Impression that 1 payment would be sent and 6 would
be cancelled and payment voided.

There were changes in the Paypal payment profile as six of the
Payment email addresses were changed to
delete-xxxxxxxxxxxxxxxxx@sandbox.paypal.com

[peterhuk]

Hi Jason,

Sorry for the confusion. What I was trying to say is on my test site
I have a number of test users set up (this will allow me to test Wordpress,
S2Member or even my own updates before I put them onto a live server).

The test user in question is still active. At some point in my tests I made
a number of account modification (i.e updated the subscription).

According to the people at x.com re: the delete-xxxxxxxxxxxxxxxxx@sandbox.paypal.com

These could be from recurring profiles that were set up. If you deleted the account, or reset the account it would of removed the email address that they were being billed on, but the profile is still active and being billed in the background as this only just removes it so that it does not show up in your account on your side.

The long and short is that I did not do any of the above.

Let me know what you think.

PeterHuk

[Jason Caldwell]

OK. Thank you.
Are you still in Sandbox mode right now? Or have you gone live now?
If you're no longer in Sandbox mode, what you could be seeing are Sandbox payments coming through to your "now live" installation. In which case, s2Member will reject those old Sandbox IPNs, which may continue to come through for quite some time. They won't hurt anything, but if you want to get rid of them, you'll need to log into the Sandbox account that you created and terminate those Subscriptions and/or Recurring Profiles that were created during testing. Does that help? Or do I not understand yet?

[peterhuk]

Hi Jason,

My test site is on a demo subdomain and will remain a test site for testing updates.
But my corncern is that whilst testing if these delete-xxxxxxxxxxxxxxxxx@sandbox.paypal.com
accounts are sending payments from the sandbox, what will happen in a live
situation?

I.e will a real account on my live domain (when I finally go live) end up having
a live subscription (which will send legitimate payments) and at some point
a delete-xxxxxxxxxxxxxxxxx@paypal.com also sending payments
after doing a subscription update?

Thanks

PeterHuk

[Jason Caldwell]

When you go live, the endpoint domain that communicates with PayPal will change internally for s2Member. Therefore, once you are live, any IPN payment notifications that come through from previous testing in the Sandbox, are simply ignored by s2Member. You may see them in your log file, but no actions are taken, because they will then be unverifiable against your live account, which is what you want.

So no, don't worry about the Sandbox testing,
once you're live that won't affect your Users/Members in any way.

If you want to take the extra step of logging into your Sandbox merchant account and terminating all test Subscriptions and/or Recurring Profiles, you can; just to be extra safe. But that's optional.

[peterhuk]

Hi Jason,

Many thanks for your response. Once again I seem to be making a hash of
my explanation. I’ll try and put it this way.

Relating to the scenario which caused the delete-xxxxxxxxxxxxxxxxx@sandbox.paypal.com
on the test site.

If we can forget about the test site and any related ipn’s from the test site for now.

Is it possible that the same scenario on the live site (i.e live site member doing
multiple subscription modification updates on the live site) could also cause the live site to create
similar delete-xxx@PAYPAL.COM reoccurring live payments also?

This is my may concern that the main site starts generating its own delette accounts.

Many thanks
PeterHuk

[Jason Caldwell]

So sorry. OK, I *think* I understand, but please feel free to correct me again if I'm wrong.

It looks like you're running a PayPal Pro account with s2Member Pro Forms. Whenever you create a Billing Modification Form with s2Member Pro, a Customer will essentially create a new Recurring Profile, with the new terms/pricing/etc that you configure for the Billing Modification Form. Any existing Recurring Profile that may or may not exist for that User/Member, will be terminated silently behind-the-scene by s2Member, and the new one takes its place. Does that help?

[peterhuk]

Hi Jason,

Yes, we are on the right track now. So would it be conceivable that:

Any existing Recurring Profile that may or may not exist for that User/Member, will be terminated silently behind-the-scene by s2Member, and the new one takes its place.

Before the old profile gets terminated Paypal might take a payment on the old profile id. That seems
to be what is happening on my test system?

Many thanks
PeterHuk

[Jason Caldwell]

Yes, that is possible, but only if the Billing Modification occurs after a payment has been received on the old Recurring Profile. Once a Billing Modification takes place, a new Billing Profile is created to replace the old one. Once the old one is terminated, no further payments will be processed on that old Billing Profile ( it's been terminated ). If you are finding this is NOT the case, please feel free to post log entries from s2Member that indicate this, and we'll be happy to investigate for you.

[peterhuk]

Hi Jason,

Many thanks for your reply, the logs that suggests payment on old profiles
are all simular to the one above:

http://www.primothemes.com/forums/viewtopic.php?f=4&t=14582&p=32579#p32342

Please let me know

PeterHuk
PS please show example of a log generated my S2 that states the profile has been
terminated.

[Jason Caldwell]

Perfect. Thanks.

OK. So now lets see the /s2member-logs/paypal-api.log entry that shows the following:

Code: Select all

METHOD = ManageRecurringPaymentsProfileStatus
ACTION = Cancel

Once I have this additional log entry, we can compare the dates.

[peterhuk]

Hi Jason,

The only type of IPN I can find with cancel is as follows:

Code: Select all

'txn_type' => 'recurring_payment_profile_cancel',
'profile_status' => 'Cancelled',

  array (
    0 => 'IPN received on: Sat Jul 30, 2011 12:57:07 am UTC',
    1 => 's2Member POST vars verified through a POST back to PayPal®.',
    2 => 'Transaction type ( recurring_payment_profile_cancel ), but there is no match to an existing account; so verification of _SERVER[HTTP_HOST] was not possible.',
    3 => 'It\'s likely this account was just upgraded/downgraded by s2Member Pro; so the Subscr. ID has probably been updated on-site; nothing to worry about here.',
  ),

But I have no problem with these. As you stated above:

a new Billing Profile is created to replace the old one. Once the old one is terminated, no further payments will be processed on that old Billing Profile ( it's been terminated ).

Could there be a scenario where if multiple modifications are made
in a short space of time (even though a terminate api is sent) will
Paypal still attempt to take the initial payment (using the delete
@sandbox.paypal.com email address)?

PeterHuk

[Jason Caldwell]

Thanks for the follow-up.

Could there be a scenario where if multiple modifications are made
in a short space of time (even though a terminate api is sent) will
Paypal still attempt to take the initial payment (using the delete
@sandbox.paypal.com email address)?

Hmm. Yea, I imagine if you had a Billing Modification form setup, where many new Recurring Profiles were being created by the same customer and then terminated very quickly, it's possible that one of their newly created Recurring Profiles, which s2Member would attempt to terminate during a Billing Modification, may still be in a `Pending` state on the PayPal side of things; in which case the termination of the Recurring Profile could fail. Perhaps that's what you're seeing? I'm not sure where the delete@sandbox.paypal.com is coming from though. That's not something I'm familiar with.

The log entry I was looking for would have been only inside /paypal-api.log, as it's a direct API call, it's not an IPN; because it's a communication directly from s2Member Pro to the PayPal Pro API.

[peterhuk]

Hi Jason,

Thanks, I think it might be that fact that I did a number of updates in quick succession. If that
is the problem then on a live server I don't expect that to happen to often.

By the way here is a api call I found. It's not the most recent because I have S2 logs switched off
as I have the ipn's auto loged to DB.

Code: Select all

WordPress® v3.2.1 :: s2Member® v110731 :: s2Member® Pro v110731
mydomain.com/advertise-with-us/?s2member_paypal_xco=s2member_pro_paypal_checkout_return&token=EC-xxxxxxxxxxxxxx
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
-------- Input vars: ( Sat Aug 6, 2011 8:57:53 pm UTC ) --------
array (
  'PROFILEID' => 'I-xxxxxxxxxxxx',
  'METHOD' => 'ManageRecurringPaymentsProfileStatus',
  'ACTION' => 'Cancel',
  'VERSION' => '71.0',
  'USER' => 'my_email_api1.mydomain.com',
  'PWD' => 'xxxxxxxxxxxxxxxx',
  'SIGNATURE' => 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
)
-------- Output string/vars: ( Sat Aug 6, 2011 8:57:54 pm UTC ) --------
TIMESTAMP=2011%2d08%2d06T20%3a57%3a54Z&CORRELATIONID=xxxxxxxxxxxxx&ACK=Failure&VERSION=71%2e0&BUILD=2020243&L_ERRORCODE0=11556&L_SHORTMESSAGE0=Invalid%20profile%20status%20for%20cancel%20action%3b%20profile%20should%20be%20active%20or%20suspended&L_LONGMESSAGE0=Invalid%20profile%20status%20for%20cancel%20action%3b%20profile%20should%20be%20active%20or%20suspended&L_SEVERITYCODE0=Error
array (
  'TIMESTAMP' => '2011-08-06T20:57:54Z',
  'CORRELATIONID' => 'xxxxxxxxxxxxx',
  'ACK' => 'Failure',
  'VERSION' => '71.0',
  'BUILD' => '2020243',
  'L_ERRORCODE0' => '11556',
  'L_SHORTMESSAGE0' => 'Invalid profile status for cancel action; profile should be active or suspended',
  'L_LONGMESSAGE0' => 'Invalid profile status for cancel action; profile should be active or suspended',
  'L_SEVERITYCODE0' => 'Error',
  '__error' => 'Error# 11556. Invalid profile status for cancel action; profile should be active or suspended. Invalid profile status for cancel action; profile should be active or suspended.',
)

If you find anything in the logs great else I'll put it down to over intense system testing.

Many thanks
PeterHuk

[Jason Caldwell]

Yea, that's exactly what's happening. The error in that log entry is exactly what I would expect to see if an existing Recurring Profile was still in a pending state on the PayPal side of things. PayPal's API won't let s2Member cancel the old Recurring Profile until it's actually active. That usually takes just seconds to sometimes minutes, but if you're testing things heavily you might see this behavior.

[peterhuk]

Many thanks Jason,

So in this scenerio, the deleted profile maywell attempt to continue taking payment.

The obvious question is, would it be worth incorporating a mechanism that on
this event would send an email to the site admin so that they can manually
investigate (before the customer sends an email demanding a refund)?

Many thanks

PeterHujk

[Jason Caldwell]

Definitely. I'm going to take a look to see if there is something we can do in the validation routines so that this never even occurs. Thank you!

[peterhuk]

Many thanks Jason

[peterhuk]

Hi Jason,

I know you’re already onto this but I had a thought and just want to share it.

From what I was able to gather the setting up of a reoccurring payment
starts with a:

Code: Select all

'METHOD' => 'CreateRecurringPaymentsProfile' api

sent form S2meber to Paypal. To which the expected response would
be.

Code: Select all

'PROFILESTATUS' => 'PendingProfile',

From this point, what if for reoccurring payments S2members creates / sets a
Pending user_meta(). Whilst set any further attempt to initiate
a reoccurring subscription payment would be halted and met with a
S2member => Previous Transaction Still Pending error.

Once the appropriate Paypal api / ipn is received (maybe a
'txn_type' => 'recurring_payment_profile_created' ipn) the
Pending user_meta() can be set to false and subsequent
subscription modification could continue.

So effectively for this account when Paypal is in pending S2Member will
also be in pending.

Hope this helps

PeterHuk