Why is everything PayPal so crazy hard?
This is what I'm sending to https://api-3t.sandbox.paypal.com/nvp :
METHOD=DoExpressCheckoutPayment&
VERSION=108.0&
USER=my-sandbox-facilitator_api1.domain.com&
PWD=&
SIGNATURE=&
SUBJECT=&
TOKEN=EC-1GE68226PG526154U&
PAYERID=my-sandbox-buyer%40domain.com
PAYMENTREQUEST_0_PAYMENTACTION=SALE&
PAYMENTREQUEST_0_AMT=19.95&
PAYMENTREQUEST_0_CURRENCYCODE=USD&
PAYMENTREQUEST_0_NOTIFYURL=
This is what I'm getting back:
TIMESTAMP=2015-12-12T21%3a35%3a34Z&
CORRELATIONID=d9a463bfa6bb4&
ACK=Failure&
VERSION=108.0&
BUILD=18308778&
L_ERRORCODE0=10406&
L_SHORTMESSAGE0=Transaction+refused+because+of+an+invalid+argument.+See+additional+error+messages+for+details.&
L_LONGMESSAGE0=The+PayerID+value+is+invalid.&
L_SEVERITYCODE0=Error
Just before this I did a METHOD=GetExpressCheckoutDetails without any problems.
PayerID wasn't invalid for that?!?!!
I have a token so I did a METHOD=SetExpressCheckout without any problems.
Ideas?
No amount of Google had a working answer for me.
Either did PP's 5(!) tech support sites.
It is the same issue even if I reconfigure and and shoot a similar transaction at my live PP.
PAYERID is a unique PayPal buyer account identification number as returned after SetExpressCheckout API call(after buyer login to paypal and gets redirected to your RETURN URL , you will need to copy that PAyer Id and use in Doexpresscheckout request. Payer is a 13 single-byte alphanumeric character and not an email address.
https://developer.paypal.com/docs/classic/api/merchant/DoExpressCheckoutPayment_API_Operation_NVP/
Related
I using Paypal / Payflow Pro's Authorization transaction (TRXTYPE=A) to validate credit card information. I am passing 0.00 as the AMT. This works fine and can filter out wrong account number as well as card expiration date, paypal returns "RESPMSG=Invalid......".
However, the problem is in verifying both CVV2 and BILLTOZIP. When passing wrong values for these two paypal still returns "RESPMSG=Approved".
I am missing something?
Can we validate CVV2 and BILLTOZIP on paypal?
Is there another method that I can use for this?
I am using this request:
USER=XXXXXX&VENDOR=XXXXXXXX&PARTNER=PayPal&PWD=XXXX&TRXTYPE=A&TENDER=C&ACCT=4xxxx&EXPDATE=xxxx&CVV2=xxx&AMT=0&INVNUM=521aa62355f5eb5515eca3777e1f8b78&PONUM=PFDCCTEST&COMMENT1=Test Comment 1&COMMENT2=Test Comment2&VERBOSITY=HIGH&BILLTOFIRSTNAME=Frank
&BILLTOLASTNAME=Enstien&BILLTOSTREET=123 Main St.&BILLTOSTREET2=Suite 267&BILLTOCITY=GILBERT
&BILLTOSTATE=AZ&BILLTOZIP=85298&INVNUM=InvoiceNumber001&CUSTOM=CustomNumber001
Is this live or sandbox?
paypal still returns "RESPMSG=Approved
Check the rest of the return for =N , =X, other documented invalid value
If you still have issues post a full return string.
I am making a simple paypal checkout and getting the response from the paypal after transaction in POST method to my return url. The response include everything I want but the phone/contact number.
I wanted to confirm if paypal does or doesn't share the contact/phone number and if it doesn't, can i have some official paypal link saying that
You need to login to your PayPal profile and enable "Require Phone Number". It's under profile->Website Payment Preferences->Contact Telephone Number
Once you've got that setup it'll come back in the contact_phone phone parameter with IPN or PDT.
I'm using PayPal Payments Advanced with TEMPLATE=TEMPLATEC. I already figured out how to create an IFRAME and receive confirm/cancel/silent_post responses from PayPal. But I've found no way to validate parameters my confirm/cancel/silent_post pages receive. Is there a way to ensure that these parameters are from PayPal and not just sent by arbitrary user?
About the best option you have is to run an inquiry transaction (TRXTYPE=I) against the secure token and secure token ID you received from PayPal before displaying the iframe. If a transaction was run, that call will give you the transaction ID (PNREF) from the transaction. (And depending on your situation, the PNREF may be all you need.) If that matches the PNREF sent back to you by the buyer, then there's a good chance that the rest of the data is genuine.
For example:
Request:
USER=****&VENDOR=****&PARTNER=****&PWD=****&TRXTYPE=I&SECURETOKEN=7tGDq6ILZeEmATCwTXrSRkwjz&SECURETOKENID=76ac5819ee01475daf15b2af038da977&VERBOSITY=HIGH
Response:
RESULT=0&PNREF=E79P4ABEC9DE&TRANSSTATE=8&ORIGRESULT=0&ORIGPNREF=E19P4BFB14B2&RESPMSG=Approved&AUTHCODE=111111&AVSADDR=Y&AVSZIP=Y&CVV2MATCH=Y&ORIGPPREF=1XR06058R58346646&CORRELATIONID=bdd79cb3c7fb6&PROCAVS=X&PROCCVV2=M&SETTLE_DATE=2013-04-23 07:22:06&TRANSTIME=2013-04-23 07:22:06&LASTNAME=NotProvided&AMT=24.99&ACCT=3698&EXPDATE=1214&CARDTYPE=0&IAVS=N
ORIGRESULT is the result of the original transaction (0 is a success; anything else is a failure.)
ORIGPNREF is the PNREF from the original transaction.
You can also put a long, unique "token" parameter in your silent post URL. Something like
"http:// www.my-web-site.com/confirm-payment?token=2348349u21034ms39n899"
and match it up with the same token a server side script is expecting. Since the silent post URL is stored in your PayPal manager account, the token is confidential, and even the URL as a whole is confidential. Plus the transaction info is also passed to this silent post URL allowing you to match up info with your transaction you saved in your database at checkout. This is a good secure method to confirm payment was correctly made. The silent post will work for both "pay with paypal" and "direct credit card payment" methods on the payments advanced iframe (a.k.a. hosted checkout page). Additionally, you can also throw in one more check, to see if PayPal is the $_SERVER['HTTP_REFERER']; (which of course can't be trusted purely on its own).
I am using PayPal with NVP API (using PHP) for express checkout. I am creating an invoice record in the database before redirecting the user to Paypal. In case the user doesn't return to my site after processing, I am using IPN to confirm the purchase and then update the invoice record that the payment is confirmed. I am still in the sandbox mode and trying to figure out how I will tie the transaction started with NVP to the confirmation I get with IPN.
I need to verify if the "PAYMENTREQUEST_n_INVNUM" sent in the NVP will come back as "invoice" in the IPN post.
It appears I cannot actually test this until I am live since the Sandbox IPN does not seem to be active with NVP initiated sandbox transactions - is this correct?
Thanks for your help.
You can test this in Sandbox. But if you're using "PayPal NVP", I assume you're using PayPal Express Checkout and calling the SetExpressCheckout and DoExpressCheckoutPayment API's.
If that's the case, you don't really need IPN, because a transaction will only be completed as soon as you call DoExpressCheckoutPayment.
In other words, buyers will always be redirected to the RETURNURL you specified in SetExpressCheckout, and the transaction is completed (or not) when you call DoExpressCheckoutPayment on this return page.
To get the invoice number, you could call GetExpressCheckoutDetails and supply the TOKEN you retrieved earlier (it's also appended to the GET of the RETURNURL).
Finally, check PAYMENTSTATUS=Completed in the DoExpressCheckoutPayment API response to see whether the transaction has completed or not.
Thank you Robert for the clarity on the process - especially useraction=commit.
I finally realized that I could turn on IPN in the Sandbox for my test seller and test NVP with IPN together. I was able to verify that PAYMENTREQUEST_0_INVNUM matches the 'INVOICE' parameter in the IPN POST.
I will use the custom field to pass customer email from my system in case they use a different email to log into paypal with, therefore allowing me to have email/invoice number pair for confirmation.
I've setup a PayPal site which uses IPN and I was having trouble getting PayPal to send the GET variables to the return URL that I had specified. It was sending the user's browser to the return URL, but nothing was being passed via GET or POST.
I changed one setting in the PayPal business account: "Payment Data Transfer (optional)" to On which generated an "Identity Token" on the PayPal website.
I also got an automated email from PayPal saying:
---------- Forwarded message ----------
From: service#paypal.com <service#paypal.com>
Subject: Payment Data Transfer (PDT) Has Been Enabled
This email is to inform you that you have successfully enabled Payment Data Transfer.
PDT's primary function is to display payment transaction details to buyers when they are redirected back to your site upon payment completion. However, there are cases, such as with pending transactions, where you won't receive notification of all transactions. For this reason, PayPal strongly recommends that you also enable Instant Payment Notification (IPN).
To learn more about enabling and setting up IPN:
https://www.paypal.com/us/cgi-bin/?cmd=p/xcl/rec/ipn-intro-outside
To learn more about Payment Data Transfer, including setup instructions and a complete list of variables:
https://www.paypal.com/us/cgi-bin/?cmd=p/xcl/rec/pdt-intro-outside
Sincerely,
PayPal
Clicking on the second link and clicking on "Technical Overview" (https://www.paypal.com/us/cgi-bin/webscr?cmd=p/xcl/rec/pdt-techview-outside) shows:
Your POST should be sent to
https://www.paypal.com/cgi-bin/webscr.
You must post the transaction token
using the variable "tx" and the value
of the transaction token previously
received (e.g.
"tx=transaction_token"), and the
special identity token using the
variable at and the value of your PDT
identity token (e.g.
"at=identity_token"). You will also
need to append a variable named "cmd"
with the value "_notify-synch", for
example "cmd=_notify-synch", to the
POST string.
However, I am NOT passing the Identity Token at all, yet everything is working fine!
(a) Is this a problem?
(b) Why is it working if the documentation implies that it shouldn't?
(c) Is this a consequence of specifying an outdated API version (58.0)? What is the value I should be using?
In my opinion the identity token should be a required param since it is the only way Paypal can verify that the request you're making is valid. Otherwise, other people can simply guess a transaction id (even though it is not intended for their accounts) and get details for that transaction from Paypal.
I'm guessing this is a bug you're experiencing. Are you testing in the Paypal sandbox or in a live environment?
Realizing that the OP probably no longer needs an answer after 9 years, but others still might:
The POST of the transaction ID and identity token is purely for the purpose of verifying that the original transaction notification (relayed via the GET method to the merchant's Return URL) actually came from PayPal.
It is as if to say to PayPal, "My website just got this supposed confirmation that a customer paid. Here is the transaction ID and my seller ID again. Is this a legitimate match?"
In fact, at https://developer.paypal.com/docs/api-basics/notifications/payment-data-transfer/, when talking about setting up for testing, it only talks about getting your script ready to receive, parse and display the GET data. It doesn't mention the POSTing back to PayPal (though that is mentioned elsewhere). So, yes, the PDT function should work without doing the POST back to PayPal afterward and waiting for that response of SUCCESS or FAIL, but...
Anyone who knew what they were doing could go to a seller's URL and append a query string with the right combination of variables to fake the same kind of GET request that the PayPal PDT system would initially send, whether or not the transaction ID were a real one.