Payments not properly registered paypal checkout

#1

I noticed already the second user emailing me about paying (I think both are one time payments not subscription) - which do not trigger the s2 payment received email nor the creation of an account.

The most relevant log entries are:
[s2member_log] => Array
(
[0] => IPN received on: Wed Feb 25, 2026 3:55:57 pm UTC
[1] => s2Member POST vars verified through a POST back to PayPal.
[2] => s2Member originating domain validation was skipped.
[3] => s2Member txn_type identified as ( cart ).
[4] => The txn_type does not require any action on the part of s2Member.
[5] => s2Member Pro handles Cart events on-site, with an IPN proxy.
)

[subscr_gateway] => paypal

I also have the paypal checkout log for this payment - but I am not sure about personal identfiable information inside it - so I don’t want to publish ir here. Could sent to Christian after basic removal of private data (IP/name/email).

This is clearly not an one off but some wrong configuartion of s2member regarding the new checkout. I’m on the latest official version.

#2

Thanks for reporting that, Felix.

Could you show me the shortcode you’re using for it? Or is it with the custom script you use?

[5] => s2Member Pro handles Cart events on-site, with an IPN proxy.

It’s odd, because you say you’re using the PayPal Checkout button, but that log entry sounds more like a pro-form. Do you have a pro-form on your site?

If you could send me privately the logs (e.g. paypal-checkout.log, gateway-core-ipn.log, paypal-api.log, gateway-core-rtn.log), that’d be very helpful. And what customer I should look for, so I find the entries related to him.

:slight_smile:

#3

I have just replied with the relevant logs in a private message. I used the checkout buttons via my form that creates and hides them accordingly. I’ve never used paypal proform, only stripe. there is no paypal api log that got updated - and I extracted all entries relevant to the timeframe of the payment (no other events within 2 hours later).

#4

and yeah - I think all subscription payments went through fine so far - it only affects one time payment payments for a fixed duration.

#5

I’m having the next case - this time it’s a again a one time payment - but from existing user as upgrade time -who didn’t get upgraded after payment so account demoted. Somehow the payment is in s2-http-api debug log, as well as in paypal checkout log, but not in the gateway-core ipn log.

@clavaque - have you found out something with my logs?
I’m going back to legacy paypal button payment for now - at least that way if it works I know it’s nothing about my adapted plugin.

#6

Thanks for the update. I’ll take a look now. :slight_smile:

#7

Okay, after reviewing the logs and your script, it seems the issue is that you were using amounts without decimals, so there was a mismatch.

You can add decimals to the amounts that your script outputs, but I also added support for this in the latest beta.

s2member-v260228.16563.zip (1.4 MB)

:slight_smile:

1 Like
#8

Perfect, will report back should there be any more problems. Good to iron out a small difference as before of course it was fine without decimals.

1 Like
#9
1 Like
#10

So far it seems fine (yeah also on 260301).
Actually I wonder a bit about encryption. Should it be turned on or not after activating PayPal checkout (beta)?

If not turned on could someone just design his own checkout button with whatever amount? I’m actually more thinking about credit card fraud here (but then with PayPal it seems to be their problem unlike with stripe where it’s your problem).

If turned on can there be problems with existing subscriptions?

#11

I’m very glad it’s working well for you! Thank you for the update.

Button Encryption is a PayPal Standard setting, so PayPal encrypts it on its side and gives you an ID for it.

In the PayPal Checkout implementation that’s done by s2Member server-side, I implemented it in a way that it can’t be tampered client-side.

It’s the default now, there is not way to not have it encrypted in the current implementation, it’s not possible now to just have something like the old button’s plain HTML form.

But feel free to study it and find a flaw, I’ll be happy to patch it.

:slight_smile:

#12

So enabling checkout beta disables old full code buttons as I understand. This i was unsure off.

Maybe you could then add something to that box saying it doesn’t apply it PayPal checkout is activated… because right now activating it still throws the notice.
(I know shortcode buttons apply to checkout once activated so cannot be tampered with).

#13

The s2 paypal button shortcode will output the Checkout one when Checkout is enabled, or it’ll output the PayPal Standard one when it isn’t (default).

If instead of the shortcode you used the HTML form for the button, that still is the same PayPal Standard button, the new PayPal Checkout integration doesn’t change that.

So the plain HTML forms for the buttons need to be changed to the s2 shortcode if you want it to work with PayPal Checkout.

:slight_smile:

#14

Yeah so the question is if the plain html form would work even though checkout is enabled. If it does and then encryption isn’t enabled it would be a security risk. So I should have phased my question better…

#15

Encryption never worked with the plain HTML form, only with the s2 shortcode for the button. The form is the form and just gets submitted, it doesn’t go through the shortcode handler and preparation.

So the HTML form will keep working as before with PayPal Standard to get paid even if you switch the shortcode to PayPal Checkout.

:slight_smile: