Context:
I have to add an online payment system, on a quite old PHP 4 website (Yay !).
As usual, an external payment platform/gateway will be used.
After preparing an order on the website, that payment platform expects to be called with POST data, then displays its online payment page if everything is Ok.
Question:
Would it be a bad practice to autosubmit a form with a bunch of hidden fields, in order to switch to the payment platform?
It seems that I don't have the choice but I would like to know if someone sees a better way for that online payment platform integration.
Current workflow:
... last ordering step: order summary
user clicks on "order" (that button is already part of a form which action is an internal page)
results page (generally: order successfully saved, will be quickly processed, etc.)
The new detailed workflow would be:
... last ordering step: order summary
user clicks on "order" (that button is already part of a form which action is an internal page)
after existing internal processing, redirection to the "autosubmitted form" page
the autosubmit form submits itself (its action being the payment platform URL)
online payment...
result page
NB. I would add some "please click to order" button for users having Javascript disabled.
Thanks for any suggestions / thoughts. Or even telling that there should be no problem with this :)
Autosubmit a form with a bunch of hidden fields, in order to switch to the payment platform is ok. But you should pay much attention to security here, because intuder can modify those hidden fields.
Related
I've ran into a problem. Basically, I have a website that users can hire someone to tutor them. Each tutor has a small profile with a video, bio and rating. The user fills out a form with information such as their name, email and the most important one which is the date and timeslot (Dropdown) they want. When they fill out this information they can then click "Buy Now" which is a PayPal button I've setup. There are no variables here, each time slot is the same price all round.
The problem I'm having is I don't know how to collect the user information when the PayPal button is clicked. Can I pass this timeslot to PayPal who then return it to me? I can set up simple form that will send this information to me in an email, however I don't know how I can trigger that PHP script when the PayPal buy now button is pressed.
Any help? I've been Googling for a while, I can't seem to find anything! Maybe I'm wording it wrong. Anyway, hope you guys can assist.
I would save all of the info in your database prior to sending the user over to PayPal. That way you can include the invoice number (or record ID) in the invoice parameter in payment requests.
If you're working with Payments Standard the parameter is called invoice. If you're working with the Express Checkout API it's called INVNUM.
Hi you can use Ajax in this situation. The ajax will prevent the redirect of the form to paypal for awhile but executes another process in which you will save and capture the information of the form to your database. After the process the redirection to paypal payment method will continue.
You can view this good tutorial in here.
http://anytch.com/save-html-form-post-to-database-before-redirect-to-paypal/
I have a site that provides guide tours. Each tour has it owns price depending the people that will participate.
The user has to fill the form, then the server has to validate the form and then sent an email to the client and to the agent office with the details of the booked tour (preferred day, how many people etc) and then redirect the user to paypal to pay.
The problem is that the Buy now button that paypal provides has his own form with some hidden fields so two forms on same page.
I found tree solutions but I don't know what is best.
When user press submit, do the validation , send the emails and then redirect the user to a page that has a button that says something like 'Proceed to paying' that submits the paypal form with the giver price in the hidden fields
When the user press the submit button an ajax call been made at server to validate the form and send the emails and then on success submit the paypal form.
When user press submit, do the validation , send the emails and then the server submits the form to paypal
I am reading a couple of hours finding the best solution to this problem. What is the most secure , efficient and won't create problems to the user.
Sorry for my English
Assuming you have a fair knowledge of web development (since you are talking about forms, sessions, etc.), I'd recommend using PayPal Express Checkout APIs. What you are trying to do is very common. And here's how I would do it:
User enters tour information in a form on page-1, and hits the "submit" button.
Your server receives the call, validates the form and calls SetExpressCheckout with PAYMENTACTION set to "Authorization". This is just like "booking a hotel room" or a "rental car". You are just asking the user to authorize payment at this moment; not charging him yet.
The API returns you a token. You store this token along with tour information in your backend database; and mark this particular "booking" as say "booking request received".
You redirect the user to paypal.com (and pass that token in the URL) to "authorize" the payment.
Once the user completes authorization, paypal redirects the user to your website (the "success page" or the "return URL" as it's called in paypal terminology).
You update your database entry with the status say "payment authorized". At this point you email the user and the agent.
Agent validates and makes sure that there is still room available in the tour, etc. and let's you know that the user is all set.
At this point you call the DoCapture API using that token. This actually "captures" the payment. And you update the database entry with the status "payment processed". You can also send another email to the user confirming the payment and the booking.
At any stage if there's a drop off (say the user never completed authorization), you'd know from your database, and you can send a follow up email to the user. Or if he authorized but later the agent says there's no space on that particular tour, you could again follow up with the user for next available date, or void the payment, etc.
Yes, this means that it's "more coding"... but then you get "more flexibility" and hopefully you'll be able to reduce drop offs.
Hope this helps. Here's the documentation for express checkout: https://cms.paypal.com/cms_content/CA/en_US/files/developer/PP_ExpressCheckout_IntegrationGuide.pdf. There are Java, PHP, etc. SDKs available for this to help merchants integrate quickly.
You'd create sort of a confirmation page with all the values of the PayPal form but using <input type="hidden" balal /> rather than <input type="text" balal />
Try to break up the process instead of having the whole transaction sitting on that "Buy Now" button. Perhaps create a basic cart system on your website, then allow users to checkout which then will send the contents of their cart using hidden inputs to PayPal.
This way will allow you to match users to bookings.
I've built a web application and I am looking to integrate cardsave's direct payment API into the application. I was wondering if anyone had any advise on the best way to do this.
Cardsave provide standard code for integrating: Download Gateway Integration Pack ZIP file
When a payment is made I need to store the CrossPaymentsReference and payment amount in my database, the rest I will leave to cardsave's api I have thought of a couple of solutions which should potentially work:
1) Using Views for all of the code and on sucessful payment and use Ajax to update the database with the crossPaymentReference and payment amount on sucessfull completion, because it involves minimal editing of the code, but does have a minor security risk because it sends the reference at the client end.
2) Create a library with the payment system class, put the preprocess payments and process payment code into a controller and copy the form into a view, and just a have a small model to update the database on sucessfull payment's. (I'm guessing this is the best way.)
3) Edit everything and build an MVC version of the code
My latest project runs on CI 2.0. I’ve integrated a payment system such as Card Save with success (in my case I use Ogone, which is a Belgian company).
Below I’ve detailed a bit how I implemented the order and payment system.
The advice I can give you is the following.
Keep your products, orders and payments in separate tables.
Link products to orders via a reference table (don’t store e.g. a list of product ID’s in a field in the order)
Allow that a payment can only have one order, but an order can have multiple payments (but only one paid). This way when a payment fails (e.g. the user pressed cancel on Card Saves payment page), you can just create a new payment on your side and let the user retry (unless Card Save accepts that you do 2 payment request with the same payment ID).
Make a separate library (not controller) that handles successfully paid orders. This library would e.g. activate a subscription that the user bought, or make a work order for someone to ship the products. By keeping it in a separate library you can extend its functionality (e.g. if for a specific product you would need to do something new) without touching at your payment logic (thus preventing heavy retesting).
Generate hashes when posting data, or redirecting users to checkout pages, pages that prepare the payment and recalculate the hashes each time to prevent that someone tampered with the data you posted or that is in the URL.
Make sure everything works without AJAX and add AJAX afterwards.
Basically the ordering process I came up with is divided as follows:
User adds services (I don’t sell physical products) to basket (using a modified version of CI’s shopping cart)
When done user clicks “Order products” which does a POST to the controller Place_order. The controller Place_order does the following things:
Check if the user is still logged in (in my case everyone needs to register before)
Get the products that are in the shopping cart and checks if they actually exist in the database (you never know)
Create a new order in the database and add the products to the order in the DB
Place_order doesn’t output anything, but redirects the user on success to a controller Checkout. Here I don’t use POST. This way you can reuse the URL (e.g. if the user decides to stop, he can continue the payment later). The URL contains the order ID and a hash.
The Checkout controller does the following
Recalculate the hash to see if no one tampered with the URL
Check if the order exists and isn’t paid yet
Check if the order belongs to the user logged in
Create the payment if it doesn’t exist yet
Show a view with a button “Cancel order” and “Pay order”. This is actually a form that contains in a hidden field the payment ID and a hash of the payment ID.
When clicking “Pay order”, a POST is done to a controller Pay_order. I don’t use GET, because I want that users only come on this page by posting data that was set by the Checkout controller. If they use GET to come on the page an error is thrown. This controller does the following:
Recalculate the hash to see of no one tampered with the posted data
Check if the payment exists and is not yet paid
If all is OK, compose the view that contains the necessary info to be posted to the payment service
Show the view.
When the user presses “Go to payment service” all data is posted to Ogone where the user executes the payment
When the payment is completed (correct or not) Ogone redirects the user back to me to a controller Payment_successfull or Payment_other (for errors etc). In the Payment_succesfull I call a library Purchase_activator which takes the payment ID as input. This one looks up the order and activates the services the user just paid. In the other case (on error) the user is shown a view with the correct error message and an option to retry or cancel.
I have created a basket where a user can add to and update etc. This basket has been built based on what product the user adds to cart obviously. The product itself is grabbed from the database and displayed in a table in the basket. How do I use Paypal from here? I now want a button called 'pay' that the user can click and then it takes them to Paypal to pay. But I want the details of the items to be displayed in Paypal.
I have signed up to paypals web standard payment. Obviously I don't need their add to cart buttons since I have got my own cart. I think I just need the buy button but as mentioned, I am not sure how to get products over to Paypal.
Can somebody explain what I need to do please
This broad of a topic is generally best suited with a quick Google search. Basically, find a paypal form (perhaps through Paypal's button builder) and edit the form's values to suit your needs. This can be accomplished with php or javascript quite easily (PHP is a bit safer as it limits tampering). Then users send the form :)
You can also create a link such ashttps://www.paypal.com/cgi-bin/webscr?cmd=_xclick&business=$business which will do the same as the full form (add all of the fields you want to send, of course).
Give it a shot - if you have more specific questions, post back with clarifications.
I have a scenario where a user can input the amount he wants to be billed. I use buynow buttons that are created using code. Now in this case what what i had in mind was to:
Set minimum billing amount to 10$
If he enters below that, give error.
Set the amount of buynow button 10$ when form loads.
Once User inputs a number greater than 10 do an ajax request to controller
Check if their is a button saved in DB against that amount that was created earier on PayPal.
If button does not exist, create a new one on PayPal, save button in the DB.
Return the HTML of the newly created button
Replace the existing button with the returned HTML
Problem with this approach is that it might be too heavy. I also do not want to spread form over 2 pages. Are there any alternate and better options? Can i do some tweaks to make this option more robust?
A better option in this case would be to use the API and do the payments via either Express or Payments Pro. Essentially, you're trying to over-complicate this by making the buttons to the job of the API; getting the worst of both worlds in the process.
You could still utilize a "pay now" button graphic, but just submit your own request to the paypal express gateway (exactly what the button does for you) with a couple curl commands.
There are many tutorials available, but PayPal provides PHP code and a complete walkthrough on their site, so best, in my opinion, to go right to the source.
Log into PayPal -> Merchant Services -> Express Checkout
Under "Setting it up", you'll find all the implementation details.