I’m using Gravity forms PayPal Checkout Add-On. GF already checks authorisation before submitting the form, but it doesn’t check if the payment was successful or not. I would like to have a different confirmation page depending on that. I was looking at using gform_ppcp_webhook but unfortunately I’m not sure how to implement it to work the way I need it.
If that's not possible then just stopping the form from submitting would be my next step, but there I'm also lost.
Thanks
Related
We use PDT's cmd=_notify-synch API to validate transactions when the customer is redirect back to our website after a payment.
We pass a "custom" value in our Paypal buttons with a customer id, and we expect to get this value back. This worked fine for the past 5 years.
Starting on or around 2018/10/19, the PDT API stopped returning the "custom" value that was passed in. This broke our payment flow.
Not sure if anybody else ran into this issue, and/or if there's a workaround or a configuration to change.
That button URL is for a hosted button, which means all of the parameters are set within PayPal when you create the button. You cannot pass a return value directly to a hosted button. You would need to adjust that in the hosted button itself within the PayPal account.
The only way to set it there would be with the Advanced Variables section, but of course you won't be able to make that dynamic. If this is a problem you're going to need to switch to using a non-hosted button so that you can then pass parameters directly the way you are trying to do.
Beyond that you could switch to using the Express Checkout API, and then you have more freedom and flexibility to do whatever you need during checkout.
We have a checkout page where the user enters their CC number, item they want to purchase, and they complete a challenge. When the form is submitted, the sever validates the challenge and then saves the payment and charges their card.
However, we want to change it to only prompt for the challenge when the person making the checkout is considered suspicious (and increase the difficulty of the challenge as they get more suspicious).
checkout button is pressed (POST)
server checks request data and compares it against previous checkouts
server determines if challenge is needed, if so, client needs to complete this and send back to the server
if challenge is not needed, checkout is accepted and CC is charged
What would be the RESTful way to do this?
What would be the RESTful way to do this?
How would you do it with web pages?
Probably - you would present the user with a form, the user would fill in the form and submit it. If the user looks innocent, then you would process the checkout as is, and send back a response that represents the checkout action.
If the user looks suspicious, then rather than processing that form, you would send the user a response that says we can't process your payment because you are suspicious; use this alternative form to make progress. The user would submit the alternative form, and then you would evaluate whether or not the user had met the security challenge.
That's the RESTful way to do it; you give the client forms to submit, and links to follow. Clients that recognize the semantics provided in the representations can make progress, those that cannot stop.
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 used PayPal's Integration Wiz to generate the code (PHP) for the Express Checkout Digital Goods functionality. I'll admit, I made a few minor changes to it so that it could work with my site... My site is a single page Angular.js app - so I need to pass back parameters to the app, and not go back to a different page (as it is, I'm not keen on leaving the page at all, but I'm not ready to shell out for a business pro account yet.. the PCI compliance is something I don't relish being on the hook for...but maybe one day... certainly not until I know I can get "basic" things working).
I would not expect any of my changes (basically changing the hardcoded URLS to being PHP session vars) to interrupt any of the flow of the Integration Wiz's processing.
However, when I test things in the sanbox, the process stops at the point of redirection to:
https://www.sandbox.paypal.com/incontext?token={somevariabletokenconent}
The token always starts with "EC-" so I'm assuming this is telling me I've been able to successfully start the Express Checkout process.
All I am seeing is a blank page, with Chrome telling me I'm getting:
Failed to load resource: net::ERR_CONNECTION_RESET
AFAICT my sandbox account is set up for EC/DG:
Your payment solution: PayPal Digital Goods (Express Checkout)
I HAVE updated my sandbox details in paypalfunctions.php
And other than the changes in checkout.php, I havent messed with any other code from the integration wizard... should this not "just work" ??
Or have I missed something else?
[Edit]
Update a few hours later...
I actually was able to get things to progress end to end. Once. But no record of the transaction can be seen on either side of the sandbox accounts. It did sit thinking for a long time... so I'm not sure what it was doing, but the final redirect was back with a success parameter, so I have to think that something behind the scenes must be having issues...
But now its not working anymore. Its stopping in the same spot again.
For the life of me, I don't believe I made any code changes to the PP wiz produced code prior to it working, or prior to it not working again.
I have logged into the sandbox to check the transaction as I mentioned. Both accounts are showing nothing. And the transactions are not processing.
[EDIT 2]
Ok - strange things are afoot. I know I did absolutely no changes since my last test...I havent even been at the keyboard. And upon trying again, the test proceeds to allow me to log into the sandbox, and approve a payment, but gets stuck processing at
https://www.sandbox.paypal.com/webapps/checkout/webflow/sparta/expresscheckoutvalidatedataflow?execution=e1s2
with the PayPal "Loading" icon spinning...
Is this a configuration issue on my side? With the Integration Wiz writing all the Express Checkout code, there's not to change, but it seems really flakey to me.
[EDIT3]
I've been hanging my head on this for about a day now, and got nowhere. My App is a single page Angular.js site, and triggers the PayPal purchase out of a Bootstrap Modal popup window.
As mentioned above, my process would get to the point of approving and confirming payment, then spin wildly at the point it should be redirecting back to the success (or failure) page.
Using the PP integration Wiz, the form code that was produced (and used) was:
<form name='ppcheckout' action='checkout.php' METHOD='POST'>
And it fails to proceed to the final redirect.
However, if I change the code to:
<form name='ppcheckout' action='checkout.php' METHOD='POST' target="_blank">
The processing occurs as expected.
Is there some interaction between PayPal's JS and Angular (or Bootstrap) that I'm not aware of? It seems strange that it "just works" when the target is added.
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.