0
votes

Paypal appears to have changed their IPN test interface. (Spoofing IPN's to your IPN page for testing.

The following is the data I receive from IPN now.

KEY: receipt_ID - VALUE:

KEY: mc_handling1 - VALUE: 1.67

KEY: address_state - VALUE: CA

KEY: quantity1 - VALUE:

KEY: reason_code - VALUE:

KEY: quantity - VALUE:

KEY: txn_id - VALUE: 359726646

KEY: last_name - VALUE: Smith

KEY: mc_currency - VALUE: 1

KEY: payer_status - VALUE: 0

KEY: address_status - VALUE: 1

KEY: auction_buyer_id - VALUE:

KEY: tax - VALUE: 2.02

KEY: invoice - VALUE: abc1234

KEY: shipping - VALUE:

KEY: address_street - VALUE: 123, any street

KEY: payer_email - VALUE: [email protected]

KEY: mc_gross1 - VALUE: 9.34

KEY: item_name - VALUE:

KEY: mc_shipping - VALUE: 3.02

KEY: cmd - VALUE: ,_notify-validate

KEY: first_name - VALUE: John

KEY: business - VALUE: [email protected]

KEY: parent_txn_id - VALUE:

KEY: payer_id - VALUE: TESTBUYERID01

KEY: payment_date - VALUE: 08:11:09 8 Mar 2013 PST

KEY: address_country - VALUE: 1

KEY: payment_status - VALUE: 2

KEY: receiver_email - VALUE: [email protected]

KEY: for_auction - VALUE:

KEY: ipn_type - VALUE: 4

KEY: payment_type - VALUE: 1

KEY: address_zip - VALUE: 95131

KEY: address_city - VALUE: San Jose

KEY: mc_shipping1 - VALUE: 1.02

KEY: item_name1 - VALUE: something

KEY: mc_gross - VALUE: 12.34

KEY: item_number1 - VALUE: AK-1234

KEY: mc_fee - VALUE: 0.44

KEY: residence_country - VALUE: US

KEY: address_country_code - VALUE: 1

KEY: notify_version - VALUE: 2.4

KEY: receiver_id - VALUE: [email protected]

KEY: pending_reason - VALUE:

KEY: mc_handling - VALUE: 2.06

KEY: txn_type - VALUE: cart

KEY: custom - VALUE: xyz123

KEY: auction_closing_date - VALUE:

KEY: item_number - VALUE:

KEY: address_name - VALUE: John Smith

KEY: notify_url - VALUE: http://www.sellwidget.com/IPN.aspx

You will notice they have integers instead of values for some fo the responses. This was not the case just yesterday.

Is this a bug, or did they change these to relational data?

2

2 Answers

1
votes

Yes, we are looking into this at the moment.
The data the IPN simulator generates appears to be causing a HTTP 400 response against www.paypal.com / www.sandbox.paypal.com when you validate the IPN data.
We'll get this fixed shortly. Apologies for any issues this is causing for you.

In the meantime, please feel free to work with me or one of my colleagues (they're on SO as well) if you need specific information on certain IPN parameters by starting a new question.

edit:
Cause seems to be an stray 'cmd=' right inside the IPN POST data. This is causing our IPN validation service to return a HTTP 400.
You could either remove just "&cmd=" from your IPN POST data in the interim, or if you can wait a little bit we'll push out a fix for this to production as soon as possible.

0
votes

Thanks. I fixed the 400 error by setting the req.host = "www.paypal.com" but then theres a certificate error because the sandbox is not www.paypal.com, its www.sandbox.paypalcom. Just a fyi.

(I think your new changes have taken affect inadvertently. (The bulletin posted regarding adding to the headers as the new ips have been added).

Can you explain why my ipn data is being passed back to me with integers for things, such as payment_status etc? Is this just a malformed join on the data, or is it going to move to a relational based parameter system?

Here is the bulletin: https://www.x.com/content/bulletin-ipn-and-pdt-scripts-and-http-1-1