Since mid-January, I'm not getting complete data in return page post and it doesn't validate

[RogerHarris]

Apparently since about mid-January, my return page -- which has been working fine for many, many years -- is not getting all the expected data in the post, and it does not validate when sent back to PayPal. (I am setting return_url and rm=2 in the ordering buttons.) Specifically, I'm not getting either receiver_email or business, and since I have many merchants using this service to manage digital product downloads, I need one or the other. But I also require the data to be validated, and the last successful validation I got was January 11. Does anyone know of any recent changes to this processing?

[RogerHarris]

To answer my own question: Yes, the data sent to return pages changed in mid-January, and one change is that it does not send the business email address now.  Since I have many merchants using my service, I relied on that to determine who the data was for.  I have had to change to use the receiver_id, which I did not have for any merchants, and since I didn't want to burden them with this problem, I extracted receiver_ids from logged IPNs.

It's very upsetting that PayPal makes changes like this without notice, and then don't even document it anywhere, and then take over a week to answer a question about it.

[RogerHarris]

It turns out another thing that changed, now verified by PayPal support, is that it is no longer possible to validate the data sent to the return page using cmd=_notify-validate. It always comes back INVALID. I use the return page to allow customers to download digital products immediately, rather than wait for the email link sent by the IPN process, so now I have to either allow unvalidated downloads or drop this feature, which has worked fine for about 20 years. Color me PO'ed.

[Nexus_Software]

Hello @RogerHarris ,

The PDT is the sending the business (merchant), the receiver_email, the verify_sign and all of the following example variables. You may be able to use  : verify_sign or another of the sent values to verify the transaction.

mc_gross = 33.00
protection_eligibility = Eligible
address_status = confirmed
payer_id = K3U3VMDRHQH9C
tax = 0.00
address_street = 1+Main+St
payment_date = 02%3A27%3A59+Mar+04%2C+2022+PST
payment_status = Completed
charset = UTF-8
address_zip = 95131
first_name = facilitator
mc_fee = 1.64
address_country_code = US
address_name = facilitator+account%27s+Test+Store
custom = Testing+custom+2
payer_status = verified
business = sb-kh32s12060300%40business.example.com
address_country = United+States
address_city = San+Jose
quantity = 1
payer_email = sales-facilitator%40nexwebsites.com
txn_id = 5VC49721MS6241223
payment_type = instant
payer_business_name = facilitator+account%27s+Test+Store
last_name = account
address_state = CA
receiver_email = sb-kh32s12060300%40business.example.com
payment_fee = 1.64
shipping_discount = 0.00
insurance_amount = 0.00
receiver_id = PNMANCRMNMTJJ
txn_type = web_accept
item_name = Testing+PDT
discount = 0.00
mc_currency = USD
item_number =
residence_country = US
shipping_method = Default
handling_amount = 0.00
transaction_subject =
payment_gross = 33.00
shipping = 0.00

Thank you.

Powered by Custom Software : NexWebSites.com PayPal Developers

[RogerHarris]

I'm not using PDT; I'm setting rm=2, which posts data to the return url, like the IPN does it but with slightly different data. Switching to PDT is not a viable option because I have hundreds of merchants already using the service, with their accounts and ordering buttons set up to work this way.

[dawgdude]

Same here. I started validating the receiver_id against the PayPal account's merchant ID, see https://www.drupal.org/project/commerce_paypal/issues/3004653#comment-14513023