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.
Related
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
On an e-commerce site in the payment page I used the new js sdk from paypal.
When the user clicks on paypal button a popup appears and the user performs the transaction in the popup.
When the transaction is over the popup closes and a callback is called to do what is needed.
If the user manually closes the popup, a CANCEL event is emitted and the transaction is considered canceled.
The problem I'm having is that sometimes I see on the logs that I receive the CANCEL event (meaning that the user has closed the popup) but on PayPal account the transaction is succesfull and correctly payed...
Is it possible that the user closes the popup just before paypal sends the confirmation back or something like that? Anyone knows how this can be handled?
Using the JS SDK alone is for very simple use cases. For an ecommerce site of any importance, the JS SDK should be combined with the v2/checkout/orders API. This way orders are always captured from the server and recorded when successful, and things happening on the client side won't be relevant nor interfere with accurate payment tracking.
Your question doesn't give technical details for your current integration, but here's how to go about making a correct one from scratch:
Use the v2/checkout/orders API and make two routes (url paths) on your server, one for 'Create Order' and one for 'Capture Order'. You could use one of the (recently deprecated) Checkout-*-SDKs for the routes' API calls to PayPal, or your own HTTPS implementation of first getting an access token and then doing the call. Both of these routes should return/output 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 reserving product or sending an email) immediately before forwarding 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 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.
i usually use the standard POST form on my site, with fields that the user fills out, which POSTs directly to https://www.paypal.com/cgi-bin/webscr
what i would like to do now, is have the form submit to my own site, for my own internal programming purposes, and when that is done, my site would automatically forward the user to paypal, with the relevant field data in the URL, for example, to: https://www.paypal.com/cgi-bin/webscr?first_name=foo&last_name=bar& etc...
this would save me from having to put the intermediate stage of the form with the hidden fields, asking the user to "click here to complete your transaction on PayPal"
hope i'm understood....
thanks!
Sure, it'll work. But keep in mind that unless you involve the BMCreateButton or Express Checkout API's, the amount will be open to URL manipulation, so you must do a check on the paid amount afterwards.
For example; https://www.paypal.com/cgi-bin/webscr?cmd=_xclick&business=blah#blah2.com&amount=0.99¤cy_code=GBP&item_name=Blah+for+sale
Note: The GET redirect must be initiated on the browser-side or via a header() redirect. You can't use cURL for this, since that's a server-to-server communication.
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 ?