I have just created my first PayPal button and it is working correctly within sand box. I would like to know the best way (if possible) to issue a unique activation code on my return url ensuring that the user has definitely paid before they receive the code. I could manually email the code but wondered if the was any way of automating this using some sort of return value? Possibly returning to an aspx page which then reads from my database to get the next activation key and displays it?
Thanks
Garry
As you already know that PayPal doesn't provide such facility for delivering activation instantly but it does offer the Instant Payment Notification API (PayPal IPN) which can be used to build such a platform.
Here is a great article for that purpose only. https://www.codeproject.com/Articles/383207/Selling-software-using-PayPal-IPN-as-an-eCommerceenter link description here
The best way to handle that would be to use Instant Payment Notification (IPN).
Any time a transaction happens on your site (whether it's a payment, refund, cleared pending payment, dispute, etc.) the PayPal server will POST details about that transaction to a script you have sitting on your server.
This script can receive the data and process it accordingly allowing you to automate things like updating a database, generating email notifications, hitting 3rd party web services, delivering e-goods, etc.
If you want the activation code to be visible on the return URL you can look at Payment Data Transfer (PDT), which is just like IPN except that it's made for use with the return URL. It is not recommended to use this, though, for post-transaction processing because there is no guarantee the user will make it back to the return URL, for one, and also it wouldn't handle things like e-checks correctly.
Related
We are trying to integrate Paypal subscriptions with .Net web application done in Blazor.
We have created a button that allows the customer to enrol to a subscription defined in paypal business.
The customer can do the "payment" or "enrolment" successfully and it returns back to our web application with the specific URL that we defined.
This return URL contains just one parameter, called "token".
The problem is that we want to be syncronize paypal payments with our own control of payments implemented by us in the application, so we need to receive some other information in this URL like the transactionID or some identifier that we can use later to link with one customer.
We have configured paypal to support PDT.
When the customer finishes the enrolment to the subscription, the token returned to the URL i passed to our backend and with this, we try to get the some extra information.
We do a post to the url "https://www.sandbox.paypal.com/cgi-bin/webscr" passing as parameter the token that we received back from the transaction and our token as merchant in paypal.
Theorically, when doing this call, we should receive a response that contains "SUCCESS" and then, we should be able to extract some parameters configured in the PDT of paypal.
But, unfortunately, we always receive "FAIL"
Do you have any idea why does it happens?
Thank you very much in advance.
PDT returns are not reliable, as a payment can complete and the client return never happen for any number of reasons -- so PDT should never be used for anything important, and thus there is no reason for a well designed integration to bother attempting to verify them. Contents of a PDT is suitable for information purposes (display summary of success) to a customer only -- if you are doing anything else with PDT data, rethink your integration..
If you must continue such a very old checkout method that uses PDT as part of its process, a service such as IPN or Webhooks should be added on to receive a somewhat more reliable, direct post from PayPal with the payment information.
The best solution however, is to do neither of those things -- since adding on asynchronous notifications to an existing very old integration has its own disadvantages. Instead, discard your current integration completely as it's already about 4 generations old / 20 years old, and implement a new, current PayPal Checkout integration from scratch:
Follow the PayPal Checkout integration guide and make 2 routes (url paths) on your server, one for 'Create Order' and one for 'Capture Order'. Both of these routes should return only JSON data (no HTML or text). Inside the 2nd route, when the capture API is successful you should verify the amount was correct and 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. In the event of an error forward the JSON details of it as well, since the frontend must handle such cases.
Pair those 2 routes with this frontend approval flow: https://developer.paypal.com/demo/checkout/#/pattern/server . (If you need to send any additional data from the client to the server, such as an items array or selected options, add a body parameter to the fetch with a value that is a JSON string or object)
I am hoping someone here can help me as I have been on to PayPal technical support who haven't been very helpful.
I am integrating PayPal checkout, following the instructions here: https://developer.paypal.com/docs/checkout/standard/integrate/
I wish to collect the paypal transaction ID in my database, send order confirmation emails etc... so as such I need to implement the optional step 5 described in this integration guide, which essentially means creating two routes on my server, one to call "create order" and one to call "capture order" - as per the sample code here: https://developer.paypal.com/demo/checkout/#/pattern/server
I have got this working successfully however I wish to know 2 things:
How can I see the 3D Secure flow - PayPal tell me know to worry about it as they handle it within the popup window but I would like to see the flow. I have tried test cards that should invoke the 3DS flow but they dont show any 3DS flow, just complete the payment.
The response to the capture order end point can return multiple statuses (COMPLETED, APPROVED, VOIDED, PAYER_ACTION_REQUIRED etc). Is it only the "COMPLETED" status that means a fully completed payment (and therefore I should complete the order)? What happens if it returns "PAYER_ACTION_REQUIRED" - which means 3DS check needed - will PayPal handle this and then re-execute my route?
Any help or advice would be greatly appreciated.
For the normal, 'Standard' integration, you don't have to test 3DS. The PayPal page/iframe already takes care of everything about it.
[Only for the 'Advanced' integration -- where you are implementing individual hosted card fields with your own styling -- do you need to implement and test 3DS yourself]
PAYER_ACTION_REQUIRED only happens with Advanced. All you need to do on the server end after the capture is check for COMPLETED and the existence of the Capture Id you're going to store for accounting purposes.
Because I accept PayPal payments on my website, I'm trying to use the Measurement Protocol to send transaction details server-side. Visitors who use PayPal to pay often don't return to my website to view the order confirmation page, so relying on IPN instead is a more reliable way of recording transactions.
I've been able to successfully record Event hits with the Measurement Protocol, but although my Ecommerce (plain ecom, not enhanced) hits validate through the debugger, they are not showing up in any of my GA reports, even a day or two after the transaction is completed. Yes, I've verified that Ecommerce (but not enhanced ecommerce) is enabled in Analytics.
Example requests, with tid and cid redacted (they are correct in the actual calls):
The ecommerce transaction:
https://www.google-analytics.com/collect?v=1&t=transaction&tid=UA-XXXXXXXX-1&cid=XXXXXXXX&ti=20D95105S1786425X&tr=50.00&cu=USD&ds=web
The ecommerce item (there is always exactly 1; the items are donations and my site doesn't allow multiple donations in 1 transaction):
https://www.google-analytics.com/debug/collect?v=1&t=item&tid=UA-XXXXXXXX-1&cid=XXXXXXXX&ti=20D95105S1786425X&in=giveNow&ip=50.00&iq=1&iv=Onetime&cu=USD&ds=web
The event hit, which does work:
https://www.google-analytics.com/debug/collect?v=1&t=event&tid=UA-XXXXXXXX-1&cid=XXXXXXXX&ec=donate&ea=Onetime&el=giveNow&ev=50.00&ta=StMU&ds=web
All three hits are sent successively, with the Event hit being the last call. Any suggestions for further debugging are welcome!
Finally solved it: I'd been debugging for so long that I was actually sending all the calls to the debugger (https://www.google-analytics.com/debug/collect) instead of the Production URL (https://www.google-analytics.com/collect).
I'm using ASP.Net Membership Provider for logging into the premium content of this web site. The content isn't downloads, it's web pages of information and discounts, etc. That part is done. We want them to also have a PayPal Subscription annual payment to see the premium content. I would like ASP Membership and PayPal Subscription to work together as much as possible, but for the minimum I am thinking they will have to create a MemberId before they pay. Then I will send that MemberId to PayPal to associate the two.
I think I can do that like this:
Set "Auto Return" on in the interface so that it will redirect to return URL when payment is made.
Set "return URL" query string to MemberId. This requires not using the precompiled "Saved" buttons. I'll have to set it in Code Behind with Name Value Pairs, "NVP" to PayPal. I was hoping to just paste the stupid button.
But then, there were those "Advanced Variables" in the Button maker. Problem was they are compiled into the Saved button, so I can't change them for each person. But maybe that one parameter could be separate from the compiled parameters? Is this better than hacking the return URL? Are "Advanced Variables" good for anything?
All the details about the transaction will be POSTed to the return URL if I put in the right code, which might be rm=2. (Right?) Then I can record it.
This process is said to be unreliable, though, and PayPal recommends using a secondary system that they have, "IPN". PayPal sends the transaction details to me. I send them back http 200 code. Then I send it back to them in the same order I got it. Then they send me http 200. Then we all know it's good. This sounds like a few hours research to me, but if you've already done it once, it sounds like copy and paste. I hate reinventing the wheel. Is there a .Net sample of this IPN handshake/dance?
Also, if I do the IPN thing, maybe I don't need Auto Return. Maybe I add MemberId to "notify" URL instead of "return" URL. Then PayPal can handle the confirmation page, email, etc. Is that better?
Assuming we get the Subscription paid for and recorded with the MemberId, at least once per user session, after they log in, I have to check if they have paid their PayPal subscription and if it's up to date. "GetRecurringPaymentsProfileDetails" does this, but it is an API operation. That makes sense, but I was hoping to avoid learning their REST API. (Is there a "NVP" version?)
REST API OAUTH tokens expire every few minutes, but the only way it tells to get one is by using "Bash" to "cURL" some Linux commands. Again, this seems like the kind of thing that would only ever have to be written once. Does this already exist as a sample code somewhere?
(I don't want to use the API to do the Subscribe, because I don't want the Credit Card numbers to ever go to our site. Too much liability. That's why I wanted PayPal.)
Will this even work? I know PayPal has 18 ways to do everything and they all exclude each other, and I'm just getting the feeling that I'm creating a patchwork of unrelated ideas to fool myself into believing there's a light at the end of the tunnel. I've already been researching and experimenting for 10 hours or so. I really thought, going in, I'd just be pasting a stupid button.
If you want to just "copy the stupid button" then you'll have to stick to Payments Standard, and then you'll be limited with what you can do. For example, you won't be able to use GetRecurringPaymentsProfileDetails for a standard subscription.
Instead, you'll need to use Express Checkout and / or Payments Pro. There is indeed an NVP API available for these, and there is also a SOAP/XML version. Details on those can be found here: https://developer.paypal.com/docs/classic/api/
Specifically, for Express Checkout, you'll want SetExpressCheckout, GetExpressCheckoutDetails, DoExpressCheckoutPayment, and CreateRecurringPaymentsProfile. Some of those calls are optional depending on how exactly you're configuring things with the checkout flow.
For Payments Pro you'll use either DoDirectPayment / CreateRecurringPaymentsProfile or PayFlow depending on what version they put you on.
In any case, IPN is definitely the way to go for post-transaction processing.
.NET IPN Sample - https://github.com/paypal/ipn-code-samples/blob/master/paypal_ipn.asp
I'm developing a site for a client, and he wants people to be able to buy licenses/support contracts via PayPal. What I'm stumped on is how I can make the payments secure. My current idea is to generate a random string using MD5 or whatever, plug this into a database, and send it along with the rest of the PayPal button code. When the payment is completed, the user is redirected to a PHP page where there is code to update their information in the database. The only thing stopping a hacker giving themselves a license/whatever without paying is the random hash, which can be found out using a sniffer of some sort, and plugged into the POST data returned by the PayPal code.
So. My question is this: How do I execute custom PHP code only on a successful PayPal payment, without leaving any loopholes open for the more evil users of the interwebs?
I think you should use a Payment Gateway such as PayFlow
if you're on the website ready to pay, there maybe a session already with your user logged in?
in this scenario, when the user returns back to the website, you can check you have a particular session variable and if it exists, you do the following
1) check your session, do you have a user logged in? should still be logged in if you just visited paypal a few minutes ago.
2) does the session contain your sale_id?
3) if no, dump the user on the home page, remember to header("Location..."); die("DEAD"). the die() part is important
4) if yes, check the sale_id was paid, the notify url should have caught the POSTED payment data, if valid, allow them to update the data
5) if yes, but not valid, allow them to repay using another method, this means to redirect them to another page to attempt to pay again, but don't let them access the "change details" page, the only way you get there, is by strictly validating the payment was successful.
how does that work for you ?