decline to approved transaction account fail

Hi. I had a customer email me about how they had trouble accessing the online product they ordered. I assign all signed up pro-form users role level 1 and give them access to whatever they purchased based on whatever custom capability is set.

Here’s the situation. I had a user checkout, but their CVV was wrong, which resulted in a decline. They resubmitted their order with the correction a mere 20 seconds later, then the transaction was approved.

But their account “Paid Subscr. Gateway”, “Paid Subscr. ID”, “Custom Value”, and “Custom Capabilities” were all empty. Their account’s role level was also set to “Subscriber” instead of “s2member Level 1”.

The account was successfully created, but nothing else. So I’m wondering is there some sort of “race condition” that’s going on where authorize’s “Silent Post URL” is reporting too late that ends up erasing s2member’s user role upgrade?

So maybe this is happening:

1) transaction declines
2) second transaction succeeds 20 seconds later
3) One second after successful second transaction authnet’s Silent Post URL reports the first failed transaction
4) s2member downgrades user account from Level 1 to subscriber

But even that seems unlikely, because after a user successfully checkouts I refer them to a custom url which tracks the sale, and that page was never loaded.

I don’t know, but there seems to be an issue with a decline followed by a quick successful transaction that results in the “payment” part of s2member from executing.

I then thought of something else. I have s2member send “s2Member® API / Notifications” for “signup”, “registration”, and “payment”. The “signup” and “registration” Notifications URL’s were alerted to this checkout, but it doesn’t look like the “payment” notification was ever fired. So if it wasn’t fired for me, perhaps it was never fired within s2member’s own internal routines?

Thanks.

There definitely seems to be something weird happening in that case. I’ll ask Jason about it, since he’s the one that knows the API and integration best.

Investigation Results

Thanks for reporting this important issue.

The account was successfully created, but nothing else. So I’m wondering is there some sort of “race condition” that’s going on where authorize’s “Silent Post URL” is reporting too late that ends up erasing s2member’s user role upgrade?

I’m not aware of any race conditions with Authorize.Net integration. The Silent Post URL only handles incoming notifications regarding successfull payments, and NOT for failed payments. Failed payments are handled via the Authorize.Net ARB system, which is a different API all together. In either case though, the communication between s2Member and Authorize.Net is dependent upon the current Paid Subscr. ID value being a match to the data provided in communications from Authorize.Net. Thus, I’m not aware of a way for that to happen.

I then thought of something else. I have s2member send “s2Member® API / Notifications” for “signup”, “registration”, and “payment”. The “signup” and “registration” Notifications URL’s were alerted to this checkout, but it doesn’t look like the “payment” notification was ever fired. So if it wasn’t fired for me, perhaps it was never fired within s2member’s own internal routines?

Yes, this coupled with what you mentioned before, would indicate that post-processing of the transaction is failing on your installation. s2Member and s2Member Pro both work internally with an underlying set of core PayPal processors, which set the standard for s2Member’s post-processing of a transaction. The best way to debug this issue in s2Member, is to enable logging under: Authorize.Net Account Details in your Dashboard, and then look at both of these log files.

See: Dashboard -› s2Member® -› Authorize.Net® Options -› Account Details -› Logging

After a test transaction, please check these log files to assist you in debugging:

authnet-api.log This will indicate all details related to s2Member’s direct communication with Authorize.Net.

paypal-ipn.log Once s2Member’s Authorize.Net-specific routines have finished, s2Member will ultimately use it’s core PayPal processor to handle post-processing of a transaction, so some errors may exist here that will shed light on things for you. This log will be generated even with an Authorize.Net integration. Please feel free to submit log entries from these files, and we’ll review them with you here.

If problems persist, please submit a Dashboard login for us privately. We’ll run diagnostics on your installation. If it comes to that, please use this form: s2Member® » Private Contact Form

Hi Jason,

Thanks for commenting on this matter. I’ve submitted the support form.

It happened again today. But this time it was a paypal transaction and not authorize.net. As before, the “signup” and “registration” notification URL’s were fired off, but the “payment” notification URL wasn’t. This results in the user’s account being created, but resulted in the four values below being empty:

* Paid Subscr. Gateway
* Paid Subscr. ID
* Custom Value
* Custom Capabilities

I use paypal express checkout, and when looking at the visitor logs it looks like the user ended up at this address:
hxxp://www.example.com/cart-paypal/?s2member_paypal_xco=s2member_pro_paypal_checkout_return&PayerID=U3CZ7CFC72BY4

I use the javascript analytics software Clicky, and Clicky’s async code is only logged on pages that a browser visits (not redirects), and it would only log something like the above if something went wrong (probably due to the user not being properly redirected?)

Notice in the url above, the “PayerID” is 13 alpha-numeric characters. The real transaction ID for that user does not match the PayerID you see. None of my paypal transaction match that. Also, it appears that all of paypal’s transaction ID’s are 17 characters in length.

By the way, I am automatically logging in users after their transaction using the hacks file as suggested here:
http://www.s2member.com/forums/topic/auto-login-after-successful-payment/

I thought maybe it’s a paypal problem, so I was planning to perform a test transaction, but before I did another paypal user checked out successfully and everything went through properly. So it seems like some sort of phenomena is occurring with inconsistency, but the end result is the same: 1) signup & registration completing, payment routine failing. 2) user account not being properly updated with payment details. As you can see with the above URL, it appears their being kicked back to the site following the transaction, but their not moving forward properly from that point. Perhaps the invalid PayerID has something to do with it?

For my checkout page, I set a custom redirect url. That url checks to see if their subscriber level is “1” and they have a specific custom capability set. Since neither of those is true for these problematic transaction routines, these buyers are being kicked out of their product and given a “no access allowed” message as soon as they complete checkout. Unfortunately, since the payment aspect of their user record was empty, I have no alternative/backup way of establishing their access to a certain area.

FYI, the problem transaction took place at Dec 6, 2012 11:49:34 EST

Thanks.

I do want to add that these are rare occurrences. I’ve corrected them simply by manually updating the users’ account profiles. The vast majority of transactions are fine.

And just FYI… the first problem transaction was from a IE9 Windows 7 user. The other was a Firefox 17.0 Windows 7 user.

• This reply was modified 4 years, 1 month ago by  TJ.

I’ll let Jason reply to your questions, but I wanted to mention that the post-registration auto-login hack is known to cause the Notifications API to not work, the redirection in the hack causes the script to not get to the part where notifications happen. I don’t know if it may be affecting something else that, in your case, is causing part of your trouble. Could you test after deactivating the hack? Just as you’d test for a conflict with other plugins.

Hi Cristián,

The auto-login hack appears to work fine in the vast majority of cases. I really can’t disable it for usability reasons. It almost seems that for these problematic transactions the redirect didn’t take place. Perhaps the browser prevented it or the user clicked ESC. It would be good if there were a backup, such as a link asking the user to proceed to login, which would then fire off the “payment” notification, as the “signup” and “registration” notifications always appear to fire without a problem.

As for testing it, I don’t think that’s possible because this is happening rarely. Too rarely to successfully and consistently reproduce with a test. It’s just that the characteristics of the failure (when it happens) is similar:
1) successful transaction (authorize.net or paypal)
2) user account successfully created
3) signup & registration notifications successfully executed
4) user profile s2member payment fields not updated (left empty)
5) payment notification never fires

Thanks

As for testing it, I don’t think that’s possible because this is happening rarely. Too rarely to successfully and consistently reproduce with a test.

I see. It’d be good if you could find a common denominator between them… Did you review and compare the log entries for those specific transactions?

4) user profile s2member payment fields not updated (left empty)
5) payment notification never fires

The payment notification not happening is most likely because of the auto-login. Does it happen with other transactions, or it just never happens?

You could modify the auto-login hack, removing the redirection in the last line. Then the user would be logged in, but not redirected and the script can work normally. If you really need a redirection, test where the user ends up normally and see how you could add the redirection there.

Payment fields not updated seems to be a problem in only those rare cases, right?

Thank you for the follow-ups.

I just investigated this issue on your installation and also made an attempt to reproduce it in our lab.

I was unable to reproduce this in a clean installation of WordPress running the latest version of s2Member and s2Member Pro in our lab. However, I did find a few things on your installation which are likely causing the problems that you’ve reported thus far.

Here are some recommendations for you.

1. Please disable object caching. Object caching is known to cause problems with s2Member, as it is implemented by the W3 Total Cache plugin. It’s fine to leave Page Caching on, but I recommend disabling object and database caching for increased reliability. You can search the forums here and find others having issues with object caching in the past. It can DEFINITELY lead to the type of issues that you’ve reported.

NOTE: I see that you’ve actually NOT enabled object caching from W3 Total Cache. However, it appears that it was once enabled at some point, and that the file was never deleted from your /wp-content/ directory. See: /wp-content/object-cache.php. See also: Dashboard -> Plugins -> Drop-ins.

For good measure, I would also recommend that you add the following line to your W3 Total Cache configuration.

See: W3 Total Cache -> Page Caching -> Never cache the following pages

*\?s2member_*

If you have any trouble with W3 Total Cache, we recommend Quick Cache (developed by us).
http://wordpress.org/extend/plugins/quick-cache/

2. The hack that you mentioned is DEFINITELY a problem in this case. That hack is known to cause almost exactly the symptoms that you’ve reported. I would ditch that hack all together, because it interrupts post-processing being handled by s2Member Pro Forms. s2Member Pro will function properly without this hack. If running properly, s2Member Pro Forms DO display a login link after a successful checkout.

If you need to customize this process further, I would suggest the use of the success="" Shortcode Attribute provided by s2Member Pro Forms, instead of using that hack. So for instance, instead of implementing a hack that interrupts s2Member, you can redirect the customer to a page of your choosing after success. Then, on that custom page (which might actually just be a redirection if you like), you can do pretty much anything you like.

See: Dashboard -› s2Member® -› PayPal® Pro Forms -› Custom Return URLs Upon Success
See: Dashboard -› s2Member® -› PayPal® Pro Forms -› Shortcode Attributes (Explained)

3. Please upgrade to the latest version of s2Member & s2Member Pro so that we’re all on the same page with this bug report. The latest version at this time is v121204.

4. I would suggest that you make an attempt to reproduce this bug on a clean installation of WordPress so that both you/we will have a better chance of identifying the underlying cause of this issue. If all else fails and you ARE able to reproduce this on a clean installation of WordPress running only s2Member and the default WP theme; then we’ll take a look at that installation for you, hopefully with a more immediate resolution for you too.

---

Regarding the PayerID. That value would only be reflected in s2Member’s own logging routines (and only if you’ve enabled s2Member’s logging routines). It’s something that’s used behind-the-scene only. In fact, it only appears in the URL because PayPal passes that back to s2Member to identify what happened during Express Checkout, nothing more.

A PayerID will NEVER be reflected in your Dashboard, and it’s not tied to any of your customer accounts within WordPress. That’s a temporary ID that PayPal and s2Member use to communicate during the flow of checkout. It’s correct for that NOT to match up with a transaction or subscription ID.

Please let us know if problems persist.

Thanks Cristián and Jason. You’ve laid out several things that I need looking at. It’ll take me some time to go through them, but I appreciate that there’s a focal point.