I am integrating PayPal subscriptions in a Django project. I have it working well but I'm thinking it could be possible that someone malicious can simulate a webhook call and get a free subscription. Currently I have no way to verify if the webhook really comes from PayPal.
In other payment systems I could set a secret word in the call (from the service provider) and then in the app server validate the call through the secret word.
There are several possible ways...
Post it back to PayPal, https://developer.paypal.com/docs/api/webhooks/v1/#verify-webhook-signature
Check the cryptographic signature, https://developer.paypal.com/docs/api-basics/notifications/webhooks/notification-messages/
Include a custom_id in the original transaction, which will be returned, https://developer.paypal.com/docs/api/orders/v2/#definition-purchase_unit_request
Just don't use one of the PayPal-*-SDKs, since they are deprecated.
Related
I am integrating PayPal Payments blind, this means I have no means to test, I've researched this more than a lot of times, and I can't seem to find any information about this.
When my client successfully pays me (integrated using REST API), and they are returned to the specified return URL, what are the exact parameters returned, primarily, what are the parameter keys for the Payment ID and the Payer ID.
Thank you for your assistance.
I am integrating PayPal Payments blind, this means I have no means to test
This doesn't make any sense; you should fully test your integration as you develop it, using the PayPal sandbox environment.
Redirecting away from your site is an old way to integrate PayPal, used by old websites. Current integrations do not use any redirects. At all.
Follow the Set up standard payments guide and make 2 routes on your server, one for 'Create Order' and one for 'Capture Order', documented here. Both routes should return only JSON data (no HTML or text). Inside the 2nd route, when the capture API is successful you should store its resulting payment details in your database (particularly purchase_units[0].payments.captures[0].id, which is the PayPal transaction ID) and perform any necessary business logic (such as sending confirmation emails or reserving product) immediately before forwarding your return JSON to the frontend caller.
Pair those 2 routes with the frontend approval flow: https://developer.paypal.com/demo/checkout/#/pattern/server
I am updating my Paypal Integration from good old NVP to the new Script.
With the old ExpressCheckout, returnURL's where handed over from my backend server through paypal for success or failure. These URL's could carry a random parameter and thus protect against someone faking the paypal responses (as I could verify that these responses carry the same parameter as given to paypal at order creation time from my server).
The current Javascript from Paypal just calls a onApprove() method and its up to me to tell this approval to my server.
As there are no returnURL's handed over anymore, there is also no way to protect the callback from being faked. Someone inspecting my (clientside javascript) code or observing the traffic from the browser can just handcraft that call and tell my server that paypal successfully authorized.
Is my reasoning wrong?
Is there any other way to prevent this scenario?
Is there a way to use the paypal API to send basic details of a payment without actually creating the payment itself? What I mean is, I'm working with a non profit organization that does not currently employ SSL. They want to use paypal to accept donations, but they want their own branded form on their page, they don't want to use the simple donate button. I had thought I might be able to send basic details, such as name and address along with the amount they wish to donate and a few other details using the paypal API, and then have the actual payment information processed on paypal's secure servers. All the examples I can find on how to use their API however are creating complete payments and sending them to Paypal, something I'm not able to do for obvious reasons. Short of employing SSL, something that we should probably do anyways, and capturing a complete payment, is there a way of sending just select information over the API and handling the rest on paypal's end?
If you want to control the form itself you don't have any choice but to go SSL. Any other route would require sending the user to PayPal, where you would no longer have that control.
I'm setting up a payment engine for a custom framework using PayPal Express Checkout. One of the business requirements is adding support for recurring payments. I've found documentation on how to implement this at https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_api_ECRecurringPayments
The thing I don't quite understand is how to retrieve the value of BillingType from the API after I've set it via SetExpressCheckout to "RecurringPayments". It doesn't seem to appear anywhere in the response data I get back from neither GetExpressCheckoutDetails nor DoExpressCheckoutPayment. I need this to know whether I need to create a recurring payments profile or not. So as far as I can tell my only option is to store the value of BillingType in my database and query it again after DoExpressCheckoutPayment. This works for me but I find it odd that this data would not be returned at all by the API. Am I missing something? Or is there another way of correctly implementing recurring payments?
Not all data you send in a request is returned in a response. You already have what you're passing to them...there's really no need for them to pass it back.
You could use session variables to save the data instead of the database, or you could log all of your API requests and refer to those logs when you need to see what you sent, but again, your application is what's telling PayPal whether or not the payment should include billing agreement information...not the other way around.
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.