Jason (Lead Developer)

Do you have any idea where to start on troubleshooting this issue? Would my silent post url have anything to do with it?

Thanks for the follow-up.

No, the silent post integration should not have any impact this.

I would start looking at your authnet-api.log file for log entries that include x_method=cancel and an x_subscription_id matching the old ARB that should have been cancelled. If there is a communication issue between your site and the Authorize.Net API, the log entry should indicate that problem.

In my investigation, I did not find any references to x_method=cancel at all; indicating to me there could be a problem with the Pro Form Shortcode.

If you would like to submit a Dashboard login for me, I’ll run diagnostics for you. Also, please post the s2Member Pro Form Shortcode that’s being used. Please make sure that your Shortcode does not have level="*".

Thanks for the heads up guys!

Thanks for your patience while we worked through this issue.

s2Member v130510 is now available (among other things, it resolves this issue).
Please see: http://www.s2member.com/changelog/#s2-changes-v130510

Changelog Excerpt:

(s2Member Pro) Updating Payflow Integration w/ Payflow Bug Workaround

Updating Payflow integration to support Billing Agreement IDs (aka: BAID values) when working together with Payflow Express Checkout APIs (and where a site owner is charging on a recurring basis).

This improvement also allows s2Member to work around a Payflow bug where BILLINGTYPE=RecurringPayments results in error #7 (Invalid/Expired TOKEN) whenever Payflow attempts to rebill a customer. s2Member now sets BILLINGTYPE=RecurringBilling; and we pass BAID=B-xxxxxx instead of passing TOKEN=xxxxxx.

Site owners also need to contact PayPal MTS and ask to have Reference Transactions (free) enabled for Recurring Billing service. If you attempt to checkout through an s2Member Pro Form, and you get error #11452 “Merchant not enabled for Reference transactions”; this is the reason.

You need to enable Reference transactions. If you have accounts at PayPal.com (and also an account at manager.paypal.com); where these accounts are connected to each other; Reference Transactions MUST be enabled in both places. It’s a vetted process, so you are required to contact PayPal MTS about this.

~ However, you ONLY need Recurring Billing service and Reference Transactions enabled IF you’re operating a PayPal Payments Pro (Payflow Edition) account; and only IF you’re charging customers on a recurring basis.

Why do I need to contact PayPal MTS about Reference Transactions?

As noted above, s2Member now sets BILLINGTYPE=RecurringBilling; and we pass BAID=B-xxxxxx instead of passing TOKEN=xxxxxx. A `BAID` is a Billing Agreement ID; and this requires your account to have Reference Transactions enabled; in order to process Recurring Billing Profiles via Express Checkout.

Express Checkout is used whenever a customer chooses to use PayPal as their billing method. Reference Transactions (e.g. BAIDs) are not required to process credit card transactions. Only for Express Checkout via PayPal, where a customer has specifically chosen to pay you via PayPal.

Why BILLINGTYPE=RecurringBilling instead of BILLINGTYPE=RecurringPayments?

We do this because there is a bug (on the Payflow side of things) with BILLINGTYPE=RecurringPayments; which actually stems (in part) from the way PayPal enables Recurring Billing service under the Payflow Edition. They enable Recurring Billing (as opposed to Recurring Payments). Anyway, this is all quite confusing, and explaining this in full detail would require another dedicated article about PayPal’s naming conventions :-) We may publish more information on this in the s2Member KB over the next few days.

Payflow Recurring Billing Profiles Don’t Show Up @ PayPal.com?

When you have a PayPal Payments Pro (Payflow Edition) account, Recurring Billing is handled via Payflow APIs (this is a PayPal standard, and NOT an s2Member standard). As a result, all Recurring Billing Profiles are maintained (i.e. viewable/editable) at manager.paypal.com. If you don’t have a PayPal Manager login, please contact PayPal MTS and request one.

Thanks for your patience.

~ I apologize for the long delay on this.

I think it with this profil Id: I-M89T1LXF2L6P

I’m sorry but I was unable to find a reference in any of your s2Member® log files related to this ID.

I just had another problem with someone tried to get a membership, but he’s from Germany, every time someone from Germany tried to get a membership I have to do it manually and it working.

I investigated your log files and inspected cases where German customers were attempting checkout. In the cases that I found, you had customers that were attempting to complete checkout via PayPal Express Checkout. s2Member Pro redirected them to PayPal Express Checkout after the customer chose PayPal as their preferred payment method. However, your log files indicate that these customers either:

(a) never returned from PayPal Express Checkout,

or (b) there was a processing failure on the PayPal end that may have prevented s2Member from being notified about the transaction.

I suspect the underlying cause of this could be this setting in your PayPal account.
Please check this section of your PayPal Account: Profile -› Website Payment Preferences

I don’t have an Id for this transaction but it’s the last attempt: his email is: c——-@googlemail.com
Thank you for your help Jason

I found log entries related to this transaction. It was the same case as above. Your log files indicate the customer was redirected to PayPal Express Checkout but never returned from checkout at PayPal.

s2Member’s API call that initiated PayPal Express Checkout succeeded, but this was the last log entry associated with this customer. Therefore, I must assume the customer never returned from PayPal Express Checkout. Or, if they did, your web server refused the connection for some reason (perhaps); you might check your Apache log files for issues related to things like Mod Security or another server-side failure upon the customer’s return.

If this customer returned from PayPal Express Checkout, s2Member did not know about it.

-------- Output string/vars: ( Thu Mar 21, 2013 3:18:25 pm UTC ) --------
RESULT=0&RESPMSG=Verified&TOKEN=EC-1H255967JL939584F&CORRELATIONID=7e92166448630
array (
  'RESULT' => '0',
  'RESPMSG' => 'Verified',
  'TOKEN' => 'EC-1H255967JL939584F',
  'CORRELATIONID' => '7e92166448630',
)

The customer would have been returned to this URL after completing checkout at PayPal.

array (
  'TRXTYPE' => 'A',
  'ACTION' => 'S',
  'TENDER' => 'P',
  'RETURNURL' => 'http://www.m----f----.com/monthly-membership/?s2member_paypal_xco=s2member_pro_paypal_checkout_return',

Please let us know if the problem continues in the latest release of s2Member®. I just made an attempt to reproduce this against the latest version; and with a sub-directory as well. So far everything seems fine.

1. It is a REST.GET.BUCKET instead of REST.GET.OBJECT like the first one.

s2Member® does not issue a REST call of any kind (other than to generate a link and redirect the customer to that link); which results in a RESTful API use on the part of s2Member; but the final call is established on the Amazon side of things, in the way it handles the URL that we generate.

Based on the output in XML that you supplied earlier, I’m not surprised to see that method being processed by the logs. The question is why was it doing that. It sounds like, the URL was corrupted in some way to me. If that came from the previous PATCH file we supplied, please try the official release of s2Member® and report back.

2. The file name is not at the beginning of “GET /” but is a parameter buried unlike “GET /doof.png”

This is to be expected. s2Member® configures the request beyond that of what many simple services will do.

3. Whatever response-requires is it expired a week ago (3/22) instead of today (3/29). (I did these tests last night.

This is to be expected. The expires value is intentionally set in the past, to prevent browser caching. This is simply the Expires: header value (s2 is following standards for this header). It’s NOT the expiration of the Bucket Object itself; which is configured in a separate component of the query string.

Thanks for the heads up on this thread :-)

I was unable to reproduce this myself. However, it sounds like this problem could be attributed to permission settings on your Bucket and/or a possible index file problem. Please make sure that your S3 Bucket is not publicly available, and that your S3 Bucket is not setup as a Static Host of any kind.

See also: https://forums.aws.amazon.com/message.jspa?messageID=108471

If problems persist, I would contact AWS about this, to find out why files served through authenticated URLs are resulting in a ListBucketResult set for you. This is not a normal occurrence.

Thanks for the follow-up…

Downgrading a customer can be accomplished by changing their Role on the site.
Please see: Knowledge Base » s2Member® Roles/Capabilities

You will want to set their Role back to a Free Subscriber status.

As for s2Member® doing this through an upgrade or downgrade process, that’s not something that an upgrade/downgrade Button or Pro Form would handle for you, because the Free Subscriber Role is at Level #0; it is reserved for Free Subscribers, or for paying customers that cancelled and were demoted back down. The act of cancelling your account, automatically demotes you back down to a Free Subscriber.

Please see also: Dashboard -› s2Member® -› PayPal® Options -› Automatic EOT Behavior

Thanks for your reply :-)

Yes, the new email log should be helpful, and server logs can also be helpful. If your site uses Sendmail, you can check your log files to see if the server is rejecting the email for some reason, or if there is some other problem.

I can tell you this is not a widespread issue, so I will have to assume that it’s something server-specific, or installation-specific. If you are having trouble with the log files, please post those privately and we’ll review them for you. Try to give me something to go on also (i.e. a specific transaction ID, or a specific email address; where I can do a lookup on a specific email message that should have been sent but was not).

Please use: s2Member® » Private Contact Form

Thanks!

Thanks for the heads up on this thread :-)

Regarding Subscription Modifications Buttons/Forms generated with s2Member®

Buttons (PayPal® Standard)

With PayPal Standard “Buttons”, a Modification is handled mostly on the PayPal side of things. There are details about this process at the PayPal website, and in the s2Member® documentation built into your Dashboard. The short version goes something like this…

Pro Forms (s2Member® Pro w/ PayPal® Pro Integration)

See: Dashboard -› s2Member® -› PayPal® Pro Forms -› Billing Modification Forms

The original question posted in this thread…

Dmitry Sandal wrote…

Hello!

We have two plans:
$ 7 / month
$ 50 for the first 2 years and then $ 50 / year

When the user selects $50 plan, he paid the full $50 for the first two years.
What happens if he decides to update its plan for $ 7 a month?
Will he get back the $ 50? If not, when it will begin to pay $ 7 a month, after 2 years? After the expiration of the first plan?

If the user cancels their subscription for $ 50 he will have access to the end of the subscription term? But if he decides to make another $ 50 subscription, he will lose the first $ 50?

When the user selects $50 plan, he paid the full $50 for the first two years.
What happens if he decides to update its plan for $ 7 a month?

When you generate your Modification Pro Form, you will need to grant the customer two free years (e.g. what the customer already paid you for); and then have the new billing start at $7/month moving forward beyond those 2 years they’ve already paid you for.

If the user cancels their subscription for $ 50 he will have access to the end of the subscription term?

Yes, the customer would continue to have access (even after cancelling);
for a full two years they have already paid you for. Please see this section of your Dashboard for further details/documentation on this behavior. Dashboard -› s2Member® -› PayPal® Options -› Automatic EOT Behavior

But if he decides to make another $ 50 subscription, he will lose the first $ 50?

Yes, this is possible, because if they purchase again, it wipes out their existing EOT Time, and allows them to start fresh on your site under the terms of their most recent purchase with you. s2Member® does NOT support multiple simultaneous subscriptions for any single customer.

I’m not sure I would term it “loses the original $50”, but I suppose that could happen, depending upon what the customer purchases next (i.e. what your site offers on that next purchase). If your site is providing access to something (normally the case with s2Member); the original $50 may have granted them access to something that their second purchase does not. It could happen, yes.

However, I’m not sure I follow you here completely. If this is happening on your site, you might want sell Custom Capabilities to existing customers instead of completely changing their primary Subscription.

In either case, this type of behavior is not something s2Member® will support natively, because s2Member® does NOT support multiple simultaneous subscriptions for any single customer. When one ends, we deal with the EOT Time for that one. If a new one takes it’s place; we’re now dealing only with the new one (e.g. the customer starts fresh under the terms of their most recent purchase).

Regarding time/date/amount calculations…

I noticed some discussion about this above. While it’s fine to do this (if you want to get very specific about things); this is NOT something that s2Member® will handle for you in any automated way; and this is by design. There are simply too many variables to consider; and too many business models in which one approach may work nicely, while another would handle the situation horribly.

There are also some important limitations on the PayPal® side of things that can prevent s2Member® from handling every possible scenario perfectly; IF we tried to update an existing Recurring Profile in an automated way. Such as raising the dollar amount or changing the frequency of billing; to which there are limitations imposed by PayPal®. This is why s2Member® Pro will actually terminate the previous Recurring Profile and replace it with a new one (to circumvent issues with the PayPal® Pro API when it comes to things like this). An s2Member® Pro Modification replaces the previous Recurring Billing with a new one; very simple. The new terms are dictated by the configuration of your Modification Pro Form. No limitations this way :-)

In most cases, it is NOT necessary to perform any advanced calculations. You can simply round things off in a way that is fair to both you and the customer. However, if you want to get specific, s2Member® stores the Last Payment Time for each customer for you; and this is a good way to calculate things like this. If you know the existing billing schedule, and you know the Last Payment Time; you can decide how many free days to give them, and make any advanced payment calculations that you’d like to make.

$s2member_last_payment_time = get_user_field ("s2member_last_payment_time"); # Timestamp. Last time an actual payment was received by s2Member.

See also: http://www.s2member.com/codex/stable/s2member/api_functions/package-functions/#src_doc_get_user_field()

Example using this technique to acquire every possible detail…

<?php
$user_id = get_current_user_ID();
$subscr_id = get_user_option('s2member_subscr_id', $user_id);

if (($paypal = c_ws_plugin__s2member_paypal_utilities::paypal_api_response (array('METHOD' => 'GetRecurringPaymentsProfileDetails', 'PROFILEID' => $subscr_id))) && !$paypal['__error'])
	print_r($paypal); // Gives you a full array of details.
?>

Further details here: https://www.s2member.com/forums/topic/last-payment-time-is-wrong/#post-28491

The $paypal variable will contain the following details, as documented by PayPal. This was pulled from the PayPal API docs, which are provided to you in your s2Member.com account. Upon logging in at s2Member.com, go to the My Account page, and download the s2m-pro-extras.zip file. Inside the zip file, you’ll find this information in the file: paypal-pro-api.pdf and/or payflow-pro-rec-api.pdf

<?php
$initial_period_days = 365 * 2; // Two years.
$new_monthly_amount = 7.00; // $7.00/monthly.

echo do_shortcode('&#91;&#91;s2Member-Pro-PayPal-Form tp="'.$free_days.'" tt="D" ta="0.00" rp="30" rt="D" ra="'.$new_monthly_amount.'" ... /&#93;&#93;');
?>

See also: Knowledge Base » Using Variables In A Shortcode
See also: Dashboard -› s2Member® -› PayPal® Pro Forms -› Shortcode Attributes (Explained)

Thanks for the heads up on this thread :-)

It does not work with Authorize.Net at all, because Authorize.Net does not notify s2Member about ANY type of refund/reversal. We do poll the Authorize.Net ARB system though, so with Subscriptions that are refunded and then terminated, that gets back to s2Member because of the termination; not because of the refund.

This is mentioned in the documentation here. I’m sorry.
Dashboard -› s2Member® -› Authorize.Net® Options -› Automatic EOT Behavior