Unable to verify post_vars on subscription payments from Paypal Poland

Not sure what’s happening there. As I require all my payments to be handled by s2member to afterwards hook in my invoicing - I noticed that except to payments last quarter where I missed the invoice (those don’t appear at all in the log - so somehow missed the IPN completely - all other missed ones where from Paypal Poland (last quarter I missed hundreds of payments - but I had not enabled logging so don’t know what happened there). All of them this quarter besides the 2 missing were like the following (and all have some very special characters in their address or state but not sure if that’s related)

LOG ENTRY: Fri Jan 6th, 2023 @ precisely 10:24 am UTC
PHP v8.1.13 :: WordPress v6.1.1 :: s2Member v221103 :: s2Member Pro v220421
Memory 13.37 MB :: Real Memory 16.00 MB :: Peak Memory 13.45 MB :: Real Peak Memory 18.00 MB
User-Agent: PayPal IPN ( https://www.paypal.com/ipn )
[s2member_log] => Array
[0] => Unable to verify $_POST vars. This is most likely related to an invalid configuration of s2Member, or a problem with server compatibility.
[1] => Please see this KB article: http://www.s2member.com/kb/server-scanner/. We suggest that you run the s2Member Server Scanner.
[2] => array (
‘s2member_paypal_notify’ => ‘1’,
‘mc_gross’ => ‘13.00’,
‘invoice’ => ‘5fe9…~178…’,
‘protection_eligibility’ => ‘Eligible’,
‘address_status’ => ‘confirmed’,
‘payer_id’ => ‘AZXJ…’,
‘address_street’ => ‘Ul.’,
‘payment_date’ => ‘02:23:51 Jan 06, 2023 PST’,
‘payment_status’ => ‘Completed’,
‘charset’ => ‘windows-1252’,

Yeah, that’s an odd behavior.

Do all those missed PayPal Poland notifications have the “unable to verify $_POST vars” message? Are you getting some through, and do you notice something in those different from the skipped ones?

Did you miss others besides those? Are any missing even from the s2 log? If so, could you look one of those up in your PayPal notifications history, and see what URL they mention? And if it’s s2’s URL, what happens if you resend it? https://www.paypal.com/merchantnotification/ipn/history

Nope, it affected all payments from polish customers, nothing else different about them. And all are exactly like this in the PayPal log and supplementary logs had no information at all. All other subscription had no problems for that quarter.
Last quarter s2member missed about every second payment for 20 days. But I didn’t have logging enabled so it was a complete mess for me to write all invoices by hand into the system (my invoice plugin requires s2member to handle the notification)


And from the PayPal IPN History, one of those that s2 didn’t take, could I see the variables it shows for that notification? (edited for privacy)

If you do an advanced users export with s2, pick the user for the notification above, for which the notification was skipped by s2, and see if that user has in his profile the subscr ID and signup vars, please.

1 Like

The paypal history in my account only goes back 28 days. The problem is that I check for failed payments only once every 3 months because it’s quite complicated (I need to put all invoice information and paypal logs into excel - then run a query for finding missing invoices).

However sometimes (not in the last quarter) the same/similar error happens for new users. Usually they contact me via email because they paid and didn’t get an account. Not sure have to check again in log once that happens for the error message.

Last 28 days I can only find a single failed one (without running a check on this month):
Here is the IPN edited for privacy:


and I don’t know if his profile at the time included the subscriber ID (still does) but I don’t know about signup vars because I deleted them in the meantime. As many people pay year by year I would notice if it’s always the same users where it fails - which it isn’t . It seems pretty random - though sometimes fails for the same user two years in a row (even though subscriber ID present).

With this user the subscription was created in 2021. In 2022 everything went fine with the payment and this year in 2023 it failed.
And the usermeta must have been identical besides deleted information in the meantime.

Actually I just did the work and looked through the last 10 days - and again one payment was missed, again from paypal Poland (about 1/3 of Paypal Poland payments are missed).

This time I could send the IPN notice again - and the resend worked. So something very strange in s2member is misbehaving. Attached both log files, the IPN message (all redacted to remove private details but keeping special characters though I think that doesn’t matter?) and also the wp usermeta redacted (no change in that one the last two days)


LOG ENTRY: Sun Apr 9th, 2023 @ precisely 10:47 am UTC
PHP v8.1.16 :: WordPress v6.2 :: s2Member v221103 :: s2Member Pro v220421
Memory 10.44 MB :: Real Memory 20.00 MB :: Peak Memory 10.46 MB :: Real Peak Memory 20.00 MB
User-Agent: PayPal IPN ( https://www.paypal.com/ipn )
[s2member_log] => Array
[0] => Unable to verify $_POST vars. This is most likely related to an invalid configuration of s2Member, or a problem with server compatibility.
[1] => Please see this KB article: http://www.s2member.com/kb/server-scanner/. We suggest that you run the s2Member Server Scanner.
[2] => array (
‘s2member_paypal_notify’ => ‘1’,
‘mc_gross’ => ‘13.00’,
‘invoice’ => ‘5caca3cd75687~87.IPaddress’,
‘protection_eligibility’ => ‘Eligible’,
‘address_status’ => ‘confirmed’,
‘payer_id’ => ‘2BJJKUAN2GF3U’,
‘address_street’ => ‘Po 60’,
‘payment_date’ => ‘03:47:26 Apr 09, 2023 PDT’,
‘payment_status’ => ‘Completed’,
‘charset’ => ‘windows-1252’,
‘address_zip’ => ‘32-420’,
‘first_name’ => ‘Kamil’,
‘option_selection1’ => ‘openmtbmap.org’,
‘option_selection2’ => ‘87.IPaddress’,
‘mc_fee’ => ‘0.73’,
‘address_country_code’ => ‘PL’,
‘address_name’ => ‘Kamil Makname’,
‘notify_version’ => ‘3.9’,
‘subscr_id’ => ‘I-04X4675G7DUK’,
‘custom’ => ‘openmtbmap.org|87.IPaddress|IT|QA|+97PHONE’,
‘payer_status’ => ‘unverified’,
‘business’ => ‘myemail@gmail.com’,
‘address_country’ => ‘Poland’,
‘address_city’ => 'Gd󷧬
‘verify_sign’ => ‘ArTxFmh-Dg57v.MlYNvVRMMpbRUGAyMRKvR1rclgkCHXQpF3gM62feks’,
‘payer_email’ => ‘buyer@email’,
‘option_name1’ => ‘Originating Domain’,
‘option_name2’ => ‘Customer IP Address’,
‘txn_id’ => ‘0MD038293A223642L’,
‘payment_type’ => ‘instant’,
‘last_name’ => ‘Makname’,
‘address_state’ => ‘maofirstname’,
‘receiver_email’ => ‘myemail@gmail.com’,
‘payment_fee’ => ‘’,
‘receiver_id’ => ‘Z89X4K6BZYG2E’,
‘txn_type’ => ‘subscr_payment’,
‘item_name’ => ‘First year access for €20, then €13 each year (recurring_charge, for OpenMTBMap access)’,
‘mc_currency’ => ‘EUR’,
‘item_number’ => ‘1’,
‘residence_country’ => ‘PL’,
‘transaction_subject’ => ‘First year access for €20, then €13 each year (recurring_charge, for OpenMTBMap access)’,
‘payment_gross’ => ‘’,
‘ipn_track_id’ => ‘bb91c860ad33c’,


LOG ENTRY: Tue Apr 11th, 2023 @ precisely 2:26 pm UTC
PHP v8.1.16 :: WordPress v6.2 :: s2Member v221103 :: s2Member Pro v220421
Memory 13.28 MB :: Real Memory 20.00 MB :: Peak Memory 13.48 MB :: Real Peak Memory 22.00 MB
User-Agent: PayPal IPN ( https://www.paypal.com/ipn )
[payer_id] => 2BJJKUAN2GF3U
[address_country_code] => QA
[option_selection1] => openmtbmap.org
[option_selection2] => 87.IPaddress
[ipn_track_id] => bb91c860ad33c
[address_zip] => 32-420
[invoice] => 5caca3cd75687~87.IPaddress
[charset] => windows-1252
[payment_gross] =>
[address_status] => confirmed
[address_street] => Po 60
[verify_sign] => AFvRfUENPz8aUZEUZ07giwk3gm1.AVKwNB6H050s3PNALDPPuNCyjz0i
[item_name] => First year access for €20, then €13 each year (recurring_charge, for OpenMTBMap access)
[txn_type] => subscr_payment
[receiver_id] => Z89X4K6BZYG2E
[payment_fee] =>
[mc_currency] => EUR
[transaction_subject] => First year access for €20, then €13 each year (recurring_charge, for OpenMTBMap access)
[custom] => {“ip_address”:“87.IPaddress”}
[protection_eligibility] => Eligible
[address_country] => Poland
[payer_status] => unverified
[first_name] => Kamil
[address_name] => Kamil Makname
[subscr_id] => I-04X4675G7DUK
[mc_gross] => 13.00
[payment_date] => 03:47:26 Apr 09, 2023 PDT
[payment_status] => Completed
[business] => myemail@gmail.com
[item_number] => 1
[last_name] => Makname
[address_state] => maofirstname
[txn_id] => 0MD038293A223642L
[mc_fee] => 0.73
[resend] => true
[payment_type] => instant
[notify_version] => 3.9
[option_name1] => Originating Domain
[option_name2] => Customer IP Address
[payer_email] => buyer@email
[receiver_email] => myemail@gmail.com
[address_city] => Gdów
[residence_country] => PL
[option_selection] => openmtbmap.org
[option_name] => Originating Domain
[s2member_log] => Array
[0] => IPN received on: Tue Apr 11, 2023 2:26:36 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_payment|recurring_payment ).
[4] => Sleeping for 15 seconds. Waiting for a possible ( subscr_signup|subscr_modify|recurring_payment_profile_created ).
[5] => Awake. It’s Tue Apr 11, 2023 2:26:51 pm UTC. s2Member txn_type identified as ( subscr_payment|recurring_payment ).
[6] => Updated Payment Times for this Member.
[7] => Payment Notification URLs have been processed.
[8] => Payment Notification Emails have been processed.

[subscr_gateway] => paypal
[subscr_baid] => I-04X4675G7DUK
[subscr_cid] => I-04X4675G7DUK
[level] => 1
[ccaps] => 
[ip] => 87.IPaddress
[currency] => EUR
[currency_symbol] => €


Actually as erroneous as this is - I think if I resend those IPN calls - then 99% would be accepted. Something in s2member communicating with paypal is going wrong. And maybe for the log s2member should always keep the IPN message in the log if it decides to stop for that error? Or better of course if you can find the reason and solve it. I am sure EVERYONE is affected by this just they don’t notice it because they have no way to check for this.
And sometimes also new user sign ups go missing from paypal. I hope I can get a log file for one of them at some point - often but not everytime I notice because user send me message about payment but no account - and s2member didn’t send any emails but I find the payment.
Oh yeah and I’ve never missed a Stripe payment. Only paypal. At least I think so (with Stripe the invoices don’t go via s2member but I use quaderno.io hook right into Stripe - but I’ve never missed the creation of an account so thing Stripe is fine)

Just an idea - could s2member signal paypal to resend the message / give a message not acccepted if the error:
Unable to verify $_POST vars. This is most likely related to an invalid configuration of s2Member, or a problem with server compatibility.

appears? That should solve most problems. Yes not if the server actualy is misconfigured - but even then it would be fine because paypal will give up after some tries and send you an email.

And exactly this error message can happen on new subscribtions or one time payments too. Actually in the past I sometimes went into paypal and sersent them. But then it’s faster to just create the user manually and create invoice manually beause it takes quite some time to fish out the IPN call and login into paypal IPN history.

I could not try to resend the IPN for the one from last month - because I already manually created the invoice and otherwise would send two invoices for one payment (would not happen if IPN call goes through twice - but if I manually create it no way for quaderno.io to identify a duplicate)

Any updates help on this? I’m 100% sure everyone using S2member is affected this but most simply only notice when it happens on initial payment.
Needing to create a user because if this bug and making copy paste error (domain in ipn field) once really broke my stripe integration (users not demoted if subscription is over). The stripe integration of s2member is stable, the PayPal one isn’t because of this bug occasionally occuring. (And this is not due to my server. It happened first on Apache running Suse, then nginx and several Ubuntu versions).

I haven’t had a new signup where this happened so I cannot provide logs and will update it next time it happens but this is really S2members biggest longtime bug and manually creating users is dangerous if you mess up. Also some people would already file complaints or even charge backs before informing you if their account isn’t instantly created

(Yeah the waiting interval that was introduced maybe 4-5 years ago at PayPal solved most problems with PayPal because before that it was like 10% missed not 1% but even 1% is not acceptable. And yeah I’m sure the error is somehow in PayPal doing things slightly slow or different because sending the ipn notification again usually resolves it but s2 should simply never drop a ipn message this way but ask PayPal to send it again…).