Community Support Forums

Hi Jason,

I signed up a test user and made a purchase using the Sandbox, which resulted in s2membeLevel 3 getting set, as expected.

I then went to the seller account and refunded the purchase (100% refund).

The level did not change.

A refund notification was sent, but no eot notification was sent.

These are "membership purchases" for one year membership using Buy Now buttons.

Any ideas?

I can execute the demotion from the refund notification as a work-around, but I would rather see this work as expected. Thanks.

Thanks for reporting this important issue.
~ I'll have a look into this.

In the mean time, if you have the paypal-ipn.log file that that shows the IPN notification that came in for the refund, please feel free to post that. It may help to speed up this bug fix.

@C/TODO :: bug investigation.

love the GTD workflow here Jason, pretty unique way to use it!

Hi,

i tried testing on the refund as well, yet my user is not demoted also. Please advise. Thank you.

The log stated that it has created a queue on auto-eot cron, but i waited for almost a day as well as running the cron manually, yet it still doesn't reflect that the user has been demoted from the database.

This is the extracted from the paypal-ipn.log:

Code: Select all

array (
  'transaction_subject' => '',
  'payment_date' => '07:22:55 Aug 09, 2010 PDT',
  'subscr_id' => 'I-L2458NG3Y311',
  'last_name' => 'User',
  'residence_country' => 'AU',
  'item_name' => 'Yearly Billing',
  'payment_gross' => '-39.99',
  'mc_currency' => 'USD',
  'business' => 'test_1281262518_biz@gmail.com',
  'payment_type' => 'instant',
  'protection_eligibility' => 'Ineligible',
  'verify_sign' => 'AFcWxV21C7fd0v3bYYYRCpSSRl31AmeQcHgnf28xxcF6b-CZIRx0VvVM',
  'test_ipn' => '1',
  'payer_email' => 'test_1281360459_per@gmail.com',
  'txn_id' => '0WT53966SS0857921',
  'receiver_email' => 'test_1281262518_biz@gmail.com',
  'first_name' => 'Test',
  'parent_txn_id' => '8HM7755766142574C',
  'payer_id' => 'V4EAHLHQ6EPZ6',
  'receiver_id' => 'Z87YXCU7B5DCC',
  'reason_code' => 'refund',
  'item_number' => '1:kboney',
  'payment_status' => 'Refunded',
  'payment_fee' => '-1.56',
  'mc_fee' => '-1.56',
  'mc_gross' => '-39.99',
  'custom' => 'plan.mytest.com',
  'charset' => 'windows-1252',
  'notify_version' => '3.0',
  's2member_log' =>
  array (
    0 => 'IPN received on: Mon Aug 9, 2010 2:23:08 pm UTC',
    1 => 's2Member POST vars verified through a POST back to PayPal¬Æ.',
    2 => 's2Member originating domain ( _SERVER[HTTP_HOST] ) validated.',
    3 => 's2Member txn_type identified as (subscr_eot|recurring_payment_expired|recurring_payment_suspended_due_to_max_failed_payment) - or - recurring_payment_profile_cancel w/ initial_payment_status (failed) - or - new_case w/ case_type (chargeback) - or - !txn_type w/ payment_status (refunded|reversed).',
    4 => 'Skipping (demote|delete) Member, for now. An Auto-EOT Time is already set. When an Auto-EOT Time has been recorded, s2Member will handle EOT (demote|delete) events using it\'s own Auto-EOT System.',
  ),

Jason Caldwell wrote:Thanks for reporting this important issue.
~ I'll have a look into this.

In the mean time, if you have the paypal-ipn.log file that that shows the IPN notification that came in for the refund, please feel free to post that. It may help to speed up this bug fix.

@C/TODO :: bug investigation.

Code: Select all

array (
  'mc_gross' => '-40.00',
  'protection_eligibility' => 'Ineligible',
  'payer_id' => 'WEJKJARFGGZGQ',
  'payment_date' => '17:19:34 Aug 01, 2010 PDT',
  'payment_status' => 'Refunded',
  'charset' => 'windows-1252',
  'first_name' => 'Test',
  'option_selection1' => '91',
  'mc_fee' => '-1.46',
  'notify_version' => '3.0',
  'reason_code' => 'refund',
  'custom' => 'usbgf.dreamhosters.com|91',
  'business' => 'richard.munitz@misys.com',
  'verify_sign' => 'AKCL94C-Py5D27VH1RRJfoidoQV8ATCej1RAvxtw.mSvj.5MkaKH555V',
  'payer_email' => 'bogus_1280006595_per@misys.com',
  'option_name1' => 'Updating Subscr. ID',
  'parent_txn_id' => '4S4879874S611660X',
  'txn_id' => '2AV76860XX410010E',
  'payment_type' => 'instant',
  'last_name' => 'User',
  'receiver_email' => 'richard.munitz@misys.com',
  'payment_fee' => '-1.46',
  'receiver_id' => 'TEDAK24DCNSZY',
  'item_name' => 'Premium Member',
  'mc_currency' => 'USD',
  'item_number' => '3::1 Y',
  'residence_country' => 'US',
  'test_ipn' => '1',
  'handling_amount' => '0.00',
  'transaction_subject' => 'usbgf.dreamhosters.com|91',
  'payment_gross' => '-40.00',
  'shipping' => '0.00',
  's2member_log' =>
  array (
    0 => 'IPN received on: Mon Aug 2, 2010 12:19:40 am UTC',
    1 => 's2Member POST vars verified through a POST back to PayPal®.',
    2 => 's2Member originating domain ( _SERVER[HTTP_HOST] ) validated.',
    3 => 's2Member txn_type identified as (subscr_eot|recurring_payment_expired|recurring_payment_suspended_due_to_max_failed_payment) - or - recurring_payment_profile_cancel w/ initial_payment_status (failed) - or - new_case w/ case_type (chargeback) - or - !txn_type w/ payment_status (refunded|reversed).',
    4 => 'Skipping (demote|delete) Member, for now. An Auto-EOT Time is already set. When an Auto-EOT Time has been recorded, s2Member will handle EOT (demote|delete) events using it\'s own Auto-EOT System.',
  ),
  'subscr_id' => '4S4879874S611660X',
)


Interesting note in the log:

Skipping (demote|delete) Member, for now.

Whoops! That must point to what needs to be fixed.

For now, I am working around this by running the demotion myself after receiving a notification via the following hook:

ws_plugin__s2member_during_paypal_notify_during_subscr_eot_refund_reversal

which does indeed activate during a refund IPN.

Jason Caldwell wrote:Thanks for reporting this important issue.
~ I'll have a look into this.

In the mean time, if you have the paypal-ipn.log file that that shows the IPN notification that came in for the refund, please feel free to post that. It may help to speed up this bug fix.

@C/TODO :: bug investigation.

I found the bug, it is due to the depreciation of "get_usermeta" function since wp3.0, should be using "get_user_meta" for wp3.0 instead.

@COMPLETED/TODO :: bug investigation.

s2Member v3.2+ corrects this bug.

- Bug fix. s2Member's PayPal® IPN processor was logging `Skipping Auto-EOT for now ...`, with Refund/reversal IPNs; when a particular Member already had an EOT-Time set. This was NOT the intended behavior in this scenario. In this release, s2Member has been updated to ignore existing Auto-EOT Times under this one special circumstance ( Refund/Reversal ). A Refund/Reversal will ALWAYS trigger an immediate EOT now.

Hi Jason,

My client determined that forcing an EOT on Refund/Reversal would be a mistake. Here are some scenarios in which it would not be desired.

1) A Partial Refund.

2) A Renewal. Say someone signed up for a year, and 11 months later, they renew - but that payment gets reversed or refunded for some reason. Instead of an immediate EOT, they should have one month left to run.

Is there any way to DISABLE this behavior now? Otherwise, I CANNOT UPDATE to version 3.2!

Thank you.

Best Regards, Marty

Thanks for reporting back on this Martonic.

I see your point. @TODO :: So we need an option for this under EOT Behavior, specifically for Refunds, and specifically for Reversals.

Until then, you can find this section inside: /includes/functions/paypal-notify.inc.php ( line #786 )

Code: Select all

if (!get_user_option ("s2member_auto_eot_time", $user_id) ||
(!$paypal["txn_type"] && preg_match ("/^(refunded|reversed)$/i", $paypal["payment_status"]) && $paypal["parent_txn_id"]))

Change it to this for the short term:

Code: Select all

if (!get_user_option ("s2member_auto_eot_time", $user_id) && !preg_match ("/^(refunded|reversed)$/i", $paypal["payment_status"]))